From tobias.hartmann at oracle.com Tue Jul 1 06:57:05 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 01 Jul 2014 08:57:05 +0200 Subject: RFR(XS) 8046289: compiler/6340864/TestLongVect.java timeout with In-Reply-To: <53B18D19.2090702@oracle.com> References: <20140623130548.GC2514@rbackman> <20140630072605.GD2514@rbackman> <53B18D19.2090702@oracle.com> Message-ID: <53B25BC1.6030401@oracle.com> Hi, > Some background: Tobias and me have been looking at JDK-8014830 [1] > and JDK-8030976 fixed the problem. I suspect that this change will > return 8014830. I just tested the changes and the bug (JDK-8014830) appears again. The problem is that no uncommon trap is added after the first loop and therefore the second loop, especially the call to inc(), is not profiled. The compiler assumes that the call site is never executed and does not inline inc(). I agree with Vladimir that we should not special case loop exits but find a solution for the case were we only have limited or no profile information. Best, Tobias > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8014830 > > On 6/30/14 11:26 AM, Rickard B?ckman wrote: >> Reviews please? >> >> Thanks >> /R >> >> On 06/23, Rickard B?ckman wrote: >>> Hi, >>> >>> a test started to timeout after JDK-8030976 was pushed. The test was >>> run >>> with -Xcomp flag, so the profiling data available is non-existing or >>> small. For some cases that meant that if a loop had at least 1 >>> iteration >>> executed it would look like the loop would always take the backedge and >>> never end and we would generate an uncommon trap on the loop exit. >>> >>> The small change checks if the block we are considering turning into an >>> uncommon trap is a loop exit. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046289 >>> Webrev: http://cr.openjdk.java.net/~rbackman/8046289/ >>> >>> Thanks >>> /R >> >> From roland.westrelin at oracle.com Tue Jul 1 08:46:51 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 1 Jul 2014 10:46:51 +0200 Subject: [9] RFR (XXS): 8048703: ReplacedNodes dumps it's content to tty In-Reply-To: <53B17299.2090301@oracle.com> References: <53B17299.2090301@oracle.com> Message-ID: > http://cr.openjdk.java.net/~vlivanov/8048703/webrev.00/ In case you need another review: that looks good to me. Roland. From vladimir.x.ivanov at oracle.com Tue Jul 1 09:18:50 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 01 Jul 2014 13:18:50 +0400 Subject: [9] RFR (XXS): 8048703: ReplacedNodes dumps it's content to tty In-Reply-To: <69EF73CA-44EA-4241-8B50-D09536C1278A@oracle.com> References: <53B17299.2090301@oracle.com> <69EF73CA-44EA-4241-8B50-D09536C1278A@oracle.com> Message-ID: <53B27CFA.5010606@oracle.com> David, Igor, thanks for review! Best regards, Vladimir Ivanov On 7/1/14 2:08 AM, Igor Veresov wrote: > Good. > > igor > > On Jun 30, 2014, at 7:22 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8048703/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8048703 >> >> ReplacedNodes::dump prints it's content to the console, but it should use caller-specified stream instead. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Tue Jul 1 09:26:38 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 01 Jul 2014 13:26:38 +0400 Subject: [9] RFR (XXS): 8048703: ReplacedNodes dumps it's content to tty In-Reply-To: References: <53B17299.2090301@oracle.com> Message-ID: <53B27ECE.80703@oracle.com> Thanks, Roland. Best regards, Vladimir Ivanov On 7/1/14 12:46 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~vlivanov/8048703/webrev.00/ > > In case you need another review: that looks good to me. > > Roland. > From tobias.hartmann at oracle.com Tue Jul 1 10:48:09 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 01 Jul 2014 12:48:09 +0200 Subject: [9] RFR(S): 8048721: -XX:+PrintCompilation prints negative bci for non entrant OSR methods Message-ID: <53B291E9.3030508@oracle.com> Hi, please review the following patch for JDK-8048721. Bug: https://bugs.openjdk.java.net/browse/JDK-8048721 Webrev: http://cr.openjdk.java.net/~thartmann/8048721/webrev.00/ *Problem* The VM option -XX:+PrintCompilation prints a negative bytecode index for not entrant OSR nmethods. The problem is that in nmethod::make_not_entrant_or_zombie(..) the _entry_bci is invalidated (i.e. set to InvalidOSREntryBci == -2) by invalidate_osr_method(..) and log_state_change(..) is called afterwards, printing the invalidated entry. *Solution *Because reordering the methods in nmethod::make_not_entrant_or_zombie(..) is not easily possible due to thread safety, I changed the implementation log_state_change(..) and dependent methods to take the entry bci as parameter. The entry bci is saved prior to invalidation and used for printing afterwards. *Testing* JPRT Thanks, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Tue Jul 1 12:02:30 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 01 Jul 2014 16:02:30 +0400 Subject: [9] RFR(S): 8048721: -XX:+PrintCompilation prints negative bci for non entrant OSR methods In-Reply-To: <53B291E9.3030508@oracle.com> References: <53B291E9.3030508@oracle.com> Message-ID: <53B2A356.4080200@oracle.com> (widening audience to Runtime folks) I don't think it's good to lose bci for OSR methods after nmethod invalidation. Regarding current invalidation logic, I don't see that "_entry_bci = InvalidOSREntryBci" is required to invalidate OSR nmethods. Yes, interpreter does "_entry_bci != InvalidOSREntryBci" check before calling OSR nmethod, but _entry_bci update isn't properly synchronized between invalidating and querying threads (no locks or memory barriers involved). So I have a question is it safe to remove "_entry_bci = InvalidOSREntryBci". Both OSR nmethod lookup (InstanceKlass::lookup_osr_nmethod) and removal (InstanceKlass::remove_osr_nmethod) synchronize on OsrList_lock, so after removal OSR nmethod can't be looked up. What bothers me is the following null check before removal: void nmethod::invalidate_osr_method() { if (method() != NULL) method()->method_holder()->remove_osr_nmethod(this); Under what conditions nmethod with _method == NULL can be invalidated? Or is it just defensive coding? We set _method to NULL only for zombie nmethods (see nmethod::make_not_entrant_or_zombie) and they are already invalidated at that point. Best regards, Vladimir Ivanov On 7/1/14 2:48 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch for JDK-8048721. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048721 > Webrev: http://cr.openjdk.java.net/~thartmann/8048721/webrev.00/ > > *Problem* > The VM option -XX:+PrintCompilation prints a negative bytecode index for > not entrant OSR nmethods. The problem is that in > nmethod::make_not_entrant_or_zombie(..) the _entry_bci is invalidated > (i.e. set to InvalidOSREntryBci == -2) by invalidate_osr_method(..) and > log_state_change(..) is called afterwards, printing the invalidated entry. > > *Solution > *Because reordering the methods in > nmethod::make_not_entrant_or_zombie(..) is not easily possible due to > thread safety, I changed the implementation log_state_change(..) and > dependent methods to take the entry bci as parameter. The entry bci is > saved prior to invalidation and used for printing afterwards. > > *Testing* > JPRT > > Thanks, > Tobias From tobias.hartmann at oracle.com Wed Jul 2 06:08:49 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 02 Jul 2014 08:08:49 +0200 Subject: [9] RFR(S): 8022968: Some codecache allocation failures don't result in invoking the sweeper In-Reply-To: <53AAD4A0.3040406@oracle.com> References: <53AAD4A0.3040406@oracle.com> Message-ID: <53B3A1F1.3070500@oracle.com> Hi, can I have reviews, please? Thanks, Tobias On 25.06.2014 15:54, Tobias Hartmann wrote: > Hi, > > please review the following patch for JDK-8022968. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8022968 > Webrev: http://cr.openjdk.java.net/~thartmann/8022968/webrev.00/ > > *Problem* > Some code cache allocation failures are not handled appropriately by > either calling CompileBroker::handle_full_code_cache() to stop > compilation and invoke the sweeper or terminating the VM. An > allocation failure in AbstractICache::initialize(..) would even lead > to a segmentation fault in the CodeBuffer constructor. > > *Solution* > Add calls to CompileBroker::handle_full_code_cache() or fail > gracefully where necessary. > > *Testing* > JPRT > > Thanks, > Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Wed Jul 2 08:53:05 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 2 Jul 2014 10:53:05 +0200 Subject: RFR(S): 8046542: [I.finalize() calls from methods compiled by C1 do not cause IllegalAccessError on Sparc In-Reply-To: <29A4E13F-AD4C-4AF0-BA84-5A8364398D8F@oracle.com> References: <58DA19A1-1D3F-42FE-939D-2766C450BFAA@oracle.com> <29A4E13F-AD4C-4AF0-BA84-5A8364398D8F@oracle.com> Message-ID: > It seems reasonable. Could you please add a comment similar to your explanation below to the resolve_vtable_index() call and the optimize_virtual_call() ones? Thanks for the review, Igor. What about these comments? http://cr.openjdk.java.net/~roland/8046542/webrev.01/ Roland. > > igor > > On Jun 18, 2014, at 6:13 AM, Roland Westrelin wrote: > >> The bug occurs with UseInlineCaches off (default on ultra sparc T machines). The calls are then compiled to vtable calls rather than ic calls. The logic that does the call resolution in c1 allows the call to finalize() with a receiver of type array in vtable calls. It shouldn?t. In the current code, the vtable index lookup is done on the Object type obtained from the array type by a call to ciEnv::get_instance_klass_for_declared_method_holder() which is why the finalize() call is allowed to proceed. The fix I propose uses the initial type for the vtable index lookup. As a consequence a small subset of methods (at least Object.clone()) called on arrays won?t be compiled as vtable calls but as ic calls which I think is a minor issue. >> >> A similar problem exists with c2: it allows inlining of the finalize() call on an array. I changed Compile::optimize_inlining() so that the finalize method is filtered out. With this bug fix, the same problem with vtable calls to finalize() exist so I applied the fix I used for c1 to c2. >> >> http://cr.openjdk.java.net/~roland/8046542/webrev.00/ >> >> Roland. >> > From roland.westrelin at oracle.com Wed Jul 2 15:26:19 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 2 Jul 2014 17:26:19 +0200 Subject: RFR (L): 7173584: Implement arraycopy as a macro node In-Reply-To: <539B7EEE.3030409@oracle.com> References: <9CAF8242-736B-4B8B-8926-3451DA87AF70@oracle.com> <5064AF8B.1090509@oracle.com> <317A0474-32A8-4C0C-8668-FA2682B4E815@oracle.com> <5069E3DD.6090401@oracle.com> <125CB7F4-DD68-4E29-A6AC-CA2F9117B410@oracle.com> <539B7EEE.3030409@oracle.com> Message-ID: <7E38E57B-6091-42CC-9EA7-E6CFA09B68B4@oracle.com> Thanks for the review, Vladimir. See comments inlined: >> Here is a new webrev for this after a long time: >> >> http://cr.openjdk.java.net/~roland/7173584/webrev.03/ > > Looks reasonable. > >> >> This addresses the comments below (replies inlined): >> >>> I don't think you need suffix "_any_phase" in the name gen_subtype_check_any_phase(). Just add comment that it is also used in phase Macro. Generally speaking GraphKit class is wrong place for it. May be it should be in base class Phase but keep the code in graphKit.cpp file. >>> >>> You don't need special gvn_transform(). It is already done since Macro phase sets gvn._delay_transform flag to true and: >>> >>> Node *PhaseIterGVN::transform( Node *n ) { >>> if (_delay_transform) { >>> // Register the node but don't optimize for now >>> register_new_node_with_optimizer(n); >>> return n; >>> } >>> >>> gvn_transform_ctrl() should remain to be record_for_igvn() but virtual as you suggested. >> >> BTW, is it required that transform_ctrl() does nothing for PhaseIterGVN? Or is it simply that it is a waste of resources to process a Region node, for instance, before its inputs? > > + gvn->transform(iff); > + if (!bol->is_Con()) gvn->transform_ctrl(iff); > > During Parse record_for_igvn() puts nodes on worklist which will populate initial igvn._worklist. register_new_node_with_optimizer(n) does that already when IGVN transformation is delayed. So PhaseIterGVN::transform() will do what record_for_igvn() does. > > transform_ctrl() is not good name. record_for_igvn() is very good. Why not use it? > > phaseX.hpp > > + virtual void record_for_igvn(Node *n) { > + C->record_for_igvn(n); > + } Ok. And: virtual void record_for_igvn(Node *n) { } for PhaseIterGVN? >>> It would be also nice to factor out IfNode creation into separate method (it used 5 times): >>> >>> + Node* cmp = gvn_transform(new(C, 3) CmpPNode(subklass, superklass), gvn); >>> + Node* bol = gvn_transform(new(C, 2) BoolNode(cmp, BoolTest::eq), gvn); >>> + IfNode* iff = new (C, 2) IfNode(*ctrl, bol, PROB_STATIC_FREQUENT, COUNT_UNKNOWN) >>> + gvn_transform(iff, gvn); >>> + if (!bol->is_Con()) gvn_transform_ctrl(iff, gvn); >>> >>> >>> Next optimization belongs to ConvI2LNode::Value(). May be we should not widen type in ConvI2LNode::Ideal() and Value() if input is singleton (constant). >>> >>> + Node *chk_off_X = LP64_ONLY(NULL) NOT_LP64(chk_off); >>> +#ifdef _LP64 >>> + jint chk_off_con = gvn->find_int_con(chk_off, Type::OffsetBot); >>> + if (chk_off_con != Type::OffsetBot) { >>> + chk_off_X = gvn->longcon((jlong) chk_off_con); >>> + } else { >>> + chk_off_X = gvn_transform(new (C, 2) ConvI2LNode(chk_off), gvn); >>> + } >>> +#endif >> >> I removed this and didn?t make any change to ConvI2LNode::Value() and ConvI2LNode::Ideal(). >> The widening uses MAX2((jlong)in_type->_lo, lo1), MIN2((jlong)in_type->_hi, hi1) as new bounds. If the input is constant and falls within [lo1, hi1] then the result is [(jlong)in_type->_lo, (jlong)in_type->_hi] which is constant. Only if the input is constant and doesn?t fall within [lo1, hi1] would there be a problem. But this inconsistency between the ConvI2L and its input is unexpected, right? It doesn?t seem to ever happen in practice. > > It happens. ConvI2L node is usually generated after range check of array index and its type is set to [0,arr.length]. Nothing prevents to have negative constant as index. The array access will not be executed then but ConvI2L's and input's types may not overlap. But then the load is control dependent on the range check, the ConvI2L is input to the load. If the index is a constant that doesn?t fit in the range, only the branch of the range check that fails is kept, the load is eliminated and so is the ConvI2L? FWIW, I ran a bunch of tests with this debug code: diff --git a/src/share/vm/opto/phaseX.cpp b/src/share/vm/opto/phaseX.cpp --- a/src/share/vm/opto/phaseX.cpp +++ b/src/share/vm/opto/phaseX.cpp @@ -1049,7 +1049,12 @@ set_type_bottom(n); } - return transform_old(n); + bool is_constant = n->Opcode() == Op_ConvI2L && n->in(1) && type(n->in(1))->is_int()->is_con(); + Node* res = transform_old(n); + if (is_constant && !type(res)->is_long()->is_con()) { + fatal("XXXXXXXXXXXX"); + } + return res; } Node *PhaseIterGVN::transform_old(Node* n) { and it never failed. Roland. > > Vladimir > >> >> ConvI2LNode::Value() computes the type with tl = tl->filter(_type) so if the input is constant, the result is constant as well unless tl and _type are disjoint. Why would that happen? >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> >>> Roland Westrelin wrote: >>>>> Also instead of duplicating gen_subtype_check() in macroArrayCopy.cpp can you modify the original one to work for you (by passing additional flag)? >>>> This (on top of previous webrev - I've done only minimal testing)? >>>> http://cr.openjdk.java.net/~roland/7173584/webrev.02/ >>>> Or do we want gvn_transform/gvn_transform_ctrl to be virtual methods of PhaseGVN/PhaseIterGVN? >>>> Roland. From vladimir.x.ivanov at oracle.com Wed Jul 2 18:45:28 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 02 Jul 2014 22:45:28 +0400 Subject: RFR(S): 8046542: [I.finalize() calls from methods compiled by C1 do not cause IllegalAccessError on Sparc In-Reply-To: References: <58DA19A1-1D3F-42FE-939D-2766C450BFAA@oracle.com> <29A4E13F-AD4C-4AF0-BA84-5A8364398D8F@oracle.com> Message-ID: <53B45348.8080109@oracle.com> Roland, I'd add comment to the following change: ! callee->holder() == env()->Object_klass()) { ! callee->holder() == env()->Object_klass() && + callee->name() != ciSymbol::finalize_method_name()) { Otherwise, looks good. Best regards, Vladimir Ivanov On 7/2/14 12:53 PM, Roland Westrelin wrote: >> It seems reasonable. Could you please add a comment similar to your explanation below to the resolve_vtable_index() call and the optimize_virtual_call() ones? > > Thanks for the review, Igor. > > What about these comments? > http://cr.openjdk.java.net/~roland/8046542/webrev.01/ > > Roland. > >> >> igor >> >> On Jun 18, 2014, at 6:13 AM, Roland Westrelin wrote: >> >>> The bug occurs with UseInlineCaches off (default on ultra sparc T machines). The calls are then compiled to vtable calls rather than ic calls. The logic that does the call resolution in c1 allows the call to finalize() with a receiver of type array in vtable calls. It shouldn?t. In the current code, the vtable index lookup is done on the Object type obtained from the array type by a call to ciEnv::get_instance_klass_for_declared_method_holder() which is why the finalize() call is allowed to proceed. The fix I propose uses the initial type for the vtable index lookup. As a consequence a small subset of methods (at least Object.clone()) called on arrays won?t be compiled as vtable calls but as ic calls which I think is a minor issue. >>> >>> A similar problem exists with c2: it allows inlining of the finalize() call on an array. I changed Compile::optimize_inlining() so that the finalize method is filtered out. With this bug fix, the same problem with vtable calls to finalize() exist so I applied the fix I used for c1 to c2. >>> >>> http://cr.openjdk.java.net/~roland/8046542/webrev.00/ >>> >>> Roland. >>> >> > From igor.veresov at oracle.com Wed Jul 2 19:11:29 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 2 Jul 2014 12:11:29 -0700 Subject: RFR(S): 8046542: [I.finalize() calls from methods compiled by C1 do not cause IllegalAccessError on Sparc In-Reply-To: References: <58DA19A1-1D3F-42FE-939D-2766C450BFAA@oracle.com> <29A4E13F-AD4C-4AF0-BA84-5A8364398D8F@oracle.com> Message-ID: Roland, Thanks for the comments. It looks good. igor On Jul 2, 2014, at 1:53 AM, Roland Westrelin wrote: >> It seems reasonable. Could you please add a comment similar to your explanation below to the resolve_vtable_index() call and the optimize_virtual_call() ones? > > Thanks for the review, Igor. > > What about these comments? > http://cr.openjdk.java.net/~roland/8046542/webrev.01/ > > Roland. > >> >> igor >> >> On Jun 18, 2014, at 6:13 AM, Roland Westrelin wrote: >> >>> The bug occurs with UseInlineCaches off (default on ultra sparc T machines). The calls are then compiled to vtable calls rather than ic calls. The logic that does the call resolution in c1 allows the call to finalize() with a receiver of type array in vtable calls. It shouldn?t. In the current code, the vtable index lookup is done on the Object type obtained from the array type by a call to ciEnv::get_instance_klass_for_declared_method_holder() which is why the finalize() call is allowed to proceed. The fix I propose uses the initial type for the vtable index lookup. As a consequence a small subset of methods (at least Object.clone()) called on arrays won?t be compiled as vtable calls but as ic calls which I think is a minor issue. >>> >>> A similar problem exists with c2: it allows inlining of the finalize() call on an array. I changed Compile::optimize_inlining() so that the finalize method is filtered out. With this bug fix, the same problem with vtable calls to finalize() exist so I applied the fix I used for c1 to c2. >>> >>> http://cr.openjdk.java.net/~roland/8046542/webrev.00/ >>> >>> Roland. >>> >> > From roland.westrelin at oracle.com Wed Jul 2 20:50:56 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 2 Jul 2014 22:50:56 +0200 Subject: RFR(S): 8046542: [I.finalize() calls from methods compiled by C1 do not cause IllegalAccessError on Sparc In-Reply-To: <53B45348.8080109@oracle.com> References: <58DA19A1-1D3F-42FE-939D-2766C450BFAA@oracle.com> <29A4E13F-AD4C-4AF0-BA84-5A8364398D8F@oracle.com> <53B45348.8080109@oracle.com> Message-ID: <2FF99563-D4E6-4318-A478-C9A1E5C116A0@oracle.com> > I'd add comment to the following change: > ! callee->holder() == env()->Object_klass()) { > ! callee->holder() == env()->Object_klass() && > + callee->name() != ciSymbol::finalize_method_name()) { > > Otherwise, looks good. Thanks for the review. I will add a comment before I push this. Roland. > > Best regards, > Vladimir Ivanov > > On 7/2/14 12:53 PM, Roland Westrelin wrote: >>> It seems reasonable. Could you please add a comment similar to your explanation below to the resolve_vtable_index() call and the optimize_virtual_call() ones? >> >> Thanks for the review, Igor. >> >> What about these comments? >> http://cr.openjdk.java.net/~roland/8046542/webrev.01/ >> >> Roland. >> >>> >>> igor >>> >>> On Jun 18, 2014, at 6:13 AM, Roland Westrelin wrote: >>> >>>> The bug occurs with UseInlineCaches off (default on ultra sparc T machines). The calls are then compiled to vtable calls rather than ic calls. The logic that does the call resolution in c1 allows the call to finalize() with a receiver of type array in vtable calls. It shouldn?t. In the current code, the vtable index lookup is done on the Object type obtained from the array type by a call to ciEnv::get_instance_klass_for_declared_method_holder() which is why the finalize() call is allowed to proceed. The fix I propose uses the initial type for the vtable index lookup. As a consequence a small subset of methods (at least Object.clone()) called on arrays won?t be compiled as vtable calls but as ic calls which I think is a minor issue. >>>> >>>> A similar problem exists with c2: it allows inlining of the finalize() call on an array. I changed Compile::optimize_inlining() so that the finalize method is filtered out. With this bug fix, the same problem with vtable calls to finalize() exist so I applied the fix I used for c1 to c2. >>>> >>>> http://cr.openjdk.java.net/~roland/8046542/webrev.00/ >>>> >>>> Roland. >>>> >>> >> From igor.veresov at oracle.com Wed Jul 2 21:11:07 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 2 Jul 2014 14:11:07 -0700 Subject: [9] RFR(S): 8022968: Some codecache allocation failures don't result in invoking the sweeper In-Reply-To: <53B3A1F1.3070500@oracle.com> References: <53AAD4A0.3040406@oracle.com> <53B3A1F1.3070500@oracle.com> Message-ID: <3144C6A1-BA5F-417F-BA90-DB2EEA14A3B1@oracle.com> Looks alright. igor On Jul 1, 2014, at 11:08 PM, Tobias Hartmann wrote: > Hi, > > can I have reviews, please? > > Thanks, > Tobias > > On 25.06.2014 15:54, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch for JDK-8022968. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8022968 >> Webrev: http://cr.openjdk.java.net/~thartmann/8022968/webrev.00/ >> >> Problem >> Some code cache allocation failures are not handled appropriately by either calling CompileBroker::handle_full_code_cache() to stop compilation and invoke the sweeper or terminating the VM. An allocation failure in AbstractICache::initialize(..) would even lead to a segmentation fault in the CodeBuffer constructor. >> >> Solution >> Add calls to CompileBroker::handle_full_code_cache() or fail gracefully where necessary. >> >> Testing >> JPRT >> >> Thanks, >> Tobias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Wed Jul 2 21:13:58 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 03 Jul 2014 01:13:58 +0400 Subject: [9] RFR(S): 8022968: Some codecache allocation failures don't result in invoking the sweeper In-Reply-To: <53B3A1F1.3070500@oracle.com> References: <53AAD4A0.3040406@oracle.com> <53B3A1F1.3070500@oracle.com> Message-ID: <53B47616.4020606@oracle.com> Good. Best regards, Vladimir Ivanov On 7/2/14 10:08 AM, Tobias Hartmann wrote: > Hi, > > can I have reviews, please? > > Thanks, > Tobias > > On 25.06.2014 15:54, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch for JDK-8022968. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8022968 >> Webrev: http://cr.openjdk.java.net/~thartmann/8022968/webrev.00/ >> >> *Problem* >> Some code cache allocation failures are not handled appropriately by >> either calling CompileBroker::handle_full_code_cache() to stop >> compilation and invoke the sweeper or terminating the VM. An >> allocation failure in AbstractICache::initialize(..) would even lead >> to a segmentation fault in the CodeBuffer constructor. >> >> *Solution* >> Add calls to CompileBroker::handle_full_code_cache() or fail >> gracefully where necessary. >> >> *Testing* >> JPRT >> >> Thanks, >> Tobias > From tobias.hartmann at oracle.com Thu Jul 3 06:44:35 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 03 Jul 2014 08:44:35 +0200 Subject: [9] RFR(S): 8022968: Some codecache allocation failures don't result in invoking the sweeper In-Reply-To: <53B47616.4020606@oracle.com> References: <53AAD4A0.3040406@oracle.com> <53B3A1F1.3070500@oracle.com> <53B47616.4020606@oracle.com> Message-ID: <53B4FBD3.6040608@oracle.com> Igor, Vladimir, thanks for the reviews. Best, Tobias On 02.07.2014 23:13, Vladimir Ivanov wrote: > Good. > > Best regards, > Vladimir Ivanov > > On 7/2/14 10:08 AM, Tobias Hartmann wrote: >> Hi, >> >> can I have reviews, please? >> >> Thanks, >> Tobias >> >> On 25.06.2014 15:54, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch for JDK-8022968. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8022968 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8022968/webrev.00/ >>> >>> *Problem* >>> Some code cache allocation failures are not handled appropriately by >>> either calling CompileBroker::handle_full_code_cache() to stop >>> compilation and invoke the sweeper or terminating the VM. An >>> allocation failure in AbstractICache::initialize(..) would even lead >>> to a segmentation fault in the CodeBuffer constructor. >>> >>> *Solution* >>> Add calls to CompileBroker::handle_full_code_cache() or fail >>> gracefully where necessary. >>> >>> *Testing* >>> JPRT >>> >>> Thanks, >>> Tobias >> From rickard.backman at oracle.com Thu Jul 3 12:37:39 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Thu, 3 Jul 2014 14:37:39 +0200 Subject: RFR(XS) 8046289: compiler/6340864/TestLongVect.java timeout with In-Reply-To: <53B25BC1.6030401@oracle.com> References: <20140623130548.GC2514@rbackman> <20140630072605.GD2514@rbackman> <53B18D19.2090702@oracle.com> <53B25BC1.6030401@oracle.com> Message-ID: <20140703123739.GA7808@rbackman> Vladimir, Tobias I've looked into something that tries to find out when we have "good enough" profiling information. Since the bug I've been working on only happens with the -Xcomp flag, I've tried to special case that instead so that we don't put uncommon traps when running with -Xcomp since the profiling information usually is pretty bad. Updated webrev: http://cr.openjdk.java.net/~rbackman/8046289.3/ Thanks /R On 07/01, Tobias Hartmann wrote: > Hi, > > >Some background: Tobias and me have been looking at JDK-8014830 > >[1] and JDK-8030976 fixed the problem. I suspect that this change > >will return 8014830. > > I just tested the changes and the bug (JDK-8014830) appears again. > The problem is that no uncommon trap is added after the first loop > and therefore the second loop, especially the call to inc(), is not > profiled. The compiler assumes that the call site is never executed > and does not inline inc(). > > I agree with Vladimir that we should not special case loop exits but > find a solution for the case were we only have limited or no profile > information. > > Best, > Tobias > > > > >Best regards, > >Vladimir Ivanov > > > >[1] https://bugs.openjdk.java.net/browse/JDK-8014830 > > > >On 6/30/14 11:26 AM, Rickard B?ckman wrote: > >>Reviews please? > >> > >>Thanks > >>/R > >> > >>On 06/23, Rickard B?ckman wrote: > >>>Hi, > >>> > >>>a test started to timeout after JDK-8030976 was pushed. The > >>>test was run > >>>with -Xcomp flag, so the profiling data available is non-existing or > >>>small. For some cases that meant that if a loop had at least 1 > >>>iteration > >>>executed it would look like the loop would always take the backedge and > >>>never end and we would generate an uncommon trap on the loop exit. > >>> > >>>The small change checks if the block we are considering turning into an > >>>uncommon trap is a loop exit. > >>> > >>>Bug: https://bugs.openjdk.java.net/browse/JDK-8046289 > >>>Webrev: http://cr.openjdk.java.net/~rbackman/8046289/ > >>> > >>>Thanks > >>>/R > >> > >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From rednaxelafx at gmail.com Thu Jul 3 23:04:53 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 3 Jul 2014 16:04:53 -0700 Subject: Accessing runtime directly in LibraryCallKit without going through ci Message-ID: Hi everyone, I just came across this piece of code in C2 LibraryCallKit: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/39bac689e998/src/share/vm/opto/library_call.cpp#l435 433: case vmIntrinsics::_getCallerClass: 434: if (!InlineReflectionGetCallerClass) return NULL; 435: if (SystemDictionary::reflect_CallerSensitive_klass() == NULL) return NULL; 436: break; Line 435 is accessing the runtime (SystemDictionary) directly without going through ci. Apparently it runs "okay" in current HotSpot. But as a convention, should it be changed to go through ci? i.e. if (C->env()->reflect_CallerSensitive_klass() == NULL) return NULL; Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Jul 4 06:50:53 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 04 Jul 2014 08:50:53 +0200 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist Message-ID: <53B64ECD.3060300@oracle.com> Hi, please review the following patch for 8040213 that finishes Vladimir's work [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8040213 Webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.00/ * **Problem* Not all nodes that are modified during C2 optimization are put on the IGVN worklist. *Solution* Verification code is added that checks if (i) modified nodes are put on the IGVN worklist and (ii) modified nodes are processed by PhaseIterGVN::transform_old(..). All code that fails verification during testing is fixed. * **Testing:* - JPRT - Full CTW - Nashorn + Octane - UTE (full testlist, BigApps, JRuby) - VM (NSK) testbase - Refworkload (reference_server) - VMSQE.adhoc.JPRT.full batch Thanks, Tobias [1] http://cr.openjdk.java.net/~kvn/8040213/webrev/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Mon Jul 7 15:49:33 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 07 Jul 2014 19:49:33 +0400 Subject: RFR(XS) 8046289: compiler/6340864/TestLongVect.java timeout with In-Reply-To: <20140703123739.GA7808@rbackman> References: <20140623130548.GC2514@rbackman> <20140630072605.GD2514@rbackman> <53B18D19.2090702@oracle.com> <53B25BC1.6030401@oracle.com> <20140703123739.GA7808@rbackman> Message-ID: <53BAC18D.8030205@oracle.com> Looks good. Best regards, Vladimir Ivanov On 7/3/14 4:37 PM, Rickard B?ckman wrote: > Vladimir, Tobias > > I've looked into something that tries to find out when we have "good > enough" profiling information. Since the bug I've been working on only > happens with the -Xcomp flag, I've tried to special case that instead so > that we don't put uncommon traps when running with -Xcomp since the > profiling information usually is pretty bad. > > Updated webrev: http://cr.openjdk.java.net/~rbackman/8046289.3/ > > Thanks > /R > > On 07/01, Tobias Hartmann wrote: >> Hi, >> >>> Some background: Tobias and me have been looking at JDK-8014830 >>> [1] and JDK-8030976 fixed the problem. I suspect that this change >>> will return 8014830. >> >> I just tested the changes and the bug (JDK-8014830) appears again. >> The problem is that no uncommon trap is added after the first loop >> and therefore the second loop, especially the call to inc(), is not >> profiled. The compiler assumes that the call site is never executed >> and does not inline inc(). >> >> I agree with Vladimir that we should not special case loop exits but >> find a solution for the case were we only have limited or no profile >> information. >> >> Best, >> Tobias >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8014830 >>> >>> On 6/30/14 11:26 AM, Rickard B?ckman wrote: >>>> Reviews please? >>>> >>>> Thanks >>>> /R >>>> >>>> On 06/23, Rickard B?ckman wrote: >>>>> Hi, >>>>> >>>>> a test started to timeout after JDK-8030976 was pushed. The >>>>> test was run >>>>> with -Xcomp flag, so the profiling data available is non-existing or >>>>> small. For some cases that meant that if a loop had at least 1 >>>>> iteration >>>>> executed it would look like the loop would always take the backedge and >>>>> never end and we would generate an uncommon trap on the loop exit. >>>>> >>>>> The small change checks if the block we are considering turning into an >>>>> uncommon trap is a loop exit. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046289 >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8046289/ >>>>> >>>>> Thanks >>>>> /R >>>> >>>> >> From igor.veresov at oracle.com Mon Jul 7 16:56:47 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 7 Jul 2014 09:56:47 -0700 Subject: RFR(XS) 8046289: compiler/6340864/TestLongVect.java timeout with In-Reply-To: <20140703123739.GA7808@rbackman> References: <20140623130548.GC2514@rbackman> <20140630072605.GD2514@rbackman> <53B18D19.2090702@oracle.com> <53B25BC1.6030401@oracle.com> <20140703123739.GA7808@rbackman> Message-ID: This looks alright. igor On Jul 3, 2014, at 5:37 AM, Rickard B?ckman wrote: > Vladimir, Tobias > > I've looked into something that tries to find out when we have "good > enough" profiling information. Since the bug I've been working on only > happens with the -Xcomp flag, I've tried to special case that instead so > that we don't put uncommon traps when running with -Xcomp since the > profiling information usually is pretty bad. > > Updated webrev: http://cr.openjdk.java.net/~rbackman/8046289.3/ > > Thanks > /R > > On 07/01, Tobias Hartmann wrote: >> Hi, >> >>> Some background: Tobias and me have been looking at JDK-8014830 >>> [1] and JDK-8030976 fixed the problem. I suspect that this change >>> will return 8014830. >> >> I just tested the changes and the bug (JDK-8014830) appears again. >> The problem is that no uncommon trap is added after the first loop >> and therefore the second loop, especially the call to inc(), is not >> profiled. The compiler assumes that the call site is never executed >> and does not inline inc(). >> >> I agree with Vladimir that we should not special case loop exits but >> find a solution for the case were we only have limited or no profile >> information. >> >> Best, >> Tobias >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8014830 >>> >>> On 6/30/14 11:26 AM, Rickard B?ckman wrote: >>>> Reviews please? >>>> >>>> Thanks >>>> /R >>>> >>>> On 06/23, Rickard B?ckman wrote: >>>>> Hi, >>>>> >>>>> a test started to timeout after JDK-8030976 was pushed. The >>>>> test was run >>>>> with -Xcomp flag, so the profiling data available is non-existing or >>>>> small. For some cases that meant that if a loop had at least 1 >>>>> iteration >>>>> executed it would look like the loop would always take the backedge and >>>>> never end and we would generate an uncommon trap on the loop exit. >>>>> >>>>> The small change checks if the block we are considering turning into an >>>>> uncommon trap is a loop exit. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046289 >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8046289/ >>>>> >>>>> Thanks >>>>> /R >>>> >>>> >> From rickard.backman at oracle.com Tue Jul 8 05:51:59 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 8 Jul 2014 07:51:59 +0200 Subject: RFR(XS) 8046289: compiler/6340864/TestLongVect.java timeout with In-Reply-To: References: <20140623130548.GC2514@rbackman> <20140630072605.GD2514@rbackman> <53B18D19.2090702@oracle.com> <53B25BC1.6030401@oracle.com> <20140703123739.GA7808@rbackman> Message-ID: <20140708055159.GA2217@rbackman> Thank you for the review. On 07/07, Igor Veresov wrote: > This looks alright. > > igor > > On Jul 3, 2014, at 5:37 AM, Rickard B?ckman wrote: > > > Vladimir, Tobias > > > > I've looked into something that tries to find out when we have "good > > enough" profiling information. Since the bug I've been working on only > > happens with the -Xcomp flag, I've tried to special case that instead so > > that we don't put uncommon traps when running with -Xcomp since the > > profiling information usually is pretty bad. > > > > Updated webrev: http://cr.openjdk.java.net/~rbackman/8046289.3/ > > > > Thanks > > /R > > > > On 07/01, Tobias Hartmann wrote: > >> Hi, > >> > >>> Some background: Tobias and me have been looking at JDK-8014830 > >>> [1] and JDK-8030976 fixed the problem. I suspect that this change > >>> will return 8014830. > >> > >> I just tested the changes and the bug (JDK-8014830) appears again. > >> The problem is that no uncommon trap is added after the first loop > >> and therefore the second loop, especially the call to inc(), is not > >> profiled. The compiler assumes that the call site is never executed > >> and does not inline inc(). > >> > >> I agree with Vladimir that we should not special case loop exits but > >> find a solution for the case were we only have limited or no profile > >> information. > >> > >> Best, > >> Tobias > >> > >>> > >>> Best regards, > >>> Vladimir Ivanov > >>> > >>> [1] https://bugs.openjdk.java.net/browse/JDK-8014830 > >>> > >>> On 6/30/14 11:26 AM, Rickard B?ckman wrote: > >>>> Reviews please? > >>>> > >>>> Thanks > >>>> /R > >>>> > >>>> On 06/23, Rickard B?ckman wrote: > >>>>> Hi, > >>>>> > >>>>> a test started to timeout after JDK-8030976 was pushed. The > >>>>> test was run > >>>>> with -Xcomp flag, so the profiling data available is non-existing or > >>>>> small. For some cases that meant that if a loop had at least 1 > >>>>> iteration > >>>>> executed it would look like the loop would always take the backedge and > >>>>> never end and we would generate an uncommon trap on the loop exit. > >>>>> > >>>>> The small change checks if the block we are considering turning into an > >>>>> uncommon trap is a loop exit. > >>>>> > >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046289 > >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8046289/ > >>>>> > >>>>> Thanks > >>>>> /R > >>>> > >>>> > >> > /R -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From rickard.backman at oracle.com Tue Jul 8 05:52:16 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 8 Jul 2014 07:52:16 +0200 Subject: RFR(XS) 8046289: compiler/6340864/TestLongVect.java timeout with In-Reply-To: <53BAC18D.8030205@oracle.com> References: <20140623130548.GC2514@rbackman> <20140630072605.GD2514@rbackman> <53B18D19.2090702@oracle.com> <53B25BC1.6030401@oracle.com> <20140703123739.GA7808@rbackman> <53BAC18D.8030205@oracle.com> Message-ID: <20140708055216.GB2217@rbackman> Thank you for the review. On 07/07, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 7/3/14 4:37 PM, Rickard B?ckman wrote: > >Vladimir, Tobias > > > >I've looked into something that tries to find out when we have "good > >enough" profiling information. Since the bug I've been working on only > >happens with the -Xcomp flag, I've tried to special case that instead so > >that we don't put uncommon traps when running with -Xcomp since the > >profiling information usually is pretty bad. > > > >Updated webrev: http://cr.openjdk.java.net/~rbackman/8046289.3/ > > > >Thanks > >/R > > > >On 07/01, Tobias Hartmann wrote: > >>Hi, > >> > >>>Some background: Tobias and me have been looking at JDK-8014830 > >>>[1] and JDK-8030976 fixed the problem. I suspect that this change > >>>will return 8014830. > >> > >>I just tested the changes and the bug (JDK-8014830) appears again. > >>The problem is that no uncommon trap is added after the first loop > >>and therefore the second loop, especially the call to inc(), is not > >>profiled. The compiler assumes that the call site is never executed > >>and does not inline inc(). > >> > >>I agree with Vladimir that we should not special case loop exits but > >>find a solution for the case were we only have limited or no profile > >>information. > >> > >>Best, > >>Tobias > >> > >>> > >>>Best regards, > >>>Vladimir Ivanov > >>> > >>>[1] https://bugs.openjdk.java.net/browse/JDK-8014830 > >>> > >>>On 6/30/14 11:26 AM, Rickard B?ckman wrote: > >>>>Reviews please? > >>>> > >>>>Thanks > >>>>/R > >>>> > >>>>On 06/23, Rickard B?ckman wrote: > >>>>>Hi, > >>>>> > >>>>>a test started to timeout after JDK-8030976 was pushed. The > >>>>>test was run > >>>>>with -Xcomp flag, so the profiling data available is non-existing or > >>>>>small. For some cases that meant that if a loop had at least 1 > >>>>>iteration > >>>>>executed it would look like the loop would always take the backedge and > >>>>>never end and we would generate an uncommon trap on the loop exit. > >>>>> > >>>>>The small change checks if the block we are considering turning into an > >>>>>uncommon trap is a loop exit. > >>>>> > >>>>>Bug: https://bugs.openjdk.java.net/browse/JDK-8046289 > >>>>>Webrev: http://cr.openjdk.java.net/~rbackman/8046289/ > >>>>> > >>>>>Thanks > >>>>>/R > >>>> > >>>> > >> /R -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From vladimir.x.ivanov at oracle.com Tue Jul 8 09:39:40 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 13:39:40 +0400 Subject: [9] RFR (XXS): 8049528: Method marked w/ @ForceInline isn't inlined with "executed < MinInliningThreshold times" message Message-ID: <53BBBC5C.7000802@oracle.com> http://cr.openjdk.java.net/~vlivanov/8049528/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8049528 There's a missing case for @ForceInline in InlineTree::should_not_inline, so sometimes inlining fails w/ "executed < MinInliningThreshold times". The fix is to add missed check. Testing: manual (no inlining failures in the log), octane (no regresssions). Thanks! Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue Jul 8 09:44:28 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 13:44:28 +0400 Subject: [9] RFR (XXS): 8049529: LogCompilation: annotate make_not_compilable with compilation level Message-ID: <53BBBD7C.90409@oracle.com> http://cr.openjdk.java.net/~vlivanov/8049529/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8049529 It is useful to know at what level method compilation is disabled. Right now, this info isn't dumped to the log. Before: After: No changes are needed in LogCompilation, since it doesn't care about make_not_{osr_}compilable tags now. I plan to address that in a separate change. Testing: manual. Thanks! Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue Jul 8 09:52:30 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 13:52:30 +0400 Subject: [9] RFR (S): 8049530: Provide descriptive failure reason for compilation tasks removed for the queue Message-ID: <53BBBF5E.6030005@oracle.com> http://cr.openjdk.java.net/~vlivanov/8049530/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8049530 Right now, failure message is empty for tasks removed from the queue before compilation is started. The fix is to add descriptive message when a stale task is removed or compilation is disabled. Testing: manual. Thanks! Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue Jul 8 09:56:34 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 13:56:34 +0400 Subject: [9] RFR (XS): 8049532: LogCompilation: C1: inlining tree is flat (no depth is stored) Message-ID: <53BBC052.3090500@oracle.com> http://cr.openjdk.java.net/~vlivanov/8049532/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8049532 There's a bug in C1 LogCompilation support which incorrectly dumps inlining tree into the log. The fix is to add missing parse tags. That's enough for LogCompilation tool to correctly reconstruct inlining tree for C1 compilation. Testing: manual. Thanks! Best regards, Vladimir Ivanov From roland.westrelin at oracle.com Tue Jul 8 10:05:26 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Jul 2014 12:05:26 +0200 Subject: [9] RFR (S): 8049530: Provide descriptive failure reason for compilation tasks removed for the queue In-Reply-To: <53BBBF5E.6030005@oracle.com> References: <53BBBF5E.6030005@oracle.com> Message-ID: > http://cr.openjdk.java.net/~vlivanov/8049530/webrev.00/ That looks good to me. Roland. From roland.westrelin at oracle.com Tue Jul 8 10:07:18 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Jul 2014 12:07:18 +0200 Subject: [9] RFR (XS): 8049532: LogCompilation: C1: inlining tree is flat (no depth is stored) In-Reply-To: <53BBC052.3090500@oracle.com> References: <53BBC052.3090500@oracle.com> Message-ID: > http://cr.openjdk.java.net/~vlivanov/8049532/webrev.00/ Would there be a way to execute the new code in LogParser only if the compilation is a c1 compilation? Roland. From roland.westrelin at oracle.com Tue Jul 8 10:07:54 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Jul 2014 12:07:54 +0200 Subject: [9] RFR (XXS): 8049529: LogCompilation: annotate make_not_compilable with compilation level In-Reply-To: <53BBBD7C.90409@oracle.com> References: <53BBBD7C.90409@oracle.com> Message-ID: <8AE0FBBD-458B-4B59-BB64-E11DE8400FDA@oracle.com> > http://cr.openjdk.java.net/~vlivanov/8049529/webrev.00/ That looks good to me. Roland. From roland.westrelin at oracle.com Tue Jul 8 12:15:36 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Jul 2014 14:15:36 +0200 Subject: [9] RFR (XXS): 8049528: Method marked w/ @ForceInline isn't inlined with "executed < MinInliningThreshold times" message In-Reply-To: <53BBBC5C.7000802@oracle.com> References: <53BBBC5C.7000802@oracle.com> Message-ID: <77A55B0B-ECA7-4DBB-9CA6-EDE7638A2523@oracle.com> > http://cr.openjdk.java.net/~vlivanov/8049528/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8049528 > > There's a missing case for @ForceInline in InlineTree::should_not_inline, so sometimes inlining fails w/ "executed < MinInliningThreshold times". > > The fix is to add missed check. > > Testing: manual (no inlining failures in the log), octane (no regresssions). Then: 259 if (!callee_method->force_inline()) { is useless. If it doesn?t affect performance why do we want to make that change? Isn?t there a risk that more inlining would exhaust the inlining budget and cause a performance degradation? Roland. From vladimir.x.ivanov at oracle.com Tue Jul 8 12:51:09 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 16:51:09 +0400 Subject: [9] RFR(S): 8048721: -XX:+PrintCompilation prints negative bci for non entrant OSR methods In-Reply-To: <53B2A356.4080200@oracle.com> References: <53B291E9.3030508@oracle.com> <53B2A356.4080200@oracle.com> Message-ID: <53BBE93D.802@oracle.com> Any thoughts about that? I still think "_entry_bci = InvalidOSREntryBci" is redundant. Best regards, Vladimir Ivanov On 7/1/14 4:02 PM, Vladimir Ivanov wrote: > (widening audience to Runtime folks) > > I don't think it's good to lose bci for OSR methods after nmethod > invalidation. > > Regarding current invalidation logic, I don't see that "_entry_bci = > InvalidOSREntryBci" is required to invalidate OSR nmethods. Yes, > interpreter does "_entry_bci != InvalidOSREntryBci" check before calling > OSR nmethod, but _entry_bci update isn't properly synchronized between > invalidating and querying threads (no locks or memory barriers involved). > > So I have a question is it safe to remove "_entry_bci = > InvalidOSREntryBci". > > Both OSR nmethod lookup (InstanceKlass::lookup_osr_nmethod) and removal > (InstanceKlass::remove_osr_nmethod) synchronize on OsrList_lock, so > after removal OSR nmethod can't be looked up. > > What bothers me is the following null check before removal: > void nmethod::invalidate_osr_method() { > if (method() != NULL) > method()->method_holder()->remove_osr_nmethod(this); > > Under what conditions nmethod with _method == NULL can be invalidated? > Or is it just defensive coding? > > We set _method to NULL only for zombie nmethods (see > nmethod::make_not_entrant_or_zombie) and they are already invalidated at > that point. > > Best regards, > Vladimir Ivanov > > On 7/1/14 2:48 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch for JDK-8048721. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048721 >> Webrev: http://cr.openjdk.java.net/~thartmann/8048721/webrev.00/ >> >> *Problem* >> The VM option -XX:+PrintCompilation prints a negative bytecode index for >> not entrant OSR nmethods. The problem is that in >> nmethod::make_not_entrant_or_zombie(..) the _entry_bci is invalidated >> (i.e. set to InvalidOSREntryBci == -2) by invalidate_osr_method(..) and >> log_state_change(..) is called afterwards, printing the invalidated >> entry. >> >> *Solution >> *Because reordering the methods in >> nmethod::make_not_entrant_or_zombie(..) is not easily possible due to >> thread safety, I changed the implementation log_state_change(..) and >> dependent methods to take the entry bci as parameter. The entry bci is >> saved prior to invalidation and used for printing afterwards. >> >> *Testing* >> JPRT >> >> Thanks, >> Tobias From vladimir.x.ivanov at oracle.com Tue Jul 8 13:10:59 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 17:10:59 +0400 Subject: [9] RFR (XXS): 8049528: Method marked w/ @ForceInline isn't inlined with "executed < MinInliningThreshold times" message In-Reply-To: <77A55B0B-ECA7-4DBB-9CA6-EDE7638A2523@oracle.com> References: <53BBBC5C.7000802@oracle.com> <77A55B0B-ECA7-4DBB-9CA6-EDE7638A2523@oracle.com> Message-ID: <53BBEDE3.10708@oracle.com> Roland, thanks for review. >> http://cr.openjdk.java.net/~vlivanov/8049528/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8049528 >> >> There's a missing case for @ForceInline in InlineTree::should_not_inline, so sometimes inlining fails w/ "executed < MinInliningThreshold times". >> >> The fix is to add missed check. >> >> Testing: manual (no inlining failures in the log), octane (no regresssions). > > Then: > 259 if (!callee_method->force_inline()) { > > is useless. Yes, you are right. Updated webrev in place. > If it doesn?t affect performance why do we want to make that change? Isn?t there a risk that more inlining would exhaust the inlining budget and cause a performance degradation? It doesn't affect performance on octane, but it can either improve or degrade performance w.r.t. our current inlining heuristics. More inlining could worsen the performance, but partial inlining of compiled lambda form chains could worsen it as well. For chains of @ForceInline methods, inlining decision should be taken either before inlining the chain or after. The whole chain should be either inlined as a whole or not inlined at all. What I want to fix with this change is to make @ForceInline consistent - the annotation should be always respected. For example, I saw noticeable performance improvement w/ this fix while prototyping alternative version of guardWithTest JSR292 combinator (which has larger bytecode size than default one). Unstable performance properties w.r.t. MethodHandle chains length already exists and this change doesn't worsen the situation, just makes the result more predictable. Best regards, Vladimir Ivanov > > Roland. > From vladimir.x.ivanov at oracle.com Tue Jul 8 13:52:45 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 17:52:45 +0400 Subject: [9] RFR (XS): 8049532: LogCompilation: C1: inlining tree is flat (no depth is stored) In-Reply-To: References: <53BBC052.3090500@oracle.com> Message-ID: <53BBF7AD.5090903@oracle.com> Roland, thanks for review. >> http://cr.openjdk.java.net/~vlivanov/8049532/webrev.00/ > > Would there be a way to execute the new code in LogParser only if the compilation is a c1 compilation? Good point. I thought about that, but taking into account 3 different configurations we have (Client VM, Server VM & Tiered VM), it's not trivial to reliably detect from the log what compiler was used. I'll add VM flavor detection in a separate change and then fix this change to limit newly added logic only for C1 compilations. Best regards, Vladimir Ivanov > > Roland. > From roland.westrelin at oracle.com Tue Jul 8 14:25:25 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Jul 2014 16:25:25 +0200 Subject: [9] RFR (XS): 8049532: LogCompilation: C1: inlining tree is flat (no depth is stored) In-Reply-To: <53BBF7AD.5090903@oracle.com> References: <53BBC052.3090500@oracle.com> <53BBF7AD.5090903@oracle.com> Message-ID: > I'll add VM flavor detection in a separate change and then fix this change to limit newly added logic only for C1 compilations. That sounds good. The fix is good to me. Roland. From roland.westrelin at oracle.com Tue Jul 8 16:39:26 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Jul 2014 18:39:26 +0200 Subject: [9] RFR (XXS): 8049528: Method marked w/ @ForceInline isn't inlined with "executed < MinInliningThreshold times" message In-Reply-To: <53BBEDE3.10708@oracle.com> References: <53BBBC5C.7000802@oracle.com> <77A55B0B-ECA7-4DBB-9CA6-EDE7638A2523@oracle.com> <53BBEDE3.10708@oracle.com> Message-ID: >> If it doesn?t affect performance why do we want to make that change? Isn?t there a risk that more inlining would exhaust the inlining budget and cause a performance degradation? > It doesn't affect performance on octane, but it can either improve or degrade performance w.r.t. our current inlining heuristics. More inlining could worsen the performance, but partial inlining of compiled lambda form chains could worsen it as well. > > For chains of @ForceInline methods, inlining decision should be taken either before inlining the chain or after. The whole chain should be either inlined as a whole or not inlined at all. > > What I want to fix with this change is to make @ForceInline consistent - the annotation should be always respected. > > For example, I saw noticeable performance improvement w/ this fix while prototyping alternative version of guardWithTest JSR292 combinator (which has larger bytecode size than default one). > > Unstable performance properties w.r.t. MethodHandle chains length already exists and this change doesn't worsen the situation, just makes the result more predictable. Why not make a similar change to InlineTree::should_inline()? Shouldn?t it always return true if callee_method->force_inline() is true? Roland. From vladimir.x.ivanov at oracle.com Tue Jul 8 19:06:14 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Jul 2014 23:06:14 +0400 Subject: [9] RFR (XXS): 8049528: Method marked w/ @ForceInline isn't inlined with "executed < MinInliningThreshold times" message In-Reply-To: References: <53BBBC5C.7000802@oracle.com> <77A55B0B-ECA7-4DBB-9CA6-EDE7638A2523@oracle.com> <53BBEDE3.10708@oracle.com> Message-ID: <53BC4126.5060901@oracle.com> > Why not make a similar change to InlineTree::should_inline()? Shouldn?t it always return true if callee_method->force_inline() is true? Agree. Updated version: http://cr.openjdk.java.net/~vlivanov/8049528/webrev.01/ Best regards, Vladimir Ivanov From david.r.chase at oracle.com Tue Jul 8 19:13:30 2014 From: david.r.chase at oracle.com (David Chase) Date: Tue, 8 Jul 2014 15:13:30 -0400 Subject: [9] RFR (XS): 8036588 : VerifyFieldClosure fails instanceKlass:3133 Message-ID: bug: https://bugs.openjdk.java.net/browse/JDK-8036588 (closed because only seen in SQE) webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.00/ cause+fix: The root cause is use of the wrong liveness information at deoptimization point. The old code uses the optimizer's notion of "live" -- but deoptimization transfers to the interpreter and which can (will) manipulate values that are dead to the optimizer. The trigger is very tricky -- the following things need to happen: 1) an object D that will be dead is allocated 2) a method M is invoked that returns an object F, to only be stored in a field f of D 3) the optimizer eliminates the allocation of D and the storefield into D.f 4) deoptimization hits an execution of M; deoptimization reallocates D for the interpreter; BUT the reallocation triggers a GC, which would forward F if it had been correctly noted as live out of the call to M (but the bug is that it was not). 5) the interpreter evaluates D.f = F (this succeeds) 6) before the frame with D in it exits, ANOTHER garbage collection occurs (or perhaps GC was running concurrently in some way) and attempts to trace/copy through D and D.f. 7) Hilarity ensues. 8) For extra giggles, this has only ever been observed with -Xmx=32G (or the corresponding -XX:MaxRAMFraction= option) plus of course -XX:+DeoptimizeALot. Also setting -XX:DeoptimizeALotInterval=1 increases the failure rate to about 10% of test runs. There's some additional missing context, because following this recipe to write a simpler test for public consumption did not result in a crashing program. fix: Use a simpler test for "pointer is live from M" -- if the return type is an object, then it is "live", at least for the interpreter. testing: jtreg of runtime, gc, compiler got to the point where I could see fails often enough for the two tests known to trigger this, and after the fix neither test was observed to fail even once, even with hundreds of repetitions. From rednaxelafx at gmail.com Tue Jul 8 20:00:20 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 8 Jul 2014 13:00:20 -0700 Subject: Accessing runtime directly in LibraryCallKit without going through ci In-Reply-To: References: Message-ID: Hi guys, Any comments on this part? Thanks, Kris On Thu, Jul 3, 2014 at 4:04 PM, Krystal Mok wrote: > Hi everyone, > > I just came across this piece of code in C2 LibraryCallKit: > > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/39bac689e998/src/share/vm/opto/library_call.cpp#l435 > > 433: case vmIntrinsics::_getCallerClass: > 434: if (!InlineReflectionGetCallerClass) return NULL; > 435: if (SystemDictionary::reflect_CallerSensitive_klass() == NULL) > return NULL; > 436: break; > > Line 435 is accessing the runtime (SystemDictionary) directly without > going through ci. > Apparently it runs "okay" in current HotSpot. But as a convention, should > it be changed to go through ci? i.e. > > if (C->env()->reflect_CallerSensitive_klass() == NULL) return NULL; > > Thanks, > Kris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Tue Jul 8 21:35:30 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 8 Jul 2014 14:35:30 -0700 Subject: [9] RFR (S): 8049530: Provide descriptive failure reason for compilation tasks removed for the queue In-Reply-To: <53BBBF5E.6030005@oracle.com> References: <53BBBF5E.6030005@oracle.com> Message-ID: <5B53BE78-946E-4F6E-8460-FC3332C1EB97@oracle.com> Looks good. igor On Jul 8, 2014, at 2:52 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8049530/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8049530 > > Right now, failure message is empty for tasks removed from the queue before compilation is started. > > The fix is to add descriptive message when a stale task is removed or compilation is disabled. > > Testing: manual. > > Thanks! > > Best regards, > Vladimir Ivanov From igor.veresov at oracle.com Tue Jul 8 21:36:09 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 8 Jul 2014 14:36:09 -0700 Subject: [9] RFR (XXS): 8049529: LogCompilation: annotate make_not_compilable with compilation level In-Reply-To: <53BBBD7C.90409@oracle.com> References: <53BBBD7C.90409@oracle.com> Message-ID: <6AEE98F9-BD99-4DFA-B5F3-CDC6BE3B6102@oracle.com> Good. igor On Jul 8, 2014, at 2:44 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8049529/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8049529 > > It is useful to know at what level method compilation is disabled. Right now, this info isn't dumped to the log. > > Before: > > > > After: > > > No changes are needed in LogCompilation, since it doesn't care about make_not_{osr_}compilable tags now. I plan to address that in a separate change. > > Testing: manual. > > Thanks! > > Best regards, > Vladimir Ivanov From igor.veresov at oracle.com Tue Jul 8 21:39:12 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 8 Jul 2014 14:39:12 -0700 Subject: [9] RFR (XS): 8049532: LogCompilation: C1: inlining tree is flat (no depth is stored) In-Reply-To: <53BBC052.3090500@oracle.com> References: <53BBC052.3090500@oracle.com> Message-ID: <55FAF677-44B7-47EF-A9E2-EE6543605EA1@oracle.com> Good. igor On Jul 8, 2014, at 2:56 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8049532/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8049532 > > There's a bug in C1 LogCompilation support which incorrectly dumps inlining tree into the log. > > The fix is to add missing parse tags. That's enough for LogCompilation tool to correctly reconstruct inlining tree for C1 compilation. > > Testing: manual. > > Thanks! > > Best regards, > Vladimir Ivanov From igor.veresov at oracle.com Tue Jul 8 21:44:08 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 8 Jul 2014 14:44:08 -0700 Subject: [9] RFR (XS): 8036588 : VerifyFieldClosure fails instanceKlass:3133 In-Reply-To: References: Message-ID: <799452AB-3D4D-465A-A5E5-6F3501D34238@oracle.com> That looks good to me. igor On Jul 8, 2014, at 12:13 PM, David Chase wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8036588 (closed because only seen in SQE) > > webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.00/ > > cause+fix: > The root cause is use of the wrong liveness information at deoptimization point. > The old code uses the optimizer's notion of "live" -- but deoptimization transfers to the > interpreter and which can (will) manipulate values that are dead to the optimizer. > The trigger is very tricky -- the following things need to happen: > > 1) an object D that will be dead is allocated > 2) a method M is invoked that returns an object F, to only be stored in a field f of D > 3) the optimizer eliminates the allocation of D and the storefield into D.f > 4) deoptimization hits an execution of M; deoptimization reallocates D for the > interpreter; BUT the reallocation triggers a GC, which would forward F if > it had been correctly noted as live out of the call to M (but the bug is that it > was not). > 5) the interpreter evaluates D.f = F (this succeeds) > 6) before the frame with D in it exits, ANOTHER garbage collection occurs (or perhaps > GC was running concurrently in some way) and attempts to trace/copy through > D and D.f. > 7) Hilarity ensues. > 8) For extra giggles, this has only ever been observed with -Xmx=32G (or the corresponding > -XX:MaxRAMFraction= option) plus of course -XX:+DeoptimizeALot. Also setting > -XX:DeoptimizeALotInterval=1 increases the failure rate to about 10% of test runs. > There's some additional missing context, because following this recipe to write a simpler > test for public consumption did not result in a crashing program. > > fix: Use a simpler test for "pointer is live from M" -- if the return type is an object, > then it is "live", at least for the interpreter. > > testing: > jtreg of runtime, gc, compiler > > got to the point where I could see fails often enough for the two tests known to trigger this, > and after the fix neither test was observed to fail even once, even with hundreds of repetitions. From john.r.rose at oracle.com Tue Jul 8 21:50:26 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 8 Jul 2014 14:50:26 -0700 Subject: [9] RFR (XXS): 8049528: Method marked w/ @ForceInline isn't inlined with "executed < MinInliningThreshold times" message Message-ID: <7C31A1B3-CFD7-4002-AF7A-72E2EDD56181@oracle.com> That looks clean. Thanks. ? John On Jul 8, 2014, at 12:06 PM, Vladimir Ivanov wrote: >> Why not make a similar change to InlineTree::should_inline()? Shouldn?t it always return true if callee_method->force_inline() is true? > Agree. Updated version: > http://cr.openjdk.java.net/~vlivanov/8049528/webrev.01/ > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Jul 9 09:07:16 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 09 Jul 2014 13:07:16 +0400 Subject: [9] RFR (S): 8049530: Provide descriptive failure reason for compilation tasks removed for the queue In-Reply-To: <5B53BE78-946E-4F6E-8460-FC3332C1EB97@oracle.com> References: <53BBBF5E.6030005@oracle.com> <5B53BE78-946E-4F6E-8460-FC3332C1EB97@oracle.com> Message-ID: <53BD0644.5080002@oracle.com> Roland, Igor, thanks for review. Best regards, Vladimir Ivanov On 7/9/14 1:35 AM, Igor Veresov wrote: > Looks good. > > igor > > On Jul 8, 2014, at 2:52 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8049530/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8049530 >> >> Right now, failure message is empty for tasks removed from the queue before compilation is started. >> >> The fix is to add descriptive message when a stale task is removed or compilation is disabled. >> >> Testing: manual. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Wed Jul 9 09:07:37 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 09 Jul 2014 13:07:37 +0400 Subject: [9] RFR (XXS): 8049529: LogCompilation: annotate make_not_compilable with compilation level In-Reply-To: <6AEE98F9-BD99-4DFA-B5F3-CDC6BE3B6102@oracle.com> References: <53BBBD7C.90409@oracle.com> <6AEE98F9-BD99-4DFA-B5F3-CDC6BE3B6102@oracle.com> Message-ID: <53BD0659.4080300@oracle.com> Roland, Igor, thanks for review. Best regards, Vladimir Ivanov On 7/9/14 1:36 AM, Igor Veresov wrote: > Good. > > igor > > On Jul 8, 2014, at 2:44 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8049529/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8049529 >> >> It is useful to know at what level method compilation is disabled. Right now, this info isn't dumped to the log. >> >> Before: >> >> >> >> After: >> >> >> No changes are needed in LogCompilation, since it doesn't care about make_not_{osr_}compilable tags now. I plan to address that in a separate change. >> >> Testing: manual. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Wed Jul 9 09:07:59 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 09 Jul 2014 13:07:59 +0400 Subject: [9] RFR (XS): 8049532: LogCompilation: C1: inlining tree is flat (no depth is stored) In-Reply-To: <55FAF677-44B7-47EF-A9E2-EE6543605EA1@oracle.com> References: <53BBC052.3090500@oracle.com> <55FAF677-44B7-47EF-A9E2-EE6543605EA1@oracle.com> Message-ID: <53BD066F.5010901@oracle.com> Roland, Igor, thanks for review. Best regards, Vladimir Ivanov On 7/9/14 1:39 AM, Igor Veresov wrote: > Good. > > igor > > On Jul 8, 2014, at 2:56 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8049532/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8049532 >> >> There's a bug in C1 LogCompilation support which incorrectly dumps inlining tree into the log. >> >> The fix is to add missing parse tags. That's enough for LogCompilation tool to correctly reconstruct inlining tree for C1 compilation. >> >> Testing: manual. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From roland.westrelin at oracle.com Wed Jul 9 10:12:01 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 9 Jul 2014 12:12:01 +0200 Subject: [9] RFR (XXS): 8049528: Method marked w/ @ForceInline isn't inlined with "executed < MinInliningThreshold times" message In-Reply-To: <53BC4126.5060901@oracle.com> References: <53BBBC5C.7000802@oracle.com> <77A55B0B-ECA7-4DBB-9CA6-EDE7638A2523@oracle.com> <53BBEDE3.10708@oracle.com> <53BC4126.5060901@oracle.com> Message-ID: <279BBC89-FCB4-48A7-B069-277BD9EB1CE4@oracle.com> > http://cr.openjdk.java.net/~vlivanov/8049528/webrev.01/ That looks good to me. Roland. From vladimir.x.ivanov at oracle.com Wed Jul 9 10:16:54 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 09 Jul 2014 14:16:54 +0400 Subject: [9] RFR (XXS): 8049528: Method marked w/ @ForceInline isn't inlined with "executed < MinInliningThreshold times" message In-Reply-To: <279BBC89-FCB4-48A7-B069-277BD9EB1CE4@oracle.com> References: <53BBBC5C.7000802@oracle.com> <77A55B0B-ECA7-4DBB-9CA6-EDE7638A2523@oracle.com> <53BBEDE3.10708@oracle.com> <53BC4126.5060901@oracle.com> <279BBC89-FCB4-48A7-B069-277BD9EB1CE4@oracle.com> Message-ID: <53BD1696.1040203@oracle.com> Roland, John, thanks for review. Best regards, Vladimir Ivanov On 7/9/14 2:12 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~vlivanov/8049528/webrev.01/ > > That looks good to me. > > Roland. > From vladimir.x.ivanov at oracle.com Wed Jul 9 18:47:42 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 09 Jul 2014 22:47:42 +0400 Subject: [8u20] [9] RFR (S): 8043546: C1 optimizes @Stable instance fields with default values Message-ID: <53BD8E4E.1050409@oracle.com> http://cr.openjdk.java.net/~vlivanov/8043546/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8043546 (not public because contains internal links) C1 doesn't respect @Stable contract and constant folds loads from stable instance fields w/ default values. The fix is to add missing check. C1 already optimizes stable static fields and after this change it also optimizes stable instance fields. C1 doesn't support stable array, so tests are changed to distiguish 3 outcomes: no @Stable support, C1 & C2. I'll try to extend C1 support to arrays in the future. The fix is very focused, since it's targeted for 8u20. I want to refactor the code for 9 & 8u40 and separate is_constant() and is_stable() properties for instance fields. Current implementation is error-prone, since it requires every place where is_constant() for instance field is used to have a check for stable. It's safer to miss optimization opportunity rather than doing wrong optimization. Improved unit tests to test C1 as well. Also, removed dependency on JMX. Testing: regression tests Thanks! Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Wed Jul 9 23:02:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Jul 2014 16:02:47 -0700 Subject: [9] RFR (XS): 8036588 : VerifyFieldClosure fails instanceKlass:3133 In-Reply-To: References: Message-ID: <53BDCA17.9020404@oracle.com> Yes, the return_value_is_used() method is incorrect, it does not take into account that the returned value could be used after deoptimization for reallocated objects. return_oop is checked by deoptimization only when EliminateAllocations is true. Only in such case and when objects are reallocated GC can happen during deoptimization. The fix will also preserve a return value when it is really not used: A a = new A(); (void)foo(); a.f = 1; or simple (void)foo(); Which is fine since deoptimization code is not critical for performance. return_value_is_used() is used only by this code. I would suggest to rename it to returns_pointer() and copy-paste code from CallNode::returns_pointer() (MachCallNode is not based on CallNode). And use it in the check. Thanks, Vladimir On 7/8/14 12:13 PM, David Chase wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8036588 (closed because only seen in SQE) > > webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.00/ > > cause+fix: > The root cause is use of the wrong liveness information at deoptimization point. > The old code uses the optimizer's notion of "live" -- but deoptimization transfers to the > interpreter and which can (will) manipulate values that are dead to the optimizer. > The trigger is very tricky -- the following things need to happen: > > 1) an object D that will be dead is allocated > 2) a method M is invoked that returns an object F, to only be stored in a field f of D > 3) the optimizer eliminates the allocation of D and the storefield into D.f > 4) deoptimization hits an execution of M; deoptimization reallocates D for the > interpreter; BUT the reallocation triggers a GC, which would forward F if > it had been correctly noted as live out of the call to M (but the bug is that it > was not). > 5) the interpreter evaluates D.f = F (this succeeds) > 6) before the frame with D in it exits, ANOTHER garbage collection occurs (or perhaps > GC was running concurrently in some way) and attempts to trace/copy through > D and D.f. > 7) Hilarity ensues. > 8) For extra giggles, this has only ever been observed with -Xmx=32G (or the corresponding > -XX:MaxRAMFraction= option) plus of course -XX:+DeoptimizeALot. Also setting > -XX:DeoptimizeALotInterval=1 increases the failure rate to about 10% of test runs. > There's some additional missing context, because following this recipe to write a simpler > test for public consumption did not result in a crashing program. > > fix: Use a simpler test for "pointer is live from M" -- if the return type is an object, > then it is "live", at least for the interpreter. > > testing: > jtreg of runtime, gc, compiler > > got to the point where I could see fails often enough for the two tests known to trigger this, > and after the fix neither test was observed to fail even once, even with hundreds of repetitions. > From john.r.rose at oracle.com Wed Jul 9 23:07:31 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Jul 2014 16:07:31 -0700 Subject: Accessing runtime directly in LibraryCallKit without going through ci In-Reply-To: References: Message-ID: <4AC56682-6624-4EF5-9FB2-ACE66AC7C30F@oracle.com> On Jul 3, 2014, at 4:04 PM, Krystal Mok wrote: > Hi everyone, > > I just came across this piece of code in C2 LibraryCallKit: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/39bac689e998/src/share/vm/opto/library_call.cpp#l435 > > 433: case vmIntrinsics::_getCallerClass: > 434: if (!InlineReflectionGetCallerClass) return NULL; > 435: if (SystemDictionary::reflect_CallerSensitive_klass() == NULL) return NULL; > 436: break; > > Line 435 is accessing the runtime (SystemDictionary) directly without going through ci. > Apparently it runs "okay" in current HotSpot. But as a convention, should it be changed to go through ci? i.e. > > if (C->env()->reflect_CallerSensitive_klass() == NULL) return NULL; Yes, it should go through the CI. It happens to run OK since it is just a null check of a Klass* value, and the GC does not convert null to non-null values. (This would be a slight hazard if the value were a compressed klass pointer.) ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From rednaxelafx at gmail.com Wed Jul 9 23:14:43 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 9 Jul 2014 16:14:43 -0700 Subject: Accessing runtime directly in LibraryCallKit without going through ci In-Reply-To: <4AC56682-6624-4EF5-9FB2-ACE66AC7C30F@oracle.com> References: <4AC56682-6624-4EF5-9FB2-ACE66AC7C30F@oracle.com> Message-ID: Hi John, Thanks for your comments. I noticed yesterday that I had made a mistake in the proposed change. Since that line of code is in Compile::make_vm_intrinsic(), it should be: if (env()->reflect_CallerSensitive_klass() == NULL) return NULL; instead of: if (C->env()->reflect_CallerSensitive_klass() == NULL) return NULL; Thanks, Kris On Wed, Jul 9, 2014 at 4:07 PM, John Rose wrote: > On Jul 3, 2014, at 4:04 PM, Krystal Mok wrote: > > Hi everyone, > > I just came across this piece of code in C2 LibraryCallKit: > > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/39bac689e998/src/share/vm/opto/library_call.cpp#l435 > > 433: case vmIntrinsics::_getCallerClass: > 434: if (!InlineReflectionGetCallerClass) return NULL; > 435: if (SystemDictionary::reflect_CallerSensitive_klass() == NULL) > return NULL; > 436: break; > > Line 435 is accessing the runtime (SystemDictionary) directly without > going through ci. > Apparently it runs "okay" in current HotSpot. But as a convention, should > it be changed to go through ci? i.e. > > if (C->env()->reflect_CallerSensitive_klass() == NULL) return NULL; > > > Yes, it should go through the CI. It happens to run OK since it is just a > null check of a Klass* value, and the GC does not convert null to non-null > values. (This would be a slight hazard if the value were a compressed > klass pointer.) > > ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Jul 10 01:15:57 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Jul 2014 18:15:57 -0700 Subject: [8u20] [9] RFR (S): 8043546: C1 optimizes @Stable instance fields with default values In-Reply-To: <53BD8E4E.1050409@oracle.com> References: <53BD8E4E.1050409@oracle.com> Message-ID: <53BDE94D.6060406@oracle.com> Seems fine. Vladimir K On 7/9/14 11:47 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8043546/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8043546 > (not public because contains internal links) > > C1 doesn't respect @Stable contract and constant folds loads from stable instance fields w/ default values. The fix is > to add missing check. > > C1 already optimizes stable static fields and after this change it also optimizes stable instance fields. C1 doesn't > support stable array, so tests are changed to distiguish 3 outcomes: no @Stable support, C1 & C2. I'll try to extend C1 > support to arrays in the future. > > The fix is very focused, since it's targeted for 8u20. I want to refactor the code for 9 & 8u40 and separate > is_constant() and is_stable() properties for instance fields. Current implementation is error-prone, since it requires > every place where is_constant() for instance field is used to have a check for stable. It's safer to miss optimization > opportunity rather than doing wrong optimization. > > Improved unit tests to test C1 as well. Also, removed dependency on JMX. > > Testing: regression tests > > Thanks! > > Best regards, > Vladimir Ivanov From john.r.rose at oracle.com Thu Jul 10 02:16:24 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Jul 2014 19:16:24 -0700 Subject: [8u20] [9] RFR (S): 8043546: C1 optimizes @Stable instance fields with default values In-Reply-To: <53BD8E4E.1050409@oracle.com> References: <53BD8E4E.1050409@oracle.com> Message-ID: <21FE56E9-29BD-4429-9A12-FA6AACB449B6@oracle.com> On Jul 9, 2014, at 11:47 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8043546/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8043546 > (not public because contains internal links) > > C1 doesn't respect @Stable contract and constant folds loads from stable instance fields w/ default values. The fix is to add missing check. > > C1 already optimizes stable static fields and after this change it also optimizes stable instance fields. C1 doesn't support stable array, so tests are changed to distiguish 3 outcomes: no @Stable support, C1 & C2. I'll try to extend C1 support to arrays in the future. The same "non default value" check is needed for getstatic as well as getfield. I don't see how the existing getstatic is already correct. ? John > The fix is very focused, since it's targeted for 8u20. I want to refactor the code for 9 & 8u40 and separate is_constant() and is_stable() properties for instance fields. Current implementation is error-prone, since it requires every place where is_constant() for instance field is used to have a check for stable. It's safer to miss optimization opportunity rather than doing wrong optimization. > > Improved unit tests to test C1 as well. Also, removed dependency on JMX. > > Testing: regression tests > > Thanks! > > Best regards, > Vladimir Ivanov From john.r.rose at oracle.com Thu Jul 10 02:28:10 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Jul 2014 19:28:10 -0700 Subject: [8u20] [9] RFR (S): 8043546: C1 optimizes @Stable instance fields with default values In-Reply-To: <21FE56E9-29BD-4429-9A12-FA6AACB449B6@oracle.com> References: <53BD8E4E.1050409@oracle.com> <21FE56E9-29BD-4429-9A12-FA6AACB449B6@oracle.com> Message-ID: <04A70A74-B7F0-46D0-B9EF-E3A6033BC991@oracle.com> On Jul 9, 2014, at 7:16 PM, John Rose wrote: >> C1 already optimizes stable static fields and after this change it also optimizes stable instance fields. C1 doesn't support stable array, so tests are changed to distiguish 3 outcomes: no @Stable support, C1 & C2. I'll try to extend C1 support to arrays in the future. > > The same "non default value" check is needed for getstatic as well as getfield. I don't see how the existing getstatic is already correct. > > ? John Sorry; now I see it. The required check, for statics, comes from the setting at the bottom of ciField::initialize_from. The corresponding non-static case gets a cut-out near the top, before the default-check. This is why the *.hpp file says: // For non-static fields, the null/zero check must be // arranged by the user, as constant_value().is_null_or_zero(). I suppose an extra comment in c1_GB.cpp, near the processing of getstatic, might reassure forgetful and/or nervous readers. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Thu Jul 10 10:05:15 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 10 Jul 2014 14:05:15 +0400 Subject: [8u20] [9] RFR (S): 8043546: C1 optimizes @Stable instance fields with default values In-Reply-To: <04A70A74-B7F0-46D0-B9EF-E3A6033BC991@oracle.com> References: <53BD8E4E.1050409@oracle.com> <21FE56E9-29BD-4429-9A12-FA6AACB449B6@oracle.com> <04A70A74-B7F0-46D0-B9EF-E3A6033BC991@oracle.com> Message-ID: <53BE655B.6020009@oracle.com> VladimirK, John, thanks for review. Fair enough. Updated version: http://cr.openjdk.java.net/~vlivanov/8043546/webrev.01/ Also, I filed RFE [1] to refactor @Stable support for instance fields. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8049837 On 7/10/14 6:28 AM, John Rose wrote: > On Jul 9, 2014, at 7:16 PM, John Rose > wrote: > >>> C1 already optimizes stable static fields and after this change it >>> also optimizes stable instance fields. C1 doesn't support stable >>> array, so tests are changed to distiguish 3 outcomes: no @Stable >>> support, C1 & C2. I'll try to extend C1 support to arrays in the future. >> >> The same "non default value" check is needed for getstatic as well as >> getfield. I don't see how the existing getstatic is already correct. >> >> ? John > > Sorry; now I see it. The required check, for statics, comes from the > setting at the bottom of ciField::initialize_from. The corresponding > non-static case gets a cut-out near the top, before the default-check. > This is why the *.hpp file says: > > // For non-static fields, the null/zero check must be > // arranged by the user, as constant_value().is_null_or_zero(). > > I suppose an extra comment in c1_GB.cpp, near the processing of > getstatic, might reassure forgetful and/or nervous readers. > > ? John From vladimir.kozlov at oracle.com Thu Jul 10 16:21:25 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Jul 2014 09:21:25 -0700 Subject: [8u20] [9] RFR (S): 8043546: C1 optimizes @Stable instance fields with default values In-Reply-To: <53BE655B.6020009@oracle.com> References: <53BD8E4E.1050409@oracle.com> <21FE56E9-29BD-4429-9A12-FA6AACB449B6@oracle.com> <04A70A74-B7F0-46D0-B9EF-E3A6033BC991@oracle.com> <53BE655B.6020009@oracle.com> Message-ID: <53BEBD85.8030601@oracle.com> Okay Vladimir On 7/10/14 3:05 AM, Vladimir Ivanov wrote: > VladimirK, John, thanks for review. > > Fair enough. Updated version: > http://cr.openjdk.java.net/~vlivanov/8043546/webrev.01/ > > Also, I filed RFE [1] to refactor @Stable support for instance fields. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8049837 > > On 7/10/14 6:28 AM, John Rose wrote: >> On Jul 9, 2014, at 7:16 PM, John Rose > > wrote: >> >>>> C1 already optimizes stable static fields and after this change it >>>> also optimizes stable instance fields. C1 doesn't support stable >>>> array, so tests are changed to distiguish 3 outcomes: no @Stable >>>> support, C1 & C2. I'll try to extend C1 support to arrays in the future. >>> >>> The same "non default value" check is needed for getstatic as well as >>> getfield. I don't see how the existing getstatic is already correct. >>> >>> ? John >> >> Sorry; now I see it. The required check, for statics, comes from the >> setting at the bottom of ciField::initialize_from. The corresponding >> non-static case gets a cut-out near the top, before the default-check. >> This is why the *.hpp file says: >> >> // For non-static fields, the null/zero check must be >> // arranged by the user, as constant_value().is_null_or_zero(). >> >> I suppose an extra comment in c1_GB.cpp, near the processing of >> getstatic, might reassure forgetful and/or nervous readers. >> >> ? John From roland.westrelin at oracle.com Thu Jul 10 19:28:24 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 10 Jul 2014 21:28:24 +0200 Subject: RFR(S): 8040237: nsk/jvmti/RetransformClasses/retransform001 crashed the VM on all platforms when run with with -server -Xcomp Message-ID: http://cr.openjdk.java.net/~roland/8040237/webrev.00/ InstanceKlass::purge_previous_versions() is called on every classes of a class loader from ClassLoaderDataGraph::do_unloading() right before free_deallocate_list() for that class loader. Every reference to a method not on_stack() in the MDO is removed. The following call to free_deallocate_list() frees methods that are not on_stack() for that class loader. Every method that is on_stack() is not freed and references to that method are left as is. The crash happens because one method?s MDO can reference another method in another class loader. When that happens, the loop in ClassLoaderDataGraph::do_unloading() may call free_deallocate_list() and free redefined method m1 that is not on stack and a subsequent iteration will go over method m2's MDO that references m1 that is gone. This is fixed by first calling InstanceKlass::purge_previous_versions() on every class of every class loaders in case of class redefinition first and then only iterating again on all class loader data to free metadata. Coleen recommended the fix to CleanExtraDataMethodClosure::is_live(). I also moved TestSpecTrapClassUnloading.java (test from a previous bug) to the correct subdirectory. Roland. From vladimir.kozlov at oracle.com Thu Jul 10 20:59:18 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Jul 2014 13:59:18 -0700 Subject: RFR(S): 8040237: nsk/jvmti/RetransformClasses/retransform001 crashed the VM on all platforms when run with with -server -Xcomp In-Reply-To: References: Message-ID: <53BEFEA6.2050603@oracle.com> Looks good. Vladimir On 7/10/14 12:28 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8040237/webrev.00/ > > InstanceKlass::purge_previous_versions() is called on every classes of a class loader from ClassLoaderDataGraph::do_unloading() right before free_deallocate_list() for that class loader. Every reference to a method not on_stack() in the MDO is removed. The following call to free_deallocate_list() frees methods that are not on_stack() for that class loader. Every method that is on_stack() is not freed and references to that method are left as is. > The crash happens because one method?s MDO can reference another method in another class loader. When that happens, the loop in ClassLoaderDataGraph::do_unloading() may call free_deallocate_list() and free redefined method m1 that is not on stack and a subsequent iteration will go over method m2's MDO that references m1 that is gone. > > This is fixed by first calling InstanceKlass::purge_previous_versions() on every class of every class loaders in case of class redefinition first and then only iterating again on all class loader data to free metadata. > > Coleen recommended the fix to CleanExtraDataMethodClosure::is_live(). > > I also moved TestSpecTrapClassUnloading.java (test from a previous bug) to the correct subdirectory. > > Roland. > From coleen.phillimore at oracle.com Thu Jul 10 21:09:23 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Jul 2014 17:09:23 -0400 Subject: RFR(S): 8040237: nsk/jvmti/RetransformClasses/retransform001 crashed the VM on all platforms when run with with -server -Xcomp In-Reply-To: References: Message-ID: <53BF0103.6030008@oracle.com> This looks good. There's a slight typo in one of the test files. 50 // loader2 must be firt on the list so loader 1 must be used first Thanks! Coleen On 7/10/14, 3:28 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8040237/webrev.00/ > > InstanceKlass::purge_previous_versions() is called on every classes of a class loader from ClassLoaderDataGraph::do_unloading() right before free_deallocate_list() for that class loader. Every reference to a method not on_stack() in the MDO is removed. The following call to free_deallocate_list() frees methods that are not on_stack() for that class loader. Every method that is on_stack() is not freed and references to that method are left as is. > The crash happens because one method?s MDO can reference another method in another class loader. When that happens, the loop in ClassLoaderDataGraph::do_unloading() may call free_deallocate_list() and free redefined method m1 that is not on stack and a subsequent iteration will go over method m2's MDO that references m1 that is gone. > > This is fixed by first calling InstanceKlass::purge_previous_versions() on every class of every class loaders in case of class redefinition first and then only iterating again on all class loader data to free metadata. > > Coleen recommended the fix to CleanExtraDataMethodClosure::is_live(). > > I also moved TestSpecTrapClassUnloading.java (test from a previous bug) to the correct subdirectory. > > Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Jul 10 22:13:41 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Jul 2014 15:13:41 -0700 Subject: [9] RFR(S): 8048721: -XX:+PrintCompilation prints negative bci for non entrant OSR methods In-Reply-To: <53BBE93D.802@oracle.com> References: <53B291E9.3030508@oracle.com> <53B2A356.4080200@oracle.com> <53BBE93D.802@oracle.com> Message-ID: <53BF1015.4080002@oracle.com> _method set to NULL also in make_unloaded() but after invalidate_osr_method() call so it should be fine. On 7/8/14 5:51 AM, Vladimir Ivanov wrote: > Any thoughts about that? I still think "_entry_bci = InvalidOSREntryBci" > is redundant. Unfortunately profiling code in Interpeter test this value: __ movl(rcx, Address(rax, nmethod::entry_bci_offset())); __ cmpl(rcx, InvalidOSREntryBci); So it would require a lot more changes. But I agree that changing _entry_bci looks strange Can we check _state value instead of _entry_bci? Could be some race conditions why _entry_bci is used. Vladimir K > > Best regards, > Vladimir Ivanov > > On 7/1/14 4:02 PM, Vladimir Ivanov wrote: >> (widening audience to Runtime folks) >> >> I don't think it's good to lose bci for OSR methods after nmethod >> invalidation. >> >> Regarding current invalidation logic, I don't see that "_entry_bci = >> InvalidOSREntryBci" is required to invalidate OSR nmethods. Yes, >> interpreter does "_entry_bci != InvalidOSREntryBci" check before calling >> OSR nmethod, but _entry_bci update isn't properly synchronized between >> invalidating and querying threads (no locks or memory barriers involved). >> >> So I have a question is it safe to remove "_entry_bci = >> InvalidOSREntryBci". >> >> Both OSR nmethod lookup (InstanceKlass::lookup_osr_nmethod) and removal >> (InstanceKlass::remove_osr_nmethod) synchronize on OsrList_lock, so >> after removal OSR nmethod can't be looked up. >> >> What bothers me is the following null check before removal: >> void nmethod::invalidate_osr_method() { >> if (method() != NULL) >> method()->method_holder()->remove_osr_nmethod(this); >> >> Under what conditions nmethod with _method == NULL can be invalidated? >> Or is it just defensive coding? >> >> We set _method to NULL only for zombie nmethods (see >> nmethod::make_not_entrant_or_zombie) and they are already invalidated at >> that point. >> >> Best regards, >> Vladimir Ivanov >> >> On 7/1/14 2:48 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch for JDK-8048721. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048721 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8048721/webrev.00/ >>> >>> *Problem* >>> The VM option -XX:+PrintCompilation prints a negative bytecode index for >>> not entrant OSR nmethods. The problem is that in >>> nmethod::make_not_entrant_or_zombie(..) the _entry_bci is invalidated >>> (i.e. set to InvalidOSREntryBci == -2) by invalidate_osr_method(..) and >>> log_state_change(..) is called afterwards, printing the invalidated >>> entry. >>> >>> *Solution >>> *Because reordering the methods in >>> nmethod::make_not_entrant_or_zombie(..) is not easily possible due to >>> thread safety, I changed the implementation log_state_change(..) and >>> dependent methods to take the entry bci as parameter. The entry bci is >>> saved prior to invalidation and used for printing afterwards. >>> >>> *Testing* >>> JPRT >>> >>> Thanks, >>> Tobias From vladimir.kozlov at oracle.com Fri Jul 11 00:06:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Jul 2014 17:06:48 -0700 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53B64ECD.3060300@oracle.com> References: <53B64ECD.3060300@oracle.com> Message-ID: <53BF2A98.30803@oracle.com> Thank you for doing this cleanup, Tobias. Looks good. Small note, in divnode.cpp please use explicit NULL checks: if (in(0) != NULL) { Thanks, Vladimir On 7/3/14 11:50 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch for 8040213 that finishes Vladimir?s > work [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8040213 > Webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.00/ > * > **Problem* > Not all nodes that are modified during C2 optimization are put on the > IGVN worklist. > > *Solution* > Verification code is added that checks if (i) modified nodes are put on > the IGVN worklist and (ii) modified nodes are processed by > PhaseIterGVN::transform_old(..). All code that fails verification during > testing is fixed. > * > **Testing:* > - JPRT > - Full CTW > - Nashorn + Octane > - UTE (full testlist, BigApps, JRuby) > - VM (NSK) testbase > - Refworkload (reference_server) > - VMSQE.adhoc.JPRT.full batch > > Thanks, > Tobias > > [1] http://cr.openjdk.java.net/~kvn/8040213/webrev/ From tobias.hartmann at oracle.com Fri Jul 11 06:28:10 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 11 Jul 2014 08:28:10 +0200 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53BF2A98.30803@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> Message-ID: <53BF83FA.3040908@oracle.com> Hi Vladimir, thanks for the review. > Thank you for doing this cleanup, Tobias. > > Looks good. Small note, in divnode.cpp please use explicit NULL checks: > > if (in(0) != NULL) { Done. New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ Thanks, Tobias > > Thanks, > Vladimir > > On 7/3/14 11:50 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch for 8040213 that finishes Vladimir?s >> work [1]. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8040213 >> Webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.00/ >> * >> **Problem* >> Not all nodes that are modified during C2 optimization are put on the >> IGVN worklist. >> >> *Solution* >> Verification code is added that checks if (i) modified nodes are put on >> the IGVN worklist and (ii) modified nodes are processed by >> PhaseIterGVN::transform_old(..). All code that fails verification during >> testing is fixed. >> * >> **Testing:* >> - JPRT >> - Full CTW >> - Nashorn + Octane >> - UTE (full testlist, BigApps, JRuby) >> - VM (NSK) testbase >> - Refworkload (reference_server) >> - VMSQE.adhoc.JPRT.full batch >> >> Thanks, >> Tobias >> >> [1] http://cr.openjdk.java.net/~kvn/8040213/webrev/ From roland.westrelin at oracle.com Fri Jul 11 09:52:34 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 11 Jul 2014 11:52:34 +0200 Subject: RFR(S): 8040237: nsk/jvmti/RetransformClasses/retransform001 crashed the VM on all platforms when run with with -server -Xcomp In-Reply-To: <53BF0103.6030008@oracle.com> References: <53BF0103.6030008@oracle.com> Message-ID: Thanks Vladimir & Coleen. Will fix the typo. Roland. From zhengyu.gu at oracle.com Fri Jul 11 13:53:55 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 11 Jul 2014 09:53:55 -0400 Subject: Round 3 RFR (S) 6424123: JVM crashes on failed 'strdup' call. In-Reply-To: <53BF8555.30803@oracle.com> References: <538F826C.8090000@oracle.com> <5391F4EB.9070007@oracle.com> <539426CD.2030104@oracle.com> <53945BAB.5030809@oracle.com> <5394DCC6.1050704@oracle.com> <5395BA18.2090403@oracle.com> <53968098.1060809@oracle.com> <539778EA.6060305@oracle.com> <53BECFDF.40308@oracle.com> <53BF8555.30803@oracle.com> Message-ID: <53BFEC73.8060900@oracle.com> Hi David, Thanks for the review. Please see comments inline. On 7/11/2014 2:33 AM, David Holmes wrote: > Hi Zhengyu, > > A number of comments ... > > First an aside ... based on the recent header file changes for > .iniline.hpp file I would think these pairs: > > +#include "memory/allocation.hpp" > +#include "memory/allocation.inline.hpp" > > would reduce to > > +#include "memory/allocation.inline.hpp" > > if allocation.inline.hpp included allocation.hpp as it apparently should. > I will fix them. > --- > > In the vm_version_* changes are you sure os::malloc will be ready to > work very early in the initialization sequence of the VM? os::malloc > calls out to a lot of other code especially in debug mode - eg: will > check_heap() work, GuardedMemory, MemTracker itself? > > Similarly with the use of os::strdup_check_oom - will it actually > manage to terminate cleanly if OOME happens? > > Same comments for arguments.cpp changes. It may be too early to call > os::strdup_check_oom. > The earliest os::malloc() calls are from initialization of static objects, ahead of vm_version_* initialization, so I don't think it is an issue. > --- > > src/share/vm/compiler/compilerOracle.cpp > > It's not obvious that your change is correct. If MethodMatcher::match > is called several times might you not want to duplicate the string on > each call? That said it isn't obvious that these strings need copying > at all - we'd need to trace their complete lifecycle. > > Similar comments for NamedCounter in runtime.cpp and vmNode in > fprofiler.cpp > > Having to add all those destructors seems messy and it isn't evident > that it is necessary. I moved 'strdup' from caller to the class, I think it makes the ownership more explicit. I can not tell if the string needs to be duplicated, or vmNode, NamedCounter ever to be released. If so, it looks to me like memory leaks. CC'd compiler mail list. Thanks, -Zhengyu > > --- > > Thanks, > David > > On 11/07/2014 3:39 AM, Zhengyu Gu wrote: >> Sorry for the long delay. The update is mainly based on Coleen's >> suggestion. >> >> DuplicateString() is changed to os::strdup_check_oom(). >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-6424123 >> >> Webrev:http://cr.openjdk.java.net/~zgu/6424123/webrev.02/ >> >> >> >> Thanks, >> >> -Zhengyu >> >> >> >> >> On 6/10/2014 5:30 PM, Coleen Phillimore wrote: >>> >>> Hi, I think this is potentially a really good cleanup. May I suggest >>> making DuplicateString an os function like os::duplicate_string() and >>> have it always throw OOM, so that the alloc_failmode parameter doesn't >>> look inconsistent. >>> >>> If new code wants to call os::strdup() and check for null return, it >>> can do that. Otherwise call os::safe_duplicate_string() or >>> os::duplicate_string() as a wrapper to a os::strdup() that doesn't >>> return null. >>> >>> I'm not convinced the original bug is caused by missing a null check >>> to strdup (unless it passed into strdup an already null string). But >>> this cleans up using this unsafe function directly. >>> >>> Thanks, >>> Coleen >>> >>> On 6/9/14, 11:50 PM, David Holmes wrote: >>>> On 9/06/2014 11:43 PM, Zhengyu Gu wrote: >>>>> Hi David, >>>>> >>>>> On 6/8/2014 5:59 PM, David Holmes wrote: >>>>>> On 8/06/2014 10:48 PM, Zhengyu Gu wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 6/8/2014 5:03 AM, David Holmes wrote: >>>>>>>> Hi Zhengyu, >>>>>>>> >>>>>>>> Still a bit perplexed by the aim here. Why replace non-null >>>>>>>> checked >>>>>>>> strdup calls with non-null os::strdup? >>>>>>> ::strdup() is not tracked by NMT, but os::strdup() is. >>>>>> >>>>>> Okay, but it still needs to be checked. >>>>>> >>>>> I am not sure what needs to be checked? >>>> >>>> The result of calling os::strdup - else we haven't fixed the original >>>> bug. Unless you are saying that all uses of os::strdup do check the >>>> return value somewhere in the call chain? >>>> >>>>>>>> If the issue is that the result of strdup must be checked then it >>>>>>>> must >>>>>>>> be checked. Why add DuplicateString instead of changing what >>>>>>>> os::strdup does? >>>>>>> I replaced strdup()/os::strdup() with DuplicateString(), where >>>>>>> caller >>>>>>> does not check null pointer. If caller checks null pointer, I >>>>>>> left it >>>>>>> alone. >>>>>> >>>>>> That is not apparent from the webrev eg: >>>>>> >>>>>> src/os/windows/vm/perfMemory_windows.cpp >>>>>> >>>>> There are several places that are not obvious. Sometimes, I have to >>>>> go a >>>>> few levels to find out how the pointers are used. >>>>> >>>>> For this particular case, sharedmem_fileName is only referenced by >>>>> PerfMemory::backing_store_filename(), but there is no caller to this >>>>> function. >>>>> >>>>> $ grep -r backing_store_filename * >>>>> os/aix/vm/perfMemory_aix.cpp:char* >>>>> PerfMemory::backing_store_filename() { >>>>> os/bsd/vm/perfMemory_bsd.cpp:char* >>>>> PerfMemory::backing_store_filename() { >>>>> os/linux/vm/perfMemory_linux.cpp:char* >>>>> PerfMemory::backing_store_filename() { >>>>> os/solaris/vm/perfMemory_solaris.cpp:char* >>>>> PerfMemory::backing_store_filename() { >>>>> os/windows/vm/perfMemory_windows.cpp:char* >>>>> PerfMemory::backing_store_filename() { >>>>> share/vm/runtime/perfMemory.hpp: static char* >>>>> backing_store_filename(); >>>>> >>>>> I thought parfait should be good at finding these things. >>>>> >>>>>> >>>>>>> DuplicateString() mirrors what AllocateHeap() does, and >>>>>>> os::strdup() >>>>>>> mirrors os::malloc(). AllocateHeap()/DuplicateString() can >>>>>>> handle OOM >>>>>>> (by default), but os::strdup()/os::malloc() do not. >>>>>> >>>>>> I don't see the need for this duality here. Why do we need to dup >>>>>> strings in different memory areas? Why can't os::strdup do the null >>>>>> check internally and abort if requested? >>>>>> >>>>>> Putting it another way if someone writes a new piece of code where >>>>>> they need to dup an incoming string, what determines whether they >>>>>> should use os::strdup or DuplicateString? >>>>>> >>>>> I agree it is confusing that we have some many memory allocation >>>>> functions to accomplish similar things, given AllocateHeap() and >>>>> ReallocateHeap() can also return NULL now. That's also the reason to >>>>> get >>>>> me wrong in the first iteration. >>>>> >>>>> The purposed approach at least keep os::malloc(), os::realloc() and >>>>> os::strdup() as replacement of c library's counterparts. >>>>> Having os::strdup() handles OOM, but not os::malloc() and >>>>> os::realloc(), >>>>> seems to me even more confusing and inconsistent. >>>>> >>>>> To determine whether uses os::strdup() or DuplicationString(), >>>>> should be >>>>> the same way to determine whether uses os::malloc() or >>>>> AllocateHeap(), >>>>> in my opinion. >>>> >>>> AllocateHeap should only be being used as the implementation for >>>> CHeapObj and related types, it is not a general purpose allocation >>>> interface. So I don't see that the analogy holds. I'd rather see only >>>> os::strdup used with all the clients doing the null check (somewhere >>>> in the stack) and handling it appropriately. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Zhengyu >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 7/06/2014 3:05 AM, Zhengyu Gu wrote: >>>>>>>>> Updated webrev introduces a new DuplicateString() function, that >>>>>>>>> handles >>>>>>>>> OOM, similar to AllocateHeap(), and replaces the call sites >>>>>>>>> that do >>>>>>>>> not >>>>>>>>> check NULL pointer with this DuplicateString(). >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~zgu/6424123/webrev.01/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Zhengyu >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/4/2014 4:32 PM, Zhengyu Gu wrote: >>>>>>>>>> JVM should avoid C library's strdup() and use os::strdup() >>>>>>>>>> instead. >>>>>>>>>> os::strdup() handles OOM, so can avoid JVM crash. >>>>>>>>>> >>>>>>>>>> Also, made limited scope of code cleanup, which makes memory >>>>>>>>>> ownership >>>>>>>>>> more explicit, so they can be claimed by object's destructors. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6424123 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/6424123/webrev.00/ >>>>>>>>>> >>>>>>>>>> Tests: >>>>>>>>>> - JPRT >>>>>>>>>> - vm.quick.testlist on Linux x64. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Zhengyu >>>>>>>>> >>>>>>> >>>>> >>> >> From filipp.zhinkin at oracle.com Fri Jul 11 15:24:01 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 11 Jul 2014 19:24:01 +0400 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out Message-ID: <53C00191.8090505@oracle.com> Hi all, please review fix for 6848902. compiler/6589834/Test_ia32.java starts 100 threads with spin-loop inside and on some hosts with small amount of CPU coresit takes too much time. Also there is another issue - test intended to catch interpreter's stack corruption after deoptimization, but it can fail only on VM crash. I've checked how it works w/ JDK 6u17 (where 6589834 was not fixed) and found that issue may not cause VM crash. In suchsituation test just prints message "Bug!", but do not actually fail. I reduced amount of used threads to 2 * availableProcessors() and add more asserts on test results, so now it can catch original issue even if VM doesn't crash. Also, VerifyStackwas added to test's options as it was suggested in original test. After all, test still can reproduce original issue w/ 6u17. Testing: on local machine, automated on all platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ Thanks, Filipp. From david.r.chase at oracle.com Fri Jul 11 16:34:48 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 11 Jul 2014 12:34:48 -0400 Subject: [9] RFR (XS): 8036588 : VerifyFieldClosure fails instanceKlass:3133 In-Reply-To: <53BDCA17.9020404@oracle.com> References: <53BDCA17.9020404@oracle.com> Message-ID: <8ADFA213-D06C-4809-BC86-E391CE67506E@oracle.com> How's this look? http://cr.openjdk.java.net/~drchase/8036588/webrev.01/ Retested with jtreg, also (this time) 900 reps of the bug-tickling test with no error. David On 2014-07-09, at 7:02 PM, Vladimir Kozlov wrote: > Yes, the return_value_is_used() method is incorrect, it does not take into account that the returned value could be used after deoptimization for reallocated objects. > > return_oop is checked by deoptimization only when EliminateAllocations is true. Only in such case and when objects are reallocated GC can happen during deoptimization. > > The fix will also preserve a return value when it is really not used: > > A a = new A(); > (void)foo(); > a.f = 1; > > or simple > > (void)foo(); > > Which is fine since deoptimization code is not critical for performance. > > return_value_is_used() is used only by this code. I would suggest to rename it to returns_pointer() and copy-paste code from CallNode::returns_pointer() (MachCallNode is not based on CallNode). And use it in the check. > > Thanks, > Vladimir > > On 7/8/14 12:13 PM, David Chase wrote: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8036588 (closed because only seen in SQE) >> >> webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.00/ >> >> cause+fix: >> The root cause is use of the wrong liveness information at deoptimization point. >> The old code uses the optimizer's notion of "live" -- but deoptimization transfers to the >> interpreter and which can (will) manipulate values that are dead to the optimizer. >> The trigger is very tricky -- the following things need to happen: >> >> 1) an object D that will be dead is allocated >> 2) a method M is invoked that returns an object F, to only be stored in a field f of D >> 3) the optimizer eliminates the allocation of D and the storefield into D.f >> 4) deoptimization hits an execution of M; deoptimization reallocates D for the >> interpreter; BUT the reallocation triggers a GC, which would forward F if >> it had been correctly noted as live out of the call to M (but the bug is that it >> was not). >> 5) the interpreter evaluates D.f = F (this succeeds) >> 6) before the frame with D in it exits, ANOTHER garbage collection occurs (or perhaps >> GC was running concurrently in some way) and attempts to trace/copy through >> D and D.f. >> 7) Hilarity ensues. >> 8) For extra giggles, this has only ever been observed with -Xmx=32G (or the corresponding >> -XX:MaxRAMFraction= option) plus of course -XX:+DeoptimizeALot. Also setting >> -XX:DeoptimizeALotInterval=1 increases the failure rate to about 10% of test runs. >> There's some additional missing context, because following this recipe to write a simpler >> test for public consumption did not result in a crashing program. >> >> fix: Use a simpler test for "pointer is live from M" -- if the return type is an object, >> then it is "live", at least for the interpreter. >> >> testing: >> jtreg of runtime, gc, compiler >> >> got to the point where I could see fails often enough for the two tests known to trigger this, >> and after the fix neither test was observed to fail even once, even with hundreds of repetitions. >> -------------- 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 Fri Jul 11 17:50:08 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jul 2014 10:50:08 -0700 Subject: [9] RFR (XS): 8036588 : VerifyFieldClosure fails instanceKlass:3133 In-Reply-To: <8ADFA213-D06C-4809-BC86-E391CE67506E@oracle.com> References: <53BDCA17.9020404@oracle.com> <8ADFA213-D06C-4809-BC86-E391CE67506E@oracle.com> Message-ID: <53C023D0.1040305@oracle.com> Looks good. Vladimir On 7/11/14 9:34 AM, David Chase wrote: > How's this look? > > http://cr.openjdk.java.net/~drchase/8036588/webrev.01/ > > Retested with jtreg, also (this time) 900 reps of the bug-tickling test with no error. > > David > > On 2014-07-09, at 7:02 PM, Vladimir Kozlov wrote: > >> Yes, the return_value_is_used() method is incorrect, it does not take into account that the returned value could be used after deoptimization for reallocated objects. >> >> return_oop is checked by deoptimization only when EliminateAllocations is true. Only in such case and when objects are reallocated GC can happen during deoptimization. >> >> The fix will also preserve a return value when it is really not used: >> >> A a = new A(); >> (void)foo(); >> a.f = 1; >> >> or simple >> >> (void)foo(); >> >> Which is fine since deoptimization code is not critical for performance. >> >> return_value_is_used() is used only by this code. I would suggest to rename it to returns_pointer() and copy-paste code from CallNode::returns_pointer() (MachCallNode is not based on CallNode). And use it in the check. >> >> Thanks, >> Vladimir >> >> On 7/8/14 12:13 PM, David Chase wrote: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8036588 (closed because only seen in SQE) >>> >>> webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.00/ >>> >>> cause+fix: >>> The root cause is use of the wrong liveness information at deoptimization point. >>> The old code uses the optimizer's notion of "live" -- but deoptimization transfers to the >>> interpreter and which can (will) manipulate values that are dead to the optimizer. >>> The trigger is very tricky -- the following things need to happen: >>> >>> 1) an object D that will be dead is allocated >>> 2) a method M is invoked that returns an object F, to only be stored in a field f of D >>> 3) the optimizer eliminates the allocation of D and the storefield into D.f >>> 4) deoptimization hits an execution of M; deoptimization reallocates D for the >>> interpreter; BUT the reallocation triggers a GC, which would forward F if >>> it had been correctly noted as live out of the call to M (but the bug is that it >>> was not). >>> 5) the interpreter evaluates D.f = F (this succeeds) >>> 6) before the frame with D in it exits, ANOTHER garbage collection occurs (or perhaps >>> GC was running concurrently in some way) and attempts to trace/copy through >>> D and D.f. >>> 7) Hilarity ensues. >>> 8) For extra giggles, this has only ever been observed with -Xmx=32G (or the corresponding >>> -XX:MaxRAMFraction= option) plus of course -XX:+DeoptimizeALot. Also setting >>> -XX:DeoptimizeALotInterval=1 increases the failure rate to about 10% of test runs. >>> There's some additional missing context, because following this recipe to write a simpler >>> test for public consumption did not result in a crashing program. >>> >>> fix: Use a simpler test for "pointer is live from M" -- if the return type is an object, >>> then it is "live", at least for the interpreter. >>> >>> testing: >>> jtreg of runtime, gc, compiler >>> >>> got to the point where I could see fails often enough for the two tests known to trigger this, >>> and after the fix neither test was observed to fail even once, even with hundreds of repetitions. >>> > From vladimir.kozlov at oracle.com Fri Jul 11 18:33:44 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jul 2014 11:33:44 -0700 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out In-Reply-To: <53C00191.8090505@oracle.com> References: <53C00191.8090505@oracle.com> Message-ID: <53C02E08.1070406@oracle.com> 2 * availableProcessors() is still very big on Sparc machines (could be > 100). Do we need more threads then available processors for bug reproduction? Do not use one symbol f(), g() methods names. Use something like foo(), bar() or test1(), test2(). thanks, Vladimir On 7/11/14 8:24 AM, Filipp Zhinkin wrote: > Hi all, > > please review fix for 6848902. > > compiler/6589834/Test_ia32.java starts 100 threads with spin-loop inside > and on some hosts with small amount of CPU coresit takes too much time. > > Also there is another issue - test intended to catch interpreter's stack > corruption after deoptimization, but it can fail only on VM crash. > I've checked how it works w/ JDK 6u17 (where 6589834 was not fixed) and > found that issue may not cause VM crash. In suchsituation test just > prints message "Bug!", but do not actually fail. > > I reduced amount of used threads to 2 * availableProcessors() > and add more asserts on test results, so now it can catch original > issue even if VM doesn't crash. > > Also, VerifyStackwas added to test's options as it was suggested in > original test. > > After all, test still can reproduce original issue w/ 6u17. > > Testing: on local machine, automated on all platforms. > Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 > Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ > > Thanks, > Filipp. From david.r.chase at oracle.com Fri Jul 11 19:42:08 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 11 Jul 2014 15:42:08 -0400 Subject: [9] RFR (XS): 8036588 : VerifyFieldClosure fails instanceKlass:3133 In-Reply-To: <53C023D0.1040305@oracle.com> References: <53BDCA17.9020404@oracle.com> <8ADFA213-D06C-4809-BC86-E391CE67506E@oracle.com> <53C023D0.1040305@oracle.com> Message-ID: Thanks much (and Igor also, and John Rose, who I just now realize I left off the list of reviewers), it is now in the hands of the Meddling Medium. On 2014-07-11, at 1:50 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 7/11/14 9:34 AM, David Chase wrote: >> How's this look? >> >> http://cr.openjdk.java.net/~drchase/8036588/webrev.01/ >> >> Retested with jtreg, also (this time) 900 reps of the bug-tickling test with no error. >> >> David >> >> On 2014-07-09, at 7:02 PM, Vladimir Kozlov wrote: >> >>> Yes, the return_value_is_used() method is incorrect, it does not take into account that the returned value could be used after deoptimization for reallocated objects. >>> >>> return_oop is checked by deoptimization only when EliminateAllocations is true. Only in such case and when objects are reallocated GC can happen during deoptimization. >>> >>> The fix will also preserve a return value when it is really not used: >>> >>> A a = new A(); >>> (void)foo(); >>> a.f = 1; >>> >>> or simple >>> >>> (void)foo(); >>> >>> Which is fine since deoptimization code is not critical for performance. >>> >>> return_value_is_used() is used only by this code. I would suggest to rename it to returns_pointer() and copy-paste code from CallNode::returns_pointer() (MachCallNode is not based on CallNode). And use it in the check. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/8/14 12:13 PM, David Chase wrote: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8036588 (closed because only seen in SQE) >>>> >>>> webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.00/ >>>> >>>> cause+fix: >>>> The root cause is use of the wrong liveness information at deoptimization point. >>>> The old code uses the optimizer's notion of "live" -- but deoptimization transfers to the >>>> interpreter and which can (will) manipulate values that are dead to the optimizer. >>>> The trigger is very tricky -- the following things need to happen: >>>> >>>> 1) an object D that will be dead is allocated >>>> 2) a method M is invoked that returns an object F, to only be stored in a field f of D >>>> 3) the optimizer eliminates the allocation of D and the storefield into D.f >>>> 4) deoptimization hits an execution of M; deoptimization reallocates D for the >>>> interpreter; BUT the reallocation triggers a GC, which would forward F if >>>> it had been correctly noted as live out of the call to M (but the bug is that it >>>> was not). >>>> 5) the interpreter evaluates D.f = F (this succeeds) >>>> 6) before the frame with D in it exits, ANOTHER garbage collection occurs (or perhaps >>>> GC was running concurrently in some way) and attempts to trace/copy through >>>> D and D.f. >>>> 7) Hilarity ensues. >>>> 8) For extra giggles, this has only ever been observed with -Xmx=32G (or the corresponding >>>> -XX:MaxRAMFraction= option) plus of course -XX:+DeoptimizeALot. Also setting >>>> -XX:DeoptimizeALotInterval=1 increases the failure rate to about 10% of test runs. >>>> There's some additional missing context, because following this recipe to write a simpler >>>> test for public consumption did not result in a crashing program. >>>> >>>> fix: Use a simpler test for "pointer is live from M" -- if the return type is an object, >>>> then it is "live", at least for the interpreter. >>>> >>>> testing: >>>> jtreg of runtime, gc, compiler >>>> >>>> got to the point where I could see fails often enough for the two tests known to trigger this, >>>> and after the fix neither test was observed to fail even once, even with hundreds of repetitions. >>>> >> -------------- 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 Fri Jul 11 20:15:42 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 11 Jul 2014 16:15:42 -0400 Subject: [9] RFR (XS): 8036588 : VerifyFieldClosure fails instanceKlass:3133 In-Reply-To: References: <53BDCA17.9020404@oracle.com> <8ADFA213-D06C-4809-BC86-E391CE67506E@oracle.com> <53C023D0.1040305@oracle.com> Message-ID: Whoops -- return_value_is_used is used by other code. ./cpu/x86/vm/x86_32.ad: if ((rt == T_FLOAT || rt == T_DOUBLE) && !return_value_is_used()) { if ((rt == T_FLOAT || rt == T_DOUBLE) && !return_value_is_used()) { // A C runtime call where the return value is unused. In SSE2+ // mode the result needs to be removed from the FPU stack. It's // likely that this function call could be removed by the // optimizer if the C function is a pure function. __ ffree(0); How about that? I think I will put that method back and keep the new modified one under the new name; it seems that this depends on the original intent of that code. New webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.02 I'm doing a test run with jprt. David On 2014-07-11, at 3:42 PM, David Chase wrote: > Thanks much (and Igor also, and John Rose, who I just now realize I left off the list of reviewers), it is now in the hands of the Meddling Medium. > > On 2014-07-11, at 1:50 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Vladimir >> >> On 7/11/14 9:34 AM, David Chase wrote: >>> How's this look? >>> >>> http://cr.openjdk.java.net/~drchase/8036588/webrev.01/ >>> >>> Retested with jtreg, also (this time) 900 reps of the bug-tickling test with no error. >>> >>> David >>> >>> On 2014-07-09, at 7:02 PM, Vladimir Kozlov wrote: >>> >>>> Yes, the return_value_is_used() method is incorrect, it does not take into account that the returned value could be used after deoptimization for reallocated objects. >>>> >>>> return_oop is checked by deoptimization only when EliminateAllocations is true. Only in such case and when objects are reallocated GC can happen during deoptimization. >>>> >>>> The fix will also preserve a return value when it is really not used: >>>> >>>> A a = new A(); >>>> (void)foo(); >>>> a.f = 1; >>>> >>>> or simple >>>> >>>> (void)foo(); >>>> >>>> Which is fine since deoptimization code is not critical for performance. >>>> >>>> return_value_is_used() is used only by this code. I would suggest to rename it to returns_pointer() and copy-paste code from CallNode::returns_pointer() (MachCallNode is not based on CallNode). And use it in the check. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/8/14 12:13 PM, David Chase wrote: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8036588 (closed because only seen in SQE) >>>>> >>>>> webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.00/ >>>>> >>>>> cause+fix: >>>>> The root cause is use of the wrong liveness information at deoptimization point. >>>>> The old code uses the optimizer's notion of "live" -- but deoptimization transfers to the >>>>> interpreter and which can (will) manipulate values that are dead to the optimizer. >>>>> The trigger is very tricky -- the following things need to happen: >>>>> >>>>> 1) an object D that will be dead is allocated >>>>> 2) a method M is invoked that returns an object F, to only be stored in a field f of D >>>>> 3) the optimizer eliminates the allocation of D and the storefield into D.f >>>>> 4) deoptimization hits an execution of M; deoptimization reallocates D for the >>>>> interpreter; BUT the reallocation triggers a GC, which would forward F if >>>>> it had been correctly noted as live out of the call to M (but the bug is that it >>>>> was not). >>>>> 5) the interpreter evaluates D.f = F (this succeeds) >>>>> 6) before the frame with D in it exits, ANOTHER garbage collection occurs (or perhaps >>>>> GC was running concurrently in some way) and attempts to trace/copy through >>>>> D and D.f. >>>>> 7) Hilarity ensues. >>>>> 8) For extra giggles, this has only ever been observed with -Xmx=32G (or the corresponding >>>>> -XX:MaxRAMFraction= option) plus of course -XX:+DeoptimizeALot. Also setting >>>>> -XX:DeoptimizeALotInterval=1 increases the failure rate to about 10% of test runs. >>>>> There's some additional missing context, because following this recipe to write a simpler >>>>> test for public consumption did not result in a crashing program. >>>>> >>>>> fix: Use a simpler test for "pointer is live from M" -- if the return type is an object, >>>>> then it is "live", at least for the interpreter. >>>>> >>>>> testing: >>>>> jtreg of runtime, gc, compiler >>>>> >>>>> got to the point where I could see fails often enough for the two tests known to trigger this, >>>>> and after the fix neither test was observed to fail even once, even with hundreds of repetitions. >>>>> >>> > -------------- 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 Fri Jul 11 20:46:19 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jul 2014 13:46:19 -0700 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53BF83FA.3040908@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> Message-ID: <53C04D1B.2050902@oracle.com> Good. thanks, Vladimir On 7/10/14 11:28 PM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > >> Thank you for doing this cleanup, Tobias. >> >> Looks good. Small note, in divnode.cpp please use explicit NULL checks: >> >> if (in(0) != NULL) { > > Done. New webrev: > http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >> On 7/3/14 11:50 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch for 8040213 that finishes Vladimir?s >>> work [1]. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040213 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.00/ >>> * >>> **Problem* >>> Not all nodes that are modified during C2 optimization are put on the >>> IGVN worklist. >>> >>> *Solution* >>> Verification code is added that checks if (i) modified nodes are put on >>> the IGVN worklist and (ii) modified nodes are processed by >>> PhaseIterGVN::transform_old(..). All code that fails verification during >>> testing is fixed. >>> * >>> **Testing:* >>> - JPRT >>> - Full CTW >>> - Nashorn + Octane >>> - UTE (full testlist, BigApps, JRuby) >>> - VM (NSK) testbase >>> - Refworkload (reference_server) >>> - VMSQE.adhoc.JPRT.full batch >>> >>> Thanks, >>> Tobias >>> >>> [1] http://cr.openjdk.java.net/~kvn/8040213/webrev/ > From vladimir.kozlov at oracle.com Fri Jul 11 20:51:57 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jul 2014 13:51:57 -0700 Subject: [9] RFR (XS): 8036588 : VerifyFieldClosure fails instanceKlass:3133 In-Reply-To: References: <53BDCA17.9020404@oracle.com> <8ADFA213-D06C-4809-BC86-E391CE67506E@oracle.com> <53C023D0.1040305@oracle.com> Message-ID: <53C04E6D.60107@oracle.com> Sorry, I grepped only opto/ directory. webrev.02 looks good. Thanks, Vladimir On 7/11/14 1:15 PM, David Chase wrote: > Whoops -- return_value_is_used is used by other code. > > ./cpu/x86/vm/x86_32.ad: if ((rt == T_FLOAT || rt == T_DOUBLE) && !return_value_is_used()) { > > if ((rt == T_FLOAT || rt == T_DOUBLE) && !return_value_is_used()) { > // A C runtime call where the return value is unused. In SSE2+ > // mode the result needs to be removed from the FPU stack. It's > // likely that this function call could be removed by the > // optimizer if the C function is a pure function. > __ ffree(0); > > How about that? > I think I will put that method back and keep the new modified one under the new name; it seems that this depends on the original intent of that code. > > New webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.02 > I'm doing a test run with jprt. > > David > > On 2014-07-11, at 3:42 PM, David Chase wrote: > >> Thanks much (and Igor also, and John Rose, who I just now realize I left off the list of reviewers), it is now in the hands of the Meddling Medium. >> >> On 2014-07-11, at 1:50 PM, Vladimir Kozlov wrote: >> >>> Looks good. >>> >>> Vladimir >>> >>> On 7/11/14 9:34 AM, David Chase wrote: >>>> How's this look? >>>> >>>> http://cr.openjdk.java.net/~drchase/8036588/webrev.01/ >>>> >>>> Retested with jtreg, also (this time) 900 reps of the bug-tickling test with no error. >>>> >>>> David >>>> >>>> On 2014-07-09, at 7:02 PM, Vladimir Kozlov wrote: >>>> >>>>> Yes, the return_value_is_used() method is incorrect, it does not take into account that the returned value could be used after deoptimization for reallocated objects. >>>>> >>>>> return_oop is checked by deoptimization only when EliminateAllocations is true. Only in such case and when objects are reallocated GC can happen during deoptimization. >>>>> >>>>> The fix will also preserve a return value when it is really not used: >>>>> >>>>> A a = new A(); >>>>> (void)foo(); >>>>> a.f = 1; >>>>> >>>>> or simple >>>>> >>>>> (void)foo(); >>>>> >>>>> Which is fine since deoptimization code is not critical for performance. >>>>> >>>>> return_value_is_used() is used only by this code. I would suggest to rename it to returns_pointer() and copy-paste code from CallNode::returns_pointer() (MachCallNode is not based on CallNode). And use it in the check. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 7/8/14 12:13 PM, David Chase wrote: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8036588 (closed because only seen in SQE) >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.00/ >>>>>> >>>>>> cause+fix: >>>>>> The root cause is use of the wrong liveness information at deoptimization point. >>>>>> The old code uses the optimizer's notion of "live" -- but deoptimization transfers to the >>>>>> interpreter and which can (will) manipulate values that are dead to the optimizer. >>>>>> The trigger is very tricky -- the following things need to happen: >>>>>> >>>>>> 1) an object D that will be dead is allocated >>>>>> 2) a method M is invoked that returns an object F, to only be stored in a field f of D >>>>>> 3) the optimizer eliminates the allocation of D and the storefield into D.f >>>>>> 4) deoptimization hits an execution of M; deoptimization reallocates D for the >>>>>> interpreter; BUT the reallocation triggers a GC, which would forward F if >>>>>> it had been correctly noted as live out of the call to M (but the bug is that it >>>>>> was not). >>>>>> 5) the interpreter evaluates D.f = F (this succeeds) >>>>>> 6) before the frame with D in it exits, ANOTHER garbage collection occurs (or perhaps >>>>>> GC was running concurrently in some way) and attempts to trace/copy through >>>>>> D and D.f. >>>>>> 7) Hilarity ensues. >>>>>> 8) For extra giggles, this has only ever been observed with -Xmx=32G (or the corresponding >>>>>> -XX:MaxRAMFraction= option) plus of course -XX:+DeoptimizeALot. Also setting >>>>>> -XX:DeoptimizeALotInterval=1 increases the failure rate to about 10% of test runs. >>>>>> There's some additional missing context, because following this recipe to write a simpler >>>>>> test for public consumption did not result in a crashing program. >>>>>> >>>>>> fix: Use a simpler test for "pointer is live from M" -- if the return type is an object, >>>>>> then it is "live", at least for the interpreter. >>>>>> >>>>>> testing: >>>>>> jtreg of runtime, gc, compiler >>>>>> >>>>>> got to the point where I could see fails often enough for the two tests known to trigger this, >>>>>> and after the fix neither test was observed to fail even once, even with hundreds of repetitions. >>>>>> >>>> >> > From tobias.hartmann at oracle.com Mon Jul 14 06:27:51 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 14 Jul 2014 08:27:51 +0200 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53C04D1B.2050902@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C04D1B.2050902@oracle.com> Message-ID: <53C37867.8080806@oracle.com> Thank you, Vladimir. Best, Tobias On 11.07.2014 22:46, Vladimir Kozlov wrote: > Good. > > thanks, > Vladimir > > On 7/10/14 11:28 PM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >>> Thank you for doing this cleanup, Tobias. >>> >>> Looks good. Small note, in divnode.cpp please use explicit NULL checks: >>> >>> if (in(0) != NULL) { >> >> Done. New webrev: >> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Vladimir >>> >>> On 7/3/14 11:50 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch for 8040213 that finishes Vladimir?s >>>> work [1]. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040213 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.00/ >>>> * >>>> **Problem* >>>> Not all nodes that are modified during C2 optimization are put on the >>>> IGVN worklist. >>>> >>>> *Solution* >>>> Verification code is added that checks if (i) modified nodes are >>>> put on >>>> the IGVN worklist and (ii) modified nodes are processed by >>>> PhaseIterGVN::transform_old(..). All code that fails verification >>>> during >>>> testing is fixed. >>>> * >>>> **Testing:* >>>> - JPRT >>>> - Full CTW >>>> - Nashorn + Octane >>>> - UTE (full testlist, BigApps, JRuby) >>>> - VM (NSK) testbase >>>> - Refworkload (reference_server) >>>> - VMSQE.adhoc.JPRT.full batch >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] http://cr.openjdk.java.net/~kvn/8040213/webrev/ >> From filipp.zhinkin at oracle.com Mon Jul 14 15:13:28 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 14 Jul 2014 19:13:28 +0400 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out In-Reply-To: <53C02E08.1070406@oracle.com> References: <53C00191.8090505@oracle.com> <53C02E08.1070406@oracle.com> Message-ID: <53C3F398.7030205@oracle.com> Hi Vladimir, thank you for watching at it. On 07/11/2014 10:33 PM, Vladimir Kozlov wrote: > 2 * availableProcessors() is still very big on Sparc machines (could > be > 100). Do we need more threads then available processors for bug > reproduction? The more threads we have, the more our chances to reproduce issue. Issue could be reproduced when method deoptimized at particular safepoint and I don't see how to make this test more stable. I executed this test w/ jdk6u17 on different platforms w/ different options and here are results for three different approaches to choose threads count: a) 2 * availableProcessors: Test failed 111 times. Test passed 57 times. b) 1 * availableProcessors: Test failed 58 times. Test passed 100 times. c) min(100, 2 * availableProcessors): Test failed: 100 times. Test passed: 68 times. So I think we can cut off threads count by 100. > > Do not use one symbol f(), g() methods names. Use something like > foo(), bar() or test1(), test2(). Sure, I'll rename it. Thanks, Filipp. > > thanks, > Vladimir > > On 7/11/14 8:24 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review fix for 6848902. >> >> compiler/6589834/Test_ia32.java starts 100 threads with spin-loop inside >> and on some hosts with small amount of CPU coresit takes too much time. >> >> Also there is another issue - test intended to catch interpreter's stack >> corruption after deoptimization, but it can fail only on VM crash. >> I've checked how it works w/ JDK 6u17 (where 6589834 was not fixed) and >> found that issue may not cause VM crash. In suchsituation test just >> prints message "Bug!", but do not actually fail. >> >> I reduced amount of used threads to 2 * availableProcessors() >> and add more asserts on test results, so now it can catch original >> issue even if VM doesn't crash. >> >> Also, VerifyStackwas added to test's options as it was suggested in >> original test. >> >> After all, test still can reproduce original issue w/ 6u17. >> >> Testing: on local machine, automated on all platforms. >> Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ >> >> Thanks, >> Filipp. From aleksey.shipilev at oracle.com Mon Jul 14 15:42:50 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 14 Jul 2014 19:42:50 +0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier Message-ID: <53C3FA7A.1070800@oracle.com> Hi guys, Any comments about pushing something like this into HS? https://bugs.openjdk.java.net/browse/JDK-8050149 http://cr.openjdk.java.net/~shade/8050149/webrev.01/ This is a follow up for: https://bugs.openjdk.java.net/browse/JDK-8050147 I think the actual switch, if any, should happen in JDK-8050147, but I would like to explore the alternatives here. Performance runs are underway. Are there any other alternatives for StoreLoad missing? Thanks, -Aleksey. From filipp.zhinkin at oracle.com Mon Jul 14 16:23:42 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 14 Jul 2014 20:23:42 +0400 Subject: RFR (XS): 8050144 : Remove '-client' from compiler/8004051/Test8004051.java's options Message-ID: <53C4040E.4090506@oracle.com> Hi all, please review tiny fix that eliminates '-client' flag from Test8004051.java's options list. This test fails when we run it on 32-bit platforms with some C2-specific options passed externally. JTreg prepends external options to list of options declared in the test, so we can't just run it with '-server'. Obvious solution is to remove '-client'. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8050144 Webrev: http://cr.openjdk.java.net/~fzhinkin/8050144/webrev.00/ Testing: on local machine w/ 32-bit JDK and -XX:-AlignVector. Thanks, Filipp. From vladimir.kozlov at oracle.com Mon Jul 14 16:58:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jul 2014 09:58:00 -0700 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out In-Reply-To: <53C3F398.7030205@oracle.com> References: <53C00191.8090505@oracle.com> <53C02E08.1070406@oracle.com> <53C3F398.7030205@oracle.com> Message-ID: <53C40C18.7010406@oracle.com> On 7/14/14 8:13 AM, Filipp Zhinkin wrote: > Hi Vladimir, > > thank you for watching at it. > > On 07/11/2014 10:33 PM, Vladimir Kozlov wrote: >> 2 * availableProcessors() is still very big on Sparc machines (could be > 100). Do we need more threads then available >> processors for bug reproduction? > The more threads we have, the more our chances to reproduce issue. > > Issue could be reproduced when method deoptimized at particular safepoint > and I don't see how to make this test more stable. > > I executed this test w/ jdk6u17 on different platforms w/ different options > and here are results for three different approaches to choose threads count: > > a) 2 * availableProcessors: > Test failed 111 times. > Test passed 57 times. > > b) 1 * availableProcessors: > Test failed 58 times. > Test passed 100 times. > > c) min(100, 2 * availableProcessors): > Test failed: 100 times. > Test passed: 68 times. I think you should use this c) Thanks, Vladimir > > So I think we can cut off threads count by 100. >> >> Do not use one symbol f(), g() methods names. Use something like foo(), bar() or test1(), test2(). > Sure, I'll rename it. > > Thanks, > Filipp. >> >> thanks, >> Vladimir >> >> On 7/11/14 8:24 AM, Filipp Zhinkin wrote: >>> Hi all, >>> >>> please review fix for 6848902. >>> >>> compiler/6589834/Test_ia32.java starts 100 threads with spin-loop inside >>> and on some hosts with small amount of CPU coresit takes too much time. >>> >>> Also there is another issue - test intended to catch interpreter's stack >>> corruption after deoptimization, but it can fail only on VM crash. >>> I've checked how it works w/ JDK 6u17 (where 6589834 was not fixed) and >>> found that issue may not cause VM crash. In suchsituation test just >>> prints message "Bug!", but do not actually fail. >>> >>> I reduced amount of used threads to 2 * availableProcessors() >>> and add more asserts on test results, so now it can catch original >>> issue even if VM doesn't crash. >>> >>> Also, VerifyStackwas added to test's options as it was suggested in >>> original test. >>> >>> After all, test still can reproduce original issue w/ 6u17. >>> >>> Testing: on local machine, automated on all platforms. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 >>> Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ >>> >>> Thanks, >>> Filipp. > From vladimir.kozlov at oracle.com Mon Jul 14 17:00:09 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jul 2014 10:00:09 -0700 Subject: RFR (XS): 8050144 : Remove '-client' from compiler/8004051/Test8004051.java's options In-Reply-To: <53C4040E.4090506@oracle.com> References: <53C4040E.4090506@oracle.com> Message-ID: <53C40C99.1030201@oracle.com> Good. Vladimir On 7/14/14 9:23 AM, Filipp Zhinkin wrote: > Hi all, > > please review tiny fix that eliminates '-client' flag from Test8004051.java's options list. > > This test fails when we run it on 32-bit platforms with some C2-specific options passed externally. > JTreg prepends external options to list of options declared in the test, so we can't just run it with '-server'. > > Obvious solution is to remove '-client'. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8050144 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8050144/webrev.00/ > Testing: on local machine w/ 32-bit JDK and -XX:-AlignVector. > > Thanks, > Filipp. > > From vladimir.kozlov at oracle.com Mon Jul 14 17:33:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jul 2014 10:33:33 -0700 Subject: 8046698: assert(false) failed: only Initialize or AddP expected macro.cpp:943 In-Reply-To: References: <539B2263.3070007@oracle.com> Message-ID: <53C4146D.8080804@oracle.com> Yes, this version looks good I think. Thanks, Vladimir On 6/17/14 8:33 AM, Roland Westrelin wrote: > Thanks for reviewing this, Vladimir. > >> May be we should return 'this' when anything but CheckCastPP, Initialize, AddP references the raw result of Allocate? >> See lines 2882-2899 in escape.cpp. Returning NULL when the result is referenced in other cases is bad because NULL is indication of it is not used after Initialize (lines 2792-2804 in escape.cpp). >> >> Could you investigate more? May be add assert to catch all cases. It could be the fix is correct because only Phi nodes could reference it. > > I ran ctw, refworkload reference_server, all jtreg tests, and ute?s nsk.stress, vm.compiler, vm.regression, nsk.regression, nsk.monitoring with an assert to catch uses other than CheckCastPP, Initialize, AddP. The only other use I found was a Phi for the test case that this change fixes. > > Should I go with this as a fix? > > http://cr.openjdk.java.net/~roland/8046698/webrev.01/ > > Roland. > >> >> Thanks, >> Vladimir >> >> On 6/13/14 8:31 AM, Roland Westrelin wrote: >>> >>> Because of a try/catch in a loop, a Allocate node is in the loop body while the uses of the results are outside the loop (see test case in webrev). Then loop unswitching clones the loop body (including the Allocate but not the Initialization node and other uses of the result projection) and adds a Phi to connect the Allocate nodes to the loop exit. CallNode::result_cast() doesn?t expect a Phi as output so returns NULL which to the allocation elimination code means no use for the allocation (allocation can be eliminated). The fix changes CallNode::result_cast() so it returns the CallNode when the result projection has a Phi as output which causes the allocation elimination code to skip that allocation. Every call to result_cast() is already followed by a check for is_CheckCastPP() so no other change is needed. >>> >>> http://cr.openjdk.java.net/~roland/8046698/webrev.00/ >>> >>> Roland. >>> > From filipp.zhinkin at oracle.com Mon Jul 14 18:02:04 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 14 Jul 2014 22:02:04 +0400 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out In-Reply-To: <53C40C18.7010406@oracle.com> References: <53C00191.8090505@oracle.com> <53C02E08.1070406@oracle.com> <53C3F398.7030205@oracle.com> <53C40C18.7010406@oracle.com> Message-ID: <53C41B1C.8000502@oracle.com> Here is new webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.01/ What was done: - threads count is min(100, 2 * availableProcessors) now; - methods f and g were renamed to invokeArrayClone and verifyArguments. Thanks, Filipp. On 07/14/2014 08:58 PM, Vladimir Kozlov wrote: > On 7/14/14 8:13 AM, Filipp Zhinkin wrote: >> Hi Vladimir, >> >> thank you for watching at it. >> >> On 07/11/2014 10:33 PM, Vladimir Kozlov wrote: >>> 2 * availableProcessors() is still very big on Sparc machines (could >>> be > 100). Do we need more threads then available >>> processors for bug reproduction? >> The more threads we have, the more our chances to reproduce issue. >> >> Issue could be reproduced when method deoptimized at particular >> safepoint >> and I don't see how to make this test more stable. >> >> I executed this test w/ jdk6u17 on different platforms w/ different >> options >> and here are results for three different approaches to choose threads >> count: >> >> a) 2 * availableProcessors: >> Test failed 111 times. >> Test passed 57 times. >> >> b) 1 * availableProcessors: >> Test failed 58 times. >> Test passed 100 times. >> >> c) min(100, 2 * availableProcessors): >> Test failed: 100 times. >> Test passed: 68 times. > > I think you should use this c) > > Thanks, > Vladimir > >> >> So I think we can cut off threads count by 100. >>> >>> Do not use one symbol f(), g() methods names. Use something like >>> foo(), bar() or test1(), test2(). >> Sure, I'll rename it. >> >> Thanks, >> Filipp. >>> >>> thanks, >>> Vladimir >>> >>> On 7/11/14 8:24 AM, Filipp Zhinkin wrote: >>>> Hi all, >>>> >>>> please review fix for 6848902. >>>> >>>> compiler/6589834/Test_ia32.java starts 100 threads with spin-loop >>>> inside >>>> and on some hosts with small amount of CPU coresit takes too much >>>> time. >>>> >>>> Also there is another issue - test intended to catch interpreter's >>>> stack >>>> corruption after deoptimization, but it can fail only on VM crash. >>>> I've checked how it works w/ JDK 6u17 (where 6589834 was not fixed) >>>> and >>>> found that issue may not cause VM crash. In suchsituation test just >>>> prints message "Bug!", but do not actually fail. >>>> >>>> I reduced amount of used threads to 2 * availableProcessors() >>>> and add more asserts on test results, so now it can catch original >>>> issue even if VM doesn't crash. >>>> >>>> Also, VerifyStackwas added to test's options as it was suggested in >>>> original test. >>>> >>>> After all, test still can reproduce original issue w/ 6u17. >>>> >>>> Testing: on local machine, automated on all platforms. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 >>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ >>>> >>>> Thanks, >>>> Filipp. >> From filipp.zhinkin at oracle.com Mon Jul 14 18:02:39 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 14 Jul 2014 22:02:39 +0400 Subject: RFR (XS): 8050144 : Remove '-client' from compiler/8004051/Test8004051.java's options In-Reply-To: <53C40C99.1030201@oracle.com> References: <53C4040E.4090506@oracle.com> <53C40C99.1030201@oracle.com> Message-ID: <53C41B3F.70209@oracle.com> Vladimir, thank you for review. Regards, Filipp. On 07/14/2014 09:00 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 7/14/14 9:23 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review tiny fix that eliminates '-client' flag from >> Test8004051.java's options list. >> >> This test fails when we run it on 32-bit platforms with some >> C2-specific options passed externally. >> JTreg prepends external options to list of options declared in the >> test, so we can't just run it with '-server'. >> >> Obvious solution is to remove '-client'. >> >> JBS issue: https://bugs.openjdk.java.net/browse/JDK-8050144 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8050144/webrev.00/ >> Testing: on local machine w/ 32-bit JDK and -XX:-AlignVector. >> >> Thanks, >> Filipp. >> >> From vladimir.kozlov at oracle.com Mon Jul 14 19:29:02 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jul 2014 12:29:02 -0700 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out In-Reply-To: <53C41B1C.8000502@oracle.com> References: <53C00191.8090505@oracle.com> <53C02E08.1070406@oracle.com> <53C3F398.7030205@oracle.com> <53C40C18.7010406@oracle.com> <53C41B1C.8000502@oracle.com> Message-ID: <53C42F7E.4050309@oracle.com> Looks good. "is compiled": + * Wait until InlinedArrayCloneTestCase::invokeArrayClone compiled. Small notes. Keep it on one line (no need for new webrev): 63 return InlinedArrayCloneTestCase.verifyArguments(1, 2, arr.clone(), 3, 64 4); Thanks, Vladimir On 7/14/14 11:02 AM, Filipp Zhinkin wrote: > Here is new webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.01/ > > What was done: > - threads count is min(100, 2 * availableProcessors) now; > - methods f and g were renamed to invokeArrayClone and verifyArguments. > > Thanks, > Filipp. > > On 07/14/2014 08:58 PM, Vladimir Kozlov wrote: >> On 7/14/14 8:13 AM, Filipp Zhinkin wrote: >>> Hi Vladimir, >>> >>> thank you for watching at it. >>> >>> On 07/11/2014 10:33 PM, Vladimir Kozlov wrote: >>>> 2 * availableProcessors() is still very big on Sparc machines (could >>>> be > 100). Do we need more threads then available >>>> processors for bug reproduction? >>> The more threads we have, the more our chances to reproduce issue. >>> >>> Issue could be reproduced when method deoptimized at particular >>> safepoint >>> and I don't see how to make this test more stable. >>> >>> I executed this test w/ jdk6u17 on different platforms w/ different >>> options >>> and here are results for three different approaches to choose threads >>> count: >>> >>> a) 2 * availableProcessors: >>> Test failed 111 times. >>> Test passed 57 times. >>> >>> b) 1 * availableProcessors: >>> Test failed 58 times. >>> Test passed 100 times. >>> >>> c) min(100, 2 * availableProcessors): >>> Test failed: 100 times. >>> Test passed: 68 times. >> >> I think you should use this c) >> >> Thanks, >> Vladimir >> >>> >>> So I think we can cut off threads count by 100. >>>> >>>> Do not use one symbol f(), g() methods names. Use something like >>>> foo(), bar() or test1(), test2(). >>> Sure, I'll rename it. >>> >>> Thanks, >>> Filipp. >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 7/11/14 8:24 AM, Filipp Zhinkin wrote: >>>>> Hi all, >>>>> >>>>> please review fix for 6848902. >>>>> >>>>> compiler/6589834/Test_ia32.java starts 100 threads with spin-loop >>>>> inside >>>>> and on some hosts with small amount of CPU coresit takes too much >>>>> time. >>>>> >>>>> Also there is another issue - test intended to catch interpreter's >>>>> stack >>>>> corruption after deoptimization, but it can fail only on VM crash. >>>>> I've checked how it works w/ JDK 6u17 (where 6589834 was not fixed) >>>>> and >>>>> found that issue may not cause VM crash. In suchsituation test just >>>>> prints message "Bug!", but do not actually fail. >>>>> >>>>> I reduced amount of used threads to 2 * availableProcessors() >>>>> and add more asserts on test results, so now it can catch original >>>>> issue even if VM doesn't crash. >>>>> >>>>> Also, VerifyStackwas added to test's options as it was suggested in >>>>> original test. >>>>> >>>>> After all, test still can reproduce original issue w/ 6u17. >>>>> >>>>> Testing: on local machine, automated on all platforms. >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 >>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ >>>>> >>>>> Thanks, >>>>> Filipp. >>> > From aleksey.shipilev at oracle.com Mon Jul 14 20:01:19 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jul 2014 00:01:19 +0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: <53C3FA7A.1070800@oracle.com> References: <53C3FA7A.1070800@oracle.com> Message-ID: <53C4370F.2080209@oracle.com> Had an off-list discussion with Dave Dice, and figured to throw in a few other options. Let me know if you think something else is missing from this list to try: http://cr.openjdk.java.net/~shade/8050149/webrev.02/ -Aleksey. On 07/14/2014 07:42 PM, Aleksey Shipilev wrote: > Hi guys, > > Any comments about pushing something like this into HS? > https://bugs.openjdk.java.net/browse/JDK-8050149 > http://cr.openjdk.java.net/~shade/8050149/webrev.01/ > > This is a follow up for: > https://bugs.openjdk.java.net/browse/JDK-8050147 > > I think the actual switch, if any, should happen in JDK-8050147, but I > would like to explore the alternatives here. Performance runs are > underway. Are there any other alternatives for StoreLoad missing? > > Thanks, > -Aleksey. > From vladimir.kozlov at oracle.com Mon Jul 14 21:39:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jul 2014 14:39:14 -0700 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: <53C4370F.2080209@oracle.com> References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> Message-ID: <53C44E02.3040306@oracle.com> Sorry Aleksey, I don't think this code should be in our sources. The patch is small enough to keep it separately when you need it. And the problem is not as big as your previous experimental codes. Thanks, Vladimir On 7/14/14 1:01 PM, Aleksey Shipilev wrote: > Had an off-list discussion with Dave Dice, and figured to throw in a few > other options. Let me know if you think something else is missing from > this list to try: > http://cr.openjdk.java.net/~shade/8050149/webrev.02/ > > -Aleksey. > > On 07/14/2014 07:42 PM, Aleksey Shipilev wrote: >> Hi guys, >> >> Any comments about pushing something like this into HS? >> https://bugs.openjdk.java.net/browse/JDK-8050149 >> http://cr.openjdk.java.net/~shade/8050149/webrev.01/ >> >> This is a follow up for: >> https://bugs.openjdk.java.net/browse/JDK-8050147 >> >> I think the actual switch, if any, should happen in JDK-8050147, but I >> would like to explore the alternatives here. Performance runs are >> underway. Are there any other alternatives for StoreLoad missing? >> >> Thanks, >> -Aleksey. >> > From aleksey.shipilev at oracle.com Mon Jul 14 21:53:26 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jul 2014 01:53:26 +0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: <53C44E02.3040306@oracle.com> References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> <53C44E02.3040306@oracle.com> Message-ID: <53C45156.3090102@oracle.com> Sure, no problems with (non-)inclusion. My question still stands: are there other things I should try to implement as StoreLoad barrier alternative? Thanks, -Aleksey. On 07/15/2014 01:39 AM, Vladimir Kozlov wrote: > Sorry Aleksey, I don't think this code should be in our sources. > The patch is small enough to keep it separately when you need it. And > the problem is not as big as your previous experimental codes. > > Thanks, > Vladimir > > On 7/14/14 1:01 PM, Aleksey Shipilev wrote: >> Had an off-list discussion with Dave Dice, and figured to throw in a few >> other options. Let me know if you think something else is missing from >> this list to try: >> http://cr.openjdk.java.net/~shade/8050149/webrev.02/ >> >> -Aleksey. >> >> On 07/14/2014 07:42 PM, Aleksey Shipilev wrote: >>> Hi guys, >>> >>> Any comments about pushing something like this into HS? >>> https://bugs.openjdk.java.net/browse/JDK-8050149 >>> http://cr.openjdk.java.net/~shade/8050149/webrev.01/ >>> >>> This is a follow up for: >>> https://bugs.openjdk.java.net/browse/JDK-8050147 >>> >>> I think the actual switch, if any, should happen in JDK-8050147, but I >>> would like to explore the alternatives here. Performance runs are >>> underway. Are there any other alternatives for StoreLoad missing? >>> >>> Thanks, >>> -Aleksey. >>> >> From vitalyd at gmail.com Mon Jul 14 22:00:10 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 14 Jul 2014 18:00:10 -0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: <53C45156.3090102@oracle.com> References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> <53C44E02.3040306@oracle.com> <53C45156.3090102@oracle.com> Message-ID: In case you're interested (and haven't checked yourself), both clang(3.4.1) and gcc(4.9) use mfence (under O2+) for std::atomic_thread_fence(std::memory_order_seq_cst), which I think is comparable to StoreLoad that's emitted on x86 backend in hotspot. On Mon, Jul 14, 2014 at 5:53 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > Sure, no problems with (non-)inclusion. > > My question still stands: are there other things I should try to > implement as StoreLoad barrier alternative? > > Thanks, > -Aleksey. > > On 07/15/2014 01:39 AM, Vladimir Kozlov wrote: > > Sorry Aleksey, I don't think this code should be in our sources. > > The patch is small enough to keep it separately when you need it. And > > the problem is not as big as your previous experimental codes. > > > > Thanks, > > Vladimir > > > > On 7/14/14 1:01 PM, Aleksey Shipilev wrote: > >> Had an off-list discussion with Dave Dice, and figured to throw in a few > >> other options. Let me know if you think something else is missing from > >> this list to try: > >> http://cr.openjdk.java.net/~shade/8050149/webrev.02/ > >> > >> -Aleksey. > >> > >> On 07/14/2014 07:42 PM, Aleksey Shipilev wrote: > >>> Hi guys, > >>> > >>> Any comments about pushing something like this into HS? > >>> https://bugs.openjdk.java.net/browse/JDK-8050149 > >>> http://cr.openjdk.java.net/~shade/8050149/webrev.01/ > >>> > >>> This is a follow up for: > >>> https://bugs.openjdk.java.net/browse/JDK-8050147 > >>> > >>> I think the actual switch, if any, should happen in JDK-8050147, but I > >>> would like to explore the alternatives here. Performance runs are > >>> underway. Are there any other alternatives for StoreLoad missing? > >>> > >>> Thanks, > >>> -Aleksey. > >>> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Mon Jul 14 22:13:59 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jul 2014 02:13:59 +0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> <53C44E02.3040306@oracle.com> <53C45156.3090102@oracle.com> Message-ID: <53C45627.9030800@oracle.com> On 07/15/2014 02:00 AM, Vitaly Davidovich wrote: > In case you're interested (and haven't checked yourself), both > clang(3.4.1) and gcc(4.9) use mfence (under O2+) for > std::atomic_thread_fence(std::memory_order_seq_cst), which I think is > comparable to StoreLoad that's emitted on x86 backend in hotspot. See "case 0" in my patch. I think C++11 folks use the docs from Sewell et al.: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html. (It is interesting that since Azeem's Jiva / Dave Dice's research we switched to "lock addl". Linux uses "lock addl" as well). Any non-trivial ideas? In fact, I would be grateful to see the x86 instruction sequences which provide the semantics (e.g. locked instructions referencing memory), and (try to) do not waste registers, and/or (try to) avoid stores. -Aleksey. From vladimir.kozlov at oracle.com Mon Jul 14 22:26:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jul 2014 15:26:26 -0700 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: <53C45627.9030800@oracle.com> References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> <53C44E02.3040306@oracle.com> <53C45156.3090102@oracle.com> <53C45627.9030800@oracle.com> Message-ID: <53C45912.9040803@oracle.com> On 7/14/14 3:13 PM, Aleksey Shipilev wrote: > On 07/15/2014 02:00 AM, Vitaly Davidovich wrote: >> In case you're interested (and haven't checked yourself), both >> clang(3.4.1) and gcc(4.9) use mfence (under O2+) for >> std::atomic_thread_fence(std::memory_order_seq_cst), which I think is >> comparable to StoreLoad that's emitted on x86 backend in hotspot. > > See "case 0" in my patch. I think C++11 folks use the docs from Sewell > et al.: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html. (It is > interesting that since Azeem's Jiva / Dave Dice's research we switched > to "lock addl". Linux uses "lock addl" as well). > > Any non-trivial ideas? In fact, I would be grateful to see the x86 > instruction sequences which provide the semantics (e.g. locked > instructions referencing memory), and (try to) do not waste registers, > and/or (try to) avoid stores. May be instructions stream: address rip = pc(); lock(); addl(InternalAddress(rip), 0); Vladimir > > -Aleksey. > From vitalyd at gmail.com Mon Jul 14 22:30:31 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 14 Jul 2014 18:30:31 -0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: <53C45627.9030800@oracle.com> References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> <53C44E02.3040306@oracle.com> <53C45156.3090102@oracle.com> <53C45627.9030800@oracle.com> Message-ID: Wouldn't the cost be dominated by the hardware fence though? Even if you carry a data dependency here, it seems like real-life performance would degrade due to store buffer drain stall, no? This seems like trying to shed a few pounds off an elephant. Also, presumably with out of order execution the register renamer should allow for speculation to proceed assuming rsp is resolved in time, which it should given that memory is in cache. Sent from my phone On Jul 14, 2014 6:14 PM, "Aleksey Shipilev" wrote: > On 07/15/2014 02:00 AM, Vitaly Davidovich wrote: > > In case you're interested (and haven't checked yourself), both > > clang(3.4.1) and gcc(4.9) use mfence (under O2+) for > > std::atomic_thread_fence(std::memory_order_seq_cst), which I think is > > comparable to StoreLoad that's emitted on x86 backend in hotspot. > > See "case 0" in my patch. I think C++11 folks use the docs from Sewell > et al.: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html. (It is > interesting that since Azeem's Jiva / Dave Dice's research we switched > to "lock addl". Linux uses "lock addl" as well). > > Any non-trivial ideas? In fact, I would be grateful to see the x86 > instruction sequences which provide the semantics (e.g. locked > instructions referencing memory), and (try to) do not waste registers, > and/or (try to) avoid stores. > > -Aleksey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Mon Jul 14 22:30:00 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jul 2014 02:30:00 +0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: <53C45912.9040803@oracle.com> References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> <53C44E02.3040306@oracle.com> <53C45156.3090102@oracle.com> <53C45627.9030800@oracle.com> <53C45912.9040803@oracle.com> Message-ID: <53C459E8.3010109@oracle.com> On 07/15/2014 02:26 AM, Vladimir Kozlov wrote: > On 7/14/14 3:13 PM, Aleksey Shipilev wrote: >> On 07/15/2014 02:00 AM, Vitaly Davidovich wrote: >>> In case you're interested (and haven't checked yourself), both >>> clang(3.4.1) and gcc(4.9) use mfence (under O2+) for >>> std::atomic_thread_fence(std::memory_order_seq_cst), which I think is >>> comparable to StoreLoad that's emitted on x86 backend in hotspot. >> >> See "case 0" in my patch. I think C++11 folks use the docs from Sewell >> et al.: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html. (It is >> interesting that since Azeem's Jiva / Dave Dice's research we switched >> to "lock addl". Linux uses "lock addl" as well). >> >> Any non-trivial ideas? In fact, I would be grateful to see the x86 >> instruction sequences which provide the semantics (e.g. locked >> instructions referencing memory), and (try to) do not waste registers, >> and/or (try to) avoid stores. > > May be instructions stream: > > address rip = pc(); > lock(); addl(InternalAddress(rip), 0); > Thanks, I might as well try that. I think messing with instruction pointer breaks some sort of CPU pipelining in the same way "lock addl"-ing stack pointer wrecks up perf now, but it would be hilarious to watch. -Aleksey. From aleksey.shipilev at oracle.com Mon Jul 14 22:32:10 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jul 2014 02:32:10 +0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: <53C459E8.3010109@oracle.com> References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> <53C44E02.3040306@oracle.com> <53C45156.3090102@oracle.com> <53C45627.9030800@oracle.com> <53C45912.9040803@oracle.com> <53C459E8.3010109@oracle.com> Message-ID: <53C45A6A.3000109@oracle.com> On 07/15/2014 02:30 AM, Aleksey Shipilev wrote: > On 07/15/2014 02:26 AM, Vladimir Kozlov wrote: >> On 7/14/14 3:13 PM, Aleksey Shipilev wrote: >>> On 07/15/2014 02:00 AM, Vitaly Davidovich wrote: >>>> In case you're interested (and haven't checked yourself), both >>>> clang(3.4.1) and gcc(4.9) use mfence (under O2+) for >>>> std::atomic_thread_fence(std::memory_order_seq_cst), which I think is >>>> comparable to StoreLoad that's emitted on x86 backend in hotspot. >>> >>> See "case 0" in my patch. I think C++11 folks use the docs from Sewell >>> et al.: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html. (It is >>> interesting that since Azeem's Jiva / Dave Dice's research we switched >>> to "lock addl". Linux uses "lock addl" as well). >>> >>> Any non-trivial ideas? In fact, I would be grateful to see the x86 >>> instruction sequences which provide the semantics (e.g. locked >>> instructions referencing memory), and (try to) do not waste registers, >>> and/or (try to) avoid stores. >> >> May be instructions stream: >> >> address rip = pc(); >> lock(); addl(InternalAddress(rip), 0); >> > > Thanks, I might as well try that. I think messing with instruction > pointer breaks some sort of CPU pipelining in the same way "lock > addl"-ing stack pointer wrecks up perf now, but it would be hilarious to > watch. ...in fact, "lock addl (%rip + OFFSET), 0" might act as L1$I prefetcher. -Aleksey. From vitalyd at gmail.com Mon Jul 14 22:35:55 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 14 Jul 2014 18:35:55 -0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: <53C45A6A.3000109@oracle.com> References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> <53C44E02.3040306@oracle.com> <53C45156.3090102@oracle.com> <53C45627.9030800@oracle.com> <53C45912.9040803@oracle.com> <53C459E8.3010109@oracle.com> <53C45A6A.3000109@oracle.com> Message-ID: What if that's not where the code would jump? What if that touches completely cold code? I think you want to preserve nop behavior (other than implied fence) unless you know for sure the second side-effect is profitable. Sent from my phone On Jul 14, 2014 6:32 PM, "Aleksey Shipilev" wrote: > On 07/15/2014 02:30 AM, Aleksey Shipilev wrote: > > On 07/15/2014 02:26 AM, Vladimir Kozlov wrote: > >> On 7/14/14 3:13 PM, Aleksey Shipilev wrote: > >>> On 07/15/2014 02:00 AM, Vitaly Davidovich wrote: > >>>> In case you're interested (and haven't checked yourself), both > >>>> clang(3.4.1) and gcc(4.9) use mfence (under O2+) for > >>>> std::atomic_thread_fence(std::memory_order_seq_cst), which I think is > >>>> comparable to StoreLoad that's emitted on x86 backend in hotspot. > >>> > >>> See "case 0" in my patch. I think C++11 folks use the docs from Sewell > >>> et al.: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html. (It is > >>> interesting that since Azeem's Jiva / Dave Dice's research we switched > >>> to "lock addl". Linux uses "lock addl" as well). > >>> > >>> Any non-trivial ideas? In fact, I would be grateful to see the x86 > >>> instruction sequences which provide the semantics (e.g. locked > >>> instructions referencing memory), and (try to) do not waste registers, > >>> and/or (try to) avoid stores. > >> > >> May be instructions stream: > >> > >> address rip = pc(); > >> lock(); addl(InternalAddress(rip), 0); > >> > > > > Thanks, I might as well try that. I think messing with instruction > > pointer breaks some sort of CPU pipelining in the same way "lock > > addl"-ing stack pointer wrecks up perf now, but it would be hilarious to > > watch. > > ...in fact, "lock addl (%rip + OFFSET), 0" might act as L1$I prefetcher. > > -Aleksey. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Mon Jul 14 22:39:53 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jul 2014 02:39:53 +0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> <53C44E02.3040306@oracle.com> <53C45156.3090102@oracle.com> <53C45627.9030800@oracle.com> Message-ID: <53C45C39.7010000@oracle.com> On 07/15/2014 02:30 AM, Vitaly Davidovich wrote: > Wouldn't the cost be dominated by the hardware fence though? Even if you > carry a data dependency here, it seems like real-life performance would > degrade due to store buffer drain stall, no? This seems like trying to > shed a few pounds off an elephant. <...> > Also, presumably with out of order execution the register renamer should > allow for speculation to proceed assuming rsp is resolved in time, which > it should given that memory is in cache. Renaming resolves WAW and WAR hazards. RAW hazards are not resolved by renaming. See https://bugs.openjdk.java.net/browse/JDK-8050147, and/or http://cr.openjdk.java.net/~shade/8050147/orig.perfasm for the example of RAW hazard. There are real life cases we are following up, but whether it is "real" enough depends on further wide-scale testing. I would prefer to gather all the crazy ideas and run them once at this point. -Aleksey. From vitalyd at gmail.com Mon Jul 14 22:45:32 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 14 Jul 2014 18:45:32 -0400 Subject: RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier In-Reply-To: <53C45C39.7010000@oracle.com> References: <53C3FA7A.1070800@oracle.com> <53C4370F.2080209@oracle.com> <53C44E02.3040306@oracle.com> <53C45156.3090102@oracle.com> <53C45627.9030800@oracle.com> <53C45C39.7010000@oracle.com> Message-ID: Shouldn't store forwarding resolve (in the cases where it's allowed) the RAW hazards? Sure, I think it's good to test this stuff out. I'm just "thinking out loud" here as it seems that optimizing data dependency chain around an expensive instruction wouldn't yield any significant gains in real code (i.e. I'm sure some microbenchmark can be constructed to show otherwise), but I'd be very interested if someone can explain it (even if you find some combination of StoreLoad that works best empirically, it'd be good to actually have some sort of explanation as to why). On Mon, Jul 14, 2014 at 6:39 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > On 07/15/2014 02:30 AM, Vitaly Davidovich wrote: > > Wouldn't the cost be dominated by the hardware fence though? Even if you > > carry a data dependency here, it seems like real-life performance would > > degrade due to store buffer drain stall, no? This seems like trying to > > shed a few pounds off an elephant. > > <...> > > > Also, presumably with out of order execution the register renamer should > > allow for speculation to proceed assuming rsp is resolved in time, which > > it should given that memory is in cache. > > Renaming resolves WAW and WAR hazards. RAW hazards are not resolved by > renaming. See https://bugs.openjdk.java.net/browse/JDK-8050147, and/or > http://cr.openjdk.java.net/~shade/8050147/orig.perfasm for the example > of RAW hazard. There are real life cases we are following up, but > whether it is "real" enough depends on further wide-scale testing. I > would prefer to gather all the crazy ideas and run them once at this point. > > -Aleksey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Tue Jul 15 14:18:57 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 15 Jul 2014 16:18:57 +0200 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53BF83FA.3040908@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> Message-ID: <53C53851.5060404@oracle.com> Can I get another review? Thanks, Tobias On 11.07.2014 08:28, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > >> Thank you for doing this cleanup, Tobias. >> >> Looks good. Small note, in divnode.cpp please use explicit NULL checks: >> >> if (in(0) != NULL) { > > Done. New webrev: > http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >> On 7/3/14 11:50 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch for 8040213 that finishes Vladimir?s >>> work [1]. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040213 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.00/ >>> * >>> **Problem* >>> Not all nodes that are modified during C2 optimization are put on the >>> IGVN worklist. >>> >>> *Solution* >>> Verification code is added that checks if (i) modified nodes are put on >>> the IGVN worklist and (ii) modified nodes are processed by >>> PhaseIterGVN::transform_old(..). All code that fails verification >>> during >>> testing is fixed. >>> * >>> **Testing:* >>> - JPRT >>> - Full CTW >>> - Nashorn + Octane >>> - UTE (full testlist, BigApps, JRuby) >>> - VM (NSK) testbase >>> - Refworkload (reference_server) >>> - VMSQE.adhoc.JPRT.full batch >>> >>> Thanks, >>> Tobias >>> >>> [1] http://cr.openjdk.java.net/~kvn/8040213/webrev/ > From filipp.zhinkin at oracle.com Tue Jul 15 14:58:00 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 15 Jul 2014 18:58:00 +0400 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out In-Reply-To: <53C42F7E.4050309@oracle.com> References: <53C00191.8090505@oracle.com> <53C02E08.1070406@oracle.com> <53C3F398.7030205@oracle.com> <53C40C18.7010406@oracle.com> <53C41B1C.8000502@oracle.com> <53C42F7E.4050309@oracle.com> Message-ID: <53C54178.7040500@oracle.com> Vladimir, thank you for review. On 07/14/2014 11:29 PM, Vladimir Kozlov wrote: > Looks good. > > "is compiled": > > + * Wait until InlinedArrayCloneTestCase::invokeArrayClone > compiled. > > Small notes. Keep it on one line (no need for new webrev): > > 63 return InlinedArrayCloneTestCase.verifyArguments(1, 2, > arr.clone(), 3, > 64 4); > I'll fix it. Thanks, Filipp. > Thanks, > Vladimir > > On 7/14/14 11:02 AM, Filipp Zhinkin wrote: >> Here is new webrev: >> http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.01/ >> >> What was done: >> - threads count is min(100, 2 * availableProcessors) now; >> - methods f and g were renamed to invokeArrayClone and verifyArguments. >> >> Thanks, >> Filipp. >> >> On 07/14/2014 08:58 PM, Vladimir Kozlov wrote: >>> On 7/14/14 8:13 AM, Filipp Zhinkin wrote: >>>> Hi Vladimir, >>>> >>>> thank you for watching at it. >>>> >>>> On 07/11/2014 10:33 PM, Vladimir Kozlov wrote: >>>>> 2 * availableProcessors() is still very big on Sparc machines (could >>>>> be > 100). Do we need more threads then available >>>>> processors for bug reproduction? >>>> The more threads we have, the more our chances to reproduce issue. >>>> >>>> Issue could be reproduced when method deoptimized at particular >>>> safepoint >>>> and I don't see how to make this test more stable. >>>> >>>> I executed this test w/ jdk6u17 on different platforms w/ different >>>> options >>>> and here are results for three different approaches to choose threads >>>> count: >>>> >>>> a) 2 * availableProcessors: >>>> Test failed 111 times. >>>> Test passed 57 times. >>>> >>>> b) 1 * availableProcessors: >>>> Test failed 58 times. >>>> Test passed 100 times. >>>> >>>> c) min(100, 2 * availableProcessors): >>>> Test failed: 100 times. >>>> Test passed: 68 times. >>> >>> I think you should use this c) >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> So I think we can cut off threads count by 100. >>>>> >>>>> Do not use one symbol f(), g() methods names. Use something like >>>>> foo(), bar() or test1(), test2(). >>>> Sure, I'll rename it. >>>> >>>> Thanks, >>>> Filipp. >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>> On 7/11/14 8:24 AM, Filipp Zhinkin wrote: >>>>>> Hi all, >>>>>> >>>>>> please review fix for 6848902. >>>>>> >>>>>> compiler/6589834/Test_ia32.java starts 100 threads with spin-loop >>>>>> inside >>>>>> and on some hosts with small amount of CPU coresit takes too much >>>>>> time. >>>>>> >>>>>> Also there is another issue - test intended to catch interpreter's >>>>>> stack >>>>>> corruption after deoptimization, but it can fail only on VM crash. >>>>>> I've checked how it works w/ JDK 6u17 (where 6589834 was not fixed) >>>>>> and >>>>>> found that issue may not cause VM crash. In suchsituation test just >>>>>> prints message "Bug!", but do not actually fail. >>>>>> >>>>>> I reduced amount of used threads to 2 * availableProcessors() >>>>>> and add more asserts on test results, so now it can catch original >>>>>> issue even if VM doesn't crash. >>>>>> >>>>>> Also, VerifyStackwas added to test's options as it was suggested in >>>>>> original test. >>>>>> >>>>>> After all, test still can reproduce original issue w/ 6u17. >>>>>> >>>>>> Testing: on local machine, automated on all platforms. >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 >>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Filipp. >>>> >> From john.r.rose at oracle.com Tue Jul 15 23:10:32 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 15 Jul 2014 16:10:32 -0700 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53C53851.5060404@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> Message-ID: <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> On Jul 15, 2014, at 7:18 AM, Tobias Hartmann wrote: > Can I get another review? > > Thanks, > Tobias > > On 11.07.2014 08:28, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >>> Thank you for doing this cleanup, Tobias. >>> >>> Looks good. Small note, in divnode.cpp please use explicit NULL checks: >>> >>> if (in(0) != NULL) { >> >> Done. New webrev: >> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ Loading C->_modified_nodes with a stack address is bad news, even if the code apparently cleans it up on exit. (I say "apparently" because there are early exits from that block, and the cleanup is not RAII style.) I strongly suggest heap allocation instead of stack allocation; it's expensive but it's for debug code. As a matter of style, I would prefer the comment '// Iterative Global Value Numbering, including ideal transforms' and the following declaration to immediately follow the open brace, with the new inserted code placed after the declaration of 'igvn' and before the block which calls 'Optimize'. I like the simplification of most of the modification sites by factoring patterns into 'replace_input_of'; that is a good cleanup. The places where 'can_reshape' gates 'rehash_node_delayed' go in the opposite, not-so-good direction; they feel kludgey and hard to understand. Surely they can be factored too, so that the fiddly logic is centralized. If you were to make a well-named brother to 'replace_input_of' and make it virtual on PhaseTransform or PhaseGVN, wouldn't that put the 'rehash_node_delayed' logic into a more central position? The flag 'can_reshape' is simply (IIRC) a cached type indication of whether the phase is an IterGVN. Suggest reducing the number of one-line DEBUG_ONLY() macro calls by using PRODUCT_RETURN: + void record_modified_node(Node* n) PRODUCT_RETURN; + void remove_modified_node(Node* n) PRODUCT_RETURN; + Unique_Node_List* modified_nodes() const { return DEBUG_ONLY(_modified_nodes) NOT_DEBUG(NULL); } I like that the new asserts apparently found a number of small bugs which you fixed. You inserted '#ifdef ASSERT' after 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you need it, since all of the code (including the similar insertion a few lines up) is '#ifndef PRODUCT'. See also suggestion above regarding 'modified_nodes'. There are a few places where tests like 'while (modified_list->size())' appears but there is no null check of 'modified_list' itself. This could cause a crash if we ever get the phasing wrong; consider an assert or explicit null check 'while (modified_list != NULL && ...)'. ? John From anton.ivanov at oracle.com Wed Jul 16 10:55:06 2014 From: anton.ivanov at oracle.com (Anton Ivanov) Date: Wed, 16 Jul 2014 14:55:06 +0400 Subject: RFR (S) : 8049348 : [TESTBUG] compiler/intrinsics/bmi/verifycode tests on lzcnt and tzcnt use incorrect assumption about REXB prefix usage Message-ID: <53C65A0A.4040500@oracle.com> Hi all, Please review the patch for bug 8049348 Promlem: compiler/intrinsics/bmi/verifycode/ tests on lzcnt and tzcnt based on assumption that REXB prefix used only for Long's intrinsic. Solution: both (integer and long) lzcnt and tzcnt tests were updated to understand different native instructions (with REX prefix, and without) webrev: http://cr.openjdk.java.net/~aaivanov/8049348/webrev.00 jbs: https://bugs.openjdk.java.net/browse/JDK-8049348 testing: compiler/intrinsics/bmi/verifycode. tested not with jprt, because there is very low or zero chance that host with CPU supporting tested instruction will be used. tests were run locally on 3 configurations, including the host where bug was found -- Best regards, Anton Ivanov From vladimir.x.ivanov at oracle.com Wed Jul 16 12:01:09 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jul 2014 16:01:09 +0400 Subject: [8u20] RFR (S): 8050050: [TESTBUG] compiler/stable tests fail because WB API is not implemented Message-ID: <53C66985.6050002@oracle.com> http://cr.openjdk.java.net/~vlivanov/8050050/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8050050 8038756 wasn't backported to 8u20, so WB::get/setVMFlag aren't available there. The fix for 8u20 is to rewrite configuration logic detection using JMX. Testing: affected tests. Thanks! Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Wed Jul 16 16:55:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Jul 2014 09:55:24 -0700 Subject: RFR (S) : 8049348 : [TESTBUG] compiler/intrinsics/bmi/verifycode tests on lzcnt and tzcnt use incorrect assumption about REXB prefix usage In-Reply-To: <53C65A0A.4040500@oracle.com> References: <53C65A0A.4040500@oracle.com> Message-ID: <53C6AE7C.3050200@oracle.com> Looks good. Vladimir On 7/16/14 3:55 AM, Anton Ivanov wrote: > Hi all, > > Please review the patch for bug 8049348 > > Promlem: > compiler/intrinsics/bmi/verifycode/ tests on lzcnt and tzcnt based on assumption that REXB prefix used only for Long's > intrinsic. > > Solution: > both (integer and long) lzcnt and tzcnt tests were updated to understand different native instructions (with REX prefix, > and without) > > > webrev: http://cr.openjdk.java.net/~aaivanov/8049348/webrev.00 > > jbs: https://bugs.openjdk.java.net/browse/JDK-8049348 > > testing: compiler/intrinsics/bmi/verifycode. tested not with jprt, because there is very low or zero chance that host > with CPU supporting tested instruction will be used. tests were run locally on 3 configurations, including the host > where bug was found > > -- Best regards, Anton Ivanov From vladimir.x.ivanov at oracle.com Wed Jul 16 17:49:14 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jul 2014 21:49:14 +0400 Subject: [9] RFR(S): 8048721: -XX:+PrintCompilation prints negative bci for non entrant OSR methods In-Reply-To: <53BF1015.4080002@oracle.com> References: <53B291E9.3030508@oracle.com> <53B2A356.4080200@oracle.com> <53BBE93D.802@oracle.com> <53BF1015.4080002@oracle.com> Message-ID: <53C6BB1A.3070503@oracle.com> Thanks, Vladimir. On 7/11/14 2:13 AM, Vladimir Kozlov wrote: > _method set to NULL also in make_unloaded() but after > invalidate_osr_method() call so it should be fine. > > On 7/8/14 5:51 AM, Vladimir Ivanov wrote: >> Any thoughts about that? I still think "_entry_bci = InvalidOSREntryBci" >> is redundant. > > Unfortunately profiling code in Interpeter test this value: > > __ movl(rcx, Address(rax, nmethod::entry_bci_offset())); > __ cmpl(rcx, InvalidOSREntryBci); > > So it would require a lot more changes. But I agree that changing > _entry_bci looks strange > > Can we check _state value instead of _entry_bci? Could be some race > conditions why _entry_bci is used. I don't think it's necessary. Since both lookup (InstanceKlass::lookup_osr_nmethod) and removal (InstanceKlass::remove_osr_nmethod) actions synchronize on OsrList_lock, the only case when _entry_bci != InvalidOSREntryBci matters is the following: - T1: Interpreter fetches an OSR nmethod - T2: invalidates OSR nmethod and writes InvalidOSREntryBci into _entry_bci - T1: checks "_entry_bci != InvalidOSREntryBci" But it's already broken since it's not guaranteed that the value written by T2 will be seen by T1 (no synchronization actions between T1 & T2). I'd stop writing InvalidOSREntryBci into _entry_bci and remove "_entry_bci != InvalidOSREntryBci" check from Interpreter, or leave it for further cleanup if it's too much for now. It's an innocent check. Best regards, Vladimir Ivanov > > Vladimir K > >> >> Best regards, >> Vladimir Ivanov >> >> On 7/1/14 4:02 PM, Vladimir Ivanov wrote: >>> (widening audience to Runtime folks) >>> >>> I don't think it's good to lose bci for OSR methods after nmethod >>> invalidation. >>> >>> Regarding current invalidation logic, I don't see that "_entry_bci = >>> InvalidOSREntryBci" is required to invalidate OSR nmethods. Yes, >>> interpreter does "_entry_bci != InvalidOSREntryBci" check before calling >>> OSR nmethod, but _entry_bci update isn't properly synchronized between >>> invalidating and querying threads (no locks or memory barriers >>> involved). >>> >>> So I have a question is it safe to remove "_entry_bci = >>> InvalidOSREntryBci". >>> >>> Both OSR nmethod lookup (InstanceKlass::lookup_osr_nmethod) and removal >>> (InstanceKlass::remove_osr_nmethod) synchronize on OsrList_lock, so >>> after removal OSR nmethod can't be looked up. >>> >>> What bothers me is the following null check before removal: >>> void nmethod::invalidate_osr_method() { >>> if (method() != NULL) >>> method()->method_holder()->remove_osr_nmethod(this); >>> >>> Under what conditions nmethod with _method == NULL can be invalidated? >>> Or is it just defensive coding? >>> >>> We set _method to NULL only for zombie nmethods (see >>> nmethod::make_not_entrant_or_zombie) and they are already invalidated at >>> that point. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 7/1/14 2:48 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch for JDK-8048721. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048721 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8048721/webrev.00/ >>>> >>>> *Problem* >>>> The VM option -XX:+PrintCompilation prints a negative bytecode index >>>> for >>>> not entrant OSR nmethods. The problem is that in >>>> nmethod::make_not_entrant_or_zombie(..) the _entry_bci is invalidated >>>> (i.e. set to InvalidOSREntryBci == -2) by invalidate_osr_method(..) and >>>> log_state_change(..) is called afterwards, printing the invalidated >>>> entry. >>>> >>>> *Solution >>>> *Because reordering the methods in >>>> nmethod::make_not_entrant_or_zombie(..) is not easily possible due to >>>> thread safety, I changed the implementation log_state_change(..) and >>>> dependent methods to take the entry bci as parameter. The entry bci is >>>> saved prior to invalidation and used for printing afterwards. >>>> >>>> *Testing* >>>> JPRT >>>> >>>> Thanks, >>>> Tobias From vladimir.kozlov at oracle.com Wed Jul 16 18:56:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Jul 2014 11:56:52 -0700 Subject: [9] RFR(S): 8048721: -XX:+PrintCompilation prints negative bci for non entrant OSR methods In-Reply-To: <53C6BB1A.3070503@oracle.com> References: <53B291E9.3030508@oracle.com> <53B2A356.4080200@oracle.com> <53BBE93D.802@oracle.com> <53BF1015.4080002@oracle.com> <53C6BB1A.3070503@oracle.com> Message-ID: <53C6CAF4.9070505@oracle.com> Lets see how big changes you need. Vladimir K On 7/16/14 10:49 AM, Vladimir Ivanov wrote: > Thanks, Vladimir. > > On 7/11/14 2:13 AM, Vladimir Kozlov wrote: >> _method set to NULL also in make_unloaded() but after >> invalidate_osr_method() call so it should be fine. >> >> On 7/8/14 5:51 AM, Vladimir Ivanov wrote: >>> Any thoughts about that? I still think "_entry_bci = InvalidOSREntryBci" >>> is redundant. >> >> Unfortunately profiling code in Interpeter test this value: >> >> __ movl(rcx, Address(rax, nmethod::entry_bci_offset())); >> __ cmpl(rcx, InvalidOSREntryBci); >> >> So it would require a lot more changes. But I agree that changing >> _entry_bci looks strange >> >> Can we check _state value instead of _entry_bci? Could be some race >> conditions why _entry_bci is used. > I don't think it's necessary. > > Since both lookup (InstanceKlass::lookup_osr_nmethod) and removal > (InstanceKlass::remove_osr_nmethod) actions synchronize on OsrList_lock, > the only case when _entry_bci != InvalidOSREntryBci matters is the > following: > - T1: Interpreter fetches an OSR nmethod > - T2: invalidates OSR nmethod and writes InvalidOSREntryBci into > _entry_bci > - T1: checks "_entry_bci != InvalidOSREntryBci" > > But it's already broken since it's not guaranteed that the value written > by T2 will be seen by T1 (no synchronization actions between T1 & T2). > > I'd stop writing InvalidOSREntryBci into _entry_bci and remove > "_entry_bci != InvalidOSREntryBci" check from Interpreter, or leave it > for further cleanup if it's too much for now. It's an innocent check. > > Best regards, > Vladimir Ivanov > >> >> Vladimir K >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 7/1/14 4:02 PM, Vladimir Ivanov wrote: >>>> (widening audience to Runtime folks) >>>> >>>> I don't think it's good to lose bci for OSR methods after nmethod >>>> invalidation. >>>> >>>> Regarding current invalidation logic, I don't see that "_entry_bci = >>>> InvalidOSREntryBci" is required to invalidate OSR nmethods. Yes, >>>> interpreter does "_entry_bci != InvalidOSREntryBci" check before >>>> calling >>>> OSR nmethod, but _entry_bci update isn't properly synchronized between >>>> invalidating and querying threads (no locks or memory barriers >>>> involved). >>>> >>>> So I have a question is it safe to remove "_entry_bci = >>>> InvalidOSREntryBci". >>>> >>>> Both OSR nmethod lookup (InstanceKlass::lookup_osr_nmethod) and removal >>>> (InstanceKlass::remove_osr_nmethod) synchronize on OsrList_lock, so >>>> after removal OSR nmethod can't be looked up. >>>> >>>> What bothers me is the following null check before removal: >>>> void nmethod::invalidate_osr_method() { >>>> if (method() != NULL) >>>> method()->method_holder()->remove_osr_nmethod(this); >>>> >>>> Under what conditions nmethod with _method == NULL can be invalidated? >>>> Or is it just defensive coding? >>>> >>>> We set _method to NULL only for zombie nmethods (see >>>> nmethod::make_not_entrant_or_zombie) and they are already >>>> invalidated at >>>> that point. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 7/1/14 2:48 PM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch for JDK-8048721. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048721 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8048721/webrev.00/ >>>>> >>>>> *Problem* >>>>> The VM option -XX:+PrintCompilation prints a negative bytecode index >>>>> for >>>>> not entrant OSR nmethods. The problem is that in >>>>> nmethod::make_not_entrant_or_zombie(..) the _entry_bci is invalidated >>>>> (i.e. set to InvalidOSREntryBci == -2) by invalidate_osr_method(..) >>>>> and >>>>> log_state_change(..) is called afterwards, printing the invalidated >>>>> entry. >>>>> >>>>> *Solution >>>>> *Because reordering the methods in >>>>> nmethod::make_not_entrant_or_zombie(..) is not easily possible due to >>>>> thread safety, I changed the implementation log_state_change(..) and >>>>> dependent methods to take the entry bci as parameter. The entry bci is >>>>> saved prior to invalidation and used for printing afterwards. >>>>> >>>>> *Testing* >>>>> JPRT >>>>> >>>>> Thanks, >>>>> Tobias From tobias.hartmann at oracle.com Thu Jul 17 10:40:08 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 17 Jul 2014 12:40:08 +0200 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> Message-ID: <53C7A808.6040807@oracle.com> Hi John, thanks a lot for the detailed review! Please see comments inline. On 16.07.2014 01:10, John Rose wrote: > On Jul 15, 2014, at 7:18 AM, Tobias Hartmann wrote: > >> Can I get another review? >> >> Thanks, >> Tobias >> >> On 11.07.2014 08:28, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> thanks for the review. >>> >>>> Thank you for doing this cleanup, Tobias. >>>> >>>> Looks good. Small note, in divnode.cpp please use explicit NULL checks: >>>> >>>> if (in(0) != NULL) { >>> Done. New webrev: >>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ > Loading C->_modified_nodes with a stack address is bad news, even if the code apparently cleans it up on exit. (I say "apparently" because there are early exits from that block, and the cleanup is not RAII style.) I strongly suggest heap allocation instead of stack allocation; it's expensive but it's for debug code. There are other places in the code where this is done, for example in Compile::Compile(..) the Unique_Node_List 'for_igvn' is created on the stack. Is this a special case? I'm not sure how to correctly allocate the object on the heap. Do I have to use new/delete or is this handled by some magic in "ResourceObject'? > As a matter of style, I would prefer the comment '// Iterative Global Value Numbering, including ideal transforms' and the following declaration to immediately follow the open brace, with the new inserted code placed after the declaration of 'igvn' and before the block which calls 'Optimize'. Okay, done. > I like the simplification of most of the modification sites by factoring patterns into 'replace_input_of'; that is a good cleanup. > > The places where 'can_reshape' gates 'rehash_node_delayed' go in the opposite, not-so-good direction; they feel kludgey and hard to understand. Surely they can be factored too, so that the fiddly logic is centralized. > > If you were to make a well-named brother to 'replace_input_of' and make it virtual on PhaseTransform or PhaseGVN, wouldn't that put the 'rehash_node_delayed' logic into a more central position? The flag 'can_reshape' is simply (IIRC) a cached type indication of whether the phase is an IterGVN. I added an empty virtual 'igvn_rehash_node_delayed' to PhaseTransform and implemented it in PhaseIterGVN to move the logic into a more central position. I removed the 'can_reshape' checks. > Suggest reducing the number of one-line DEBUG_ONLY() macro calls by using PRODUCT_RETURN: > + void record_modified_node(Node* n) PRODUCT_RETURN; > + void remove_modified_node(Node* n) PRODUCT_RETURN; > + Unique_Node_List* modified_nodes() const { return DEBUG_ONLY(_modified_nodes) NOT_DEBUG(NULL); } Thanks for the hint, it looks way better now! > I like that the new asserts apparently found a number of small bugs which you fixed. Yes, I'm a little bit concerned that additional bugs will show up after integration, although I did a lot of testing. > You inserted '#ifdef ASSERT' after 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you need it, since all of the code (including the similar insertion a few lines up) is '#ifndef PRODUCT'. See also suggestion above regarding 'modified_nodes'. True, I removed the #ifdef. > There are a few places where tests like 'while (modified_list->size())' appears but there is no null check of 'modified_list' itself. This could cause a crash if we ever get the phasing wrong; consider an assert or explicit null check 'while (modified_list != NULL && ...)'. I added explicit null checks. New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.02/ Thanks, Tobias > ? John From igor.ignatyev at oracle.com Thu Jul 17 10:53:05 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 17 Jul 2014 14:53:05 +0400 Subject: RFR (S) : 8031978 : compiler/ciReplay/TestVM_no_comp_level.sh fails with "TEST [CHECK :: REPLAY DATA GENERATION] FAILED: Message-ID: <53C7AB11.4040700@oracle.com> webrev: http://cr.openjdk.java.net/~iignatyev/8031978/webrev.00/ 31 lines changed: 15 ins; 6 del; 10 mod; Hi all, Please review patch: Problem: the tests expect that compiled_id of 1st compile task is 1, but sometimes creating of native wrapper (I saw j.l.Object::wait) executes assign_compile_id() first and takes compiled_id == 1. Fix: added -XX:-PreferInterpreterNativeStubs to prevent creating of native wrapper fixed core locations processing: - removed the rest of line - added core file w/o pid and path instead of duplicated 'core_with_pid' I also added -XX:+PrintCompilation to have more details in future, -XX:-TransmitErrorReport not to transmit report for expecting errors, check of exit code to have specific error message. jbs: https://jbs.oracle.com/bugs/browse/JDK-8031978 testing: failing tests locally/jprt -- Igor From vladimir.kozlov at oracle.com Thu Jul 17 16:06:46 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Jul 2014 09:06:46 -0700 Subject: RFR (S) : 8031978 : compiler/ciReplay/TestVM_no_comp_level.sh fails with "TEST [CHECK :: REPLAY DATA GENERATION] FAILED: In-Reply-To: <53C7AB11.4040700@oracle.com> References: <53C7AB11.4040700@oracle.com> Message-ID: <53C7F496.5070405@oracle.com> Nice solution with PreferInterpreterNativeStubs. Changes looks good. Thanks, Vladimir On 7/17/14 3:53 AM, Igor Ignatyev wrote: > webrev: http://cr.openjdk.java.net/~iignatyev/8031978/webrev.00/ > 31 lines changed: 15 ins; 6 del; 10 mod; > > Hi all, > > Please review patch: > > Problem: > the tests expect that compiled_id of 1st compile task is 1, but sometimes creating of native wrapper (I saw > j.l.Object::wait) executes assign_compile_id() first and takes compiled_id == 1. > > Fix: > added -XX:-PreferInterpreterNativeStubs to prevent creating of native wrapper > fixed core locations processing: > - removed the rest of line > - added core file w/o pid and path instead of duplicated 'core_with_pid' > > I also added -XX:+PrintCompilation to have more details in future, -XX:-TransmitErrorReport not to transmit report for > expecting errors, check of exit code to have specific error message. > > jbs: https://jbs.oracle.com/bugs/browse/JDK-8031978 > testing: failing tests locally/jprt From pavel.punegov at oracle.com Thu Jul 17 17:08:33 2014 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 17 Jul 2014 21:08:33 +0400 Subject: RFR (S): 8048882: Some regression tests are not robust with VM output Message-ID: <53C80311.6000008@oracle.com> Please review the next change for the test bug webrev: http://cr.openjdk.java.net/~iignatyev/ppunegov/8048882/webrev.00/ Problem: The test used shell script that diffs output got form the test. If there are warning, test fails. Fix: Remove shell script. Make compare of the test results inside the java-file. Also, I have fixed indentation and code style to be more Java-style. Testing: Locally and JPRT. Verified that it still reproduces the original issue the regression test was made for. Bug: https://bugs.openjdk.java.net/browse/JDK-8048882 -- Thanks, Pavel Punegov From vladimir.kozlov at oracle.com Thu Jul 17 18:07:46 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Jul 2014 11:07:46 -0700 Subject: RFR (S): 8048882: Some regression tests are not robust with VM output In-Reply-To: <53C80311.6000008@oracle.com> References: <53C80311.6000008@oracle.com> Message-ID: <53C810F2.9060200@oracle.com> Thank you, Pavel, for this cleaning up. Changes looks fine to me. The only question is - did you reproduced the original failure with modified test? Thanks, Vladimir On 7/17/14 10:08 AM, Pavel Punegov wrote: > Please review the next change for the test bug > webrev: > http://cr.openjdk.java.net/~iignatyev/ppunegov/8048882/webrev.00/ > > > Problem: > The test used shell script that diffs output got form the test. If > there are warning, test fails. > > Fix: > Remove shell script. Make compare of the test results inside the > java-file. > Also, I have fixed indentation and code style to be more Java-style. > > Testing: > Locally and JPRT. > Verified that it still reproduces the original issue the regression > test was made for. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048882 > From igor.ignatyev at oracle.com Thu Jul 17 18:56:24 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 17 Jul 2014 22:56:24 +0400 Subject: RFR (S): 8048882: Some regression tests are not robust with VM output In-Reply-To: <53C810F2.9060200@oracle.com> References: <53C80311.6000008@oracle.com> <53C810F2.9060200@oracle.com> Message-ID: <53C81C58.20608@oracle.com> Vladimir, as Pavel mentioned in his email, he reproduced the original failure: >> Verified that it still reproduces the original issue the regression >> test was made for. Thanks, Igor On 07/17/2014 10:07 PM, Vladimir Kozlov wrote: > Thank you, Pavel, for this cleaning up. > Changes looks fine to me. The only question is - did you reproduced the > original failure with modified test? > > Thanks, > Vladimir > > On 7/17/14 10:08 AM, Pavel Punegov wrote: >> Please review the next change for the test bug >> webrev: >> http://cr.openjdk.java.net/~iignatyev/ppunegov/8048882/webrev.00/ >> >> >> Problem: >> The test used shell script that diffs output got form the test. If >> there are warning, test fails. >> >> Fix: >> Remove shell script. Make compare of the test results inside the >> java-file. >> Also, I have fixed indentation and code style to be more Java-style. >> >> Testing: >> Locally and JPRT. >> Verified that it still reproduces the original issue the regression >> test was made for. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048882 >> From igor.ignatyev at oracle.com Thu Jul 17 18:57:15 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 17 Jul 2014 22:57:15 +0400 Subject: RFR (S) : 8031978 : compiler/ciReplay/TestVM_no_comp_level.sh fails with "TEST [CHECK :: REPLAY DATA GENERATION] FAILED: In-Reply-To: <53C7F496.5070405@oracle.com> References: <53C7AB11.4040700@oracle.com> <53C7F496.5070405@oracle.com> Message-ID: <53C81C8B.6010602@oracle.com> Vladimir, thank you for review. Igor On 07/17/2014 08:06 PM, Vladimir Kozlov wrote: > Nice solution with PreferInterpreterNativeStubs. > Changes looks good. > > Thanks, > Vladimir > > On 7/17/14 3:53 AM, Igor Ignatyev wrote: >> webrev: http://cr.openjdk.java.net/~iignatyev/8031978/webrev.00/ >> 31 lines changed: 15 ins; 6 del; 10 mod; >> >> Hi all, >> >> Please review patch: >> >> Problem: >> the tests expect that compiled_id of 1st compile task is 1, but >> sometimes creating of native wrapper (I saw >> j.l.Object::wait) executes assign_compile_id() first and takes >> compiled_id == 1. >> >> Fix: >> added -XX:-PreferInterpreterNativeStubs to prevent creating of native >> wrapper >> fixed core locations processing: >> - removed the rest of line >> - added core file w/o pid and path instead of duplicated >> 'core_with_pid' >> >> I also added -XX:+PrintCompilation to have more details in future, >> -XX:-TransmitErrorReport not to transmit report for >> expecting errors, check of exit code to have specific error message. >> >> jbs: https://jbs.oracle.com/bugs/browse/JDK-8031978 >> testing: failing tests locally/jprt From vladimir.kozlov at oracle.com Thu Jul 17 19:33:22 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Jul 2014 12:33:22 -0700 Subject: RFR (S): 8048882: Some regression tests are not robust with VM output In-Reply-To: <53C81C58.20608@oracle.com> References: <53C80311.6000008@oracle.com> <53C810F2.9060200@oracle.com> <53C81C58.20608@oracle.com> Message-ID: <53C82502.9020100@oracle.com> Good. Thanks, Vladimir On 7/17/14 11:56 AM, Igor Ignatyev wrote: > Vladimir, > > as Pavel mentioned in his email, he reproduced the original failure: >>> Verified that it still reproduces the original issue the regression >>> test was made for. > > Thanks, > Igor > > On 07/17/2014 10:07 PM, Vladimir Kozlov wrote: >> Thank you, Pavel, for this cleaning up. >> Changes looks fine to me. The only question is - did you reproduced the >> original failure with modified test? >> >> Thanks, >> Vladimir >> >> On 7/17/14 10:08 AM, Pavel Punegov wrote: >>> Please review the next change for the test bug >>> webrev: >>> http://cr.openjdk.java.net/~iignatyev/ppunegov/8048882/webrev.00/ >>> >>> >>> Problem: >>> The test used shell script that diffs output got form the test. If >>> there are warning, test fails. >>> >>> Fix: >>> Remove shell script. Make compare of the test results inside the >>> java-file. >>> Also, I have fixed indentation and code style to be more Java-style. >>> >>> Testing: >>> Locally and JPRT. >>> Verified that it still reproduces the original issue the regression >>> test was made for. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048882 >>> From igor.ignatyev at oracle.com Thu Jul 17 22:18:09 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Jul 2014 02:18:09 +0400 Subject: RFR (S) : 8032449 : Get rid of JMX in test/compiler/whitebox/CompilerWhiteBoxTest.java Message-ID: <53C84BA1.4030909@oracle.com> webrev: http://cr.openjdk.java.net/~iignatyev/8032449/webrev.00/ 69 lines changed: 27 ins; 34 del; 8 mod; Hi all, Please review the patch which removes dependency on JMX from several tests (replacing usage of 'c.s.m.HotSpotDiagnosticMXBean' w/ WhiteBox::get*VMFlag) and removes them from needs_compact3 group. I also moved @ignore tags after @library in the tests quarantined by 8047996. I needed this to verify that my changes don't break them, w/o that, jtreg can't start them and counts as errors even w/ -ignore:run due to: > Parse Exception: `@library' must appear before first `@run' jbs: https://bugs.openjdk.java.net/browse/JDK-8032449 testing: :compact1 w/ -ignore:run on compact1-linux-i586; ./compiler in JPRT -- Igor From vladimir.kozlov at oracle.com Thu Jul 17 22:32:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Jul 2014 15:32:10 -0700 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53C7A808.6040807@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> <53C7A808.6040807@oracle.com> Message-ID: <53C84EEA.3000508@oracle.com> Initial prototype was written by me so part of changes are mine. On 7/17/14 3:40 AM, Tobias Hartmann wrote: > Hi John, > > thanks a lot for the detailed review! Please see comments inline. > > On 16.07.2014 01:10, John Rose wrote: >>>> Done. New webrev: >>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ >> Loading C->_modified_nodes with a stack address is bad news, even if >> the code apparently cleans it up on exit. (I say "apparently" because >> there are early exits from that block, and the cleanup is not RAII >> style.) I strongly suggest heap allocation instead of stack >> allocation; it's expensive but it's for debug code. The list array allocation is done in compiler arena which is cleaned after compilation finished by ResourceMark, only descriptor is on stack: + Unique_Node_List modified_nodes(comp_arena()); It is our normal style. We do it a lot, see Compile::Code_Gen(). Tobias, if you want to allocate Unique_Node_List object on arena: _modified_nodes = new (comp_arena()) Unique_Node_List(comp_arena()); > > There are other places in the code where this is done, for example in > Compile::Compile(..) the Unique_Node_List 'for_igvn' is created on the > stack. Is this a special case? > > I'm not sure how to correctly allocate the object on the heap. Do I have > to use new/delete or is this handled by some magic in "ResourceObject'? > > >> You inserted '#ifdef ASSERT' after >> 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you need it, >> since all of the code (including the similar insertion a few lines up) >> is '#ifndef PRODUCT'. See also suggestion above regarding >> 'modified_nodes'. #ifndef PRODUCT is also 'optimized' version of VM. n->dump() method is not defined in optimized build. That is why asserts are needed. Tobias, please, build 'optimized' VM to verify your changes. Thanks, Vladimir > > True, I removed the #ifdef. > >> There are a few places where tests like 'while >> (modified_list->size())' appears but there is no null check of >> 'modified_list' itself. This could cause a crash if we ever get the >> phasing wrong; consider an assert or explicit null check 'while >> (modified_list != NULL && ...)'. > > I added explicit null checks. > > > New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.02/ > > Thanks, > Tobias > >> ? John From vladimir.kozlov at oracle.com Thu Jul 17 22:37:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Jul 2014 15:37:56 -0700 Subject: RFR (S) : 8032449 : Get rid of JMX in test/compiler/whitebox/CompilerWhiteBoxTest.java In-Reply-To: <53C84BA1.4030909@oracle.com> References: <53C84BA1.4030909@oracle.com> Message-ID: <53C85044.9010209@oracle.com> Looks nice. Thanks, Vladimir On 7/17/14 3:18 PM, Igor Ignatyev wrote: > webrev: http://cr.openjdk.java.net/~iignatyev/8032449/webrev.00/ > 69 lines changed: 27 ins; 34 del; 8 mod; > > Hi all, > > Please review the patch which removes dependency on JMX from several > tests (replacing usage of 'c.s.m.HotSpotDiagnosticMXBean' w/ > WhiteBox::get*VMFlag) and removes them from needs_compact3 group. > > I also moved @ignore tags after @library in the tests quarantined by > 8047996. I needed this to verify that my changes don't break them, w/o > that, jtreg can't start them and counts as errors even w/ -ignore:run > due to: >> Parse Exception: `@library' must appear before first `@run' > > jbs: https://bugs.openjdk.java.net/browse/JDK-8032449 > testing: :compact1 w/ -ignore:run on compact1-linux-i586; ./compiler in > JPRT From john.r.rose at oracle.com Thu Jul 17 23:32:08 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 17 Jul 2014 16:32:08 -0700 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53C84EEA.3000508@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> <53C7A808.6040807@oracle.com> <53C84EEA.3000508@oracle.com> Message-ID: On Jul 17, 2014, at 3:32 PM, Vladimir Kozlov wrote: > Initial prototype was written by me so part of changes are mine. > > On 7/17/14 3:40 AM, Tobias Hartmann wrote: >> Hi John, >> >> thanks a lot for the detailed review! Please see comments inline. >> >> On 16.07.2014 01:10, John Rose wrote: >>>>> Done. New webrev: >>>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ >>> Loading C->_modified_nodes with a stack address is bad news, even if >>> the code apparently cleans it up on exit. (I say "apparently" because >>> there are early exits from that block, and the cleanup is not RAII >>> style.) I strongly suggest heap allocation instead of stack >>> allocation; it's expensive but it's for debug code. > > The list array allocation is done in compiler arena which is cleaned after compilation finished by ResourceMark, only descriptor is on stack: > > + Unique_Node_List modified_nodes(comp_arena()); > > It is our normal style. We do it a lot, see Compile::Code_Gen(). Yes, we do it when adding phase control blocks to the Compile object, within the tree of calls rooted at the constructor. I see that the new code is arguably part of that pattern. I hope that is an exceptional use of this style? Note that C2Compiler::compile_method creates the Compile object and then queries it. When it queries it, the Compile object may contain dangling pointers into phase control blocks stored on the stack (during subroutine calls like Code_Gen) but now deallocated. It seems to me that we avoid touching those dangling pointers by simple will power and discipline. Such a style doesn't scale, since it's too easy to make mistakes as the code gets complicated. > Tobias, if you want to allocate Unique_Node_List object on arena: > > _modified_nodes = new (comp_arena()) Unique_Node_List(comp_arena()); That makes me feel much better. I would prefer for us to do it this way for the other stack-chunks also, but that would be outside the scope of this bug. Tobias, thanks for doing this work. ? John >> >> There are other places in the code where this is done, for example in >> Compile::Compile(..) the Unique_Node_List 'for_igvn' is created on the >> stack. Is this a special case? >> >> I'm not sure how to correctly allocate the object on the heap. Do I have >> to use new/delete or is this handled by some magic in "ResourceObject'? >> >> >>> You inserted '#ifdef ASSERT' after >>> 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you need it, >>> since all of the code (including the similar insertion a few lines up) >>> is '#ifndef PRODUCT'. See also suggestion above regarding >>> 'modified_nodes'. > > #ifndef PRODUCT is also 'optimized' version of VM. n->dump() method is not defined in optimized build. That is why asserts are needed. > > Tobias, please, build 'optimized' VM to verify your changes. > > Thanks, > Vladimir > >> >> True, I removed the #ifdef. >> >>> There are a few places where tests like 'while >>> (modified_list->size())' appears but there is no null check of >>> 'modified_list' itself. This could cause a crash if we ever get the >>> phasing wrong; consider an assert or explicit null check 'while >>> (modified_list != NULL && ...)'. >> >> I added explicit null checks. >> >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.02/ >> >> Thanks, >> Tobias >> >>> ? John From pavel.punegov at oracle.com Fri Jul 18 09:44:20 2014 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Fri, 18 Jul 2014 13:44:20 +0400 Subject: RFR (S): 8048882: Some regression tests are not robust with VM output In-Reply-To: <53C82502.9020100@oracle.com> References: <53C80311.6000008@oracle.com> <53C810F2.9060200@oracle.com> <53C81C58.20608@oracle.com> <53C82502.9020100@oracle.com> Message-ID: <53C8EC74.1000206@oracle.com> Vladimir & Igor, thank you for review On 17.07.2014 23:33, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 7/17/14 11:56 AM, Igor Ignatyev wrote: >> Vladimir, >> >> as Pavel mentioned in his email, he reproduced the original failure: >>>> Verified that it still reproduces the original issue the regression >>>> test was made for. >> >> Thanks, >> Igor >> >> On 07/17/2014 10:07 PM, Vladimir Kozlov wrote: >>> Thank you, Pavel, for this cleaning up. >>> Changes looks fine to me. The only question is - did you reproduced the >>> original failure with modified test? >>> >>> Thanks, >>> Vladimir >>> >>> On 7/17/14 10:08 AM, Pavel Punegov wrote: >>>> Please review the next change for the test bug >>>> webrev: >>>> http://cr.openjdk.java.net/~iignatyev/ppunegov/8048882/webrev.00/ >>>> >>>> >>>> Problem: >>>> The test used shell script that diffs output got form the test. If >>>> there are warning, test fails. >>>> >>>> Fix: >>>> Remove shell script. Make compare of the test results inside the >>>> java-file. >>>> Also, I have fixed indentation and code style to be more >>>> Java-style. >>>> >>>> Testing: >>>> Locally and JPRT. >>>> Verified that it still reproduces the original issue the regression >>>> test was made for. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048882 >>>> -- Thanks, Pavel Punegov From zoltan.majo at oracle.com Fri Jul 18 11:34:10 2014 From: zoltan.majo at oracle.com (=?ISO-8859-1?Q?Zolt=E1n_Maj=F3?=) Date: Fri, 18 Jul 2014 13:34:10 +0200 Subject: [9] RFR(S): 8051303: 'optimized' build broken by JDK-8039425 Message-ID: <53C90632.2060204@oracle.com> Hi all, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8051303 Problem: 'optimized' build fails because of changes by JDK-8039425: "Code cleanup: PhaseIterGVN::optimize()" Solution: Changed preprocessor directive #ifndef PRODUCT to #ifdef ASSERT in PhaseIterGVN::optimize() Webrev: http://cr.openjdk.java.net/~thartmann/8051303/webrev.00/ Testing: run all JPRT tests, all passed. Thank you and best regards, Zoltan Majo From vladimir.kozlov at oracle.com Fri Jul 18 14:56:32 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jul 2014 07:56:32 -0700 Subject: [9] RFR(S): 8051303: 'optimized' build broken by JDK-8039425 In-Reply-To: <53C90632.2060204@oracle.com> References: <53C90632.2060204@oracle.com> Message-ID: <53C935A0.7080409@oracle.com> Zoltan, Change is good. Did you build 'optimized' VM to check the fix? Unfortunately JPRT does not build it. Thanks, Vladimir On 7/18/14 4:34 AM, Zolt?n Maj? wrote: > Hi all, > > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8051303 > > Problem: 'optimized' build fails because of changes by JDK-8039425: "Code cleanup: PhaseIterGVN::optimize()" > > Solution: Changed preprocessor directive #ifndef PRODUCT to #ifdef ASSERT in PhaseIterGVN::optimize() > > Webrev: http://cr.openjdk.java.net/~thartmann/8051303/webrev.00/ > > Testing: run all JPRT tests, all passed. > > Thank you and best regards, > > > Zoltan Majo > From zoltan.majo at oracle.com Fri Jul 18 14:59:32 2014 From: zoltan.majo at oracle.com (=?ISO-8859-1?Q?Zolt=E1n_Maj=F3?=) Date: Fri, 18 Jul 2014 16:59:32 +0200 Subject: [9] RFR(S): 8051303: 'optimized' build broken by JDK-8039425 In-Reply-To: <53C935A0.7080409@oracle.com> References: <53C90632.2060204@oracle.com> <53C935A0.7080409@oracle.com> Message-ID: <53C93654.1000004@oracle.com> Hi Vladimir, I have built 'all_optimized' (which includes 'optimized'). There were no problems. Sorry that I forgot to mention that. Best, Zoltan From vladimir.kozlov at oracle.com Fri Jul 18 15:06:43 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jul 2014 08:06:43 -0700 Subject: [9] RFR(S): 8051303: 'optimized' build broken by JDK-8039425 In-Reply-To: <53C93654.1000004@oracle.com> References: <53C90632.2060204@oracle.com> <53C935A0.7080409@oracle.com> <53C93654.1000004@oracle.com> Message-ID: <53C93803.1010903@oracle.com> Okay, good. Thanks, Vladimir On 7/18/14 7:59 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > I have built 'all_optimized' (which includes 'optimized'). There were no problems. > > Sorry that I forgot to mention that. > > Best, > > > Zoltan > From igor.ignatyev at oracle.com Fri Jul 18 15:27:28 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Jul 2014 19:27:28 +0400 Subject: RFR (S) : 8032449 : Get rid of JMX in test/compiler/whitebox/CompilerWhiteBoxTest.java In-Reply-To: <53C85044.9010209@oracle.com> References: <53C84BA1.4030909@oracle.com> <53C85044.9010209@oracle.com> Message-ID: <53C93CE0.6040901@oracle.com> Vladimir, thanks for review. during testing, I've found a problem: if a flag doesn't exist, WhiteBox::getVMFlag() will throw j.u.NoSuchElementException. I fixed it by replacing Optional::get() w/ Optional::orElse(null) webrev: http://cr.openjdk.java.net/~iignatyev/8032449/webrev.01/ retested locally and in JPRT, no failures except JDK-7076820 (JDK-8051337). Igor On 07/18/2014 02:37 AM, Vladimir Kozlov wrote: > Looks nice. > > Thanks, > Vladimir > > On 7/17/14 3:18 PM, Igor Ignatyev wrote: >> webrev: http://cr.openjdk.java.net/~iignatyev/8032449/webrev.00/ >> 69 lines changed: 27 ins; 34 del; 8 mod; >> >> Hi all, >> >> Please review the patch which removes dependency on JMX from several >> tests (replacing usage of 'c.s.m.HotSpotDiagnosticMXBean' w/ >> WhiteBox::get*VMFlag) and removes them from needs_compact3 group. >> >> I also moved @ignore tags after @library in the tests quarantined by >> 8047996. I needed this to verify that my changes don't break them, w/o >> that, jtreg can't start them and counts as errors even w/ -ignore:run >> due to: >>> Parse Exception: `@library' must appear before first `@run' >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8032449 >> testing: :compact1 w/ -ignore:run on compact1-linux-i586; ./compiler in >> JPRT From igor.ignatyev at oracle.com Fri Jul 18 15:38:24 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Jul 2014 19:38:24 +0400 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out In-Reply-To: <53C54178.7040500@oracle.com> References: <53C00191.8090505@oracle.com> <53C02E08.1070406@oracle.com> <53C3F398.7030205@oracle.com> <53C40C18.7010406@oracle.com> <53C41B1C.8000502@oracle.com> <53C42F7E.4050309@oracle.com> <53C54178.7040500@oracle.com> Message-ID: <53C93F70.8020501@oracle.com> Filipp, since the test doesn't depend on 'java.rmi.RMISecurityException', you can remove it from needs_compact2 group. otherwise, it looks good to me. // empty group looks like: ' = ' Igor On 07/15/2014 06:58 PM, Filipp Zhinkin wrote: > Vladimir, > > thank you for review. > > On 07/14/2014 11:29 PM, Vladimir Kozlov wrote: >> Looks good. >> >> "is compiled": >> >> + * Wait until InlinedArrayCloneTestCase::invokeArrayClone >> compiled. >> >> Small notes. Keep it on one line (no need for new webrev): >> >> 63 return InlinedArrayCloneTestCase.verifyArguments(1, 2, >> arr.clone(), 3, >> 64 4); >> > I'll fix it. > > Thanks, > Filipp. >> Thanks, >> Vladimir >> >> On 7/14/14 11:02 AM, Filipp Zhinkin wrote: >>> Here is new webrev: >>> http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.01/ >>> >>> What was done: >>> - threads count is min(100, 2 * availableProcessors) now; >>> - methods f and g were renamed to invokeArrayClone and verifyArguments. >>> >>> Thanks, >>> Filipp. >>> >>> On 07/14/2014 08:58 PM, Vladimir Kozlov wrote: >>>> On 7/14/14 8:13 AM, Filipp Zhinkin wrote: >>>>> Hi Vladimir, >>>>> >>>>> thank you for watching at it. >>>>> >>>>> On 07/11/2014 10:33 PM, Vladimir Kozlov wrote: >>>>>> 2 * availableProcessors() is still very big on Sparc machines (could >>>>>> be > 100). Do we need more threads then available >>>>>> processors for bug reproduction? >>>>> The more threads we have, the more our chances to reproduce issue. >>>>> >>>>> Issue could be reproduced when method deoptimized at particular >>>>> safepoint >>>>> and I don't see how to make this test more stable. >>>>> >>>>> I executed this test w/ jdk6u17 on different platforms w/ different >>>>> options >>>>> and here are results for three different approaches to choose threads >>>>> count: >>>>> >>>>> a) 2 * availableProcessors: >>>>> Test failed 111 times. >>>>> Test passed 57 times. >>>>> >>>>> b) 1 * availableProcessors: >>>>> Test failed 58 times. >>>>> Test passed 100 times. >>>>> >>>>> c) min(100, 2 * availableProcessors): >>>>> Test failed: 100 times. >>>>> Test passed: 68 times. >>>> >>>> I think you should use this c) >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> So I think we can cut off threads count by 100. >>>>>> >>>>>> Do not use one symbol f(), g() methods names. Use something like >>>>>> foo(), bar() or test1(), test2(). >>>>> Sure, I'll rename it. >>>>> >>>>> Thanks, >>>>> Filipp. >>>>>> >>>>>> thanks, >>>>>> Vladimir >>>>>> >>>>>> On 7/11/14 8:24 AM, Filipp Zhinkin wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> please review fix for 6848902. >>>>>>> >>>>>>> compiler/6589834/Test_ia32.java starts 100 threads with spin-loop >>>>>>> inside >>>>>>> and on some hosts with small amount of CPU coresit takes too much >>>>>>> time. >>>>>>> >>>>>>> Also there is another issue - test intended to catch interpreter's >>>>>>> stack >>>>>>> corruption after deoptimization, but it can fail only on VM crash. >>>>>>> I've checked how it works w/ JDK 6u17 (where 6589834 was not fixed) >>>>>>> and >>>>>>> found that issue may not cause VM crash. In suchsituation test just >>>>>>> prints message "Bug!", but do not actually fail. >>>>>>> >>>>>>> I reduced amount of used threads to 2 * availableProcessors() >>>>>>> and add more asserts on test results, so now it can catch original >>>>>>> issue even if VM doesn't crash. >>>>>>> >>>>>>> Also, VerifyStackwas added to test's options as it was suggested in >>>>>>> original test. >>>>>>> >>>>>>> After all, test still can reproduce original issue w/ 6u17. >>>>>>> >>>>>>> Testing: on local machine, automated on all platforms. >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 >>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Filipp. >>>>> >>> > From vladimir.kozlov at oracle.com Fri Jul 18 15:47:21 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jul 2014 08:47:21 -0700 Subject: RFR (S) : 8032449 : Get rid of JMX in test/compiler/whitebox/CompilerWhiteBoxTest.java In-Reply-To: <53C93CE0.6040901@oracle.com> References: <53C84BA1.4030909@oracle.com> <53C85044.9010209@oracle.com> <53C93CE0.6040901@oracle.com> Message-ID: <53C94189.6020502@oracle.com> Okay. Thanks, Vladimir On 7/18/14 8:27 AM, Igor Ignatyev wrote: > Vladimir, thanks for review. > > during testing, I've found a problem: if a flag doesn't exist, WhiteBox::getVMFlag() will throw > j.u.NoSuchElementException. I fixed it by replacing Optional::get() w/ Optional::orElse(null) > > webrev: http://cr.openjdk.java.net/~iignatyev/8032449/webrev.01/ > > retested locally and in JPRT, no failures except JDK-7076820 (JDK-8051337). > > Igor > > On 07/18/2014 02:37 AM, Vladimir Kozlov wrote: >> Looks nice. >> >> Thanks, >> Vladimir >> >> On 7/17/14 3:18 PM, Igor Ignatyev wrote: >>> webrev: http://cr.openjdk.java.net/~iignatyev/8032449/webrev.00/ >>> 69 lines changed: 27 ins; 34 del; 8 mod; >>> >>> Hi all, >>> >>> Please review the patch which removes dependency on JMX from several >>> tests (replacing usage of 'c.s.m.HotSpotDiagnosticMXBean' w/ >>> WhiteBox::get*VMFlag) and removes them from needs_compact3 group. >>> >>> I also moved @ignore tags after @library in the tests quarantined by >>> 8047996. I needed this to verify that my changes don't break them, w/o >>> that, jtreg can't start them and counts as errors even w/ -ignore:run >>> due to: >>>> Parse Exception: `@library' must appear before first `@run' >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8032449 >>> testing: :compact1 w/ -ignore:run on compact1-linux-i586; ./compiler in >>> JPRT From filipp.zhinkin at oracle.com Fri Jul 18 15:58:47 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 18 Jul 2014 19:58:47 +0400 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out In-Reply-To: <53C93F70.8020501@oracle.com> References: <53C00191.8090505@oracle.com> <53C02E08.1070406@oracle.com> <53C3F398.7030205@oracle.com> <53C40C18.7010406@oracle.com> <53C41B1C.8000502@oracle.com> <53C42F7E.4050309@oracle.com> <53C54178.7040500@oracle.com> <53C93F70.8020501@oracle.com> Message-ID: <53C94437.8040304@oracle.com> Igor, thank you for review. Here is updated webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.02/ I've fix small issues mentioned by Vladimir and remove this test from needs_compact2 group. Thanks, Filipp. On 07/18/2014 07:38 PM, Igor Ignatyev wrote: > Filipp, > > since the test doesn't depend on 'java.rmi.RMISecurityException', you > can remove it from needs_compact2 group. > > otherwise, it looks good to me. > > // empty group looks like: ' = ' > > Igor > > On 07/15/2014 06:58 PM, Filipp Zhinkin wrote: >> Vladimir, >> >> thank you for review. >> >> On 07/14/2014 11:29 PM, Vladimir Kozlov wrote: >>> Looks good. >>> >>> "is compiled": >>> >>> + * Wait until InlinedArrayCloneTestCase::invokeArrayClone >>> compiled. >>> >>> Small notes. Keep it on one line (no need for new webrev): >>> >>> 63 return InlinedArrayCloneTestCase.verifyArguments(1, 2, >>> arr.clone(), 3, >>> 64 4); >>> >> I'll fix it. >> >> Thanks, >> Filipp. >>> Thanks, >>> Vladimir >>> >>> On 7/14/14 11:02 AM, Filipp Zhinkin wrote: >>>> Here is new webrev: >>>> http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.01/ >>>> >>>> What was done: >>>> - threads count is min(100, 2 * availableProcessors) now; >>>> - methods f and g were renamed to invokeArrayClone and >>>> verifyArguments. >>>> >>>> Thanks, >>>> Filipp. >>>> >>>> On 07/14/2014 08:58 PM, Vladimir Kozlov wrote: >>>>> On 7/14/14 8:13 AM, Filipp Zhinkin wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> thank you for watching at it. >>>>>> >>>>>> On 07/11/2014 10:33 PM, Vladimir Kozlov wrote: >>>>>>> 2 * availableProcessors() is still very big on Sparc machines >>>>>>> (could >>>>>>> be > 100). Do we need more threads then available >>>>>>> processors for bug reproduction? >>>>>> The more threads we have, the more our chances to reproduce issue. >>>>>> >>>>>> Issue could be reproduced when method deoptimized at particular >>>>>> safepoint >>>>>> and I don't see how to make this test more stable. >>>>>> >>>>>> I executed this test w/ jdk6u17 on different platforms w/ different >>>>>> options >>>>>> and here are results for three different approaches to choose >>>>>> threads >>>>>> count: >>>>>> >>>>>> a) 2 * availableProcessors: >>>>>> Test failed 111 times. >>>>>> Test passed 57 times. >>>>>> >>>>>> b) 1 * availableProcessors: >>>>>> Test failed 58 times. >>>>>> Test passed 100 times. >>>>>> >>>>>> c) min(100, 2 * availableProcessors): >>>>>> Test failed: 100 times. >>>>>> Test passed: 68 times. >>>>> >>>>> I think you should use this c) >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> So I think we can cut off threads count by 100. >>>>>>> >>>>>>> Do not use one symbol f(), g() methods names. Use something like >>>>>>> foo(), bar() or test1(), test2(). >>>>>> Sure, I'll rename it. >>>>>> >>>>>> Thanks, >>>>>> Filipp. >>>>>>> >>>>>>> thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 7/11/14 8:24 AM, Filipp Zhinkin wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> please review fix for 6848902. >>>>>>>> >>>>>>>> compiler/6589834/Test_ia32.java starts 100 threads with spin-loop >>>>>>>> inside >>>>>>>> and on some hosts with small amount of CPU coresit takes too much >>>>>>>> time. >>>>>>>> >>>>>>>> Also there is another issue - test intended to catch interpreter's >>>>>>>> stack >>>>>>>> corruption after deoptimization, but it can fail only on VM crash. >>>>>>>> I've checked how it works w/ JDK 6u17 (where 6589834 was not >>>>>>>> fixed) >>>>>>>> and >>>>>>>> found that issue may not cause VM crash. In suchsituation test >>>>>>>> just >>>>>>>> prints message "Bug!", but do not actually fail. >>>>>>>> >>>>>>>> I reduced amount of used threads to 2 * availableProcessors() >>>>>>>> and add more asserts on test results, so now it can catch original >>>>>>>> issue even if VM doesn't crash. >>>>>>>> >>>>>>>> Also, VerifyStackwas added to test's options as it was >>>>>>>> suggested in >>>>>>>> original test. >>>>>>>> >>>>>>>> After all, test still can reproduce original issue w/ 6u17. >>>>>>>> >>>>>>>> Testing: on local machine, automated on all platforms. >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 >>>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Filipp. >>>>>> >>>> >> From igor.ignatyev at oracle.com Fri Jul 18 16:10:28 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Jul 2014 20:10:28 +0400 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out In-Reply-To: <53C94437.8040304@oracle.com> References: <53C00191.8090505@oracle.com> <53C02E08.1070406@oracle.com> <53C3F398.7030205@oracle.com> <53C40C18.7010406@oracle.com> <53C41B1C.8000502@oracle.com> <53C42F7E.4050309@oracle.com> <53C54178.7040500@oracle.com> <53C93F70.8020501@oracle.com> <53C94437.8040304@oracle.com> Message-ID: <53C946F4.2070102@oracle.com> good, thanks for fixing this. I'll sponsor your fix. Igor On 07/18/2014 07:58 PM, Filipp Zhinkin wrote: > Igor, > > thank you for review. > > Here is updated webrev: > http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.02/ > > I've fix small issues mentioned by Vladimir and remove this test from > needs_compact2 group. > > Thanks, > Filipp. > > On 07/18/2014 07:38 PM, Igor Ignatyev wrote: >> Filipp, >> >> since the test doesn't depend on 'java.rmi.RMISecurityException', you >> can remove it from needs_compact2 group. >> >> otherwise, it looks good to me. >> >> // empty group looks like: ' = ' >> >> Igor >> >> On 07/15/2014 06:58 PM, Filipp Zhinkin wrote: >>> Vladimir, >>> >>> thank you for review. >>> >>> On 07/14/2014 11:29 PM, Vladimir Kozlov wrote: >>>> Looks good. >>>> >>>> "is compiled": >>>> >>>> + * Wait until InlinedArrayCloneTestCase::invokeArrayClone >>>> compiled. >>>> >>>> Small notes. Keep it on one line (no need for new webrev): >>>> >>>> 63 return InlinedArrayCloneTestCase.verifyArguments(1, 2, >>>> arr.clone(), 3, >>>> 64 4); >>>> >>> I'll fix it. >>> >>> Thanks, >>> Filipp. >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/14/14 11:02 AM, Filipp Zhinkin wrote: >>>>> Here is new webrev: >>>>> http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.01/ >>>>> >>>>> What was done: >>>>> - threads count is min(100, 2 * availableProcessors) now; >>>>> - methods f and g were renamed to invokeArrayClone and >>>>> verifyArguments. >>>>> >>>>> Thanks, >>>>> Filipp. >>>>> >>>>> On 07/14/2014 08:58 PM, Vladimir Kozlov wrote: >>>>>> On 7/14/14 8:13 AM, Filipp Zhinkin wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> thank you for watching at it. >>>>>>> >>>>>>> On 07/11/2014 10:33 PM, Vladimir Kozlov wrote: >>>>>>>> 2 * availableProcessors() is still very big on Sparc machines >>>>>>>> (could >>>>>>>> be > 100). Do we need more threads then available >>>>>>>> processors for bug reproduction? >>>>>>> The more threads we have, the more our chances to reproduce issue. >>>>>>> >>>>>>> Issue could be reproduced when method deoptimized at particular >>>>>>> safepoint >>>>>>> and I don't see how to make this test more stable. >>>>>>> >>>>>>> I executed this test w/ jdk6u17 on different platforms w/ different >>>>>>> options >>>>>>> and here are results for three different approaches to choose >>>>>>> threads >>>>>>> count: >>>>>>> >>>>>>> a) 2 * availableProcessors: >>>>>>> Test failed 111 times. >>>>>>> Test passed 57 times. >>>>>>> >>>>>>> b) 1 * availableProcessors: >>>>>>> Test failed 58 times. >>>>>>> Test passed 100 times. >>>>>>> >>>>>>> c) min(100, 2 * availableProcessors): >>>>>>> Test failed: 100 times. >>>>>>> Test passed: 68 times. >>>>>> >>>>>> I think you should use this c) >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> So I think we can cut off threads count by 100. >>>>>>>> >>>>>>>> Do not use one symbol f(), g() methods names. Use something like >>>>>>>> foo(), bar() or test1(), test2(). >>>>>>> Sure, I'll rename it. >>>>>>> >>>>>>> Thanks, >>>>>>> Filipp. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 7/11/14 8:24 AM, Filipp Zhinkin wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> please review fix for 6848902. >>>>>>>>> >>>>>>>>> compiler/6589834/Test_ia32.java starts 100 threads with spin-loop >>>>>>>>> inside >>>>>>>>> and on some hosts with small amount of CPU coresit takes too much >>>>>>>>> time. >>>>>>>>> >>>>>>>>> Also there is another issue - test intended to catch interpreter's >>>>>>>>> stack >>>>>>>>> corruption after deoptimization, but it can fail only on VM crash. >>>>>>>>> I've checked how it works w/ JDK 6u17 (where 6589834 was not >>>>>>>>> fixed) >>>>>>>>> and >>>>>>>>> found that issue may not cause VM crash. In suchsituation test >>>>>>>>> just >>>>>>>>> prints message "Bug!", but do not actually fail. >>>>>>>>> >>>>>>>>> I reduced amount of used threads to 2 * availableProcessors() >>>>>>>>> and add more asserts on test results, so now it can catch original >>>>>>>>> issue even if VM doesn't crash. >>>>>>>>> >>>>>>>>> Also, VerifyStackwas added to test's options as it was >>>>>>>>> suggested in >>>>>>>>> original test. >>>>>>>>> >>>>>>>>> After all, test still can reproduce original issue w/ 6u17. >>>>>>>>> >>>>>>>>> Testing: on local machine, automated on all platforms. >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Filipp. >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Fri Jul 18 16:10:28 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jul 2014 09:10:28 -0700 Subject: RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out In-Reply-To: <53C94437.8040304@oracle.com> References: <53C00191.8090505@oracle.com> <53C02E08.1070406@oracle.com> <53C3F398.7030205@oracle.com> <53C40C18.7010406@oracle.com> <53C41B1C.8000502@oracle.com> <53C42F7E.4050309@oracle.com> <53C54178.7040500@oracle.com> <53C93F70.8020501@oracle.com> <53C94437.8040304@oracle.com> Message-ID: <53C946F4.1050301@oracle.com> Good. Thanks, Vladimir On 7/18/14 8:58 AM, Filipp Zhinkin wrote: > Igor, > > thank you for review. > > Here is updated webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.02/ > > I've fix small issues mentioned by Vladimir and remove this test from needs_compact2 group. > > Thanks, > Filipp. > > On 07/18/2014 07:38 PM, Igor Ignatyev wrote: >> Filipp, >> >> since the test doesn't depend on 'java.rmi.RMISecurityException', you can remove it from needs_compact2 group. >> >> otherwise, it looks good to me. >> >> // empty group looks like: ' = ' >> >> Igor >> >> On 07/15/2014 06:58 PM, Filipp Zhinkin wrote: >>> Vladimir, >>> >>> thank you for review. >>> >>> On 07/14/2014 11:29 PM, Vladimir Kozlov wrote: >>>> Looks good. >>>> >>>> "is compiled": >>>> >>>> + * Wait until InlinedArrayCloneTestCase::invokeArrayClone >>>> compiled. >>>> >>>> Small notes. Keep it on one line (no need for new webrev): >>>> >>>> 63 return InlinedArrayCloneTestCase.verifyArguments(1, 2, >>>> arr.clone(), 3, >>>> 64 4); >>>> >>> I'll fix it. >>> >>> Thanks, >>> Filipp. >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/14/14 11:02 AM, Filipp Zhinkin wrote: >>>>> Here is new webrev: >>>>> http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.01/ >>>>> >>>>> What was done: >>>>> - threads count is min(100, 2 * availableProcessors) now; >>>>> - methods f and g were renamed to invokeArrayClone and verifyArguments. >>>>> >>>>> Thanks, >>>>> Filipp. >>>>> >>>>> On 07/14/2014 08:58 PM, Vladimir Kozlov wrote: >>>>>> On 7/14/14 8:13 AM, Filipp Zhinkin wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> thank you for watching at it. >>>>>>> >>>>>>> On 07/11/2014 10:33 PM, Vladimir Kozlov wrote: >>>>>>>> 2 * availableProcessors() is still very big on Sparc machines (could >>>>>>>> be > 100). Do we need more threads then available >>>>>>>> processors for bug reproduction? >>>>>>> The more threads we have, the more our chances to reproduce issue. >>>>>>> >>>>>>> Issue could be reproduced when method deoptimized at particular >>>>>>> safepoint >>>>>>> and I don't see how to make this test more stable. >>>>>>> >>>>>>> I executed this test w/ jdk6u17 on different platforms w/ different >>>>>>> options >>>>>>> and here are results for three different approaches to choose threads >>>>>>> count: >>>>>>> >>>>>>> a) 2 * availableProcessors: >>>>>>> Test failed 111 times. >>>>>>> Test passed 57 times. >>>>>>> >>>>>>> b) 1 * availableProcessors: >>>>>>> Test failed 58 times. >>>>>>> Test passed 100 times. >>>>>>> >>>>>>> c) min(100, 2 * availableProcessors): >>>>>>> Test failed: 100 times. >>>>>>> Test passed: 68 times. >>>>>> >>>>>> I think you should use this c) >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> So I think we can cut off threads count by 100. >>>>>>>> >>>>>>>> Do not use one symbol f(), g() methods names. Use something like >>>>>>>> foo(), bar() or test1(), test2(). >>>>>>> Sure, I'll rename it. >>>>>>> >>>>>>> Thanks, >>>>>>> Filipp. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 7/11/14 8:24 AM, Filipp Zhinkin wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> please review fix for 6848902. >>>>>>>>> >>>>>>>>> compiler/6589834/Test_ia32.java starts 100 threads with spin-loop >>>>>>>>> inside >>>>>>>>> and on some hosts with small amount of CPU coresit takes too much >>>>>>>>> time. >>>>>>>>> >>>>>>>>> Also there is another issue - test intended to catch interpreter's >>>>>>>>> stack >>>>>>>>> corruption after deoptimization, but it can fail only on VM crash. >>>>>>>>> I've checked how it works w/ JDK 6u17 (where 6589834 was not fixed) >>>>>>>>> and >>>>>>>>> found that issue may not cause VM crash. In suchsituation test just >>>>>>>>> prints message "Bug!", but do not actually fail. >>>>>>>>> >>>>>>>>> I reduced amount of used threads to 2 * availableProcessors() >>>>>>>>> and add more asserts on test results, so now it can catch original >>>>>>>>> issue even if VM doesn't crash. >>>>>>>>> >>>>>>>>> Also, VerifyStackwas added to test's options as it was suggested in >>>>>>>>> original test. >>>>>>>>> >>>>>>>>> After all, test still can reproduce original issue w/ 6u17. >>>>>>>>> >>>>>>>>> Testing: on local machine, automated on all platforms. >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6848902 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Filipp. >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Fri Jul 18 17:31:23 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jul 2014 10:31:23 -0700 Subject: RFR (L): 7173584: Implement arraycopy as a macro node In-Reply-To: <7E38E57B-6091-42CC-9EA7-E6CFA09B68B4@oracle.com> References: <9CAF8242-736B-4B8B-8926-3451DA87AF70@oracle.com> <5064AF8B.1090509@oracle.com> <317A0474-32A8-4C0C-8668-FA2682B4E815@oracle.com> <5069E3DD.6090401@oracle.com> <125CB7F4-DD68-4E29-A6AC-CA2F9117B410@oracle.com> <539B7EEE.3030409@oracle.com> <7E38E57B-6091-42CC-9EA7-E6CFA09B68B4@oracle.com> Message-ID: <53C959EB.5060908@oracle.com> On 7/2/14 8:26 AM, Roland Westrelin wrote: > Thanks for the review, Vladimir. See comments inlined: > >>> Here is a new webrev for this after a long time: >>> >>> http://cr.openjdk.java.net/~roland/7173584/webrev.03/ >> >> Looks reasonable. >> >>> >>> This addresses the comments below (replies inlined): >>> >>>> I don't think you need suffix "_any_phase" in the name gen_subtype_check_any_phase(). Just add comment that it is also used in phase Macro. Generally speaking GraphKit class is wrong place for it. May be it should be in base class Phase but keep the code in graphKit.cpp file. >>>> >>>> You don't need special gvn_transform(). It is already done since Macro phase sets gvn._delay_transform flag to true and: >>>> >>>> Node *PhaseIterGVN::transform( Node *n ) { >>>> if (_delay_transform) { >>>> // Register the node but don't optimize for now >>>> register_new_node_with_optimizer(n); >>>> return n; >>>> } >>>> >>>> gvn_transform_ctrl() should remain to be record_for_igvn() but virtual as you suggested. >>> >>> BTW, is it required that transform_ctrl() does nothing for PhaseIterGVN? Or is it simply that it is a waste of resources to process a Region node, for instance, before its inputs? >> >> + gvn->transform(iff); >> + if (!bol->is_Con()) gvn->transform_ctrl(iff); >> >> During Parse record_for_igvn() puts nodes on worklist which will populate initial igvn._worklist. register_new_node_with_optimizer(n) does that already when IGVN transformation is delayed. So PhaseIterGVN::transform() will do what record_for_igvn() does. >> >> transform_ctrl() is not good name. record_for_igvn() is very good. Why not use it? >> >> phaseX.hpp >> >> + virtual void record_for_igvn(Node *n) { >> + C->record_for_igvn(n); >> + } > > Ok. And: > > virtual void record_for_igvn(Node *n) { } > > for PhaseIterGVN? Yes. > >>>> It would be also nice to factor out IfNode creation into separate method (it used 5 times): >>>> >>>> + Node* cmp = gvn_transform(new(C, 3) CmpPNode(subklass, superklass), gvn); >>>> + Node* bol = gvn_transform(new(C, 2) BoolNode(cmp, BoolTest::eq), gvn); >>>> + IfNode* iff = new (C, 2) IfNode(*ctrl, bol, PROB_STATIC_FREQUENT, COUNT_UNKNOWN) >>>> + gvn_transform(iff, gvn); >>>> + if (!bol->is_Con()) gvn_transform_ctrl(iff, gvn); >>>> >>>> >>>> Next optimization belongs to ConvI2LNode::Value(). May be we should not widen type in ConvI2LNode::Ideal() and Value() if input is singleton (constant). >>>> >>>> + Node *chk_off_X = LP64_ONLY(NULL) NOT_LP64(chk_off); >>>> +#ifdef _LP64 >>>> + jint chk_off_con = gvn->find_int_con(chk_off, Type::OffsetBot); >>>> + if (chk_off_con != Type::OffsetBot) { >>>> + chk_off_X = gvn->longcon((jlong) chk_off_con); >>>> + } else { >>>> + chk_off_X = gvn_transform(new (C, 2) ConvI2LNode(chk_off), gvn); >>>> + } >>>> +#endif >>> >>> I removed this and didn?t make any change to ConvI2LNode::Value() and ConvI2LNode::Ideal(). >>> The widening uses MAX2((jlong)in_type->_lo, lo1), MIN2((jlong)in_type->_hi, hi1) as new bounds. If the input is constant and falls within [lo1, hi1] then the result is [(jlong)in_type->_lo, (jlong)in_type->_hi] which is constant. Only if the input is constant and doesn?t fall within [lo1, hi1] would there be a problem. But this inconsistency between the ConvI2L and its input is unexpected, right? It doesn?t seem to ever happen in practice. >> >> It happens. ConvI2L node is usually generated after range check of array index and its type is set to [0,arr.length]. Nothing prevents to have negative constant as index. The array access will not be executed then but ConvI2L's and input's types may not overlap. > > But then the load is control dependent on the range check, the ConvI2L is input to the load. If the index is a constant that doesn?t fit in the range, only the branch of the range check that fails is kept, the load is eliminated and so is the ConvI2L? That is correct unless we have a bug. > > FWIW, I ran a bunch of tests with this debug code: > > diff --git a/src/share/vm/opto/phaseX.cpp b/src/share/vm/opto/phaseX.cpp > --- a/src/share/vm/opto/phaseX.cpp > +++ b/src/share/vm/opto/phaseX.cpp > @@ -1049,7 +1049,12 @@ > set_type_bottom(n); > } > > - return transform_old(n); > + bool is_constant = n->Opcode() == Op_ConvI2L && n->in(1) && type(n->in(1))->is_int()->is_con(); > + Node* res = transform_old(n); > + if (is_constant && !type(res)->is_long()->is_con()) { > + fatal("XXXXXXXXXXXX"); > + } > + return res; > } > > Node *PhaseIterGVN::transform_old(Node* n) { > > and it never failed. ConvI2LNode::Value() will produce Long constant or Top. And Top is also constant. Vladimir > > Roland. > >> >> Vladimir >> >>> >>> ConvI2LNode::Value() computes the type with tl = tl->filter(_type) so if the input is constant, the result is constant as well unless tl and _type are disjoint. Why would that happen? >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> Roland Westrelin wrote: >>>>>> Also instead of duplicating gen_subtype_check() in macroArrayCopy.cpp can you modify the original one to work for you (by passing additional flag)? >>>>> This (on top of previous webrev - I've done only minimal testing)? >>>>> http://cr.openjdk.java.net/~roland/7173584/webrev.02/ >>>>> Or do we want gvn_transform/gvn_transform_ctrl to be virtual methods of PhaseGVN/PhaseIterGVN? >>>>> Roland. > From vladimir.kozlov at oracle.com Fri Jul 18 17:58:50 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jul 2014 10:58:50 -0700 Subject: Optimize signed integer comparison In-Reply-To: <53A95B03.4020309@oracle.com> References: <53A95B03.4020309@oracle.com> Message-ID: <53C9605A.4040602@oracle.com> What you described is exactly why 8043284 was filed. If we only looking for BoolNode 'eq'/'ne' checks then returning TypeInt:CC_LT or CC_GT should give correct 'ne' result. Right? See BoolTest::cc2logical(). Vladimir On 6/24/14 4:03 AM, Tobias Hartmann wrote: > Hi, > > it would be nice if someone could have a look at this. While working at > JDK-8043284 [1] I noticed the following problem (see attached example > Unreachable.java): > > The method test(..) takes a char c, casts it to int and adds INT_MAX to > it. If the result is equal to CHAR_MAX the method shouldNotReachHere(..) > is executed. But no matter what value c has, shouldNotReachHere(...) is > never executed because after the addition the result is either MAX_INT > or overflows and has a value between INT_MIN and INT_MIN + CHAR_MAX - 1. > > The problem is that the C2 compiler does not detect this unreachable > code. The C2 type system merges the two possible integer ranges > [INT_MIN] and [INT_MIN + CHAR_MAX -1] into the general [INT_MIN, > INT_MAX] range. The CmpINode is then unable to detect the inequality and > returns the TypeInt::CC condition code which we cannot optimize. > > To fix this we can check in CmpINode::Value(..) if the result of the > AddINode overflows and if so compare the two possible ranges with the > target value (very similar to what Vladimir did for [2]). If both ranges > are unequal we would return an unequal condition code and translate it > to a boolean value in BoolNode::Value(..). This would lead to removal of > all unreachable nodes in the graph. > > However, the problem with this solution is that we currently do not have > an unequal type (we only have LT, GT, EQ, LE, GE) and adding one seems > to be difficult because the CC integer range [-1, 1] is already used > (see type.cpp line 297). I wonder why we don't have an own type for the > condition codes but use TypeInt. > > Because my example is quite artificial, I did some testing with Octane > and it looks like as if this happens quite often. I therefore think we > should fix it. > > What do you think? > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8043284 > [2] https://bugs.openjdk.java.net/browse/JDK-8042786 From john.r.rose at oracle.com Fri Jul 18 20:18:18 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 18 Jul 2014 13:18:18 -0700 Subject: Optimize signed integer comparison In-Reply-To: <53C9605A.4040602@oracle.com> References: <53A95B03.4020309@oracle.com> <53C9605A.4040602@oracle.com> Message-ID: <7F0ECBF5-E5B0-43E4-BD60-D5AC6B88BC9B@oracle.com> On Jul 18, 2014, at 10:58 AM, Vladimir Kozlov wrote: > What you described is exactly why 8043284 was filed. > > If we only looking for BoolNode 'eq'/'ne' checks then returning TypeInt:CC_LT or CC_GT should give correct 'ne' result. Right? See BoolTest::cc2logical(). It is risky to return an incorrect value for a node based on what other nodes we think might be testing it, since if some other node picks up the incorrect value, it might make a wrong decision with it. A couple of scenarios where "some other node" might pop up: 1. During parsing when we haven't hooked everything together yet (because we haven't parsed every bytecode yet). 2. If a third node gets replaced by the incorrectly-valued node (because of something like value numbering). It would be better to transform the nodes that are testing for the NE condition. The NE condition (which we can't directly express in types) is produced by a Cmp node. The node which could use an NE condition is a Bool node (testing eq or ne). If we can make a transformation fold up both the Bool and the Cmp, then we can eliminate the unreached code, right? So the optimization is a little less local than we want. Alternatively, and more powerfully, we could add bitfield tracking to the type system. Graal has this (based on type equations I sent them). If we were to do both range and bitfield tracking of the {-1,0,1} range of Cmp operations, we could express the type NE using the type assertion "(cmp&-2)!=0" which can be coded as "downMask!=0". ? John > Vladimir > > On 6/24/14 4:03 AM, Tobias Hartmann wrote: >> Hi, >> >> it would be nice if someone could have a look at this. While working at >> JDK-8043284 [1] I noticed the following problem (see attached example >> Unreachable.java): >> >> The method test(..) takes a char c, casts it to int and adds INT_MAX to >> it. If the result is equal to CHAR_MAX the method shouldNotReachHere(..) >> is executed. But no matter what value c has, shouldNotReachHere(...) is >> never executed because after the addition the result is either MAX_INT >> or overflows and has a value between INT_MIN and INT_MIN + CHAR_MAX - 1. >> >> The problem is that the C2 compiler does not detect this unreachable >> code. The C2 type system merges the two possible integer ranges >> [INT_MIN] and [INT_MIN + CHAR_MAX -1] into the general [INT_MIN, >> INT_MAX] range. The CmpINode is then unable to detect the inequality and >> returns the TypeInt::CC condition code which we cannot optimize. >> >> To fix this we can check in CmpINode::Value(..) if the result of the >> AddINode overflows and if so compare the two possible ranges with the >> target value (very similar to what Vladimir did for [2]). If both ranges >> are unequal we would return an unequal condition code and translate it >> to a boolean value in BoolNode::Value(..). This would lead to removal of >> all unreachable nodes in the graph. >> >> However, the problem with this solution is that we currently do not have >> an unequal type (we only have LT, GT, EQ, LE, GE) and adding one seems >> to be difficult because the CC integer range [-1, 1] is already used >> (see type.cpp line 297). I wonder why we don't have an own type for the >> condition codes but use TypeInt. >> >> Because my example is quite artificial, I did some testing with Octane >> and it looks like as if this happens quite often. I therefore think we >> should fix it. >> >> What do you think? >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8043284 >> [2] https://bugs.openjdk.java.net/browse/JDK-8042786 From vladimir.kozlov at oracle.com Fri Jul 18 21:58:43 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jul 2014 14:58:43 -0700 Subject: Optimize signed integer comparison In-Reply-To: <7F0ECBF5-E5B0-43E4-BD60-D5AC6B88BC9B@oracle.com> References: <53A95B03.4020309@oracle.com> <53C9605A.4040602@oracle.com> <7F0ECBF5-E5B0-43E4-BD60-D5AC6B88BC9B@oracle.com> Message-ID: <53C99893.6060308@oracle.com> On 7/18/14 1:18 PM, John Rose wrote: > On Jul 18, 2014, at 10:58 AM, Vladimir Kozlov wrote: > >> What you described is exactly why 8043284 was filed. >> >> If we only looking for BoolNode 'eq'/'ne' checks then returning TypeInt:CC_LT or CC_GT should give correct 'ne' result. Right? See BoolTest::cc2logical(). > > It is risky to return an incorrect value for a node based on what other nodes we think might be testing it, since if some other node picks up the incorrect value, it might make a wrong decision with it. A couple of scenarios where "some other node" might pop up: 1. During parsing when we haven't hooked everything together yet (because we haven't parsed every bytecode yet). 2. If a third node gets replaced by the incorrectly-valued node (because of something like value numbering). We already do this trick for CmpP nodes: return TypeInt::CC_GT; // different pointers We never change BoolNode._test condition from 'eq' to 'lt', for example. We only can change it to 'ne' and swap If node's projections. Also we usually guard such cases by checking that we have only one user (one BoolNode). > > It would be better to transform the nodes that are testing for the NE condition. The NE condition (which we can't directly express in types) is produced by a Cmp node. The node which could use an NE condition is a Bool node (testing eq or ne). If we can make a transformation fold up both the Bool and the Cmp, then we can eliminate the unreached code, right? So the optimization is a little less local than we want. Yes, in the bug report I suggested to optimize BoolNode instead of optimizing CmpI. It may be safer then setting type to CmpI, I agree. > > Alternatively, and more powerfully, we could add bitfield tracking to the type system. Graal has this (based on type equations I sent them). If we were to do both range and bitfield tracking of the {-1,0,1} range of Cmp operations, we could express the type NE using the type assertion "(cmp&-2)!=0" which can be coded as "downMask!=0". It is out of scope of these changes. Should be filed separate RFE. Thanks, Vladimir > > ? John > >> Vladimir >> >> On 6/24/14 4:03 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> it would be nice if someone could have a look at this. While working at >>> JDK-8043284 [1] I noticed the following problem (see attached example >>> Unreachable.java): >>> >>> The method test(..) takes a char c, casts it to int and adds INT_MAX to >>> it. If the result is equal to CHAR_MAX the method shouldNotReachHere(..) >>> is executed. But no matter what value c has, shouldNotReachHere(...) is >>> never executed because after the addition the result is either MAX_INT >>> or overflows and has a value between INT_MIN and INT_MIN + CHAR_MAX - 1. >>> >>> The problem is that the C2 compiler does not detect this unreachable >>> code. The C2 type system merges the two possible integer ranges >>> [INT_MIN] and [INT_MIN + CHAR_MAX -1] into the general [INT_MIN, >>> INT_MAX] range. The CmpINode is then unable to detect the inequality and >>> returns the TypeInt::CC condition code which we cannot optimize. >>> >>> To fix this we can check in CmpINode::Value(..) if the result of the >>> AddINode overflows and if so compare the two possible ranges with the >>> target value (very similar to what Vladimir did for [2]). If both ranges >>> are unequal we would return an unequal condition code and translate it >>> to a boolean value in BoolNode::Value(..). This would lead to removal of >>> all unreachable nodes in the graph. >>> >>> However, the problem with this solution is that we currently do not have >>> an unequal type (we only have LT, GT, EQ, LE, GE) and adding one seems >>> to be difficult because the CC integer range [-1, 1] is already used >>> (see type.cpp line 297). I wonder why we don't have an own type for the >>> condition codes but use TypeInt. >>> >>> Because my example is quite artificial, I did some testing with Octane >>> and it looks like as if this happens quite often. I therefore think we >>> should fix it. >>> >>> What do you think? >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8043284 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8042786 > From john.r.rose at oracle.com Fri Jul 18 22:16:11 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 18 Jul 2014 15:16:11 -0700 Subject: Optimize signed integer comparison In-Reply-To: <53C99893.6060308@oracle.com> References: <53A95B03.4020309@oracle.com> <53C9605A.4040602@oracle.com> <7F0ECBF5-E5B0-43E4-BD60-D5AC6B88BC9B@oracle.com> <53C99893.6060308@oracle.com> Message-ID: <412B83A9-CBA8-420A-80DD-E4D6762CBF88@oracle.com> On Jul 18, 2014, at 2:58 PM, Vladimir Kozlov wrote: >> >> Alternatively, and more powerfully, we could add bitfield tracking to the type system. Graal has this (based on type equations I sent them). If we were to do both range and bitfield tracking of the {-1,0,1} range of Cmp operations, we could express the type NE using the type assertion "(cmp&-2)!=0" which can be coded as "downMask!=0". > > It is out of scope of these changes. Should be filed separate RFE. Already done as JDK-8001436; I linked the bugs FTR. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.noll at oracle.com Mon Jul 21 06:46:39 2014 From: albert.noll at oracle.com (Albert) Date: Mon, 21 Jul 2014 08:46:39 +0200 Subject: [9] RFR(S): 8051303: 'optimized' build broken by JDK-8039425 In-Reply-To: <53C93803.1010903@oracle.com> References: <53C90632.2060204@oracle.com> <53C935A0.7080409@oracle.com> <53C93654.1000004@oracle.com> <53C93803.1010903@oracle.com> Message-ID: <53CCB74F.3000408@oracle.com> Looks good, Albert On 07/18/2014 05:06 PM, Vladimir Kozlov wrote: > Okay, good. > > Thanks, > Vladimir > > On 7/18/14 7:59 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> I have built 'all_optimized' (which includes 'optimized'). There were >> no problems. >> >> Sorry that I forgot to mention that. >> >> Best, >> >> >> Zoltan >> From tobias.hartmann at oracle.com Mon Jul 21 09:50:51 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 21 Jul 2014 11:50:51 +0200 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> <53C7A808.6040807@oracle.com> <53C84EEA.3000508@oracle.com> Message-ID: <53CCE27B.4010102@oracle.com> Vladimir, John, thanks for the review. On 18.07.2014 01:32, John Rose wrote: > On Jul 17, 2014, at 3:32 PM, Vladimir Kozlov wrote: > >> Initial prototype was written by me so part of changes are mine. >> >> On 7/17/14 3:40 AM, Tobias Hartmann wrote: >>> Hi John, >>> >>> thanks a lot for the detailed review! Please see comments inline. >>> >>> On 16.07.2014 01:10, John Rose wrote: >>>>>> Done. New webrev: >>>>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ >>>> Loading C->_modified_nodes with a stack address is bad news, even if >>>> the code apparently cleans it up on exit. (I say "apparently" because >>>> there are early exits from that block, and the cleanup is not RAII >>>> style.) I strongly suggest heap allocation instead of stack >>>> allocation; it's expensive but it's for debug code. >> The list array allocation is done in compiler arena which is cleaned after compilation finished by ResourceMark, only descriptor is on stack: >> >> + Unique_Node_List modified_nodes(comp_arena()); >> >> It is our normal style. We do it a lot, see Compile::Code_Gen(). > Yes, we do it when adding phase control blocks to the Compile object, within the tree of calls rooted at the constructor. I see that the new code is arguably part of that pattern. I hope that is an exceptional use of this style? > > Note that C2Compiler::compile_method creates the Compile object and then queries it. When it queries it, the Compile object may contain dangling pointers into phase control blocks stored on the stack (during subroutine calls like Code_Gen) but now deallocated. > > It seems to me that we avoid touching those dangling pointers by simple will power and discipline. Such a style doesn't scale, since it's too easy to make mistakes as the code gets complicated. > >> Tobias, if you want to allocate Unique_Node_List object on arena: >> >> _modified_nodes = new (comp_arena()) Unique_Node_List(comp_arena()); > That makes me feel much better. > > I would prefer for us to do it this way for the other stack-chunks also, but that would be outside the scope of this bug. I changed it to heap allocation. > Tobias, thanks for doing this work. > > ? John > >>> There are other places in the code where this is done, for example in >>> Compile::Compile(..) the Unique_Node_List 'for_igvn' is created on the >>> stack. Is this a special case? >>> >>> I'm not sure how to correctly allocate the object on the heap. Do I have >>> to use new/delete or is this handled by some magic in "ResourceObject'? >>> >>> >>>> You inserted '#ifdef ASSERT' after >>>> 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you need it, >>>> since all of the code (including the similar insertion a few lines up) >>>> is '#ifndef PRODUCT'. See also suggestion above regarding >>>> 'modified_nodes'. >> #ifndef PRODUCT is also 'optimized' version of VM. n->dump() method is not defined in optimized build. That is why asserts are needed. >> >> Tobias, please, build 'optimized' VM to verify your changes. Thanks for the hint, the optimized build did not work. I'm now using PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. This is consistent with other verification methods like Compile::verify_graph_edges(..). New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.03/ Thanks, Tobias >> Thanks, >> Vladimir >> >>> True, I removed the #ifdef. >>> >>>> There are a few places where tests like 'while >>>> (modified_list->size())' appears but there is no null check of >>>> 'modified_list' itself. This could cause a crash if we ever get the >>>> phasing wrong; consider an assert or explicit null check 'while >>>> (modified_list != NULL && ...)'. >>> I added explicit null checks. >>> >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.02/ >>> >>> Thanks, >>> Tobias >>> >>>> ? John From tobias.hartmann at oracle.com Mon Jul 21 15:24:11 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 21 Jul 2014 17:24:11 +0200 Subject: Optimize signed integer comparison In-Reply-To: <53C99893.6060308@oracle.com> References: <53A95B03.4020309@oracle.com> <53C9605A.4040602@oracle.com> <7F0ECBF5-E5B0-43E4-BD60-D5AC6B88BC9B@oracle.com> <53C99893.6060308@oracle.com> Message-ID: <53CD309B.8000708@oracle.com> Vladimir, John, thanks for the help. As you suggested, I will try to optimize the BoolNode instead of the CmpINode. Best, Tobias On 18.07.2014 23:58, Vladimir Kozlov wrote: > On 7/18/14 1:18 PM, John Rose wrote: >> On Jul 18, 2014, at 10:58 AM, Vladimir Kozlov >> wrote: >> >>> What you described is exactly why 8043284 was filed. >>> >>> If we only looking for BoolNode 'eq'/'ne' checks then returning >>> TypeInt:CC_LT or CC_GT should give correct 'ne' result. Right? See >>> BoolTest::cc2logical(). >> >> It is risky to return an incorrect value for a node based on what >> other nodes we think might be testing it, since if some other node >> picks up the incorrect value, it might make a wrong decision with >> it. A couple of scenarios where "some other node" might pop up: 1. >> During parsing when we haven't hooked everything together yet >> (because we haven't parsed every bytecode yet). 2. If a third node >> gets replaced by the incorrectly-valued node (because of something >> like value numbering). > > We already do this trick for CmpP nodes: > > return TypeInt::CC_GT; // different pointers > > We never change BoolNode._test condition from 'eq' to 'lt', for > example. We only can change it to 'ne' and swap If node's projections. > Also we usually guard such cases by checking that we have only one > user (one BoolNode). > >> >> It would be better to transform the nodes that are testing for the NE >> condition. The NE condition (which we can't directly express in >> types) is produced by a Cmp node. The node which could use an NE >> condition is a Bool node (testing eq or ne). If we can make a >> transformation fold up both the Bool and the Cmp, then we can >> eliminate the unreached code, right? So the optimization is a little >> less local than we want. > > Yes, in the bug report I suggested to optimize BoolNode instead of > optimizing CmpI. It may be safer then setting type to CmpI, I agree. > >> >> Alternatively, and more powerfully, we could add bitfield tracking to >> the type system. Graal has this (based on type equations I sent >> them). If we were to do both range and bitfield tracking of the >> {-1,0,1} range of Cmp operations, we could express the type NE using >> the type assertion "(cmp&-2)!=0" which can be coded as "downMask!=0". > > It is out of scope of these changes. Should be filed separate RFE. > > Thanks, > Vladimir > >> >> ? John >> >>> Vladimir >>> >>> On 6/24/14 4:03 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> it would be nice if someone could have a look at this. While >>>> working at >>>> JDK-8043284 [1] I noticed the following problem (see attached example >>>> Unreachable.java): >>>> >>>> The method test(..) takes a char c, casts it to int and adds >>>> INT_MAX to >>>> it. If the result is equal to CHAR_MAX the method >>>> shouldNotReachHere(..) >>>> is executed. But no matter what value c has, >>>> shouldNotReachHere(...) is >>>> never executed because after the addition the result is either MAX_INT >>>> or overflows and has a value between INT_MIN and INT_MIN + CHAR_MAX >>>> - 1. >>>> >>>> The problem is that the C2 compiler does not detect this unreachable >>>> code. The C2 type system merges the two possible integer ranges >>>> [INT_MIN] and [INT_MIN + CHAR_MAX -1] into the general [INT_MIN, >>>> INT_MAX] range. The CmpINode is then unable to detect the >>>> inequality and >>>> returns the TypeInt::CC condition code which we cannot optimize. >>>> >>>> To fix this we can check in CmpINode::Value(..) if the result of the >>>> AddINode overflows and if so compare the two possible ranges with the >>>> target value (very similar to what Vladimir did for [2]). If both >>>> ranges >>>> are unequal we would return an unequal condition code and translate it >>>> to a boolean value in BoolNode::Value(..). This would lead to >>>> removal of >>>> all unreachable nodes in the graph. >>>> >>>> However, the problem with this solution is that we currently do not >>>> have >>>> an unequal type (we only have LT, GT, EQ, LE, GE) and adding one seems >>>> to be difficult because the CC integer range [-1, 1] is already used >>>> (see type.cpp line 297). I wonder why we don't have an own type for >>>> the >>>> condition codes but use TypeInt. >>>> >>>> Because my example is quite artificial, I did some testing with Octane >>>> and it looks like as if this happens quite often. I therefore think we >>>> should fix it. >>>> >>>> What do you think? >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8043284 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8042786 >> From mark.reinhold at oracle.com Mon Jul 21 15:43:46 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 21 Jul 2014 08:43:46 -0700 (PDT) Subject: JEP 197: Segmented Code Cache Message-ID: <20140721154347.0048630B47@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/197 - Mark From vladimir.kozlov at oracle.com Mon Jul 21 17:13:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jul 2014 10:13:49 -0700 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53CCE27B.4010102@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> <53C7A808.6040807@oracle.com> <53C84EEA.3000508@oracle.com> <53CCE27B.4010102@oracle.com> Message-ID: <53CD4A4D.2020504@oracle.com> > Thanks for the hint, the optimized build did not work. I'm now using > PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. This is > consistent with other verification methods like > Compile::verify_graph_edges(..). The logic which verifies modified nodes in phaseX.cpp is under #ifdef ASSERT. Yes, you are not collecting data in optimized VM by returning NULL from modified_nodes(). But it is very confusing. I would suggest to move all this code to debug build only. You can use NOT_DEBUG_RETURN instead of PRODUCT_RETURN and put definitions under #ifdef ASSERT in compile.cpp file. Thanks, Vladimir On 7/21/14 2:50 AM, Tobias Hartmann wrote: > Vladimir, John, thanks for the review. > > On 18.07.2014 01:32, John Rose wrote: >> On Jul 17, 2014, at 3:32 PM, Vladimir Kozlov >> wrote: >> >>> Initial prototype was written by me so part of changes are mine. >>> >>> On 7/17/14 3:40 AM, Tobias Hartmann wrote: >>>> Hi John, >>>> >>>> thanks a lot for the detailed review! Please see comments inline. >>>> >>>> On 16.07.2014 01:10, John Rose wrote: >>>>>>> Done. New webrev: >>>>>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ >>>>> Loading C->_modified_nodes with a stack address is bad news, even if >>>>> the code apparently cleans it up on exit. (I say "apparently" because >>>>> there are early exits from that block, and the cleanup is not RAII >>>>> style.) I strongly suggest heap allocation instead of stack >>>>> allocation; it's expensive but it's for debug code. >>> The list array allocation is done in compiler arena which is cleaned >>> after compilation finished by ResourceMark, only descriptor is on stack: >>> >>> + Unique_Node_List modified_nodes(comp_arena()); >>> >>> It is our normal style. We do it a lot, see Compile::Code_Gen(). >> Yes, we do it when adding phase control blocks to the Compile object, >> within the tree of calls rooted at the constructor. I see that the >> new code is arguably part of that pattern. I hope that is an >> exceptional use of this style? >> >> Note that C2Compiler::compile_method creates the Compile object and >> then queries it. When it queries it, the Compile object may contain >> dangling pointers into phase control blocks stored on the stack >> (during subroutine calls like Code_Gen) but now deallocated. >> >> It seems to me that we avoid touching those dangling pointers by >> simple will power and discipline. Such a style doesn't scale, since >> it's too easy to make mistakes as the code gets complicated. >> >>> Tobias, if you want to allocate Unique_Node_List object on arena: >>> >>> _modified_nodes = new (comp_arena()) Unique_Node_List(comp_arena()); >> That makes me feel much better. >> >> I would prefer for us to do it this way for the other stack-chunks >> also, but that would be outside the scope of this bug. > > I changed it to heap allocation. > >> Tobias, thanks for doing this work. >> >> ? John >> >>>> There are other places in the code where this is done, for example in >>>> Compile::Compile(..) the Unique_Node_List 'for_igvn' is created on the >>>> stack. Is this a special case? >>>> >>>> I'm not sure how to correctly allocate the object on the heap. Do I >>>> have >>>> to use new/delete or is this handled by some magic in "ResourceObject'? >>>> >>>> >>>>> You inserted '#ifdef ASSERT' after >>>>> 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you need it, >>>>> since all of the code (including the similar insertion a few lines up) >>>>> is '#ifndef PRODUCT'. See also suggestion above regarding >>>>> 'modified_nodes'. >>> #ifndef PRODUCT is also 'optimized' version of VM. n->dump() method >>> is not defined in optimized build. That is why asserts are needed. >>> >>> Tobias, please, build 'optimized' VM to verify your changes. > > Thanks for the hint, the optimized build did not work. I'm now using > PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. This is > consistent with other verification methods like > Compile::verify_graph_edges(..). > > New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.03/ > > Thanks, > Tobias > >>> Thanks, >>> Vladimir >>> >>>> True, I removed the #ifdef. >>>> >>>>> There are a few places where tests like 'while >>>>> (modified_list->size())' appears but there is no null check of >>>>> 'modified_list' itself. This could cause a crash if we ever get the >>>>> phasing wrong; consider an assert or explicit null check 'while >>>>> (modified_list != NULL && ...)'. >>>> I added explicit null checks. >>>> >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.02/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> ? John From filipp.zhinkin at oracle.com Mon Jul 21 17:27:13 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 21 Jul 2014 21:27:13 +0400 Subject: RFR(S): 8051344: JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on Message-ID: <53CD4D71.6000904@oracle.com> Hi all, please review fix for JDK-8051344. Original issue is about misplaced Parse::rtm_deopt call: it was done between method entry setup and check for bailouts during that setup. As a result, when rtm_deopt was called after bailout it either crashed while tryingto access start block (which is NULL after Compile::record_failure call) or failed on assert inside Compile::start. Fix is trivial: rtm_deopt call was placed after bailouts check. I've also added new test that cause OSR bailout due to non-empty interpreter stack. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8051344 Webrev: http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.00/ Testing: JPRT, manual on host w/ Haswell CPU From vladimir.kozlov at oracle.com Mon Jul 21 18:05:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jul 2014 11:05:52 -0700 Subject: [8u20] RFR (S): 8050050: [TESTBUG] compiler/stable tests fail because WB API is not implemented In-Reply-To: <53C66985.6050002@oracle.com> References: <53C66985.6050002@oracle.com> Message-ID: <53CD5680.50601@oracle.com> Looks fine to me but David asked about TEST.groups. Do you need to change it too? Thanks, Vladimir On 7/16/14 5:01 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050050/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050050 > > 8038756 wasn't backported to 8u20, so WB::get/setVMFlag aren't available > there. The fix for 8u20 is to rewrite configuration logic detection > using JMX. > > Testing: affected tests. > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Mon Jul 21 18:13:34 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jul 2014 11:13:34 -0700 Subject: RFR(S): 8051344: JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on In-Reply-To: <53CD4D71.6000904@oracle.com> References: <53CD4D71.6000904@oracle.com> Message-ID: <53CD584E.2090600@oracle.com> The original placement was done in assumption that rtm_deopt() may also produce failing() state. But looking through methods it uses it may not treu. So moving it after failing() check without adding an other check after it seems fine but please verify. Otherwise it look good. Thanks, Vladimir On 7/21/14 10:27 AM, Filipp Zhinkin wrote: > Hi all, > > please review fix for JDK-8051344. > > Original issue is about misplaced Parse::rtm_deopt call: > it was done between method entry setup and check for bailouts during > that setup. > > As a result, when rtm_deopt was called after bailout it either crashed > while > tryingto access start block (which is NULL after Compile::record_failure > call) > or failed on assert inside Compile::start. > > Fix is trivial: rtm_deopt call was placed after bailouts check. > > I've also added new test that cause OSR bailout due to non-empty > interpreter stack. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8051344 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.00/ > Testing: JPRT, manual on host w/ Haswell CPU > From morris.meyer at oracle.com Mon Jul 21 22:42:58 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Mon, 21 Jul 2014 18:42:58 -0400 Subject: RFR(S): 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp In-Reply-To: <28242CCB-42EE-4F39-9A4D-4B5AEBA540EC@oracle.com> References: <53593C18.6090208@oracle.com> <535954EF.4070108@oracle.com> <5361453E.6@oracle.com> <53616A84.30500@oracle.com> <48FFF0DF-FD22-4E42-906E-591CC35C9408@oracle.com> <5361715B.3040208@oracle.com> <28242CCB-42EE-4F39-9A4D-4B5AEBA540EC@oracle.com> Message-ID: <53CD9772.9040507@oracle.com> Christian and Vladimir, I have incorporated these comments into this latest webrev. It has been put through JPRT west. --mm WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.07 JBS - https://bug.openjdk.java.net/browse/JDK-8040920 On 4/30/14, 6:41 PM, Christian Thalinger wrote: > On Apr 30, 2014, at 11:55 AM, Vladimir Kozlov wrote: > >> On 4/30/14 2:35 PM, Christian Thalinger wrote: >>> On Apr 30, 2014, at 11:26 AM, Vladimir Kozlov wrote: >>> >>>> Morris, >>>> >>>> How you verified that you put ResourceMark in all needed places? >>>> That is what I don't like about GrowableArray. >>> He could put a ResourceMark in front of every GrowableArray. That would do it. >> Nested ResourceMark has bad effect on external GrowableArray: if it grows after inner ResourceMark that space will be released after inner scope ends. You will get memory stomps because of that. You need to be sure that external GrowableArray never grows inside inner ResourceMark scope. > Ugh. You?re right. Yeah, as I said we don?t need a GrowableArray here but the regular Array is only for metadata. > >> Vladimir >> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/30/14 11:47 AM, Morris Meyer wrote: >>>>> Vladimir and Christian, >>>>> >>>>> Thank you for the reviews. >>>>> >>>>> This version has your comments incorporated and has been put through >>>>> JPRT and passes Parfait cleanly. >>>>> >>>>> --mm >>>>> >>>>> JBS - https://bugs.openjdk.java.net/browse/JDK-8040920 >>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.05 >>>>> >>>>> >>>>> On 4/24/14, 2:16 PM, Vladimir Kozlov wrote: >>>>>> Using GrowableArray requires adding ResourceMark otherwise it will be >>>>>> memory leak. Method clear() does not free resources. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 4/24/14 9:30 AM, Morris Meyer wrote: >>>>>>> Folks, >>>>>>> >>>>>>> Could I get a review for this parfait issue? I've refactored >>>>>>> dependencies to use a GrowableArray to protect from inconsistencies in >>>>>>> passed in argument pairs (int nargs, DepArgument args[]) >>>>>>> >>>>>>> Thanks to Christian Thalinger and Vladimir Kozlov for looking at earlier >>>>>>> versions of this. >>>>>>> >>>>>>> --morris >>>>>>> >>>>>>> JBS - https://bugs.openjdk.java.net/browse/JDK-8040920 >>>>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.04 >>>>>>> From tobias.hartmann at oracle.com Tue Jul 22 08:15:34 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 22 Jul 2014 10:15:34 +0200 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53CD4A4D.2020504@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> <53C7A808.6040807@oracle.com> <53C84EEA.3000508@oracle.com> <53CCE27B.4010102@oracle.com> <53CD4A4D.2020504@oracle.com> Message-ID: <53CE1DA6.10301@oracle.com> Hi Vladimir, On 21.07.2014 19:13, Vladimir Kozlov wrote: > > Thanks for the hint, the optimized build did not work. I'm now using > > PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. This is > > consistent with other verification methods like > > Compile::verify_graph_edges(..). > > The logic which verifies modified nodes in phaseX.cpp is under #ifdef > ASSERT. Yes, you are not collecting data in optimized VM by returning > NULL from modified_nodes(). But it is very confusing. I would suggest > to move all this code to debug build only. You can use > NOT_DEBUG_RETURN instead of PRODUCT_RETURN and put definitions under > #ifdef ASSERT in compile.cpp file. Okay, that's true. I missed that there is a NOT_DEBUG_RETURN. Now using it. New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.04/ Thanks, Tobias > > Thanks, > Vladimir > > On 7/21/14 2:50 AM, Tobias Hartmann wrote: >> Vladimir, John, thanks for the review. >> >> On 18.07.2014 01:32, John Rose wrote: >>> On Jul 17, 2014, at 3:32 PM, Vladimir Kozlov >>> wrote: >>> >>>> Initial prototype was written by me so part of changes are mine. >>>> >>>> On 7/17/14 3:40 AM, Tobias Hartmann wrote: >>>>> Hi John, >>>>> >>>>> thanks a lot for the detailed review! Please see comments inline. >>>>> >>>>> On 16.07.2014 01:10, John Rose wrote: >>>>>>>> Done. New webrev: >>>>>>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ >>>>>> Loading C->_modified_nodes with a stack address is bad news, even if >>>>>> the code apparently cleans it up on exit. (I say "apparently" >>>>>> because >>>>>> there are early exits from that block, and the cleanup is not RAII >>>>>> style.) I strongly suggest heap allocation instead of stack >>>>>> allocation; it's expensive but it's for debug code. >>>> The list array allocation is done in compiler arena which is cleaned >>>> after compilation finished by ResourceMark, only descriptor is on >>>> stack: >>>> >>>> + Unique_Node_List modified_nodes(comp_arena()); >>>> >>>> It is our normal style. We do it a lot, see Compile::Code_Gen(). >>> Yes, we do it when adding phase control blocks to the Compile object, >>> within the tree of calls rooted at the constructor. I see that the >>> new code is arguably part of that pattern. I hope that is an >>> exceptional use of this style? >>> >>> Note that C2Compiler::compile_method creates the Compile object and >>> then queries it. When it queries it, the Compile object may contain >>> dangling pointers into phase control blocks stored on the stack >>> (during subroutine calls like Code_Gen) but now deallocated. >>> >>> It seems to me that we avoid touching those dangling pointers by >>> simple will power and discipline. Such a style doesn't scale, since >>> it's too easy to make mistakes as the code gets complicated. >>> >>>> Tobias, if you want to allocate Unique_Node_List object on arena: >>>> >>>> _modified_nodes = new (comp_arena()) Unique_Node_List(comp_arena()); >>> That makes me feel much better. >>> >>> I would prefer for us to do it this way for the other stack-chunks >>> also, but that would be outside the scope of this bug. >> >> I changed it to heap allocation. >> >>> Tobias, thanks for doing this work. >>> >>> ? John >>> >>>>> There are other places in the code where this is done, for example in >>>>> Compile::Compile(..) the Unique_Node_List 'for_igvn' is created on >>>>> the >>>>> stack. Is this a special case? >>>>> >>>>> I'm not sure how to correctly allocate the object on the heap. Do I >>>>> have >>>>> to use new/delete or is this handled by some magic in >>>>> "ResourceObject'? >>>>> >>>>> >>>>>> You inserted '#ifdef ASSERT' after >>>>>> 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you need it, >>>>>> since all of the code (including the similar insertion a few >>>>>> lines up) >>>>>> is '#ifndef PRODUCT'. See also suggestion above regarding >>>>>> 'modified_nodes'. >>>> #ifndef PRODUCT is also 'optimized' version of VM. n->dump() method >>>> is not defined in optimized build. That is why asserts are needed. >>>> >>>> Tobias, please, build 'optimized' VM to verify your changes. >> >> Thanks for the hint, the optimized build did not work. I'm now using >> PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. This is >> consistent with other verification methods like >> Compile::verify_graph_edges(..). >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.03/ >> >> Thanks, >> Tobias >> >>>> Thanks, >>>> Vladimir >>>> >>>>> True, I removed the #ifdef. >>>>> >>>>>> There are a few places where tests like 'while >>>>>> (modified_list->size())' appears but there is no null check of >>>>>> 'modified_list' itself. This could cause a crash if we ever get the >>>>>> phasing wrong; consider an assert or explicit null check 'while >>>>>> (modified_list != NULL && ...)'. >>>>> I added explicit null checks. >>>>> >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.02/ >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> ? John From tobias.hartmann at oracle.com Tue Jul 22 10:38:37 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 22 Jul 2014 12:38:37 +0200 Subject: [9] RFR(S): 8051550: Printing of 'cmpN_reg_branch_short' instruction shows wrong 'op2' register Message-ID: <53CE3F2D.3060907@oracle.com> Hi, please review the following patch that adds a missing '$' to the format string of the 'cmpN_reg_branch_short' instruction (sparc.ad). Bug: https://bugs.openjdk.java.net/browse/JDK-8051550 Webrev: http://cr.openjdk.java.net/~thartmann/8051550/webrev.00/ Thanks, Tobias From maaartinus at gmail.com Tue Jul 22 11:08:16 2014 From: maaartinus at gmail.com (Martin Grajcar) Date: Tue, 22 Jul 2014 13:08:16 +0200 Subject: A missing optimization for simple loops In-Reply-To: References: Message-ID: I wonder if this old posting of mine landed in spam or if you're all too busy? Regards, Martin. On Sat, Jun 14, 2014 at 9:43 PM, Martin Grajcar wrote: > A simple loop like in String.hashCode could be sped up by a factor of > nearly 4, if its operations would be rearranged slightly. The problem is > the latency of the iteration (mul+add, i.e., 4 cycles), which can't be > helped by unrolling because of data dependencies. But with the help of some > trivial math it's possible as I described in [1]. Does anybody think it's > worth the effort? > > [1]: http://stackoverflow.com/q/21745619/581205 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Tue Jul 22 15:22:45 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 22 Jul 2014 19:22:45 +0400 Subject: RFR(S): 8051344: JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on In-Reply-To: <53CD584E.2090600@oracle.com> References: <53CD4D71.6000904@oracle.com> <53CD584E.2090600@oracle.com> Message-ID: <53CE81C5.9060803@oracle.com> Hi Vladimir, thank you for looking at it. I've updated fix so now rtm_deopt called only if there were no bailouts and after that failing() state is checked. Updated webrev: http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.01/ Thanks, Filipp. On 07/21/2014 10:13 PM, Vladimir Kozlov wrote: > The original placement was done in assumption that rtm_deopt() may > also produce failing() state. But looking through methods it uses it > may not treu. So moving it after failing() check without adding an > other check after it seems fine but please verify. > > Otherwise it look good. > > Thanks, > Vladimir > > On 7/21/14 10:27 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review fix for JDK-8051344. >> >> Original issue is about misplaced Parse::rtm_deopt call: >> it was done between method entry setup and check for bailouts during >> that setup. >> >> As a result, when rtm_deopt was called after bailout it either crashed >> while >> tryingto access start block (which is NULL after Compile::record_failure >> call) >> or failed on assert inside Compile::start. >> >> Fix is trivial: rtm_deopt call was placed after bailouts check. >> >> I've also added new test that cause OSR bailout due to non-empty >> interpreter stack. >> >> JBS issue: https://bugs.openjdk.java.net/browse/JDK-8051344 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.00/ >> Testing: JPRT, manual on host w/ Haswell CPU >> From vladimir.kozlov at oracle.com Tue Jul 22 16:18:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jul 2014 09:18:49 -0700 Subject: RFR(S): 8051344: JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on In-Reply-To: <53CE81C5.9060803@oracle.com> References: <53CD4D71.6000904@oracle.com> <53CD584E.2090600@oracle.com> <53CE81C5.9060803@oracle.com> Message-ID: <53CE8EE9.5050906@oracle.com> Perfect. Thanks, Vladimir On 7/22/14 8:22 AM, Filipp Zhinkin wrote: > Hi Vladimir, > > thank you for looking at it. > > I've updated fix so now rtm_deopt called only if there were no bailouts > and after that failing() state is checked. > > Updated webrev: http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.01/ > > Thanks, > Filipp. > > On 07/21/2014 10:13 PM, Vladimir Kozlov wrote: >> The original placement was done in assumption that rtm_deopt() may also produce failing() state. But looking through >> methods it uses it may not treu. So moving it after failing() check without adding an other check after it seems fine >> but please verify. >> >> Otherwise it look good. >> >> Thanks, >> Vladimir >> >> On 7/21/14 10:27 AM, Filipp Zhinkin wrote: >>> Hi all, >>> >>> please review fix for JDK-8051344. >>> >>> Original issue is about misplaced Parse::rtm_deopt call: >>> it was done between method entry setup and check for bailouts during >>> that setup. >>> >>> As a result, when rtm_deopt was called after bailout it either crashed >>> while >>> tryingto access start block (which is NULL after Compile::record_failure >>> call) >>> or failed on assert inside Compile::start. >>> >>> Fix is trivial: rtm_deopt call was placed after bailouts check. >>> >>> I've also added new test that cause OSR bailout due to non-empty >>> interpreter stack. >>> >>> JBS issue: https://bugs.openjdk.java.net/browse/JDK-8051344 >>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.00/ >>> Testing: JPRT, manual on host w/ Haswell CPU >>> > From igor.veresov at oracle.com Tue Jul 22 17:13:19 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Jul 2014 10:13:19 -0700 Subject: [9] RFR(S): 8051550: Printing of 'cmpN_reg_branch_short' instruction shows wrong 'op2' register In-Reply-To: <53CE3F2D.3060907@oracle.com> References: <53CE3F2D.3060907@oracle.com> Message-ID: <6AA46C76-716D-4862-A9E0-F09E7BD4F0C4@oracle.com> Good. igor On Jul 22, 2014, at 3:38 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that adds a missing '$' to the format string of the 'cmpN_reg_branch_short' instruction (sparc.ad). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8051550 > Webrev: http://cr.openjdk.java.net/~thartmann/8051550/webrev.00/ > > Thanks, > Tobias From vladimir.kozlov at oracle.com Tue Jul 22 17:20:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jul 2014 10:20:31 -0700 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53CE1DA6.10301@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> <53C7A808.6040807@oracle.com> <53C84EEA.3000508@oracle.com> <53CCE27B.4010102@oracle.com> <53CD4A4D.2020504@oracle.com> <53CE1DA6.10301@oracle.com> Message-ID: <53CE9D5F.7000407@oracle.com> C->modified_nodes() is called only from debug code so you can simplify it by putting whole method inside DEBUG_ONLY() instead of different return: DEBUG_ONLY( Unique_Node_List* modified_nodes() const { return _modified_nodes; } ) Otherwise look good. Thanks, Vladimir On 7/22/14 1:15 AM, Tobias Hartmann wrote: > Hi Vladimir, > > On 21.07.2014 19:13, Vladimir Kozlov wrote: >> > Thanks for the hint, the optimized build did not work. I'm now using >> > PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. This is >> > consistent with other verification methods like >> > Compile::verify_graph_edges(..). >> >> The logic which verifies modified nodes in phaseX.cpp is under #ifdef >> ASSERT. Yes, you are not collecting data in optimized VM by returning >> NULL from modified_nodes(). But it is very confusing. I would suggest >> to move all this code to debug build only. You can use >> NOT_DEBUG_RETURN instead of PRODUCT_RETURN and put definitions under >> #ifdef ASSERT in compile.cpp file. > > Okay, that's true. I missed that there is a NOT_DEBUG_RETURN. Now using it. > > New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.04/ > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >> On 7/21/14 2:50 AM, Tobias Hartmann wrote: >>> Vladimir, John, thanks for the review. >>> >>> On 18.07.2014 01:32, John Rose wrote: >>>> On Jul 17, 2014, at 3:32 PM, Vladimir Kozlov >>>> wrote: >>>> >>>>> Initial prototype was written by me so part of changes are mine. >>>>> >>>>> On 7/17/14 3:40 AM, Tobias Hartmann wrote: >>>>>> Hi John, >>>>>> >>>>>> thanks a lot for the detailed review! Please see comments inline. >>>>>> >>>>>> On 16.07.2014 01:10, John Rose wrote: >>>>>>>>> Done. New webrev: >>>>>>>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ >>>>>>> Loading C->_modified_nodes with a stack address is bad news, even if >>>>>>> the code apparently cleans it up on exit. (I say "apparently" >>>>>>> because >>>>>>> there are early exits from that block, and the cleanup is not RAII >>>>>>> style.) I strongly suggest heap allocation instead of stack >>>>>>> allocation; it's expensive but it's for debug code. >>>>> The list array allocation is done in compiler arena which is cleaned >>>>> after compilation finished by ResourceMark, only descriptor is on >>>>> stack: >>>>> >>>>> + Unique_Node_List modified_nodes(comp_arena()); >>>>> >>>>> It is our normal style. We do it a lot, see Compile::Code_Gen(). >>>> Yes, we do it when adding phase control blocks to the Compile object, >>>> within the tree of calls rooted at the constructor. I see that the >>>> new code is arguably part of that pattern. I hope that is an >>>> exceptional use of this style? >>>> >>>> Note that C2Compiler::compile_method creates the Compile object and >>>> then queries it. When it queries it, the Compile object may contain >>>> dangling pointers into phase control blocks stored on the stack >>>> (during subroutine calls like Code_Gen) but now deallocated. >>>> >>>> It seems to me that we avoid touching those dangling pointers by >>>> simple will power and discipline. Such a style doesn't scale, since >>>> it's too easy to make mistakes as the code gets complicated. >>>> >>>>> Tobias, if you want to allocate Unique_Node_List object on arena: >>>>> >>>>> _modified_nodes = new (comp_arena()) Unique_Node_List(comp_arena()); >>>> That makes me feel much better. >>>> >>>> I would prefer for us to do it this way for the other stack-chunks >>>> also, but that would be outside the scope of this bug. >>> >>> I changed it to heap allocation. >>> >>>> Tobias, thanks for doing this work. >>>> >>>> ? John >>>> >>>>>> There are other places in the code where this is done, for example in >>>>>> Compile::Compile(..) the Unique_Node_List 'for_igvn' is created on >>>>>> the >>>>>> stack. Is this a special case? >>>>>> >>>>>> I'm not sure how to correctly allocate the object on the heap. Do I >>>>>> have >>>>>> to use new/delete or is this handled by some magic in >>>>>> "ResourceObject'? >>>>>> >>>>>> >>>>>>> You inserted '#ifdef ASSERT' after >>>>>>> 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you need it, >>>>>>> since all of the code (including the similar insertion a few >>>>>>> lines up) >>>>>>> is '#ifndef PRODUCT'. See also suggestion above regarding >>>>>>> 'modified_nodes'. >>>>> #ifndef PRODUCT is also 'optimized' version of VM. n->dump() method >>>>> is not defined in optimized build. That is why asserts are needed. >>>>> >>>>> Tobias, please, build 'optimized' VM to verify your changes. >>> >>> Thanks for the hint, the optimized build did not work. I'm now using >>> PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. This is >>> consistent with other verification methods like >>> Compile::verify_graph_edges(..). >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.03/ >>> >>> Thanks, >>> Tobias >>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> True, I removed the #ifdef. >>>>>> >>>>>>> There are a few places where tests like 'while >>>>>>> (modified_list->size())' appears but there is no null check of >>>>>>> 'modified_list' itself. This could cause a crash if we ever get the >>>>>>> phasing wrong; consider an assert or explicit null check 'while >>>>>>> (modified_list != NULL && ...)'. >>>>>> I added explicit null checks. >>>>>> >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> ? John > From vladimir.kozlov at oracle.com Tue Jul 22 17:21:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jul 2014 10:21:29 -0700 Subject: [9] RFR(S): 8051550: Printing of 'cmpN_reg_branch_short' instruction shows wrong 'op2' register In-Reply-To: <53CE3F2D.3060907@oracle.com> References: <53CE3F2D.3060907@oracle.com> Message-ID: <53CE9D99.70904@oracle.com> Good. vladimir On 7/22/14 3:38 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that adds a missing '$' to the format > string of the 'cmpN_reg_branch_short' instruction (sparc.ad). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8051550 > Webrev: http://cr.openjdk.java.net/~thartmann/8051550/webrev.00/ > > Thanks, > Tobias From vladimir.x.ivanov at oracle.com Tue Jul 22 19:17:48 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 22 Jul 2014 23:17:48 +0400 Subject: [8u20] RFR (S): 8050050: [TESTBUG] compiler/stable tests fail because WB API is not implemented In-Reply-To: <53CD5680.50601@oracle.com> References: <53C66985.6050002@oracle.com> <53CD5680.50601@oracle.com> Message-ID: <53CEB8DC.3080005@oracle.com> Thanks, Vladimir. Though the tests weren't part of needs_compact3 group before, I added them. Also, tuned the check a little to forbid tiered mode - the tests don't work there. http://cr.openjdk.java.net/~vlivanov/8050050/webrev.01 Best regards, Vladimir Ivanov On 7/21/14, 10:05 PM, Vladimir Kozlov wrote: > Looks fine to me but David asked about TEST.groups. Do you need to > change it too? > > Thanks, > Vladimir > > On 7/16/14 5:01 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8050050/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8050050 >> >> 8038756 wasn't backported to 8u20, so WB::get/setVMFlag aren't available >> there. The fix for 8u20 is to rewrite configuration logic detection >> using JMX. >> >> Testing: affected tests. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From vladimir.kozlov at oracle.com Tue Jul 22 19:25:19 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jul 2014 12:25:19 -0700 Subject: [8u20] RFR (S): 8050050: [TESTBUG] compiler/stable tests fail because WB API is not implemented In-Reply-To: <53CEB8DC.3080005@oracle.com> References: <53C66985.6050002@oracle.com> <53CD5680.50601@oracle.com> <53CEB8DC.3080005@oracle.com> Message-ID: <53CEBA9F.9040909@oracle.com> Looks good. Thanks, Vladimir On 7/22/14 12:17 PM, Vladimir Ivanov wrote: > Thanks, Vladimir. > > Though the tests weren't part of needs_compact3 group before, I added > them. Also, tuned the check a little to forbid tiered mode - the tests > don't work there. > > http://cr.openjdk.java.net/~vlivanov/8050050/webrev.01 > > Best regards, > Vladimir Ivanov > > On 7/21/14, 10:05 PM, Vladimir Kozlov wrote: >> Looks fine to me but David asked about TEST.groups. Do you need to >> change it too? >> >> Thanks, >> Vladimir >> >> On 7/16/14 5:01 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8050050/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8050050 >>> >>> 8038756 wasn't backported to 8u20, so WB::get/setVMFlag aren't available >>> there. The fix for 8u20 is to rewrite configuration logic detection >>> using JMX. >>> >>> Testing: affected tests. >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov From morris.meyer at oracle.com Tue Jul 22 19:46:38 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 22 Jul 2014 15:46:38 -0400 Subject: RFR(XS): JDK-8040921: Uninitialised memory in hotspot/src/share/vm/c1/c1_LinearScan.cpp In-Reply-To: <3723EF44-4D7B-4E12-AA83-45EF7DA8645B@oracle.com> References: <53555C8D.7090406@oracle.com> <80C84BCB-1E02-4668-9B5C-7D351BB922E9@oracle.com> <53613588.8000306@oracle.com> <305D7E38-B9F1-4A89-8C92-805DFC62DA4B@oracle.com> <536293B4.8040601@oracle.com> <3723EF44-4D7B-4E12-AA83-45EF7DA8645B@oracle.com> Message-ID: <53CEBF9E.7080207@oracle.com> Folks, Could I get a review of this parfait issue. It has been tested through JPRT. Thanks! --morris JBS - http://bugs.openjdk.java.net/browse/JDK-8040921 WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.07 On 5/1/14, 9:51 PM, Christian Thalinger wrote: > > On May 1, 2014, at 8:34 AM, Morris Meyer > wrote: > >> The parfait error is with the ASSERT define blocking out >> initialization of a the fpu structures when that code path is enabled. >> >> I've removed the ifdef such that both paths initialized their cpu and >> fpu variables, and the assertion is always checked. > > But the code path using the uninitialized variables is also under: > > 1648 if (has_fpu_registers()) { > > Am I missing something? Anyway, during an earlier internal review I > said we should keep the assert; I take that back. We should move the > variables and initialization down to the use and remove the assert. > It doesn?t have much value anyway. > >> >> --mm >> >> On 4/30/14, 3:36 PM, Christian Thalinger wrote: >>> I don?t understand the Parfait error here. Could you explain? >>> >>> On Apr 30, 2014, at 7:40 AM, Morris Meyer >> > wrote: >>> >>>> Folks, >>>> >>>> Could I get a review for this Parfait uninitialized variable issue? >>>> This has been tested with JPRT and a clear pass with Parfait. >>>> >>>> Thanks, >>>> >>>> --mm >>>> >>>> BUG - https://bugs.openjdk.java.net/browse/JDK-8040921 >>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.05 >>>> >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Jul 22 20:04:35 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 Jul 2014 00:04:35 +0400 Subject: RFR (S) : 8051484 : Test compiler/6932496/Test6932496.java failed to compile after JDK-8011044: 1.5 is no longer supported Message-ID: <53CEC3D3.9070202@oracle.com> http://cr.openjdk.java.net/~iignatyev/8051484/webrev.00/ 139 lines changed: 126 ins; 2 del; 11 mod Hi all, Please review patch: Problem: JDK-8011044 removed support of javac 1.5 sources and target platform, but compiler/6932496/Test6932496.java uses it to generate jtr, ret instructions Fix: the test was rewritten by using ASM jbs: https://bugs.openjdk.java.net/browse/JDK-8051484 testing: - locally - I'm not able to reproduce 6932496 on 1.7.0-b80 neither by the original version nor the new one, since but I reproduced it on jdk9 w/o the fix for 8051484, src/share/vm/c1/c1_LIR.cpp: > LIR_Opr LIR_OprFact::value_type(ValueType* type) { ... > case addressTag: // return LIR_OprFact::addressConst(type->as_AddressConstant()->value()); > case intTag : return LIR_OprFact::intConst(type->as_IntConstant()->value()); > LIR_Opr LIR_OprFact::dummy_value_type(ValueType* type) { ... > case addressTag://return LIR_OprFact::addressConst(0); > case intTag: return LIR_OprFact::intConst(0); -- Igor From vladimir.kozlov at oracle.com Tue Jul 22 20:47:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jul 2014 13:47:51 -0700 Subject: RFR (S) : 8051484 : Test compiler/6932496/Test6932496.java failed to compile after JDK-8011044: 1.5 is no longer supported In-Reply-To: <53CEC3D3.9070202@oracle.com> References: <53CEC3D3.9070202@oracle.com> Message-ID: <53CECDF7.3040205@oracle.com> On 7/22/14 1:04 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8051484/webrev.00/ > 139 lines changed: 126 ins; 2 del; 11 mod > > Hi all, > > Please review patch: > > Problem: > JDK-8011044 removed support of javac 1.5 sources and target platform, > but compiler/6932496/Test6932496.java uses it to generate jtr, ret > instructions > > Fix: > the test was rewritten by using ASM Looks good. I think it would be better if you put whole Test class in one comment before generateTestClass() in addition to spreading comments in the code. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8051484 > testing: > - locally > - I'm not able to reproduce 6932496 on 1.7.0-b80 neither by the > original version nor the new one, since but I reproduced it on jdk9 w/o > the fix for 8051484, src/share/vm/c1/c1_LIR.cpp: You mean without part of 6932496 fix. Right? Thank you for reproducing the failure with new test version. Thanks, Vladimir > >> LIR_Opr LIR_OprFact::value_type(ValueType* type) { > ... >> case addressTag: // return >> LIR_OprFact::addressConst(type->as_AddressConstant()->value()); >> case intTag : return >> LIR_OprFact::intConst(type->as_IntConstant()->value()); > >> LIR_Opr LIR_OprFact::dummy_value_type(ValueType* type) { > ... >> case addressTag://return LIR_OprFact::addressConst(0); >> case intTag: return LIR_OprFact::intConst(0); > > From igor.ignatyev at oracle.com Tue Jul 22 21:02:20 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 Jul 2014 01:02:20 +0400 Subject: RFR (S) : 8051484 : Test compiler/6932496/Test6932496.java failed to compile after JDK-8011044: 1.5 is no longer supported In-Reply-To: <53CECDF7.3040205@oracle.com> References: <53CEC3D3.9070202@oracle.com> <53CECDF7.3040205@oracle.com> Message-ID: <53CED15C.8070909@oracle.com> updated webrev: http://cr.openjdk.java.net/~iignatyev/8051484/webrev.01/ On 07/23/2014 12:47 AM, Vladimir Kozlov wrote: > On 7/22/14 1:04 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8051484/webrev.00/ >> 139 lines changed: 126 ins; 2 del; 11 mod >> >> Hi all, >> >> Please review patch: >> >> Problem: >> JDK-8011044 removed support of javac 1.5 sources and target platform, >> but compiler/6932496/Test6932496.java uses it to generate jtr, ret >> instructions >> >> Fix: >> the test was rewritten by using ASM > > Looks good. I think it would be better if you put whole Test class in > one comment before generateTestClass() in addition to spreading comments > in the code. sure, added. > >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8051484 >> testing: >> - locally >> - I'm not able to reproduce 6932496 on 1.7.0-b80 neither by the >> original version nor the new one, since but I reproduced it on jdk9 w/o >> the fix for 8051484, src/share/vm/c1/c1_LIR.cpp: > > You mean without part of 6932496 fix. Right? yeap, I mean 6932496. > Thank you for reproducing the failure with new test version. > > Thanks, > Vladimir > >> >>> LIR_Opr LIR_OprFact::value_type(ValueType* type) { >> ... >>> case addressTag: // return >>> LIR_OprFact::addressConst(type->as_AddressConstant()->value()); >>> case intTag : return >>> LIR_OprFact::intConst(type->as_IntConstant()->value()); >> >>> LIR_Opr LIR_OprFact::dummy_value_type(ValueType* type) { >> ... >>> case addressTag://return LIR_OprFact::addressConst(0); >>> case intTag: return LIR_OprFact::intConst(0); >> >> From vladimir.kozlov at oracle.com Tue Jul 22 21:06:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jul 2014 14:06:36 -0700 Subject: RFR (S) : 8051484 : Test compiler/6932496/Test6932496.java failed to compile after JDK-8011044: 1.5 is no longer supported In-Reply-To: <53CED15C.8070909@oracle.com> References: <53CEC3D3.9070202@oracle.com> <53CECDF7.3040205@oracle.com> <53CED15C.8070909@oracle.com> Message-ID: <53CED25C.9040400@oracle.com> Good. Thanks, Vladimir On 7/22/14 2:02 PM, Igor Ignatyev wrote: > updated webrev: http://cr.openjdk.java.net/~iignatyev/8051484/webrev.01/ > > On 07/23/2014 12:47 AM, Vladimir Kozlov wrote: >> On 7/22/14 1:04 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8051484/webrev.00/ >>> 139 lines changed: 126 ins; 2 del; 11 mod >>> >>> Hi all, >>> >>> Please review patch: >>> >>> Problem: >>> JDK-8011044 removed support of javac 1.5 sources and target platform, >>> but compiler/6932496/Test6932496.java uses it to generate jtr, ret >>> instructions >>> >>> Fix: >>> the test was rewritten by using ASM >> >> Looks good. I think it would be better if you put whole Test class in >> one comment before generateTestClass() in addition to spreading comments >> in the code. > sure, added. >> >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8051484 >>> testing: >>> - locally >>> - I'm not able to reproduce 6932496 on 1.7.0-b80 neither by the >>> original version nor the new one, since but I reproduced it on jdk9 w/o >>> the fix for 8051484, src/share/vm/c1/c1_LIR.cpp: >> >> You mean without part of 6932496 fix. Right? > yeap, I mean 6932496. >> Thank you for reproducing the failure with new test version. >> >> Thanks, >> Vladimir >> >>> >>>> LIR_Opr LIR_OprFact::value_type(ValueType* type) { >>> ... >>>> case addressTag: // return >>>> LIR_OprFact::addressConst(type->as_AddressConstant()->value()); >>>> case intTag : return >>>> LIR_OprFact::intConst(type->as_IntConstant()->value()); >>> >>>> LIR_Opr LIR_OprFact::dummy_value_type(ValueType* type) { >>> ... >>>> case addressTag://return LIR_OprFact::addressConst(0); >>>> case intTag: return LIR_OprFact::intConst(0); >>> >>> From aleksey.shipilev at oracle.com Tue Jul 22 21:38:03 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 23 Jul 2014 01:38:03 +0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages Message-ID: <53CED9BB.4000007@oracle.com> (the patch itself is XS, but the explanation is M) Hi, This is a follow up for the issue discovered earlier. In a tight performance-sensitive loops StoreLoad barrier in the form of "lock addl (%esp+0), 0" interferes with stack users: https://bugs.openjdk.java.net/browse/JDK-8050147 I used the experimental patch: https://bugs.openjdk.java.net/browse/JDK-8050149 ...to juggle different StoreLoad barrier strategies: 1) mfence: we know it is slow on almost all platforms, keep this as control 2) lock addl (%esp), 0: current default 3) lock addl (%esp-8), 0: unties the data dependency against (%esp) users 4) lock addl (%esp-CacheLine-8), 0: unties the data dependency, and also steps back a cache line to untie possible memory contention of (%esp) users and our locked instructions 5) lock addl (%esp-RedZone-8), 0: Not sure how it interacts with our calling convention, but System V ABI tells us there is a "red zone" 128 bytes down the stack pointer which is always preserved by interrupt handlers, etc. It seems we can use red zone for scratch data. Dave Dice suggests that idempotent operations in red zone are benign anyway. But in case we have a problem with the red zone, we can fallback to this mode. Targeted benchmarks triage that the issue only manifests in a tight loops where the users of (%esp) are very close to the StoreLoad barrier. By carefully backing off between the StoreLoad barrier and the users of (%esp), we were able to quantify where different StoreLoad strategies benefit. We use the same targeted benchmark (two prebuilt JARs are also there): http://cr.openjdk.java.net/~shade/8050147/micros/VolatileBarrierBench.java Running this on different machine architectures yields more or less consistent result among the strategies. The links below point to charted data in PNG format, but they are also available in SVG, as well in raw data form, in the same folder. The graphs show how the throughput of volatile write + backoff changes with different backoffs. Lines are different StoreLoad strategies. Tiles correspond to the number of measurement threads doing the loop. * 1x1x2 Intel Atom Z530 seems completely oblivious of memory barrier issue. This seems to be due the generated code in 32-bit mode which completely pads away the StoreLoad barrier costs -- notice tens of nanoseconds per write: http://cr.openjdk.java.net/~shade/8050147/micros/Intel-Atom-client.data.png http://cr.openjdk.java.net/~shade/8050147/micros/Intel-Atom-server.data.png * 2x16 AMD Opteron (Abu Dhabi) benefits greatly with offsetting %esp. We can also quantify the area where the interference occurs. It spans the area in backoff [0..10], which is loosely [0..30] instructions between the stack user and StoreLoad barrier: http://cr.openjdk.java.net/~shade/8050147/micros/AMD-Abudhabi.data.png * 2x16 AMD Opteron (Interlagos) tests paint the same picture (it is remarkable that mfence is consistently behind): http://cr.openjdk.java.net/~shade/8050147/micros/AMD-Interlagos.data.png * 1x4x1 Intel Core (Haswell-DT) benefits from offsetting %esp as well. There is an interesting hump on lower backoffs with addl (%esp-8), which seems to be a second-order microarchitectural effect. Unfortunately, we don't have large Haswells available at the moment to dive into this: http://cr.openjdk.java.net/~shade/8050147/micros/Intel-Haswell.data.png * 1x2x2 Intel Core (Sandy Bridge), anecdotal evidence from my laptop also shows offsetting %esp helps: https://bugs.openjdk.java.net/browse/JDK-8050147?focusedCommentId=13521925#comment-13521925 Our large reference workloads running on reference performance servers show no statistically significant improvements/regressions with either mode. I think this is because a) in large workloads the padding between stack users and StoreLoads is beefy; and b) there is not so many StoreLoads in performance benchmarks (survivorship bias). Selected ForkJoin-rich microbenchmarks show the good improvement for all (%esp-offset) modes. Having this data, I propose we switch either to "lock addl (%esp-8), 0", optimistically thinking there are no second-order effects with sharing the cache lines: http://cr.openjdk.java.net/~shade/8050147/webrev.01/ ...or "lock addl (%esp-CL-8), 0), pessimistically padding away from stack users: http://cr.openjdk.java.net/~shade/8050147/webrev.02/ Both patches pass full JPRT cycle. Thoughts? Thanks, -Aleksey. From dave.dice at oracle.com Tue Jul 22 22:08:29 2014 From: dave.dice at oracle.com (Dave Dice) Date: Tue, 22 Jul 2014 18:08:29 -0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53CED9BB.4000007@oracle.com> References: <53CED9BB.4000007@oracle.com> Message-ID: <0EAD657B-1234-456C-8A03-6FBDBB753593@oracle.com> On 2014-7-22, at 5:38 PM, Aleksey Shipilev wrote: > (the patch itself is XS, but the explanation is M) > > Hi, > > This is a follow up for the issue discovered earlier. In a tight > performance-sensitive loops StoreLoad barrier in the form of "lock addl > (%esp+0), 0" interferes with stack users: > https://bugs.openjdk.java.net/browse/JDK-8050147 > > I used the experimental patch: > https://bugs.openjdk.java.net/browse/JDK-8050149 > > ...to juggle different StoreLoad barrier strategies: > > 1) mfence: > we know it is slow on almost all platforms, keep this as control Admittedly old data, but related : https://blogs.oracle.com/dave/entry/instruction_selection_for_volatile_fences Over time, mfence has been freighted with additional semantics. For 64-bit mode it?d be useful to try the ?xchg rThread, rThread->Self? idiom, where the Self field points to the enclosing thread structure in a self-referential fashion. I?ve seen good results from that form. And of course if we?re willing to kill a register ? a register that might be on the verge of becoming dead anyway ? then replacing [ST; fence-idiom] with XCHG might be interesting. Regards Dave > > 2) lock addl (%esp), 0: > current default > > 3) lock addl (%esp-8), 0: > unties the data dependency against (%esp) users > > 4) lock addl (%esp-CacheLine-8), 0: > unties the data dependency, and also steps back a cache line > to untie possible memory contention of (%esp) users and our > locked instructions > > 5) lock addl (%esp-RedZone-8), 0: > Not sure how it interacts with our calling convention, but > System V ABI tells us there is a "red zone" 128 bytes down the > stack pointer which is always preserved by interrupt handlers, > etc. It seems we can use red zone for scratch data. Dave Dice > suggests that idempotent operations in red zone are benign > anyway. But in case we have a problem with the red zone, we can > fallback to this mode. > > Targeted benchmarks triage that the issue only manifests in a tight > loops where the users of (%esp) are very close to the StoreLoad barrier. > By carefully backing off between the StoreLoad barrier and the users of > (%esp), we were able to quantify where different StoreLoad strategies > benefit. We use the same targeted benchmark (two prebuilt JARs are also > there): > http://cr.openjdk.java.net/~shade/8050147/micros/VolatileBarrierBench.java > > Running this on different machine architectures yields more or less > consistent result among the strategies. The links below point to charted > data in PNG format, but they are also available in SVG, as well in raw > data form, in the same folder. The graphs show how the throughput of > volatile write + backoff changes with different backoffs. Lines are > different StoreLoad strategies. Tiles correspond to the number of > measurement threads doing the loop. > > * 1x1x2 Intel Atom Z530 seems completely oblivious of memory barrier > issue. This seems to be due the generated code in 32-bit mode which > completely pads away the StoreLoad barrier costs -- notice tens of > nanoseconds per write: > > http://cr.openjdk.java.net/~shade/8050147/micros/Intel-Atom-client.data.png > > http://cr.openjdk.java.net/~shade/8050147/micros/Intel-Atom-server.data.png > > * 2x16 AMD Opteron (Abu Dhabi) benefits greatly with offsetting %esp. > We can also quantify the area where the interference occurs. It spans > the area in backoff [0..10], which is loosely [0..30] instructions > between the stack user and StoreLoad barrier: > http://cr.openjdk.java.net/~shade/8050147/micros/AMD-Abudhabi.data.png > > * 2x16 AMD Opteron (Interlagos) tests paint the same picture (it is > remarkable that mfence is consistently behind): > http://cr.openjdk.java.net/~shade/8050147/micros/AMD-Interlagos.data.png > > * 1x4x1 Intel Core (Haswell-DT) benefits from offsetting %esp as well. > There is an interesting hump on lower backoffs with addl (%esp-8), which > seems to be a second-order microarchitectural effect. Unfortunately, we > don't have large Haswells available at the moment to dive into this: > http://cr.openjdk.java.net/~shade/8050147/micros/Intel-Haswell.data.png > > * 1x2x2 Intel Core (Sandy Bridge), anecdotal evidence from my laptop > also shows offsetting %esp helps: > > https://bugs.openjdk.java.net/browse/JDK-8050147?focusedCommentId=13521925#comment-13521925 > > Our large reference workloads running on reference performance servers > show no statistically significant improvements/regressions with either > mode. I think this is because a) in large workloads the padding between > stack users and StoreLoads is beefy; and b) there is not so many > StoreLoads in performance benchmarks (survivorship bias). > > Selected ForkJoin-rich microbenchmarks show the good improvement for all > (%esp-offset) modes. > > Having this data, I propose we switch either to "lock addl (%esp-8), 0", > optimistically thinking there are no second-order effects with sharing > the cache lines: > http://cr.openjdk.java.net/~shade/8050147/webrev.01/ > > ...or "lock addl (%esp-CL-8), 0), pessimistically padding away from > stack users: > http://cr.openjdk.java.net/~shade/8050147/webrev.02/ > > Both patches pass full JPRT cycle. > > Thoughts? > > Thanks, > -Aleksey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Jul 22 22:40:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jul 2014 15:40:37 -0700 Subject: RFR(XS): JDK-8040921: Uninitialised memory in hotspot/src/share/vm/c1/c1_LinearScan.cpp In-Reply-To: <53CEBF9E.7080207@oracle.com> References: <53555C8D.7090406@oracle.com> <80C84BCB-1E02-4668-9B5C-7D351BB922E9@oracle.com> <53613588.8000306@oracle.com> <305D7E38-B9F1-4A89-8C92-805DFC62DA4B@oracle.com> <536293B4.8040601@oracle.com> <3723EF44-4D7B-4E12-AA83-45EF7DA8645B@oracle.com> <53CEBF9E.7080207@oracle.com> Message-ID: <53CEE865.6040504@oracle.com> You did not do for fpu registers what Christian said: "We should move the variables and initialization down to the use" Vladimir On 7/22/14 12:46 PM, Morris Meyer wrote: > Folks, > > Could I get a review of this parfait issue. It has been tested through > JPRT. > > Thanks! > > --morris > > JBS - http://bugs.openjdk.java.net/browse/JDK-8040921 > WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.07 > > On 5/1/14, 9:51 PM, Christian Thalinger wrote: >> >> On May 1, 2014, at 8:34 AM, Morris Meyer > > wrote: >> >>> The parfait error is with the ASSERT define blocking out >>> initialization of a the fpu structures when that code path is enabled. >>> >>> I've removed the ifdef such that both paths initialized their cpu and >>> fpu variables, and the assertion is always checked. >> >> But the code path using the uninitialized variables is also under: >> >> 1648 if (has_fpu_registers()) { >> >> Am I missing something? Anyway, during an earlier internal review I >> said we should keep the assert; I take that back. We should move the >> variables and initialization down to the use and remove the assert. >> It doesn?t have much value anyway. >> >>> >>> --mm >>> >>> On 4/30/14, 3:36 PM, Christian Thalinger wrote: >>>> I don?t understand the Parfait error here. Could you explain? >>>> >>>> On Apr 30, 2014, at 7:40 AM, Morris Meyer >>> > wrote: >>>> >>>>> Folks, >>>>> >>>>> Could I get a review for this Parfait uninitialized variable issue? >>>>> This has been tested with JPRT and a clear pass with Parfait. >>>>> >>>>> Thanks, >>>>> >>>>> --mm >>>>> >>>>> BUG - https://bugs.openjdk.java.net/browse/JDK-8040921 >>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.05 >>>>> >>>>> >>>>> >>> >> > From vladimir.kozlov at oracle.com Tue Jul 22 23:05:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jul 2014 16:05:33 -0700 Subject: RFR(S): 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp In-Reply-To: <53CD9772.9040507@oracle.com> References: <53593C18.6090208@oracle.com> <535954EF.4070108@oracle.com> <5361453E.6@oracle.com> <53616A84.30500@oracle.com> <48FFF0DF-FD22-4E42-906E-591CC35C9408@oracle.com> <5361715B.3040208@oracle.com> <28242CCB-42EE-4F39-9A4D-4B5AEBA540EC@oracle.com> <53CD9772.9040507@oracle.com> Message-ID: <53CEEE3D.4070501@oracle.com> how you determined where you should place ResourceMark? You missed one in log_dependency(). write_dependency_to() methods are used only by Dependencies so they could be private. Then we would guarantee that they are called in known places which may have ResourceMark already. thanks, Vladimir On 7/21/14 3:42 PM, Morris Meyer wrote: > Christian and Vladimir, > > I have incorporated these comments into this latest webrev. It has been > put through JPRT west. > > --mm > > WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.07 > JBS - https://bug.openjdk.java.net/browse/JDK-8040920 > > > On 4/30/14, 6:41 PM, Christian Thalinger wrote: >> On Apr 30, 2014, at 11:55 AM, Vladimir Kozlov >> wrote: >> >>> On 4/30/14 2:35 PM, Christian Thalinger wrote: >>>> On Apr 30, 2014, at 11:26 AM, Vladimir Kozlov >>>> wrote: >>>> >>>>> Morris, >>>>> >>>>> How you verified that you put ResourceMark in all needed places? >>>>> That is what I don't like about GrowableArray. >>>> He could put a ResourceMark in front of every GrowableArray. That >>>> would do it. >>> Nested ResourceMark has bad effect on external GrowableArray: if it >>> grows after inner ResourceMark that space will be released after >>> inner scope ends. You will get memory stomps because of that. You >>> need to be sure that external GrowableArray never grows inside inner >>> ResourceMark scope. >> Ugh. You?re right. Yeah, as I said we don?t need a GrowableArray >> here but the regular Array is only for metadata. >> >>> Vladimir >>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 4/30/14 11:47 AM, Morris Meyer wrote: >>>>>> Vladimir and Christian, >>>>>> >>>>>> Thank you for the reviews. >>>>>> >>>>>> This version has your comments incorporated and has been put through >>>>>> JPRT and passes Parfait cleanly. >>>>>> >>>>>> --mm >>>>>> >>>>>> JBS - https://bugs.openjdk.java.net/browse/JDK-8040920 >>>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.05 >>>>>> >>>>>> >>>>>> On 4/24/14, 2:16 PM, Vladimir Kozlov wrote: >>>>>>> Using GrowableArray requires adding ResourceMark otherwise it >>>>>>> will be >>>>>>> memory leak. Method clear() does not free resources. >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> On 4/24/14 9:30 AM, Morris Meyer wrote: >>>>>>>> Folks, >>>>>>>> >>>>>>>> Could I get a review for this parfait issue? I've refactored >>>>>>>> dependencies to use a GrowableArray to protect from >>>>>>>> inconsistencies in >>>>>>>> passed in argument pairs (int nargs, DepArgument args[]) >>>>>>>> >>>>>>>> Thanks to Christian Thalinger and Vladimir Kozlov for looking at >>>>>>>> earlier >>>>>>>> versions of this. >>>>>>>> >>>>>>>> --morris >>>>>>>> >>>>>>>> JBS - https://bugs.openjdk.java.net/browse/JDK-8040920 >>>>>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.04 >>>>>>>> > From tobias.hartmann at oracle.com Wed Jul 23 05:49:52 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Jul 2014 07:49:52 +0200 Subject: [9] RFR(S): 8051550: Printing of 'cmpN_reg_branch_short' instruction shows wrong 'op2' register In-Reply-To: <53CE9D99.70904@oracle.com> References: <53CE3F2D.3060907@oracle.com> <53CE9D99.70904@oracle.com> Message-ID: <53CF4D00.7070100@oracle.com> Vladimir, Igor, thanks for the review. Best, Tobias On 22.07.2014 19:21, Vladimir Kozlov wrote: > Good. > > vladimir > > On 7/22/14 3:38 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch that adds a missing '$' to the format >> string of the 'cmpN_reg_branch_short' instruction (sparc.ad). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8051550 >> Webrev: http://cr.openjdk.java.net/~thartmann/8051550/webrev.00/ >> >> Thanks, >> Tobias From zoltan.majo at oracle.com Wed Jul 23 07:37:29 2014 From: zoltan.majo at oracle.com (=?ISO-8859-1?Q?Zolt=E1n_Maj=F3?=) Date: Wed, 23 Jul 2014 09:37:29 +0200 Subject: [9] RFR(S): 8050860: Cleanup TypeTuple and TypeFunc Message-ID: <53CF6639.4020708@oracle.com> Hi all, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8050860 Problem: TypeFunc::_domain, TypeFunc::_range, TypeTuple::_cnt and TypeTuple::_fields are public, but could be declared private. Solution: Declared fields private, changed direct accesses to fields (from other classes) to use accessor methods instead. Webrev: http://cr.openjdk.java.net/~thartmann/8050860/webrev.00/ Testing: run all JPRT tests, all passed; built all_optimized and all_debug successfully. Thank you and best regards, Zoltan Majo From filipp.zhinkin at oracle.com Wed Jul 23 08:58:56 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 23 Jul 2014 12:58:56 +0400 Subject: RFR(S): 8051344: JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on In-Reply-To: <53CE8EE9.5050906@oracle.com> References: <53CD4D71.6000904@oracle.com> <53CD584E.2090600@oracle.com> <53CE81C5.9060803@oracle.com> <53CE8EE9.5050906@oracle.com> Message-ID: <53CF7950.4090600@oracle.com> Vladimir, thank you for the review. FIlipp. On 07/22/2014 08:18 PM, Vladimir Kozlov wrote: > Perfect. > > Thanks, > Vladimir > > On 7/22/14 8:22 AM, Filipp Zhinkin wrote: >> Hi Vladimir, >> >> thank you for looking at it. >> >> I've updated fix so now rtm_deopt called only if there were no bailouts >> and after that failing() state is checked. >> >> Updated webrev: http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.01/ >> >> Thanks, >> Filipp. >> >> On 07/21/2014 10:13 PM, Vladimir Kozlov wrote: >>> The original placement was done in assumption that rtm_deopt() may >>> also produce failing() state. But looking through >>> methods it uses it may not treu. So moving it after failing() check >>> without adding an other check after it seems fine >>> but please verify. >>> >>> Otherwise it look good. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/21/14 10:27 AM, Filipp Zhinkin wrote: >>>> Hi all, >>>> >>>> please review fix for JDK-8051344. >>>> >>>> Original issue is about misplaced Parse::rtm_deopt call: >>>> it was done between method entry setup and check for bailouts during >>>> that setup. >>>> >>>> As a result, when rtm_deopt was called after bailout it either crashed >>>> while >>>> tryingto access start block (which is NULL after >>>> Compile::record_failure >>>> call) >>>> or failed on assert inside Compile::start. >>>> >>>> Fix is trivial: rtm_deopt call was placed after bailouts check. >>>> >>>> I've also added new test that cause OSR bailout due to non-empty >>>> interpreter stack. >>>> >>>> JBS issue: https://bugs.openjdk.java.net/browse/JDK-8051344 >>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.00/ >>>> Testing: JPRT, manual on host w/ Haswell CPU >>>> >> From vladimir.x.ivanov at oracle.com Wed Jul 23 09:17:11 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 23 Jul 2014 13:17:11 +0400 Subject: [8u20] RFR (S): 8050050: [TESTBUG] compiler/stable tests fail because WB API is not implemented In-Reply-To: <53CEBA9F.9040909@oracle.com> References: <53C66985.6050002@oracle.com> <53CD5680.50601@oracle.com> <53CEB8DC.3080005@oracle.com> <53CEBA9F.9040909@oracle.com> Message-ID: <53CF7D97.2080305@oracle.com> Vladimir, thanks! Best regards, Vladimir Ivanov On 7/22/14, 11:25 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 7/22/14 12:17 PM, Vladimir Ivanov wrote: >> Thanks, Vladimir. >> >> Though the tests weren't part of needs_compact3 group before, I added >> them. Also, tuned the check a little to forbid tiered mode - the tests >> don't work there. >> >> http://cr.openjdk.java.net/~vlivanov/8050050/webrev.01 >> >> Best regards, >> Vladimir Ivanov >> >> On 7/21/14, 10:05 PM, Vladimir Kozlov wrote: >>> Looks fine to me but David asked about TEST.groups. Do you need to >>> change it too? >>> >>> Thanks, >>> Vladimir >>> >>> On 7/16/14 5:01 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8050050/webrev.00 >>>> https://bugs.openjdk.java.net/browse/JDK-8050050 >>>> >>>> 8038756 wasn't backported to 8u20, so WB::get/setVMFlag aren't >>>> available >>>> there. The fix for 8u20 is to rewrite configuration logic detection >>>> using JMX. >>>> >>>> Testing: affected tests. >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov From tobias.hartmann at oracle.com Wed Jul 23 11:12:49 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Jul 2014 13:12:49 +0200 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp Message-ID: <53CF98B1.9070508@oracle.com> Hi, please review the following patch for JDK- 8049043 (Parfait warning). Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ Problem: Parfait issues 6 warnings " Load variable through a pointer of an incompatible type" because of the __HI(x) and __LO(x) macros used in copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) to cast between double* and int*. Solution: A union 'DoubleIntConv' is used to access the high and low 32 bits of a double. The '# pragma warning( disable: 4748 )' in sharedRuntimeTrans.cpp is necessary because otherwise the VS compiler fails with the following warning: "/GS can not protect parameters and local variables from local buffer overrun because optimizations are disabled in function". There exists a bug to fix this [1]. Testing: JPRT, Parfait (all 6 warnings removed) Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8046696 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Wed Jul 23 11:19:22 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Jul 2014 13:19:22 +0200 Subject: [9] RFR(S): 8048721: -XX:+PrintCompilation prints negative bci for non entrant OSR methods In-Reply-To: <53C6CAF4.9070505@oracle.com> References: <53B291E9.3030508@oracle.com> <53B2A356.4080200@oracle.com> <53BBE93D.802@oracle.com> <53BF1015.4080002@oracle.com> <53C6BB1A.3070503@oracle.com> <53C6CAF4.9070505@oracle.com> Message-ID: <53CF9A3A.2010802@oracle.com> Hi, thanks for the review and sorry for the delay. Should I try to implement and test the suggested changes or wait for someone from runtime to have a look at it? Thanks, Tobias On 16.07.2014 20:56, Vladimir Kozlov wrote: > Lets see how big changes you need. > > Vladimir K > > On 7/16/14 10:49 AM, Vladimir Ivanov wrote: >> Thanks, Vladimir. >> >> On 7/11/14 2:13 AM, Vladimir Kozlov wrote: >>> _method set to NULL also in make_unloaded() but after >>> invalidate_osr_method() call so it should be fine. >>> >>> On 7/8/14 5:51 AM, Vladimir Ivanov wrote: >>>> Any thoughts about that? I still think "_entry_bci = >>>> InvalidOSREntryBci" >>>> is redundant. >>> >>> Unfortunately profiling code in Interpeter test this value: >>> >>> __ movl(rcx, Address(rax, nmethod::entry_bci_offset())); >>> __ cmpl(rcx, InvalidOSREntryBci); >>> >>> So it would require a lot more changes. But I agree that changing >>> _entry_bci looks strange >>> >>> Can we check _state value instead of _entry_bci? Could be some race >>> conditions why _entry_bci is used. >> I don't think it's necessary. >> >> Since both lookup (InstanceKlass::lookup_osr_nmethod) and removal >> (InstanceKlass::remove_osr_nmethod) actions synchronize on OsrList_lock, >> the only case when _entry_bci != InvalidOSREntryBci matters is the >> following: >> - T1: Interpreter fetches an OSR nmethod >> - T2: invalidates OSR nmethod and writes InvalidOSREntryBci into >> _entry_bci >> - T1: checks "_entry_bci != InvalidOSREntryBci" >> >> But it's already broken since it's not guaranteed that the value written >> by T2 will be seen by T1 (no synchronization actions between T1 & T2). >> >> I'd stop writing InvalidOSREntryBci into _entry_bci and remove >> "_entry_bci != InvalidOSREntryBci" check from Interpreter, or leave it >> for further cleanup if it's too much for now. It's an innocent check. >> >> Best regards, >> Vladimir Ivanov >> >>> >>> Vladimir K >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 7/1/14 4:02 PM, Vladimir Ivanov wrote: >>>>> (widening audience to Runtime folks) >>>>> >>>>> I don't think it's good to lose bci for OSR methods after nmethod >>>>> invalidation. >>>>> >>>>> Regarding current invalidation logic, I don't see that "_entry_bci = >>>>> InvalidOSREntryBci" is required to invalidate OSR nmethods. Yes, >>>>> interpreter does "_entry_bci != InvalidOSREntryBci" check before >>>>> calling >>>>> OSR nmethod, but _entry_bci update isn't properly synchronized >>>>> between >>>>> invalidating and querying threads (no locks or memory barriers >>>>> involved). >>>>> >>>>> So I have a question is it safe to remove "_entry_bci = >>>>> InvalidOSREntryBci". >>>>> >>>>> Both OSR nmethod lookup (InstanceKlass::lookup_osr_nmethod) and >>>>> removal >>>>> (InstanceKlass::remove_osr_nmethod) synchronize on OsrList_lock, so >>>>> after removal OSR nmethod can't be looked up. >>>>> >>>>> What bothers me is the following null check before removal: >>>>> void nmethod::invalidate_osr_method() { >>>>> if (method() != NULL) >>>>> method()->method_holder()->remove_osr_nmethod(this); >>>>> >>>>> Under what conditions nmethod with _method == NULL can be >>>>> invalidated? >>>>> Or is it just defensive coding? >>>>> >>>>> We set _method to NULL only for zombie nmethods (see >>>>> nmethod::make_not_entrant_or_zombie) and they are already >>>>> invalidated at >>>>> that point. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 7/1/14 2:48 PM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch for JDK-8048721. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048721 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8048721/webrev.00/ >>>>>> >>>>>> *Problem* >>>>>> The VM option -XX:+PrintCompilation prints a negative bytecode index >>>>>> for >>>>>> not entrant OSR nmethods. The problem is that in >>>>>> nmethod::make_not_entrant_or_zombie(..) the _entry_bci is >>>>>> invalidated >>>>>> (i.e. set to InvalidOSREntryBci == -2) by invalidate_osr_method(..) >>>>>> and >>>>>> log_state_change(..) is called afterwards, printing the invalidated >>>>>> entry. >>>>>> >>>>>> *Solution >>>>>> *Because reordering the methods in >>>>>> nmethod::make_not_entrant_or_zombie(..) is not easily possible >>>>>> due to >>>>>> thread safety, I changed the implementation log_state_change(..) and >>>>>> dependent methods to take the entry bci as parameter. The entry >>>>>> bci is >>>>>> saved prior to invalidation and used for printing afterwards. >>>>>> >>>>>> *Testing* >>>>>> JPRT >>>>>> >>>>>> Thanks, >>>>>> Tobias From tobias.hartmann at oracle.com Wed Jul 23 11:19:52 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Jul 2014 13:19:52 +0200 Subject: [9] RFR(S): 8048721: -XX:+PrintCompilation prints negative bci for non entrant OSR methods In-Reply-To: <53C6CAF4.9070505@oracle.com> References: <53B291E9.3030508@oracle.com> <53B2A356.4080200@oracle.com> <53BBE93D.802@oracle.com> <53BF1015.4080002@oracle.com> <53C6BB1A.3070503@oracle.com> <53C6CAF4.9070505@oracle.com> Message-ID: <53CF9A58.5030703@oracle.com> Hi, thanks for the review and sorry for the delay. Should I try to implement and test the suggested changes or wait for someone from runtime to have a look at it? Thanks, Tobias On 16.07.2014 20:56, Vladimir Kozlov wrote: > Lets see how big changes you need. > > Vladimir K > > On 7/16/14 10:49 AM, Vladimir Ivanov wrote: >> Thanks, Vladimir. >> >> On 7/11/14 2:13 AM, Vladimir Kozlov wrote: >>> _method set to NULL also in make_unloaded() but after >>> invalidate_osr_method() call so it should be fine. >>> >>> On 7/8/14 5:51 AM, Vladimir Ivanov wrote: >>>> Any thoughts about that? I still think "_entry_bci = >>>> InvalidOSREntryBci" >>>> is redundant. >>> >>> Unfortunately profiling code in Interpeter test this value: >>> >>> __ movl(rcx, Address(rax, nmethod::entry_bci_offset())); >>> __ cmpl(rcx, InvalidOSREntryBci); >>> >>> So it would require a lot more changes. But I agree that changing >>> _entry_bci looks strange >>> >>> Can we check _state value instead of _entry_bci? Could be some race >>> conditions why _entry_bci is used. >> I don't think it's necessary. >> >> Since both lookup (InstanceKlass::lookup_osr_nmethod) and removal >> (InstanceKlass::remove_osr_nmethod) actions synchronize on OsrList_lock, >> the only case when _entry_bci != InvalidOSREntryBci matters is the >> following: >> - T1: Interpreter fetches an OSR nmethod >> - T2: invalidates OSR nmethod and writes InvalidOSREntryBci into >> _entry_bci >> - T1: checks "_entry_bci != InvalidOSREntryBci" >> >> But it's already broken since it's not guaranteed that the value written >> by T2 will be seen by T1 (no synchronization actions between T1 & T2). >> >> I'd stop writing InvalidOSREntryBci into _entry_bci and remove >> "_entry_bci != InvalidOSREntryBci" check from Interpreter, or leave it >> for further cleanup if it's too much for now. It's an innocent check. >> >> Best regards, >> Vladimir Ivanov >> >>> >>> Vladimir K >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 7/1/14 4:02 PM, Vladimir Ivanov wrote: >>>>> (widening audience to Runtime folks) >>>>> >>>>> I don't think it's good to lose bci for OSR methods after nmethod >>>>> invalidation. >>>>> >>>>> Regarding current invalidation logic, I don't see that "_entry_bci = >>>>> InvalidOSREntryBci" is required to invalidate OSR nmethods. Yes, >>>>> interpreter does "_entry_bci != InvalidOSREntryBci" check before >>>>> calling >>>>> OSR nmethod, but _entry_bci update isn't properly synchronized >>>>> between >>>>> invalidating and querying threads (no locks or memory barriers >>>>> involved). >>>>> >>>>> So I have a question is it safe to remove "_entry_bci = >>>>> InvalidOSREntryBci". >>>>> >>>>> Both OSR nmethod lookup (InstanceKlass::lookup_osr_nmethod) and >>>>> removal >>>>> (InstanceKlass::remove_osr_nmethod) synchronize on OsrList_lock, so >>>>> after removal OSR nmethod can't be looked up. >>>>> >>>>> What bothers me is the following null check before removal: >>>>> void nmethod::invalidate_osr_method() { >>>>> if (method() != NULL) >>>>> method()->method_holder()->remove_osr_nmethod(this); >>>>> >>>>> Under what conditions nmethod with _method == NULL can be >>>>> invalidated? >>>>> Or is it just defensive coding? >>>>> >>>>> We set _method to NULL only for zombie nmethods (see >>>>> nmethod::make_not_entrant_or_zombie) and they are already >>>>> invalidated at >>>>> that point. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 7/1/14 2:48 PM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch for JDK-8048721. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048721 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8048721/webrev.00/ >>>>>> >>>>>> *Problem* >>>>>> The VM option -XX:+PrintCompilation prints a negative bytecode index >>>>>> for >>>>>> not entrant OSR nmethods. The problem is that in >>>>>> nmethod::make_not_entrant_or_zombie(..) the _entry_bci is >>>>>> invalidated >>>>>> (i.e. set to InvalidOSREntryBci == -2) by invalidate_osr_method(..) >>>>>> and >>>>>> log_state_change(..) is called afterwards, printing the invalidated >>>>>> entry. >>>>>> >>>>>> *Solution >>>>>> *Because reordering the methods in >>>>>> nmethod::make_not_entrant_or_zombie(..) is not easily possible >>>>>> due to >>>>>> thread safety, I changed the implementation log_state_change(..) and >>>>>> dependent methods to take the entry bci as parameter. The entry >>>>>> bci is >>>>>> saved prior to invalidation and used for printing afterwards. >>>>>> >>>>>> *Testing* >>>>>> JPRT >>>>>> >>>>>> Thanks, >>>>>> Tobias From tobias.hartmann at oracle.com Wed Jul 23 12:46:50 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Jul 2014 14:46:50 +0200 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53CE9D5F.7000407@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> <53C7A808.6040807@oracle.com> <53C84EEA.3000508@oracle.com> <53CCE27B.4010102@oracle.com> <53CD4A4D.2020504@oracle.com> <53CE1DA6.10301@oracle.com> <53CE9D5F.7000407@oracle.com> Message-ID: <53CFAEBA.3050204@oracle.com> Hi Vladimir, thanks for the review. On 22.07.2014 19:20, Vladimir Kozlov wrote: > C->modified_nodes() is called only from debug code so you can simplify > it by putting whole method inside DEBUG_ONLY() instead of different > return: > > DEBUG_ONLY( Unique_Node_List* modified_nodes() const { return > _modified_nodes; } ) Done: http://cr.openjdk.java.net/~thartmann/8040213/webrev.05/ Thanks, Tobias > > Otherwise look good. > > Thanks, > Vladimir > > On 7/22/14 1:15 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> On 21.07.2014 19:13, Vladimir Kozlov wrote: >>> > Thanks for the hint, the optimized build did not work. I'm now using >>> > PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. >>> This is >>> > consistent with other verification methods like >>> > Compile::verify_graph_edges(..). >>> >>> The logic which verifies modified nodes in phaseX.cpp is under #ifdef >>> ASSERT. Yes, you are not collecting data in optimized VM by returning >>> NULL from modified_nodes(). But it is very confusing. I would suggest >>> to move all this code to debug build only. You can use >>> NOT_DEBUG_RETURN instead of PRODUCT_RETURN and put definitions under >>> #ifdef ASSERT in compile.cpp file. >> >> Okay, that's true. I missed that there is a NOT_DEBUG_RETURN. Now >> using it. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.04/ >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Vladimir >>> >>> On 7/21/14 2:50 AM, Tobias Hartmann wrote: >>>> Vladimir, John, thanks for the review. >>>> >>>> On 18.07.2014 01:32, John Rose wrote: >>>>> On Jul 17, 2014, at 3:32 PM, Vladimir Kozlov >>>>> wrote: >>>>> >>>>>> Initial prototype was written by me so part of changes are mine. >>>>>> >>>>>> On 7/17/14 3:40 AM, Tobias Hartmann wrote: >>>>>>> Hi John, >>>>>>> >>>>>>> thanks a lot for the detailed review! Please see comments inline. >>>>>>> >>>>>>> On 16.07.2014 01:10, John Rose wrote: >>>>>>>>>> Done. New webrev: >>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ >>>>>>>> Loading C->_modified_nodes with a stack address is bad news, >>>>>>>> even if >>>>>>>> the code apparently cleans it up on exit. (I say "apparently" >>>>>>>> because >>>>>>>> there are early exits from that block, and the cleanup is not RAII >>>>>>>> style.) I strongly suggest heap allocation instead of stack >>>>>>>> allocation; it's expensive but it's for debug code. >>>>>> The list array allocation is done in compiler arena which is cleaned >>>>>> after compilation finished by ResourceMark, only descriptor is on >>>>>> stack: >>>>>> >>>>>> + Unique_Node_List modified_nodes(comp_arena()); >>>>>> >>>>>> It is our normal style. We do it a lot, see Compile::Code_Gen(). >>>>> Yes, we do it when adding phase control blocks to the Compile object, >>>>> within the tree of calls rooted at the constructor. I see that the >>>>> new code is arguably part of that pattern. I hope that is an >>>>> exceptional use of this style? >>>>> >>>>> Note that C2Compiler::compile_method creates the Compile object and >>>>> then queries it. When it queries it, the Compile object may contain >>>>> dangling pointers into phase control blocks stored on the stack >>>>> (during subroutine calls like Code_Gen) but now deallocated. >>>>> >>>>> It seems to me that we avoid touching those dangling pointers by >>>>> simple will power and discipline. Such a style doesn't scale, since >>>>> it's too easy to make mistakes as the code gets complicated. >>>>> >>>>>> Tobias, if you want to allocate Unique_Node_List object on arena: >>>>>> >>>>>> _modified_nodes = new (comp_arena()) Unique_Node_List(comp_arena()); >>>>> That makes me feel much better. >>>>> >>>>> I would prefer for us to do it this way for the other stack-chunks >>>>> also, but that would be outside the scope of this bug. >>>> >>>> I changed it to heap allocation. >>>> >>>>> Tobias, thanks for doing this work. >>>>> >>>>> ? John >>>>> >>>>>>> There are other places in the code where this is done, for >>>>>>> example in >>>>>>> Compile::Compile(..) the Unique_Node_List 'for_igvn' is created on >>>>>>> the >>>>>>> stack. Is this a special case? >>>>>>> >>>>>>> I'm not sure how to correctly allocate the object on the heap. Do I >>>>>>> have >>>>>>> to use new/delete or is this handled by some magic in >>>>>>> "ResourceObject'? >>>>>>> >>>>>>> >>>>>>>> You inserted '#ifdef ASSERT' after >>>>>>>> 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you need >>>>>>>> it, >>>>>>>> since all of the code (including the similar insertion a few >>>>>>>> lines up) >>>>>>>> is '#ifndef PRODUCT'. See also suggestion above regarding >>>>>>>> 'modified_nodes'. >>>>>> #ifndef PRODUCT is also 'optimized' version of VM. n->dump() method >>>>>> is not defined in optimized build. That is why asserts are needed. >>>>>> >>>>>> Tobias, please, build 'optimized' VM to verify your changes. >>>> >>>> Thanks for the hint, the optimized build did not work. I'm now using >>>> PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. This is >>>> consistent with other verification methods like >>>> Compile::verify_graph_edges(..). >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.03/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> True, I removed the #ifdef. >>>>>>> >>>>>>>> There are a few places where tests like 'while >>>>>>>> (modified_list->size())' appears but there is no null check of >>>>>>>> 'modified_list' itself. This could cause a crash if we ever >>>>>>>> get the >>>>>>>> phasing wrong; consider an assert or explicit null check 'while >>>>>>>> (modified_list != NULL && ...)'. >>>>>>> I added explicit null checks. >>>>>>> >>>>>>> >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.02/ >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>>> ? John >> From tobias.hartmann at oracle.com Wed Jul 23 13:11:45 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Jul 2014 15:11:45 +0200 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53CF98B1.9070508@oracle.com> References: <53CF98B1.9070508@oracle.com> Message-ID: <53CFB491.1010709@oracle.com> I just noticed that the 'DoubleIntConv' union is useful for other fixes as well (for example JDK-8040121). Can I add it to share/vm/utilities/globalDefinitions.hpp or is there a better place? Thanks, Tobias On 23.07.2014 13:12, Tobias Hartmann wrote: > Hi, > > please review the following patch for JDK- 8049043 (Parfait warning). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 > Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ > > Problem: > Parfait issues 6 warnings " Load variable through a pointer of an > incompatible type" because of the __HI(x) and __LO(x) macros used in > copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) to cast > between double* and int*. > > Solution: > A union 'DoubleIntConv' is used to access the high and low 32 bits of > a double. > The '# pragma warning( disable: 4748 )' in sharedRuntimeTrans.cpp is > necessary because otherwise the VS compiler fails with the following > warning: "/GS can not protect parameters and local variables from > local buffer overrun because optimizations are disabled in function". > There exists a bug to fix this [1]. > > Testing: > JPRT, Parfait (all 6 warnings removed) > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8046696 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Jul 23 14:22:09 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jul 2014 07:22:09 -0700 Subject: [9] RFR(S): 8050860: Cleanup TypeTuple and TypeFunc In-Reply-To: <53CF6639.4020708@oracle.com> References: <53CF6639.4020708@oracle.com> Message-ID: <53CFC511.8030201@oracle.com> Good. Vladimir On 7/23/14 12:37 AM, Zolt?n Maj? wrote: > Hi all, > > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8050860 > > Problem: TypeFunc::_domain, TypeFunc::_range, TypeTuple::_cnt and TypeTuple::_fields are public, but could be declared > private. > > Solution: Declared fields private, changed direct accesses to fields (from other classes) to use accessor methods instead. > > Webrev: http://cr.openjdk.java.net/~thartmann/8050860/webrev.00/ > > Testing: run all JPRT tests, all passed; built all_optimized and all_debug successfully. > > Thank you and best regards, > > > Zoltan Majo > From vladimir.x.ivanov at oracle.com Wed Jul 23 14:25:12 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 23 Jul 2014 18:25:12 +0400 Subject: [9] RFR(S): 8050860: Cleanup TypeTuple and TypeFunc In-Reply-To: <53CF6639.4020708@oracle.com> References: <53CF6639.4020708@oracle.com> Message-ID: <53CFC5C8.8040706@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 7/23/14, 11:37 AM, Zolt?n Maj? wrote: > Hi all, > > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8050860 > > Problem: TypeFunc::_domain, TypeFunc::_range, TypeTuple::_cnt and > TypeTuple::_fields are public, but could be declared private. > > Solution: Declared fields private, changed direct accesses to fields > (from other classes) to use accessor methods instead. > > Webrev: http://cr.openjdk.java.net/~thartmann/8050860/webrev.00/ > > Testing: run all JPRT tests, all passed; built all_optimized and > all_debug successfully. > > Thank you and best regards, > > > Zoltan Majo > From vladimir.kozlov at oracle.com Wed Jul 23 14:35:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jul 2014 07:35:20 -0700 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53CFAEBA.3050204@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> <53C7A808.6040807@oracle.com> <53C84EEA.3000508@oracle.com> <53CCE27B.4010102@oracle.com> <53CD4A4D.2020504@oracle.com> <53CE1DA6.10301@oracle.com> <53CE9D5F.7000407@oracle.com> <53CFAEBA.3050204@oracle.com> Message-ID: <53CFC828.4040106@oracle.com> Good. Thanks, Vladimir On 7/23/14 5:46 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > > On 22.07.2014 19:20, Vladimir Kozlov wrote: >> C->modified_nodes() is called only from debug code so you can simplify it by putting whole method inside DEBUG_ONLY() >> instead of different return: >> >> DEBUG_ONLY( Unique_Node_List* modified_nodes() const { return _modified_nodes; } ) > > Done: http://cr.openjdk.java.net/~thartmann/8040213/webrev.05/ > > Thanks, > Tobias > >> >> Otherwise look good. >> >> Thanks, >> Vladimir >> >> On 7/22/14 1:15 AM, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> On 21.07.2014 19:13, Vladimir Kozlov wrote: >>>> > Thanks for the hint, the optimized build did not work. I'm now using >>>> > PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. This is >>>> > consistent with other verification methods like >>>> > Compile::verify_graph_edges(..). >>>> >>>> The logic which verifies modified nodes in phaseX.cpp is under #ifdef >>>> ASSERT. Yes, you are not collecting data in optimized VM by returning >>>> NULL from modified_nodes(). But it is very confusing. I would suggest >>>> to move all this code to debug build only. You can use >>>> NOT_DEBUG_RETURN instead of PRODUCT_RETURN and put definitions under >>>> #ifdef ASSERT in compile.cpp file. >>> >>> Okay, that's true. I missed that there is a NOT_DEBUG_RETURN. Now using it. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.04/ >>> >>> Thanks, >>> Tobias >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/21/14 2:50 AM, Tobias Hartmann wrote: >>>>> Vladimir, John, thanks for the review. >>>>> >>>>> On 18.07.2014 01:32, John Rose wrote: >>>>>> On Jul 17, 2014, at 3:32 PM, Vladimir Kozlov >>>>>> wrote: >>>>>> >>>>>>> Initial prototype was written by me so part of changes are mine. >>>>>>> >>>>>>> On 7/17/14 3:40 AM, Tobias Hartmann wrote: >>>>>>>> Hi John, >>>>>>>> >>>>>>>> thanks a lot for the detailed review! Please see comments inline. >>>>>>>> >>>>>>>> On 16.07.2014 01:10, John Rose wrote: >>>>>>>>>>> Done. New webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ >>>>>>>>> Loading C->_modified_nodes with a stack address is bad news, even if >>>>>>>>> the code apparently cleans it up on exit. (I say "apparently" >>>>>>>>> because >>>>>>>>> there are early exits from that block, and the cleanup is not RAII >>>>>>>>> style.) I strongly suggest heap allocation instead of stack >>>>>>>>> allocation; it's expensive but it's for debug code. >>>>>>> The list array allocation is done in compiler arena which is cleaned >>>>>>> after compilation finished by ResourceMark, only descriptor is on >>>>>>> stack: >>>>>>> >>>>>>> + Unique_Node_List modified_nodes(comp_arena()); >>>>>>> >>>>>>> It is our normal style. We do it a lot, see Compile::Code_Gen(). >>>>>> Yes, we do it when adding phase control blocks to the Compile object, >>>>>> within the tree of calls rooted at the constructor. I see that the >>>>>> new code is arguably part of that pattern. I hope that is an >>>>>> exceptional use of this style? >>>>>> >>>>>> Note that C2Compiler::compile_method creates the Compile object and >>>>>> then queries it. When it queries it, the Compile object may contain >>>>>> dangling pointers into phase control blocks stored on the stack >>>>>> (during subroutine calls like Code_Gen) but now deallocated. >>>>>> >>>>>> It seems to me that we avoid touching those dangling pointers by >>>>>> simple will power and discipline. Such a style doesn't scale, since >>>>>> it's too easy to make mistakes as the code gets complicated. >>>>>> >>>>>>> Tobias, if you want to allocate Unique_Node_List object on arena: >>>>>>> >>>>>>> _modified_nodes = new (comp_arena()) Unique_Node_List(comp_arena()); >>>>>> That makes me feel much better. >>>>>> >>>>>> I would prefer for us to do it this way for the other stack-chunks >>>>>> also, but that would be outside the scope of this bug. >>>>> >>>>> I changed it to heap allocation. >>>>> >>>>>> Tobias, thanks for doing this work. >>>>>> >>>>>> ? John >>>>>> >>>>>>>> There are other places in the code where this is done, for example in >>>>>>>> Compile::Compile(..) the Unique_Node_List 'for_igvn' is created on >>>>>>>> the >>>>>>>> stack. Is this a special case? >>>>>>>> >>>>>>>> I'm not sure how to correctly allocate the object on the heap. Do I >>>>>>>> have >>>>>>>> to use new/delete or is this handled by some magic in >>>>>>>> "ResourceObject'? >>>>>>>> >>>>>>>> >>>>>>>>> You inserted '#ifdef ASSERT' after >>>>>>>>> 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you need it, >>>>>>>>> since all of the code (including the similar insertion a few >>>>>>>>> lines up) >>>>>>>>> is '#ifndef PRODUCT'. See also suggestion above regarding >>>>>>>>> 'modified_nodes'. >>>>>>> #ifndef PRODUCT is also 'optimized' version of VM. n->dump() method >>>>>>> is not defined in optimized build. That is why asserts are needed. >>>>>>> >>>>>>> Tobias, please, build 'optimized' VM to verify your changes. >>>>> >>>>> Thanks for the hint, the optimized build did not work. I'm now using >>>>> PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. This is >>>>> consistent with other verification methods like >>>>> Compile::verify_graph_edges(..). >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.03/ >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> True, I removed the #ifdef. >>>>>>>> >>>>>>>>> There are a few places where tests like 'while >>>>>>>>> (modified_list->size())' appears but there is no null check of >>>>>>>>> 'modified_list' itself. This could cause a crash if we ever get the >>>>>>>>> phasing wrong; consider an assert or explicit null check 'while >>>>>>>>> (modified_list != NULL && ...)'. >>>>>>>> I added explicit null checks. >>>>>>>> >>>>>>>> >>>>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.02/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>>> ? John >>> > From zhengyu.gu at oracle.com Wed Jul 23 17:00:00 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 23 Jul 2014 13:00:00 -0400 Subject: Round 3 RFR (S) 6424123: JVM crashes on failed 'strdup' call. In-Reply-To: <53BF8555.30803@oracle.com> References: <538F826C.8090000@oracle.com> <5391F4EB.9070007@oracle.com> <539426CD.2030104@oracle.com> <53945BAB.5030809@oracle.com> <5394DCC6.1050704@oracle.com> <5395BA18.2090403@oracle.com> <53968098.1060809@oracle.com> <539778EA.6060305@oracle.com> <53BECFDF.40308@oracle.com> <53BF8555.30803@oracle.com> Message-ID: <53CFEA10.8000007@oracle.com> Try again, > --- > > src/share/vm/compiler/compilerOracle.cpp > > It's not obvious that your change is correct. If MethodMatcher::match > is called several times might you not want to duplicate the string on > each call? That said it isn't obvious that these strings need copying > at all - we'd need to trace their complete lifecycle. > > Similar comments for NamedCounter in runtime.cpp and vmNode in > fprofiler.cpp > > Having to add all those destructors seems messy and it isn't evident > that it is necessary. > Can someone from compiler team take a look? Webrev:http://cr.openjdk.java.net/~zgu/6424123/webrev.02 Thanks, -Zhengyu > --- > > Thanks, > David > > On 11/07/2014 3:39 AM, Zhengyu Gu wrote: >> Sorry for the long delay. The update is mainly based on Coleen's >> suggestion. >> >> DuplicateString() is changed to os::strdup_check_oom(). >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-6424123 >> >> Webrev:http://cr.openjdk.java.net/~zgu/6424123/webrev.02/ >> >> >> >> Thanks, >> >> -Zhengyu >> >> >> >> >> On 6/10/2014 5:30 PM, Coleen Phillimore wrote: >>> >>> Hi, I think this is potentially a really good cleanup. May I suggest >>> making DuplicateString an os function like os::duplicate_string() and >>> have it always throw OOM, so that the alloc_failmode parameter doesn't >>> look inconsistent. >>> >>> If new code wants to call os::strdup() and check for null return, it >>> can do that. Otherwise call os::safe_duplicate_string() or >>> os::duplicate_string() as a wrapper to a os::strdup() that doesn't >>> return null. >>> >>> I'm not convinced the original bug is caused by missing a null check >>> to strdup (unless it passed into strdup an already null string). But >>> this cleans up using this unsafe function directly. >>> >>> Thanks, >>> Coleen >>> >>> On 6/9/14, 11:50 PM, David Holmes wrote: >>>> On 9/06/2014 11:43 PM, Zhengyu Gu wrote: >>>>> Hi David, >>>>> >>>>> On 6/8/2014 5:59 PM, David Holmes wrote: >>>>>> On 8/06/2014 10:48 PM, Zhengyu Gu wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 6/8/2014 5:03 AM, David Holmes wrote: >>>>>>>> Hi Zhengyu, >>>>>>>> >>>>>>>> Still a bit perplexed by the aim here. Why replace non-null >>>>>>>> checked >>>>>>>> strdup calls with non-null os::strdup? >>>>>>> ::strdup() is not tracked by NMT, but os::strdup() is. >>>>>> >>>>>> Okay, but it still needs to be checked. >>>>>> >>>>> I am not sure what needs to be checked? >>>> >>>> The result of calling os::strdup - else we haven't fixed the original >>>> bug. Unless you are saying that all uses of os::strdup do check the >>>> return value somewhere in the call chain? >>>> >>>>>>>> If the issue is that the result of strdup must be checked then it >>>>>>>> must >>>>>>>> be checked. Why add DuplicateString instead of changing what >>>>>>>> os::strdup does? >>>>>>> I replaced strdup()/os::strdup() with DuplicateString(), where >>>>>>> caller >>>>>>> does not check null pointer. If caller checks null pointer, I >>>>>>> left it >>>>>>> alone. >>>>>> >>>>>> That is not apparent from the webrev eg: >>>>>> >>>>>> src/os/windows/vm/perfMemory_windows.cpp >>>>>> >>>>> There are several places that are not obvious. Sometimes, I have to >>>>> go a >>>>> few levels to find out how the pointers are used. >>>>> >>>>> For this particular case, sharedmem_fileName is only referenced by >>>>> PerfMemory::backing_store_filename(), but there is no caller to this >>>>> function. >>>>> >>>>> $ grep -r backing_store_filename * >>>>> os/aix/vm/perfMemory_aix.cpp:char* >>>>> PerfMemory::backing_store_filename() { >>>>> os/bsd/vm/perfMemory_bsd.cpp:char* >>>>> PerfMemory::backing_store_filename() { >>>>> os/linux/vm/perfMemory_linux.cpp:char* >>>>> PerfMemory::backing_store_filename() { >>>>> os/solaris/vm/perfMemory_solaris.cpp:char* >>>>> PerfMemory::backing_store_filename() { >>>>> os/windows/vm/perfMemory_windows.cpp:char* >>>>> PerfMemory::backing_store_filename() { >>>>> share/vm/runtime/perfMemory.hpp: static char* >>>>> backing_store_filename(); >>>>> >>>>> I thought parfait should be good at finding these things. >>>>> >>>>>> >>>>>>> DuplicateString() mirrors what AllocateHeap() does, and >>>>>>> os::strdup() >>>>>>> mirrors os::malloc(). AllocateHeap()/DuplicateString() can >>>>>>> handle OOM >>>>>>> (by default), but os::strdup()/os::malloc() do not. >>>>>> >>>>>> I don't see the need for this duality here. Why do we need to dup >>>>>> strings in different memory areas? Why can't os::strdup do the null >>>>>> check internally and abort if requested? >>>>>> >>>>>> Putting it another way if someone writes a new piece of code where >>>>>> they need to dup an incoming string, what determines whether they >>>>>> should use os::strdup or DuplicateString? >>>>>> >>>>> I agree it is confusing that we have some many memory allocation >>>>> functions to accomplish similar things, given AllocateHeap() and >>>>> ReallocateHeap() can also return NULL now. That's also the reason to >>>>> get >>>>> me wrong in the first iteration. >>>>> >>>>> The purposed approach at least keep os::malloc(), os::realloc() and >>>>> os::strdup() as replacement of c library's counterparts. >>>>> Having os::strdup() handles OOM, but not os::malloc() and >>>>> os::realloc(), >>>>> seems to me even more confusing and inconsistent. >>>>> >>>>> To determine whether uses os::strdup() or DuplicationString(), >>>>> should be >>>>> the same way to determine whether uses os::malloc() or >>>>> AllocateHeap(), >>>>> in my opinion. >>>> >>>> AllocateHeap should only be being used as the implementation for >>>> CHeapObj and related types, it is not a general purpose allocation >>>> interface. So I don't see that the analogy holds. I'd rather see only >>>> os::strdup used with all the clients doing the null check (somewhere >>>> in the stack) and handling it appropriately. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Zhengyu >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 7/06/2014 3:05 AM, Zhengyu Gu wrote: >>>>>>>>> Updated webrev introduces a new DuplicateString() function, that >>>>>>>>> handles >>>>>>>>> OOM, similar to AllocateHeap(), and replaces the call sites >>>>>>>>> that do >>>>>>>>> not >>>>>>>>> check NULL pointer with this DuplicateString(). >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~zgu/6424123/webrev.01/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Zhengyu >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/4/2014 4:32 PM, Zhengyu Gu wrote: >>>>>>>>>> JVM should avoid C library's strdup() and use os::strdup() >>>>>>>>>> instead. >>>>>>>>>> os::strdup() handles OOM, so can avoid JVM crash. >>>>>>>>>> >>>>>>>>>> Also, made limited scope of code cleanup, which makes memory >>>>>>>>>> ownership >>>>>>>>>> more explicit, so they can be claimed by object's destructors. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6424123 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/6424123/webrev.00/ >>>>>>>>>> >>>>>>>>>> Tests: >>>>>>>>>> - JPRT >>>>>>>>>> - vm.quick.testlist on Linux x64. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Zhengyu >>>>>>>>> >>>>>>> >>>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Jul 23 17:33:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jul 2014 10:33:35 -0700 Subject: Round 3 RFR (S) 6424123: JVM crashes on failed 'strdup' call. In-Reply-To: <53CFEA10.8000007@oracle.com> References: <538F826C.8090000@oracle.com> <5391F4EB.9070007@oracle.com> <539426CD.2030104@oracle.com> <53945BAB.5030809@oracle.com> <5394DCC6.1050704@oracle.com> <5395BA18.2090403@oracle.com> <53968098.1060809@oracle.com> <539778EA.6060305@oracle.com> <53BECFDF.40308@oracle.com> <53BF8555.30803@oracle.com> <53CFEA10.8000007@oracle.com> Message-ID: <53CFF1EF.5070604@oracle.com> In compilerOracle.cpp the collected information is never deleted so destructor will not be called for MethodOptionMatcher. But I am fine to have the destructor (at least for silencing parfait if it complains). opto/runtime.* changes are fine. Thanks, Vladimir On 7/23/14 10:00 AM, Zhengyu Gu wrote: > Try again, > >> --- >> >> src/share/vm/compiler/compilerOracle.cpp >> >> It's not obvious that your change is correct. If MethodMatcher::match >> is called several times might you not want to duplicate the string on >> each call? That said it isn't obvious that these strings need copying >> at all - we'd need to trace their complete lifecycle. >> >> Similar comments for NamedCounter in runtime.cpp and vmNode in >> fprofiler.cpp >> >> Having to add all those destructors seems messy and it isn't evident >> that it is necessary. >> > > Can someone from compiler team take a look? > > Webrev:http://cr.openjdk.java.net/~zgu/6424123/webrev.02 > > > Thanks, > > -Zhengyu > > >> --- >> >> Thanks, >> David >> >> On 11/07/2014 3:39 AM, Zhengyu Gu wrote: >>> Sorry for the long delay. The update is mainly based on Coleen's >>> suggestion. >>> >>> DuplicateString() is changed to os::strdup_check_oom(). >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-6424123 >>> >>> Webrev:http://cr.openjdk.java.net/~zgu/6424123/webrev.02/ >>> >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> >>> >>> On 6/10/2014 5:30 PM, Coleen Phillimore wrote: >>>> >>>> Hi, I think this is potentially a really good cleanup. May I suggest >>>> making DuplicateString an os function like os::duplicate_string() and >>>> have it always throw OOM, so that the alloc_failmode parameter doesn't >>>> look inconsistent. >>>> >>>> If new code wants to call os::strdup() and check for null return, it >>>> can do that. Otherwise call os::safe_duplicate_string() or >>>> os::duplicate_string() as a wrapper to a os::strdup() that doesn't >>>> return null. >>>> >>>> I'm not convinced the original bug is caused by missing a null check >>>> to strdup (unless it passed into strdup an already null string). But >>>> this cleans up using this unsafe function directly. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 6/9/14, 11:50 PM, David Holmes wrote: >>>>> On 9/06/2014 11:43 PM, Zhengyu Gu wrote: >>>>>> Hi David, >>>>>> >>>>>> On 6/8/2014 5:59 PM, David Holmes wrote: >>>>>>> On 8/06/2014 10:48 PM, Zhengyu Gu wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 6/8/2014 5:03 AM, David Holmes wrote: >>>>>>>>> Hi Zhengyu, >>>>>>>>> >>>>>>>>> Still a bit perplexed by the aim here. Why replace non-null >>>>>>>>> checked >>>>>>>>> strdup calls with non-null os::strdup? >>>>>>>> ::strdup() is not tracked by NMT, but os::strdup() is. >>>>>>> >>>>>>> Okay, but it still needs to be checked. >>>>>>> >>>>>> I am not sure what needs to be checked? >>>>> >>>>> The result of calling os::strdup - else we haven't fixed the original >>>>> bug. Unless you are saying that all uses of os::strdup do check the >>>>> return value somewhere in the call chain? >>>>> >>>>>>>>> If the issue is that the result of strdup must be checked then it >>>>>>>>> must >>>>>>>>> be checked. Why add DuplicateString instead of changing what >>>>>>>>> os::strdup does? >>>>>>>> I replaced strdup()/os::strdup() with DuplicateString(), where >>>>>>>> caller >>>>>>>> does not check null pointer. If caller checks null pointer, I >>>>>>>> left it >>>>>>>> alone. >>>>>>> >>>>>>> That is not apparent from the webrev eg: >>>>>>> >>>>>>> src/os/windows/vm/perfMemory_windows.cpp >>>>>>> >>>>>> There are several places that are not obvious. Sometimes, I have to >>>>>> go a >>>>>> few levels to find out how the pointers are used. >>>>>> >>>>>> For this particular case, sharedmem_fileName is only referenced by >>>>>> PerfMemory::backing_store_filename(), but there is no caller to this >>>>>> function. >>>>>> >>>>>> $ grep -r backing_store_filename * >>>>>> os/aix/vm/perfMemory_aix.cpp:char* >>>>>> PerfMemory::backing_store_filename() { >>>>>> os/bsd/vm/perfMemory_bsd.cpp:char* >>>>>> PerfMemory::backing_store_filename() { >>>>>> os/linux/vm/perfMemory_linux.cpp:char* >>>>>> PerfMemory::backing_store_filename() { >>>>>> os/solaris/vm/perfMemory_solaris.cpp:char* >>>>>> PerfMemory::backing_store_filename() { >>>>>> os/windows/vm/perfMemory_windows.cpp:char* >>>>>> PerfMemory::backing_store_filename() { >>>>>> share/vm/runtime/perfMemory.hpp: static char* >>>>>> backing_store_filename(); >>>>>> >>>>>> I thought parfait should be good at finding these things. >>>>>> >>>>>>> >>>>>>>> DuplicateString() mirrors what AllocateHeap() does, and >>>>>>>> os::strdup() >>>>>>>> mirrors os::malloc(). AllocateHeap()/DuplicateString() can >>>>>>>> handle OOM >>>>>>>> (by default), but os::strdup()/os::malloc() do not. >>>>>>> >>>>>>> I don't see the need for this duality here. Why do we need to dup >>>>>>> strings in different memory areas? Why can't os::strdup do the null >>>>>>> check internally and abort if requested? >>>>>>> >>>>>>> Putting it another way if someone writes a new piece of code where >>>>>>> they need to dup an incoming string, what determines whether they >>>>>>> should use os::strdup or DuplicateString? >>>>>>> >>>>>> I agree it is confusing that we have some many memory allocation >>>>>> functions to accomplish similar things, given AllocateHeap() and >>>>>> ReallocateHeap() can also return NULL now. That's also the reason to >>>>>> get >>>>>> me wrong in the first iteration. >>>>>> >>>>>> The purposed approach at least keep os::malloc(), os::realloc() and >>>>>> os::strdup() as replacement of c library's counterparts. >>>>>> Having os::strdup() handles OOM, but not os::malloc() and >>>>>> os::realloc(), >>>>>> seems to me even more confusing and inconsistent. >>>>>> >>>>>> To determine whether uses os::strdup() or DuplicationString(), >>>>>> should be >>>>>> the same way to determine whether uses os::malloc() or >>>>>> AllocateHeap(), >>>>>> in my opinion. >>>>> >>>>> AllocateHeap should only be being used as the implementation for >>>>> CHeapObj and related types, it is not a general purpose allocation >>>>> interface. So I don't see that the analogy holds. I'd rather see only >>>>> os::strdup used with all the clients doing the null check (somewhere >>>>> in the stack) and handling it appropriately. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Zhengyu >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 7/06/2014 3:05 AM, Zhengyu Gu wrote: >>>>>>>>>> Updated webrev introduces a new DuplicateString() function, that >>>>>>>>>> handles >>>>>>>>>> OOM, similar to AllocateHeap(), and replaces the call sites >>>>>>>>>> that do >>>>>>>>>> not >>>>>>>>>> check NULL pointer with this DuplicateString(). >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~zgu/6424123/webrev.01/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Zhengyu >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 6/4/2014 4:32 PM, Zhengyu Gu wrote: >>>>>>>>>>> JVM should avoid C library's strdup() and use os::strdup() >>>>>>>>>>> instead. >>>>>>>>>>> os::strdup() handles OOM, so can avoid JVM crash. >>>>>>>>>>> >>>>>>>>>>> Also, made limited scope of code cleanup, which makes memory >>>>>>>>>>> ownership >>>>>>>>>>> more explicit, so they can be claimed by object's destructors. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6424123 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/6424123/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Tests: >>>>>>>>>>> - JPRT >>>>>>>>>>> - vm.quick.testlist on Linux x64. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Zhengyu >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From zhengyu.gu at oracle.com Wed Jul 23 17:45:27 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 23 Jul 2014 13:45:27 -0400 Subject: Round 3 RFR (S) 6424123: JVM crashes on failed 'strdup' call. In-Reply-To: <53CFF1EF.5070604@oracle.com> References: <538F826C.8090000@oracle.com> <5391F4EB.9070007@oracle.com> <539426CD.2030104@oracle.com> <53945BAB.5030809@oracle.com> <5394DCC6.1050704@oracle.com> <5395BA18.2090403@oracle.com> <53968098.1060809@oracle.com> <539778EA.6060305@oracle.com> <53BECFDF.40308@oracle.com> <53BF8555.30803@oracle.com> <53CFEA10.8000007@oracle.com> <53CFF1EF.5070604@oracle.com> Message-ID: <53CFF4B7.1070808@oracle.com> Thanks a lot! -Zhengyu On 7/23/2014 1:33 PM, Vladimir Kozlov wrote: > In compilerOracle.cpp the collected information is never deleted so > destructor will not be called for MethodOptionMatcher. But I am fine > to have the destructor (at least for silencing parfait if it complains). > > opto/runtime.* changes are fine. > > Thanks, > Vladimir > > On 7/23/14 10:00 AM, Zhengyu Gu wrote: >> Try again, >> >>> --- >>> >>> src/share/vm/compiler/compilerOracle.cpp >>> >>> It's not obvious that your change is correct. If MethodMatcher::match >>> is called several times might you not want to duplicate the string on >>> each call? That said it isn't obvious that these strings need copying >>> at all - we'd need to trace their complete lifecycle. >>> >>> Similar comments for NamedCounter in runtime.cpp and vmNode in >>> fprofiler.cpp >>> >>> Having to add all those destructors seems messy and it isn't evident >>> that it is necessary. >>> >> >> Can someone from compiler team take a look? >> >> Webrev:http://cr.openjdk.java.net/~zgu/6424123/webrev.02 >> >> >> Thanks, >> >> -Zhengyu >> >> >>> --- >>> >>> Thanks, >>> David >>> >>> On 11/07/2014 3:39 AM, Zhengyu Gu wrote: >>>> Sorry for the long delay. The update is mainly based on Coleen's >>>> suggestion. >>>> >>>> DuplicateString() is changed to os::strdup_check_oom(). >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-6424123 >>>> >>>> Webrev:http://cr.openjdk.java.net/~zgu/6424123/webrev.02/ >>>> >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> >>>> >>>> On 6/10/2014 5:30 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi, I think this is potentially a really good cleanup. May I suggest >>>>> making DuplicateString an os function like os::duplicate_string() and >>>>> have it always throw OOM, so that the alloc_failmode parameter >>>>> doesn't >>>>> look inconsistent. >>>>> >>>>> If new code wants to call os::strdup() and check for null return, it >>>>> can do that. Otherwise call os::safe_duplicate_string() or >>>>> os::duplicate_string() as a wrapper to a os::strdup() that doesn't >>>>> return null. >>>>> >>>>> I'm not convinced the original bug is caused by missing a null check >>>>> to strdup (unless it passed into strdup an already null string). But >>>>> this cleans up using this unsafe function directly. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 6/9/14, 11:50 PM, David Holmes wrote: >>>>>> On 9/06/2014 11:43 PM, Zhengyu Gu wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 6/8/2014 5:59 PM, David Holmes wrote: >>>>>>>> On 8/06/2014 10:48 PM, Zhengyu Gu wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 6/8/2014 5:03 AM, David Holmes wrote: >>>>>>>>>> Hi Zhengyu, >>>>>>>>>> >>>>>>>>>> Still a bit perplexed by the aim here. Why replace non-null >>>>>>>>>> checked >>>>>>>>>> strdup calls with non-null os::strdup? >>>>>>>>> ::strdup() is not tracked by NMT, but os::strdup() is. >>>>>>>> >>>>>>>> Okay, but it still needs to be checked. >>>>>>>> >>>>>>> I am not sure what needs to be checked? >>>>>> >>>>>> The result of calling os::strdup - else we haven't fixed the >>>>>> original >>>>>> bug. Unless you are saying that all uses of os::strdup do check the >>>>>> return value somewhere in the call chain? >>>>>> >>>>>>>>>> If the issue is that the result of strdup must be checked >>>>>>>>>> then it >>>>>>>>>> must >>>>>>>>>> be checked. Why add DuplicateString instead of changing what >>>>>>>>>> os::strdup does? >>>>>>>>> I replaced strdup()/os::strdup() with DuplicateString(), where >>>>>>>>> caller >>>>>>>>> does not check null pointer. If caller checks null pointer, I >>>>>>>>> left it >>>>>>>>> alone. >>>>>>>> >>>>>>>> That is not apparent from the webrev eg: >>>>>>>> >>>>>>>> src/os/windows/vm/perfMemory_windows.cpp >>>>>>>> >>>>>>> There are several places that are not obvious. Sometimes, I have to >>>>>>> go a >>>>>>> few levels to find out how the pointers are used. >>>>>>> >>>>>>> For this particular case, sharedmem_fileName is only referenced by >>>>>>> PerfMemory::backing_store_filename(), but there is no caller to >>>>>>> this >>>>>>> function. >>>>>>> >>>>>>> $ grep -r backing_store_filename * >>>>>>> os/aix/vm/perfMemory_aix.cpp:char* >>>>>>> PerfMemory::backing_store_filename() { >>>>>>> os/bsd/vm/perfMemory_bsd.cpp:char* >>>>>>> PerfMemory::backing_store_filename() { >>>>>>> os/linux/vm/perfMemory_linux.cpp:char* >>>>>>> PerfMemory::backing_store_filename() { >>>>>>> os/solaris/vm/perfMemory_solaris.cpp:char* >>>>>>> PerfMemory::backing_store_filename() { >>>>>>> os/windows/vm/perfMemory_windows.cpp:char* >>>>>>> PerfMemory::backing_store_filename() { >>>>>>> share/vm/runtime/perfMemory.hpp: static char* >>>>>>> backing_store_filename(); >>>>>>> >>>>>>> I thought parfait should be good at finding these things. >>>>>>> >>>>>>>> >>>>>>>>> DuplicateString() mirrors what AllocateHeap() does, and >>>>>>>>> os::strdup() >>>>>>>>> mirrors os::malloc(). AllocateHeap()/DuplicateString() can >>>>>>>>> handle OOM >>>>>>>>> (by default), but os::strdup()/os::malloc() do not. >>>>>>>> >>>>>>>> I don't see the need for this duality here. Why do we need to dup >>>>>>>> strings in different memory areas? Why can't os::strdup do the >>>>>>>> null >>>>>>>> check internally and abort if requested? >>>>>>>> >>>>>>>> Putting it another way if someone writes a new piece of code where >>>>>>>> they need to dup an incoming string, what determines whether they >>>>>>>> should use os::strdup or DuplicateString? >>>>>>>> >>>>>>> I agree it is confusing that we have some many memory allocation >>>>>>> functions to accomplish similar things, given AllocateHeap() and >>>>>>> ReallocateHeap() can also return NULL now. That's also the >>>>>>> reason to >>>>>>> get >>>>>>> me wrong in the first iteration. >>>>>>> >>>>>>> The purposed approach at least keep os::malloc(), os::realloc() and >>>>>>> os::strdup() as replacement of c library's counterparts. >>>>>>> Having os::strdup() handles OOM, but not os::malloc() and >>>>>>> os::realloc(), >>>>>>> seems to me even more confusing and inconsistent. >>>>>>> >>>>>>> To determine whether uses os::strdup() or DuplicationString(), >>>>>>> should be >>>>>>> the same way to determine whether uses os::malloc() or >>>>>>> AllocateHeap(), >>>>>>> in my opinion. >>>>>> >>>>>> AllocateHeap should only be being used as the implementation for >>>>>> CHeapObj and related types, it is not a general purpose allocation >>>>>> interface. So I don't see that the analogy holds. I'd rather see >>>>>> only >>>>>> os::strdup used with all the clients doing the null check (somewhere >>>>>> in the stack) and handling it appropriately. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Zhengyu >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Zhengyu >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 7/06/2014 3:05 AM, Zhengyu Gu wrote: >>>>>>>>>>> Updated webrev introduces a new DuplicateString() function, >>>>>>>>>>> that >>>>>>>>>>> handles >>>>>>>>>>> OOM, similar to AllocateHeap(), and replaces the call sites >>>>>>>>>>> that do >>>>>>>>>>> not >>>>>>>>>>> check NULL pointer with this DuplicateString(). >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~zgu/6424123/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Zhengyu >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 6/4/2014 4:32 PM, Zhengyu Gu wrote: >>>>>>>>>>>> JVM should avoid C library's strdup() and use os::strdup() >>>>>>>>>>>> instead. >>>>>>>>>>>> os::strdup() handles OOM, so can avoid JVM crash. >>>>>>>>>>>> >>>>>>>>>>>> Also, made limited scope of code cleanup, which makes memory >>>>>>>>>>>> ownership >>>>>>>>>>>> more explicit, so they can be claimed by object's destructors. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6424123 >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/6424123/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Tests: >>>>>>>>>>>> - JPRT >>>>>>>>>>>> - vm.quick.testlist on Linux x64. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -Zhengyu >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> From vladimir.kozlov at oracle.com Wed Jul 23 17:58:32 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jul 2014 10:58:32 -0700 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53CF98B1.9070508@oracle.com> References: <53CF98B1.9070508@oracle.com> Message-ID: <53CFF7C8.3090207@oracle.com> Tobias, why you are creating local copy 'conv' of a variable in all places? Vladimir On 7/23/14 4:12 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch for JDK- 8049043 (Parfait warning). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 > Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ > > Problem: > Parfait issues 6 warnings " Load variable through a pointer of an > incompatible type" because of the __HI(x) and __LO(x) macros used in > copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) to cast > between double* and int*. > > Solution: > A union 'DoubleIntConv' is used to access the high and low 32 bits of a > double. > The '# pragma warning( disable: 4748 )' in sharedRuntimeTrans.cpp is > necessary because otherwise the VS compiler fails with the following > warning: "/GS can not protect parameters and local variables from local > buffer overrun because optimizations are disabled in function". There > exists a bug to fix this [1]. > > Testing: > JPRT, Parfait (all 6 warnings removed) > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8046696 From aleksey.shipilev at oracle.com Wed Jul 23 18:38:51 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 23 Jul 2014 22:38:51 +0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53CED9BB.4000007@oracle.com> References: <53CED9BB.4000007@oracle.com> Message-ID: <53D0013B.4090603@oracle.com> On 07/23/2014 01:38 AM, Aleksey Shipilev wrote: > * 1x4x1 Intel Core (Haswell-DT) benefits from offsetting %esp as well. > There is an interesting hump on lower backoffs with addl (%esp-8), which > seems to be a second-order microarchitectural effect. Unfortunately, we > don't have large Haswells available at the moment to dive into this: > http://cr.openjdk.java.net/~shade/8050147/micros/Intel-Haswell.data.png Finally managed to get the profile on this Haswell. The hottest loops are identical, although the second variant is consistently better. This produces 1200.318 +- 18.520 ns/op: 2.65% 0x00007fdcb87190b0: mov (%rsp),%r10 0x00007fdcb87190b4: mov 0xc(%r10),%r10d 0.06% 0x00007fdcb87190b8: mov %r10d,0xc(%rbp) 2.66% 0x00007fdcb87190bc: lock addl $0x0,-0x8(%rsp) 80.08% 95.59% 0x00007fdcb87190c2: mov %rbp,%rsi 0x00007fdcb87190c5: xchg %ax,%ax 0x00007fdcb87190c7: callq 0x00007fdcb85d7fe0 0x00007fdcb87190cc: test %eax,%eax 0x00007fdcb87190ce: jne 0x00007fdcb87190b0 This produces 891.427 +- 15.277 ns/op: 3.52% 0.02% 0x00007ffa3918f030: mov (%rsp),%r10 0x00007ffa3918f034: mov 0xc(%r10),%r10d 0.07% 0x00007ffa3918f038: mov %r10d,0xc(%rbp) 3.68% 0x00007ffa3918f03c: lock addl $0x0,-0x48(%rsp) 76.54% 97.13% 0x00007ffa3918f042: mov %rbp,%rsi 0x00007ffa3918f045: xchg %ax,%ax 0x00007ffa3918f047: callq 0x00007ffa39045fe0 0x00007ffa3918f04c: test %eax,%eax 0x00007ffa3918f04e: jne 0x00007ffa3918f030 Full logs here: http://cr.openjdk.java.net/~shade/8050147/haswell-barrier2.perfasm http://cr.openjdk.java.net/~shade/8050147/haswell-barrier3.perfasm It is puzzling to me why do we have the difference here. In the logs there, you may see the second-hottest method, looping(), which is called in this busy loop. It does: 2.60% 0x00007fdcb871b200: sub $0x18,%rsp 0x00007fdcb871b207: mov %rbp,0x10(%rsp) ...which seems to callee-save %rbp to (%rsp-8)? Any pointers how we manage the stack in callees? It would seem we need to step back more than -8 to dodge callee-saves, but how much? It seems odd this affects Haswell so much. I've checked on my SandyBridge laptop, and we have the same code, but performance is consistent. Barring that, it would seem like some the second-order microarchitectural effect on Haswell. ...which makes me say this is the mode we should switch to: > ...or "lock addl (%esp-CL-8), 0), pessimistically padding away from > stack users: > http://cr.openjdk.java.net/~shade/8050147/webrev.02/ Thanks, -Aleksey. From david.r.chase at oracle.com Wed Jul 23 19:30:30 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 23 Jul 2014 15:30:30 -0400 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53CFF7C8.3090207@oracle.com> References: <53CF98B1.9070508@oracle.com> <53CFF7C8.3090207@oracle.com> Message-ID: <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> Vladimir, I think the mistake is instead to include the cast to the type that it already is. I think performing the cast to the union type from a non-union address might get you a warning otherwise. I can confirm that if you write it plainly with the assignment to a correctly typed ?conv? that clang (at least) generates good code: union ca { double d; int i[2]; }; int la(double d) { union ca x = { d } ; return x.i[0]; } clang produces (-O3 -S, cleaned up) _la: ## @la pushq %rbp movq %rsp, %rbp movd %xmm0, %rax popq %rbp ret gcc 4.8.1 produces (-O4 -S, cleaned up) la: movsd %xmm0, -8(%rsp) movq -8(%rsp), %rax ret So I think this is generally a good idea, but the macro should be cleaned up to remove the cast that is certainly unnecessary now. E.g. 39 #ifdef VM_LITTLE_ENDIAN 40 # define __HI(x) ((x).i[1]) 41 # define __LO(x) ((x).i[0]) 42 #else 43 # define __HI(x) (x.i[0]) 44 # define __LO(x) (x.i[1]) 45 #endif The temporary is only annoying to humans using a last-millenium dialect of C. The code runs fast, and the address-of+dereference in the macro forced it to memory (lacking a lot of alias analysis) anyhow. David On Jul 23, 2014, at 1:58 PM, Vladimir Kozlov wrote: > Tobias, why you are creating local copy 'conv' of a variable in all places? > > Vladimir > > On 7/23/14 4:12 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch for JDK- 8049043 (Parfait warning). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >> Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ >> >> Problem: >> Parfait issues 6 warnings " Load variable through a pointer of an >> incompatible type" because of the __HI(x) and __LO(x) macros used in >> copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) to cast >> between double* and int*. >> >> Solution: >> A union 'DoubleIntConv' is used to access the high and low 32 bits of a >> double. >> The '# pragma warning( disable: 4748 )' in sharedRuntimeTrans.cpp is >> necessary because otherwise the VS compiler fails with the following >> warning: "/GS can not protect parameters and local variables from local >> buffer overrun because optimizations are disabled in function". There >> exists a bug to fix this [1]. >> >> Testing: >> JPRT, Parfait (all 6 warnings removed) >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8046696 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Wed Jul 23 19:37:21 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jul 2014 12:37:21 -0700 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> References: <53CF98B1.9070508@oracle.com> <53CFF7C8.3090207@oracle.com> <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> Message-ID: <53D00EF1.7010506@oracle.com> David, I agree with your suggestion to pass union to _HI and _LO. The creation of a local union var makes sense then. Thanks, Vladimir On 7/23/14 12:30 PM, David Chase wrote: > Vladimir, I think the mistake is instead to include the cast to the type > that it already is. > I think performing the cast to the union type from a non-union address > might get you a warning otherwise. > I can confirm that if you write it plainly with the assignment to a > correctly typed ?conv? > that clang (at least) generates good code: > > union ca { > double d; > int i[2]; > }; > > int la(double d) { > union ca x = { d } ; > return x.i[0]; > } > > clang produces (-O3 -S, cleaned up) > > _la: ## @la > pushq %rbp > movq %rsp, %rbp > movd %xmm0, %rax > popq %rbp > ret > gcc 4.8.1 produces (-O4 -S, cleaned up) > > la: > movsd%xmm0, -8(%rsp) > movq-8(%rsp), %rax > ret > > So I think this is generally a good idea, but the macro should be > cleaned up to > remove the cast that is certainly unnecessary now. E.g. > > 39 #ifdef VM_LITTLE_ENDIAN > 40 # define __HI(x) ((x).i[1]) > 41 # define __LO(x) ((x).i[0]) > 42 #else > 43 # define __HI(x) (x.i[0]) > 44 # define __LO(x) (x.i[1]) > 45 #endif > > The temporary is only annoying to humans using a last-millenium dialect > of C. The code runs fast, and the address-of+dereference in the macro > forced it to memory (lacking a lot of alias analysis) anyhow. > > David > > > On Jul 23, 2014, at 1:58 PM, Vladimir Kozlov > wrote: > >> Tobias, why you are creating local copy 'conv' of a variable in all >> places? >> >> Vladimir >> >> On 7/23/14 4:12 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch for JDK- 8049043 (Parfait warning). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ >>> >>> Problem: >>> Parfait issues 6 warnings " Load variable through a pointer of an >>> incompatible type" because of the __HI(x) and __LO(x) macros used in >>> copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) to cast >>> between double* and int*. >>> >>> Solution: >>> A union 'DoubleIntConv' is used to access the high and low 32 bits of a >>> double. >>> The '# pragma warning( disable: 4748 )' in sharedRuntimeTrans.cpp is >>> necessary because otherwise the VS compiler fails with the following >>> warning: "/GS can not protect parameters and local variables from local >>> buffer overrun because optimizations are disabled in function". There >>> exists a bug to fix this [1]. >>> >>> Testing: >>> JPRT, Parfait (all 6 warnings removed) >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8046696 > From david.r.chase at oracle.com Wed Jul 23 19:43:24 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 23 Jul 2014 15:43:24 -0400 Subject: [8u backport] RFR(XS): 8051803 [parfait] warnings from b114 for hotspot.src.share.vm Message-ID: <5EE8F785-D437-4E90-A3C7-995525F65C49@oracle.com> Summary: it?s a parfait warning, where convoluted and perhaps delicate logic ensures that a NULL could ?never? appear. Fix is to insert a null check and return the ?nothing here? result (false) which (a) should never occur anyhow and (b) is safe and consistent behavior. webrev: http://cr.openjdk.java.net/~drchase/8051803/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8051803 backport of: https://bugs.openjdk.java.net/browse/JDK-8028037 old review discussion: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-March/013684.html testing: local jtreg David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From david.r.chase at oracle.com Wed Jul 23 20:00:42 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 23 Jul 2014 16:00:42 -0400 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53D00EF1.7010506@oracle.com> References: <53CF98B1.9070508@oracle.com> <53CFF7C8.3090207@oracle.com> <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> <53D00EF1.7010506@oracle.com> Message-ID: It occurred to me that a cleaner way is to put the ifdef in the definition of the union: typedef union { double d; struct { #ifdef VM_LITTLE_ENDIAN int lo; int hi; #else int hi; int lo; #endif }; } DoubleIntConv; # define __HI(x) (x.hi) # define __LO(x) (x.lo) At which point, the continued use of the macro starts to look perhaps a hair silly. I was inspired to write the following test program and compile it under clang and gcc (but not under Solaris Studio yet) to see if we could instead just write a stinking static method (that would be inlined) and at clang -O3 and gcc -O4, it was indeed inlined. So we could just write clean code and to heck with the macro. (Aren?t you loving this review process? :-) We would, however, suffer some slowdown in slowdebug builds. ---------------------- #define VM_LITTLE_ENDIAN 1 typedef union { double d; struct { #ifdef VM_LITTLE_ENDIAN int lo; int hi; #else int hi; int lo; #endif }; } DoubleIntConv; # define __HI(x) (x.hi) # define __LO(x) (x.lo) static int inline_low(double d) { DoubleIntConv x = { d } ; return __LO(x); } static int inline_high(double d) { DoubleIntConv x = { d } ; return __HI(x); } int low(double d) { return inline_low(d); } int high(double d) { return inline_high(d); } ---------------------- On Jul 23, 2014, at 3:37 PM, Vladimir Kozlov wrote: > David, I agree with your suggestion to pass union to _HI and _LO. The creation of a local union var makes sense then. > > Thanks, > Vladimir > > On 7/23/14 12:30 PM, David Chase wrote: >> Vladimir, I think the mistake is instead to include the cast to the type >> that it already is. >> I think performing the cast to the union type from a non-union address >> might get you a warning otherwise. >> I can confirm that if you write it plainly with the assignment to a >> correctly typed ?conv? >> that clang (at least) generates good code: >> >> union ca { >> double d; >> int i[2]; >> }; >> >> int la(double d) { >> union ca x = { d } ; >> return x.i[0]; >> } >> >> clang produces (-O3 -S, cleaned up) >> >> _la: ## @la >> pushq %rbp >> movq %rsp, %rbp >> movd %xmm0, %rax >> popq %rbp >> ret >> gcc 4.8.1 produces (-O4 -S, cleaned up) >> >> la: >> movsd%xmm0, -8(%rsp) >> movq-8(%rsp), %rax >> ret >> >> So I think this is generally a good idea, but the macro should be >> cleaned up to >> remove the cast that is certainly unnecessary now. E.g. >> >> 39 #ifdef VM_LITTLE_ENDIAN >> 40 # define __HI(x) ((x).i[1]) >> 41 # define __LO(x) ((x).i[0]) >> 42 #else >> 43 # define __HI(x) (x.i[0]) >> 44 # define __LO(x) (x.i[1]) >> 45 #endif >> >> The temporary is only annoying to humans using a last-millenium dialect >> of C. The code runs fast, and the address-of+dereference in the macro >> forced it to memory (lacking a lot of alias analysis) anyhow. >> >> David >> >> >> On Jul 23, 2014, at 1:58 PM, Vladimir Kozlov > > wrote: >> >>> Tobias, why you are creating local copy 'conv' of a variable in all >>> places? >>> >>> Vladimir >>> >>> On 7/23/14 4:12 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch for JDK- 8049043 (Parfait warning). >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ >>>> >>>> Problem: >>>> Parfait issues 6 warnings " Load variable through a pointer of an >>>> incompatible type" because of the __HI(x) and __LO(x) macros used in >>>> copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) to cast >>>> between double* and int*. >>>> >>>> Solution: >>>> A union 'DoubleIntConv' is used to access the high and low 32 bits of a >>>> double. >>>> The '# pragma warning( disable: 4748 )' in sharedRuntimeTrans.cpp is >>>> necessary because otherwise the VS compiler fails with the following >>>> warning: "/GS can not protect parameters and local variables from local >>>> buffer overrun because optimizations are disabled in function". There >>>> exists a bug to fix this [1]. >>>> >>>> Testing: >>>> JPRT, Parfait (all 6 warnings removed) >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8046696 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Wed Jul 23 20:55:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jul 2014 13:55:00 -0700 Subject: [8u backport] RFR(XS): 8051803 [parfait] warnings from b114 for hotspot.src.share.vm In-Reply-To: <5EE8F785-D437-4E90-A3C7-995525F65C49@oracle.com> References: <5EE8F785-D437-4E90-A3C7-995525F65C49@oracle.com> Message-ID: <53D02124.1060508@oracle.com> Changes are good. David, you should use only original bug id in Subject and in the request text (nobody care about backport bug id). Also you have to point jdk9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/de9cd35a3d1f And you should say if you need to change the fix for 8u or it is applied (hg export/import) cleanly. And backport it using hg export/import. Thanks, Vladimir On 7/23/14 12:43 PM, David Chase wrote: > Summary: it?s a parfait warning, where convoluted and perhaps delicate logic ensures that a NULL could ?never? appear. > Fix is to insert a null check and return the ?nothing here? result (false) which (a) should never occur anyhow and > (b) is safe and consistent behavior. > > webrev: http://cr.openjdk.java.net/~drchase/8051803/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8051803 > > backport of: https://bugs.openjdk.java.net/browse/JDK-8028037 > > old review discussion: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-March/013684.html > > testing: local jtreg > > David > From david.r.chase at oracle.com Wed Jul 23 21:05:22 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 23 Jul 2014 17:05:22 -0400 Subject: [8u backport] RFR(XS): 8051803 [parfait] warnings from b114 for hotspot.src.share.vm In-Reply-To: <53D02124.1060508@oracle.com> References: <5EE8F785-D437-4E90-A3C7-995525F65C49@oracle.com> <53D02124.1060508@oracle.com> Message-ID: On Jul 23, 2014, at 4:55 PM, Vladimir Kozlov wrote: > Changes are good. > > David, you should use only original bug id in Subject and in the request text (nobody care about backport bug id). Also you have to point jdk9 changeset: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/de9cd35a3d1f > > And you should say if you need to change the fix for 8u or it is applied (hg export/import) cleanly. And backport it using hg export/import. The old change set applied clean. So how would you phrase the Subject? Like this? (Literal copy of old subject appended to [8u backport] ) [8u backport] RFR (XS): 8028037: "[parfait] warnings from b114 for hotspot.src.share.vm " David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Wed Jul 23 21:12:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jul 2014 14:12:56 -0700 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: References: <53CF98B1.9070508@oracle.com> <53CFF7C8.3090207@oracle.com> <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> <53D00EF1.7010506@oracle.com> Message-ID: <53D02558.5040801@oracle.com> Or you can use union with jlong and don't mess with ENDIAN at all. 64-bit is now main platform now. Vladimir On 7/23/14 1:00 PM, David Chase wrote: > It occurred to me that a cleaner way is to put the ifdef in the definition of the union: > > typedef union { > double d; > struct { > #ifdef VM_LITTLE_ENDIAN > int lo; > int hi; > #else > int hi; > int lo; > #endif > }; > } DoubleIntConv; > > # define __HI(x) (x.hi) > # define __LO(x) (x.lo) > > At which point, the continued use of the macro starts to look perhaps a hair silly. > > I was inspired to write the following test program and compile it under clang and gcc (but not under Solaris Studio yet) to see if we could instead just write a stinking static method (that would be inlined) and at clang -O3 and gcc -O4, it was indeed inlined. So we could just write clean code and to heck with the macro. (Aren?t you loving this review process? :-) > > We would, however, suffer some slowdown in slowdebug builds. > ---------------------- > #define VM_LITTLE_ENDIAN 1 > typedef union { > double d; > struct { > #ifdef VM_LITTLE_ENDIAN > int lo; > int hi; > #else > int hi; > int lo; > #endif > }; > } DoubleIntConv; > > # define __HI(x) (x.hi) > # define __LO(x) (x.lo) > > static int inline_low(double d) { > DoubleIntConv x = { d } ; > return __LO(x); > } > > static int inline_high(double d) { > DoubleIntConv x = { d } ; > return __HI(x); > } > > int low(double d) { > return inline_low(d); > } > > int high(double d) { > return inline_high(d); > } > ---------------------- > > > > On Jul 23, 2014, at 3:37 PM, Vladimir Kozlov wrote: > >> David, I agree with your suggestion to pass union to _HI and _LO. The creation of a local union var makes sense then. >> >> Thanks, >> Vladimir >> >> On 7/23/14 12:30 PM, David Chase wrote: >>> Vladimir, I think the mistake is instead to include the cast to the type >>> that it already is. >>> I think performing the cast to the union type from a non-union address >>> might get you a warning otherwise. >>> I can confirm that if you write it plainly with the assignment to a >>> correctly typed ?conv? >>> that clang (at least) generates good code: >>> >>> union ca { >>> double d; >>> int i[2]; >>> }; >>> >>> int la(double d) { >>> union ca x = { d } ; >>> return x.i[0]; >>> } >>> >>> clang produces (-O3 -S, cleaned up) >>> >>> _la: ## @la >>> pushq %rbp >>> movq %rsp, %rbp >>> movd %xmm0, %rax >>> popq %rbp >>> ret >>> gcc 4.8.1 produces (-O4 -S, cleaned up) >>> >>> la: >>> movsd%xmm0, -8(%rsp) >>> movq-8(%rsp), %rax >>> ret >>> >>> So I think this is generally a good idea, but the macro should be >>> cleaned up to >>> remove the cast that is certainly unnecessary now. E.g. >>> >>> 39 #ifdef VM_LITTLE_ENDIAN >>> 40 # define __HI(x) ((x).i[1]) >>> 41 # define __LO(x) ((x).i[0]) >>> 42 #else >>> 43 # define __HI(x) (x.i[0]) >>> 44 # define __LO(x) (x.i[1]) >>> 45 #endif >>> >>> The temporary is only annoying to humans using a last-millenium dialect >>> of C. The code runs fast, and the address-of+dereference in the macro >>> forced it to memory (lacking a lot of alias analysis) anyhow. >>> >>> David >>> >>> >>> On Jul 23, 2014, at 1:58 PM, Vladimir Kozlov >> > wrote: >>> >>>> Tobias, why you are creating local copy 'conv' of a variable in all >>>> places? >>>> >>>> Vladimir >>>> >>>> On 7/23/14 4:12 AM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch for JDK- 8049043 (Parfait warning). >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ >>>>> >>>>> Problem: >>>>> Parfait issues 6 warnings " Load variable through a pointer of an >>>>> incompatible type" because of the __HI(x) and __LO(x) macros used in >>>>> copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) to cast >>>>> between double* and int*. >>>>> >>>>> Solution: >>>>> A union 'DoubleIntConv' is used to access the high and low 32 bits of a >>>>> double. >>>>> The '# pragma warning( disable: 4748 )' in sharedRuntimeTrans.cpp is >>>>> necessary because otherwise the VS compiler fails with the following >>>>> warning: "/GS can not protect parameters and local variables from local >>>>> buffer overrun because optimizations are disabled in function". There >>>>> exists a bug to fix this [1]. >>>>> >>>>> Testing: >>>>> JPRT, Parfait (all 6 warnings removed) >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8046696 > From vladimir.kozlov at oracle.com Wed Jul 23 21:22:08 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jul 2014 14:22:08 -0700 Subject: [8u backport] RFR(XS): 8051803 [parfait] warnings from b114 for hotspot.src.share.vm In-Reply-To: References: <5EE8F785-D437-4E90-A3C7-995525F65C49@oracle.com> <53D02124.1060508@oracle.com> Message-ID: <53D02780.3070803@oracle.com> On 7/23/14 2:05 PM, David Chase wrote: > > On Jul 23, 2014, at 4:55 PM, Vladimir Kozlov wrote: > >> Changes are good. >> >> David, you should use only original bug id in Subject and in the request text (nobody care about backport bug id). Also you have to point jdk9 changeset: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/de9cd35a3d1f >> >> And you should say if you need to change the fix for 8u or it is applied (hg export/import) cleanly. And backport it using hg export/import. > > The old change set applied clean. Good. > > So how would you phrase the Subject? Like this? (Literal copy of old subject appended to [8u backport] ) > > [8u backport] RFR (XS): 8028037: "[parfait] warnings from b114 for hotspot.src.share.vm " > > David > Yes, I usually use Subject from the original RFR and add [8u] prefix to it: [8u] RFR (XS): 8028037: "[parfait] warnings from b114 for hotspot.src.share.vm " Tobias is using [9] for current jdk9 code fixes which may be a good idea too. Vladimir From tobias.hartmann at oracle.com Thu Jul 24 09:47:48 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 24 Jul 2014 11:47:48 +0200 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53D02558.5040801@oracle.com> References: <53CF98B1.9070508@oracle.com> <53CFF7C8.3090207@oracle.com> <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> <53D00EF1.7010506@oracle.com> <53D02558.5040801@oracle.com> Message-ID: <53D0D644.1020100@oracle.com> Hi, Vladimir, David, thanks for the review. Please see comments inline. >> Tobias, why you are creating local copy 'conv' of a variable in all >> places? Doing it like this __HI(x) = (__HI(x)&0x7fffffff)|(__HI(y)&0x80000000); return x; Parfait still complained that a 32 bit value is assigned to x and it is then used as a 64 bit value. That's why I had to create a local copy of 'conv'. On 23.07.2014 21:30, David Chase wrote: > Vladimir, I think the mistake is instead to include the cast to the > type that it already is. True, the cast is not necessary. On 23.07.2014 23:12, Vladimir Kozlov wrote: > Or you can use union with jlong and don't mess with ENDIAN at all. > 64-bit is now main platform now. > > Vladimir How do we access the low and high bits then? > On 7/23/14 1:00 PM, David Chase wrote: >> It occurred to me that a cleaner way is to put the ifdef in the >> definition of the union: >> >> typedef union { >> double d; >> struct { >> #ifdef VM_LITTLE_ENDIAN >> int lo; >> int hi; >> #else >> int hi; >> int lo; >> #endif >> }; >> } DoubleIntConv; >> >> # define __HI(x) (x.hi) >> # define __LO(x) (x.lo) >> >> At which point, the continued use of the macro starts to look perhaps >> a hair silly. >> >> I was inspired to write the following test program and compile it >> under clang and gcc (but not under Solaris Studio yet) to see if we >> could instead just write a stinking static method (that would be >> inlined) and at clang -O3 and gcc -O4, it was indeed inlined. So we >> could just write clean code and to heck with the macro. I like this solution because in my opinion it is the most readable one and it is always a good idea to remove ugly macros. If the potential slowdown in slowdebug builds is not a problem I would like to stick to this. I removed the macros and changed all parts of the code that used them (unfortunately quite a lot). The parfait warnings in the files sharedRuntimeMath.hpp, sharedRutimeTrans.cpp and sharedRuntimeTrigg.cpp were reduced by 12. New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.02 The problem with this solution is that some of the compilers do not support anonymous structs. We could name the struct and access it via the name, for example like this: typedef union { double d; struct { #ifdef VM_LITTLE_ENDIAN int lo; int hi; #else int hi; int lo; #endif } i; } DoubleIntConv; DoubleIntConv conv = { x }; int high = conv.i.hi; But that does not really improve code readability... What do you think? Thanks, Tobias >> (Aren?t you loving this review process? :-) Yes, thanks for all the testing :) Best, Tobias >> >> We would, however, suffer some slowdown in slowdebug builds. >> ---------------------- >> #define VM_LITTLE_ENDIAN 1 >> typedef union { >> double d; >> struct { >> #ifdef VM_LITTLE_ENDIAN >> int lo; >> int hi; >> #else >> int hi; >> int lo; >> #endif >> }; >> } DoubleIntConv; >> >> # define __HI(x) (x.hi) >> # define __LO(x) (x.lo) >> >> static int inline_low(double d) { >> DoubleIntConv x = { d } ; >> return __LO(x); >> } >> >> static int inline_high(double d) { >> DoubleIntConv x = { d } ; >> return __HI(x); >> } >> >> int low(double d) { >> return inline_low(d); >> } >> >> int high(double d) { >> return inline_high(d); >> } >> ---------------------- >> >> >> >> On Jul 23, 2014, at 3:37 PM, Vladimir Kozlov >> wrote: >> >>> David, I agree with your suggestion to pass union to _HI and _LO. >>> The creation of a local union var makes sense then. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/23/14 12:30 PM, David Chase wrote: >>>> Vladimir, I think the mistake is instead to include the cast to the >>>> type >>>> that it already is. >>>> I think performing the cast to the union type from a non-union address >>>> might get you a warning otherwise. >>>> I can confirm that if you write it plainly with the assignment to a >>>> correctly typed ?conv? >>>> that clang (at least) generates good code: >>>> >>>> union ca { >>>> double d; >>>> int i[2]; >>>> }; >>>> >>>> int la(double d) { >>>> union ca x = { d } ; >>>> return x.i[0]; >>>> } >>>> >>>> clang produces (-O3 -S, cleaned up) >>>> >>>> _la: ## @la >>>> pushq %rbp >>>> movq %rsp, %rbp >>>> movd %xmm0, %rax >>>> popq %rbp >>>> ret >>>> gcc 4.8.1 produces (-O4 -S, cleaned up) >>>> >>>> la: >>>> movsd%xmm0, -8(%rsp) >>>> movq-8(%rsp), %rax >>>> ret >>>> >>>> So I think this is generally a good idea, but the macro should be >>>> cleaned up to >>>> remove the cast that is certainly unnecessary now. E.g. >>>> >>>> 39 #ifdef VM_LITTLE_ENDIAN >>>> 40 # define __HI(x) ((x).i[1]) >>>> 41 # define __LO(x) ((x).i[0]) >>>> 42 #else >>>> 43 # define __HI(x) (x.i[0]) >>>> 44 # define __LO(x) (x.i[1]) >>>> 45 #endif >>>> >>>> The temporary is only annoying to humans using a last-millenium >>>> dialect >>>> of C. The code runs fast, and the address-of+dereference in the macro >>>> forced it to memory (lacking a lot of alias analysis) anyhow. >>>> >>>> David >>>> >>>> >>>> On Jul 23, 2014, at 1:58 PM, Vladimir Kozlov >>>> >>> > wrote: >>>> >>>>> Tobias, why you are creating local copy 'conv' of a variable in all >>>>> places? >>>>> >>>>> Vladimir >>>>> >>>>> On 7/23/14 4:12 AM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch for JDK- 8049043 (Parfait >>>>>> warning). >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ >>>>>> >>>>>> Problem: >>>>>> Parfait issues 6 warnings " Load variable through a pointer of an >>>>>> incompatible type" because of the __HI(x) and __LO(x) macros used in >>>>>> copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) to >>>>>> cast >>>>>> between double* and int*. >>>>>> >>>>>> Solution: >>>>>> A union 'DoubleIntConv' is used to access the high and low 32 >>>>>> bits of a >>>>>> double. >>>>>> The '# pragma warning( disable: 4748 )' in sharedRuntimeTrans.cpp is >>>>>> necessary because otherwise the VS compiler fails with the following >>>>>> warning: "/GS can not protect parameters and local variables from >>>>>> local >>>>>> buffer overrun because optimizations are disabled in function". >>>>>> There >>>>>> exists a bug to fix this [1]. >>>>>> >>>>>> Testing: >>>>>> JPRT, Parfait (all 6 warnings removed) >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8046696 >> From tobias.hartmann at oracle.com Thu Jul 24 11:55:28 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 24 Jul 2014 13:55:28 +0200 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53D0D644.1020100@oracle.com> References: <53CF98B1.9070508@oracle.com> <53CFF7C8.3090207@oracle.com> <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> <53D00EF1.7010506@oracle.com> <53D02558.5040801@oracle.com> <53D0D644.1020100@oracle.com> Message-ID: <53D0F430.6060504@oracle.com> Hi, I refactored the code and added set_high(..) and set_low(..) methods (similar to the ones defined in globalDefinitions.hpp). New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.03 Testing: Parfait, JPRT Thanks, Tobias On 24.07.2014 11:47, Tobias Hartmann wrote: > Hi, > > Vladimir, David, thanks for the review. Please see comments inline. > >>> Tobias, why you are creating local copy 'conv' of a variable in all >>> places? > > Doing it like this > > __HI(x) = (__HI(x)&0x7fffffff)|(__HI(y)&0x80000000); > return x; > > Parfait still complained that a 32 bit value is assigned to x and it > is then used as a 64 bit value. That's why I had to create a local > copy of 'conv'. > > On 23.07.2014 21:30, David Chase wrote: >> Vladimir, I think the mistake is instead to include the cast to the >> type that it already is. > > True, the cast is not necessary. > > On 23.07.2014 23:12, Vladimir Kozlov wrote: >> Or you can use union with jlong and don't mess with ENDIAN at all. >> 64-bit is now main platform now. >> >> Vladimir > > How do we access the low and high bits then? > >> On 7/23/14 1:00 PM, David Chase wrote: >>> It occurred to me that a cleaner way is to put the ifdef in the >>> definition of the union: >>> >>> typedef union { >>> double d; >>> struct { >>> #ifdef VM_LITTLE_ENDIAN >>> int lo; >>> int hi; >>> #else >>> int hi; >>> int lo; >>> #endif >>> }; >>> } DoubleIntConv; >>> >>> # define __HI(x) (x.hi) >>> # define __LO(x) (x.lo) >>> >>> At which point, the continued use of the macro starts to look >>> perhaps a hair silly. >>> >>> I was inspired to write the following test program and compile it >>> under clang and gcc (but not under Solaris Studio yet) to see if we >>> could instead just write a stinking static method (that would be >>> inlined) and at clang -O3 and gcc -O4, it was indeed inlined. So we >>> could just write clean code and to heck with the macro. > > I like this solution because in my opinion it is the most readable one > and it is always a good idea to remove ugly macros. If the potential > slowdown in slowdebug builds is not a problem I would like to stick to > this. > > I removed the macros and changed all parts of the code that used them > (unfortunately quite a lot). > > The parfait warnings in the files sharedRuntimeMath.hpp, > sharedRutimeTrans.cpp and sharedRuntimeTrigg.cpp were reduced by 12. > > New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.02 > > The problem with this solution is that some of the compilers do not > support anonymous structs. We could name the struct and access it via > the name, for example like this: > > typedef union { > double d; > struct { > #ifdef VM_LITTLE_ENDIAN > int lo; > int hi; > #else > int hi; > int lo; > #endif > } i; > } DoubleIntConv; > > DoubleIntConv conv = { x }; > int high = conv.i.hi; > > But that does not really improve code readability... What do you think? > > Thanks, > Tobias > >>> (Aren?t you loving this review process? :-) > > Yes, thanks for all the testing :) > > Best, > Tobias > >>> >>> We would, however, suffer some slowdown in slowdebug builds. >>> ---------------------- >>> #define VM_LITTLE_ENDIAN 1 >>> typedef union { >>> double d; >>> struct { >>> #ifdef VM_LITTLE_ENDIAN >>> int lo; >>> int hi; >>> #else >>> int hi; >>> int lo; >>> #endif >>> }; >>> } DoubleIntConv; >>> >>> # define __HI(x) (x.hi) >>> # define __LO(x) (x.lo) >>> >>> static int inline_low(double d) { >>> DoubleIntConv x = { d } ; >>> return __LO(x); >>> } >>> >>> static int inline_high(double d) { >>> DoubleIntConv x = { d } ; >>> return __HI(x); >>> } >>> >>> int low(double d) { >>> return inline_low(d); >>> } >>> >>> int high(double d) { >>> return inline_high(d); >>> } >>> ---------------------- >>> >>> >>> >>> On Jul 23, 2014, at 3:37 PM, Vladimir Kozlov >>> wrote: >>> >>>> David, I agree with your suggestion to pass union to _HI and _LO. >>>> The creation of a local union var makes sense then. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/23/14 12:30 PM, David Chase wrote: >>>>> Vladimir, I think the mistake is instead to include the cast to >>>>> the type >>>>> that it already is. >>>>> I think performing the cast to the union type from a non-union >>>>> address >>>>> might get you a warning otherwise. >>>>> I can confirm that if you write it plainly with the assignment to a >>>>> correctly typed ?conv? >>>>> that clang (at least) generates good code: >>>>> >>>>> union ca { >>>>> double d; >>>>> int i[2]; >>>>> }; >>>>> >>>>> int la(double d) { >>>>> union ca x = { d } ; >>>>> return x.i[0]; >>>>> } >>>>> >>>>> clang produces (-O3 -S, cleaned up) >>>>> >>>>> _la: ## @la >>>>> pushq %rbp >>>>> movq %rsp, %rbp >>>>> movd %xmm0, %rax >>>>> popq %rbp >>>>> ret >>>>> gcc 4.8.1 produces (-O4 -S, cleaned up) >>>>> >>>>> la: >>>>> movsd%xmm0, -8(%rsp) >>>>> movq-8(%rsp), %rax >>>>> ret >>>>> >>>>> So I think this is generally a good idea, but the macro should be >>>>> cleaned up to >>>>> remove the cast that is certainly unnecessary now. E.g. >>>>> >>>>> 39 #ifdef VM_LITTLE_ENDIAN >>>>> 40 # define __HI(x) ((x).i[1]) >>>>> 41 # define __LO(x) ((x).i[0]) >>>>> 42 #else >>>>> 43 # define __HI(x) (x.i[0]) >>>>> 44 # define __LO(x) (x.i[1]) >>>>> 45 #endif >>>>> >>>>> The temporary is only annoying to humans using a last-millenium >>>>> dialect >>>>> of C. The code runs fast, and the address-of+dereference in the >>>>> macro >>>>> forced it to memory (lacking a lot of alias analysis) anyhow. >>>>> >>>>> David >>>>> >>>>> >>>>> On Jul 23, 2014, at 1:58 PM, Vladimir Kozlov >>>>> >>>> > wrote: >>>>> >>>>>> Tobias, why you are creating local copy 'conv' of a variable in all >>>>>> places? >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 7/23/14 4:12 AM, Tobias Hartmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review the following patch for JDK- 8049043 (Parfait >>>>>>> warning). >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ >>>>>>> >>>>>>> Problem: >>>>>>> Parfait issues 6 warnings " Load variable through a pointer of an >>>>>>> incompatible type" because of the __HI(x) and __LO(x) macros >>>>>>> used in >>>>>>> copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) >>>>>>> to cast >>>>>>> between double* and int*. >>>>>>> >>>>>>> Solution: >>>>>>> A union 'DoubleIntConv' is used to access the high and low 32 >>>>>>> bits of a >>>>>>> double. >>>>>>> The '# pragma warning( disable: 4748 )' in >>>>>>> sharedRuntimeTrans.cpp is >>>>>>> necessary because otherwise the VS compiler fails with the >>>>>>> following >>>>>>> warning: "/GS can not protect parameters and local variables >>>>>>> from local >>>>>>> buffer overrun because optimizations are disabled in function". >>>>>>> There >>>>>>> exists a bug to fix this [1]. >>>>>>> >>>>>>> Testing: >>>>>>> JPRT, Parfait (all 6 warnings removed) >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8046696 >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Thu Jul 24 12:01:54 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 24 Jul 2014 14:01:54 +0200 Subject: [9] RFR(M): 8040213: C2 does not put all modified nodes on IGVN worklist In-Reply-To: <53CFC828.4040106@oracle.com> References: <53B64ECD.3060300@oracle.com> <53BF2A98.30803@oracle.com> <53BF83FA.3040908@oracle.com> <53C53851.5060404@oracle.com> <84D8E326-AB46-4F71-B4E1-E020E3C27D8B@oracle.com> <53C7A808.6040807@oracle.com> <53C84EEA.3000508@oracle.com> <53CCE27B.4010102@oracle.com> <53CD4A4D.2020504@oracle.com> <53CE1DA6.10301@oracle.com> <53CE9D5F.7000407@oracle.com> <53CFAEBA.3050204@oracle.com> <53CFC828.4040106@oracle.com> Message-ID: <53D0F5B2.8060808@oracle.com> Thank you, Vladimir. Best, Tobias On 23.07.2014 16:35, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 7/23/14 5:46 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >> On 22.07.2014 19:20, Vladimir Kozlov wrote: >>> C->modified_nodes() is called only from debug code so you can >>> simplify it by putting whole method inside DEBUG_ONLY() >>> instead of different return: >>> >>> DEBUG_ONLY( Unique_Node_List* modified_nodes() const { return >>> _modified_nodes; } ) >> >> Done: http://cr.openjdk.java.net/~thartmann/8040213/webrev.05/ >> >> Thanks, >> Tobias >> >>> >>> Otherwise look good. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/22/14 1:15 AM, Tobias Hartmann wrote: >>>> Hi Vladimir, >>>> >>>> On 21.07.2014 19:13, Vladimir Kozlov wrote: >>>>> > Thanks for the hint, the optimized build did not work. I'm now >>>>> using >>>>> > PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. >>>>> This is >>>>> > consistent with other verification methods like >>>>> > Compile::verify_graph_edges(..). >>>>> >>>>> The logic which verifies modified nodes in phaseX.cpp is under #ifdef >>>>> ASSERT. Yes, you are not collecting data in optimized VM by returning >>>>> NULL from modified_nodes(). But it is very confusing. I would suggest >>>>> to move all this code to debug build only. You can use >>>>> NOT_DEBUG_RETURN instead of PRODUCT_RETURN and put definitions under >>>>> #ifdef ASSERT in compile.cpp file. >>>> >>>> Okay, that's true. I missed that there is a NOT_DEBUG_RETURN. Now >>>> using it. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.04/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 7/21/14 2:50 AM, Tobias Hartmann wrote: >>>>>> Vladimir, John, thanks for the review. >>>>>> >>>>>> On 18.07.2014 01:32, John Rose wrote: >>>>>>> On Jul 17, 2014, at 3:32 PM, Vladimir Kozlov >>>>>>> wrote: >>>>>>> >>>>>>>> Initial prototype was written by me so part of changes are mine. >>>>>>>> >>>>>>>> On 7/17/14 3:40 AM, Tobias Hartmann wrote: >>>>>>>>> Hi John, >>>>>>>>> >>>>>>>>> thanks a lot for the detailed review! Please see comments inline. >>>>>>>>> >>>>>>>>> On 16.07.2014 01:10, John Rose wrote: >>>>>>>>>>>> Done. New webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.01/ >>>>>>>>>> Loading C->_modified_nodes with a stack address is bad news, >>>>>>>>>> even if >>>>>>>>>> the code apparently cleans it up on exit. (I say "apparently" >>>>>>>>>> because >>>>>>>>>> there are early exits from that block, and the cleanup is not >>>>>>>>>> RAII >>>>>>>>>> style.) I strongly suggest heap allocation instead of stack >>>>>>>>>> allocation; it's expensive but it's for debug code. >>>>>>>> The list array allocation is done in compiler arena which is >>>>>>>> cleaned >>>>>>>> after compilation finished by ResourceMark, only descriptor is on >>>>>>>> stack: >>>>>>>> >>>>>>>> + Unique_Node_List modified_nodes(comp_arena()); >>>>>>>> >>>>>>>> It is our normal style. We do it a lot, see Compile::Code_Gen(). >>>>>>> Yes, we do it when adding phase control blocks to the Compile >>>>>>> object, >>>>>>> within the tree of calls rooted at the constructor. I see that the >>>>>>> new code is arguably part of that pattern. I hope that is an >>>>>>> exceptional use of this style? >>>>>>> >>>>>>> Note that C2Compiler::compile_method creates the Compile object and >>>>>>> then queries it. When it queries it, the Compile object may >>>>>>> contain >>>>>>> dangling pointers into phase control blocks stored on the stack >>>>>>> (during subroutine calls like Code_Gen) but now deallocated. >>>>>>> >>>>>>> It seems to me that we avoid touching those dangling pointers by >>>>>>> simple will power and discipline. Such a style doesn't scale, >>>>>>> since >>>>>>> it's too easy to make mistakes as the code gets complicated. >>>>>>> >>>>>>>> Tobias, if you want to allocate Unique_Node_List object on arena: >>>>>>>> >>>>>>>> _modified_nodes = new (comp_arena()) >>>>>>>> Unique_Node_List(comp_arena()); >>>>>>> That makes me feel much better. >>>>>>> >>>>>>> I would prefer for us to do it this way for the other stack-chunks >>>>>>> also, but that would be outside the scope of this bug. >>>>>> >>>>>> I changed it to heap allocation. >>>>>> >>>>>>> Tobias, thanks for doing this work. >>>>>>> >>>>>>> ? John >>>>>>> >>>>>>>>> There are other places in the code where this is done, for >>>>>>>>> example in >>>>>>>>> Compile::Compile(..) the Unique_Node_List 'for_igvn' is >>>>>>>>> created on >>>>>>>>> the >>>>>>>>> stack. Is this a special case? >>>>>>>>> >>>>>>>>> I'm not sure how to correctly allocate the object on the heap. >>>>>>>>> Do I >>>>>>>>> have >>>>>>>>> to use new/delete or is this handled by some magic in >>>>>>>>> "ResourceObject'? >>>>>>>>> >>>>>>>>> >>>>>>>>>> You inserted '#ifdef ASSERT' after >>>>>>>>>> 'PhaseIterGVN::verify_PhaseIterGVN', but I don't think you >>>>>>>>>> need it, >>>>>>>>>> since all of the code (including the similar insertion a few >>>>>>>>>> lines up) >>>>>>>>>> is '#ifndef PRODUCT'. See also suggestion above regarding >>>>>>>>>> 'modified_nodes'. >>>>>>>> #ifndef PRODUCT is also 'optimized' version of VM. n->dump() >>>>>>>> method >>>>>>>> is not defined in optimized build. That is why asserts are needed. >>>>>>>> >>>>>>>> Tobias, please, build 'optimized' VM to verify your changes. >>>>>> >>>>>> Thanks for the hint, the optimized build did not work. I'm now using >>>>>> PRODUCT_RETURN and NOT_PRODUCT to guard the verification code. >>>>>> This is >>>>>> consistent with other verification methods like >>>>>> Compile::verify_graph_edges(..). >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8040213/webrev.03/ >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> True, I removed the #ifdef. >>>>>>>>> >>>>>>>>>> There are a few places where tests like 'while >>>>>>>>>> (modified_list->size())' appears but there is no null check of >>>>>>>>>> 'modified_list' itself. This could cause a crash if we ever >>>>>>>>>> get the >>>>>>>>>> phasing wrong; consider an assert or explicit null check 'while >>>>>>>>>> (modified_list != NULL && ...)'. >>>>>>>>> I added explicit null checks. >>>>>>>>> >>>>>>>>> >>>>>>>>> New webrev: >>>>>>>>> http://cr.openjdk.java.net/~thartmann/8040213/webrev.02/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>>> ? John >>>> >> From tobias.hartmann at oracle.com Thu Jul 24 12:23:02 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 24 Jul 2014 14:23:02 +0200 Subject: [9] RFR(S): 8040121: Load variable through a pointer of an incompatible type in src/hotspot/src/share/vm: opto/output.cpp [...] Message-ID: <53D0FAA6.2080504@oracle.com> Hi, please review the following patch that fixes the Parfait warnings listed in JDK-8040121. Bug: https://bugs.openjdk.java.net/browse/JDK-8040121 Webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.00/ The " Load variable through a pointer of an incompatible type" warnings in following files were fixed: - hotspot.src.share.vm.opto.output.cpp::Compile::FillLocArray -> Pointer cast is replaced by union - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::copysign - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::scalbn -> JDK-8043301 moved these methods to sharedRuntimeMath.cpp, the warnings will be fixed with JDK-8049043 - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jdouble - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jfloat - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jint - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jlong -> Same methods are in globalDefinitions_gcc.hpp, globalDefinitions_sparcWorks.hpp, globalDefinitions_xlc.hpp. Because they are not compiler specific, I moved the methods into globalDefinitions.hpp. The casts are now implemented using a union. Testing: Parfait, JPRT Thanks, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Jul 24 15:48:03 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Jul 2014 08:48:03 -0700 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53D0D644.1020100@oracle.com> References: <53CF98B1.9070508@oracle.com> <53CFF7C8.3090207@oracle.com> <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> <53D00EF1.7010506@oracle.com> <53D02558.5040801@oracle.com> <53D0D644.1020100@oracle.com> Message-ID: <53D12AB3.4020005@oracle.com> >> Or you can use union with jlong and don't mess with ENDIAN at all. 64-bit is now main platform now. >> >> Vladimir > > How do we access the low and high bits then? Shifts and masks as we do in other places. Do we trust that C++ compilers keep declared order of int fields? Is it in spec? If yes I am fine with your last code. > typedef union { > } DoubleIntConv; > But that does not really improve code readability... What do you think? It is fine, we do that. > I refactored the code and added set_high(..) and set_low(..) methods (similar to the ones defined in globalDefinitions.hpp). > > New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.03 I like set_* methods. This webrev.03 looks good. Thanks, Vladimir On 7/24/14 2:47 AM, Tobias Hartmann wrote: > Hi, > > Vladimir, David, thanks for the review. Please see comments inline. > >>> Tobias, why you are creating local copy 'conv' of a variable in all places? > > Doing it like this > > __HI(x) = (__HI(x)&0x7fffffff)|(__HI(y)&0x80000000); > return x; > > Parfait still complained that a 32 bit value is assigned to x and it is then used as a 64 bit value. That's why I had to > create a local copy of 'conv'. > > On 23.07.2014 21:30, David Chase wrote: >> Vladimir, I think the mistake is instead to include the cast to the type that it already is. > > True, the cast is not necessary. > > On 23.07.2014 23:12, Vladimir Kozlov wrote: >> Or you can use union with jlong and don't mess with ENDIAN at all. 64-bit is now main platform now. >> >> Vladimir > > How do we access the low and high bits then? > >> On 7/23/14 1:00 PM, David Chase wrote: >>> It occurred to me that a cleaner way is to put the ifdef in the definition of the union: >>> >>> typedef union { >>> double d; >>> struct { >>> #ifdef VM_LITTLE_ENDIAN >>> int lo; >>> int hi; >>> #else >>> int hi; >>> int lo; >>> #endif >>> }; >>> } DoubleIntConv; >>> >>> # define __HI(x) (x.hi) >>> # define __LO(x) (x.lo) >>> >>> At which point, the continued use of the macro starts to look perhaps a hair silly. >>> >>> I was inspired to write the following test program and compile it under clang and gcc (but not under Solaris Studio >>> yet) to see if we could instead just write a stinking static method (that would be inlined) and at clang -O3 and gcc >>> -O4, it was indeed inlined. So we could just write clean code and to heck with the macro. > > I like this solution because in my opinion it is the most readable one and it is always a good idea to remove ugly > macros. If the potential slowdown in slowdebug builds is not a problem I would like to stick to this. > > I removed the macros and changed all parts of the code that used them (unfortunately quite a lot). > > The parfait warnings in the files sharedRuntimeMath.hpp, sharedRutimeTrans.cpp and sharedRuntimeTrigg.cpp were reduced > by 12. > > New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.02 > > The problem with this solution is that some of the compilers do not support anonymous structs. We could name the struct > and access it via the name, for example like this: > > typedef union { > double d; > struct { > #ifdef VM_LITTLE_ENDIAN > int lo; > int hi; > #else > int hi; > int lo; > #endif > } i; > } DoubleIntConv; > > DoubleIntConv conv = { x }; > int high = conv.i.hi; > > But that does not really improve code readability... What do you think? > > Thanks, > Tobias > >>> (Aren?t you loving this review process? :-) > > Yes, thanks for all the testing :) > > Best, > Tobias > >>> >>> We would, however, suffer some slowdown in slowdebug builds. >>> ---------------------- >>> #define VM_LITTLE_ENDIAN 1 >>> typedef union { >>> double d; >>> struct { >>> #ifdef VM_LITTLE_ENDIAN >>> int lo; >>> int hi; >>> #else >>> int hi; >>> int lo; >>> #endif >>> }; >>> } DoubleIntConv; >>> >>> # define __HI(x) (x.hi) >>> # define __LO(x) (x.lo) >>> >>> static int inline_low(double d) { >>> DoubleIntConv x = { d } ; >>> return __LO(x); >>> } >>> >>> static int inline_high(double d) { >>> DoubleIntConv x = { d } ; >>> return __HI(x); >>> } >>> >>> int low(double d) { >>> return inline_low(d); >>> } >>> >>> int high(double d) { >>> return inline_high(d); >>> } >>> ---------------------- >>> >>> >>> >>> On Jul 23, 2014, at 3:37 PM, Vladimir Kozlov wrote: >>> >>>> David, I agree with your suggestion to pass union to _HI and _LO. The creation of a local union var makes sense then. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/23/14 12:30 PM, David Chase wrote: >>>>> Vladimir, I think the mistake is instead to include the cast to the type >>>>> that it already is. >>>>> I think performing the cast to the union type from a non-union address >>>>> might get you a warning otherwise. >>>>> I can confirm that if you write it plainly with the assignment to a >>>>> correctly typed ?conv? >>>>> that clang (at least) generates good code: >>>>> >>>>> union ca { >>>>> double d; >>>>> int i[2]; >>>>> }; >>>>> >>>>> int la(double d) { >>>>> union ca x = { d } ; >>>>> return x.i[0]; >>>>> } >>>>> >>>>> clang produces (-O3 -S, cleaned up) >>>>> >>>>> _la: ## @la >>>>> pushq %rbp >>>>> movq %rsp, %rbp >>>>> movd %xmm0, %rax >>>>> popq %rbp >>>>> ret >>>>> gcc 4.8.1 produces (-O4 -S, cleaned up) >>>>> >>>>> la: >>>>> movsd%xmm0, -8(%rsp) >>>>> movq-8(%rsp), %rax >>>>> ret >>>>> >>>>> So I think this is generally a good idea, but the macro should be >>>>> cleaned up to >>>>> remove the cast that is certainly unnecessary now. E.g. >>>>> >>>>> 39 #ifdef VM_LITTLE_ENDIAN >>>>> 40 # define __HI(x) ((x).i[1]) >>>>> 41 # define __LO(x) ((x).i[0]) >>>>> 42 #else >>>>> 43 # define __HI(x) (x.i[0]) >>>>> 44 # define __LO(x) (x.i[1]) >>>>> 45 #endif >>>>> >>>>> The temporary is only annoying to humans using a last-millenium dialect >>>>> of C. The code runs fast, and the address-of+dereference in the macro >>>>> forced it to memory (lacking a lot of alias analysis) anyhow. >>>>> >>>>> David >>>>> >>>>> >>>>> On Jul 23, 2014, at 1:58 PM, Vladimir Kozlov >>>> > wrote: >>>>> >>>>>> Tobias, why you are creating local copy 'conv' of a variable in all >>>>>> places? >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 7/23/14 4:12 AM, Tobias Hartmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review the following patch for JDK- 8049043 (Parfait warning). >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ >>>>>>> >>>>>>> Problem: >>>>>>> Parfait issues 6 warnings " Load variable through a pointer of an >>>>>>> incompatible type" because of the __HI(x) and __LO(x) macros used in >>>>>>> copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) to cast >>>>>>> between double* and int*. >>>>>>> >>>>>>> Solution: >>>>>>> A union 'DoubleIntConv' is used to access the high and low 32 bits of a >>>>>>> double. >>>>>>> The '# pragma warning( disable: 4748 )' in sharedRuntimeTrans.cpp is >>>>>>> necessary because otherwise the VS compiler fails with the following >>>>>>> warning: "/GS can not protect parameters and local variables from local >>>>>>> buffer overrun because optimizations are disabled in function". There >>>>>>> exists a bug to fix this [1]. >>>>>>> >>>>>>> Testing: >>>>>>> JPRT, Parfait (all 6 warnings removed) >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8046696 >>> > From vladimir.kozlov at oracle.com Thu Jul 24 16:03:07 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Jul 2014 09:03:07 -0700 Subject: [9] RFR(S): 8040121: Load variable through a pointer of an incompatible type in src/hotspot/src/share/vm: opto/output.cpp [...] In-Reply-To: <53D0FAA6.2080504@oracle.com> References: <53D0FAA6.2080504@oracle.com> Message-ID: <53D12E3B.4040304@oracle.com> DoubleIntConv is duplicate of one from 8049043. Can you combine them? typedef union { double d; int i[2]; struct { #ifdef VM_LITTLE_ENDIAN int lo; int hi; #else int hi; int lo; #endif } split; } DoubleIntConv; Otherwise good. Thanks, Vladimir On 7/24/14 5:23 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that fixes the Parfait warnings listed in JDK-8040121. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8040121 > Webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.00/ > > The " Load variable through a pointer of an incompatible type" warnings in following files were fixed: > > - hotspot.src.share.vm.opto.output.cpp::Compile::FillLocArray > -> Pointer cast is replaced by union > > - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::copysign > - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::scalbn > -> JDK-8043301 moved these methods to sharedRuntimeMath.cpp, the warnings will be fixed with JDK-8049043 > > - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jdouble > - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jfloat > - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jint > - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jlong > -> Same methods are in globalDefinitions_gcc.hpp, globalDefinitions_sparcWorks.hpp, globalDefinitions_xlc.hpp. Because > they are not compiler specific, I moved the methods into globalDefinitions.hpp. The casts are now implemented using a union. > > Testing: Parfait, JPRT > > Thanks, > Tobias From igor.ignatyev at oracle.com Thu Jul 24 18:04:05 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 24 Jul 2014 22:04:05 +0400 Subject: RFR(XS) : 8051896 : compiler/ciReplay tests don't use $TESTJAVAOPTS Message-ID: <53D14A95.5010009@oracle.com> http://cr.openjdk.java.net/~iignatyev/8051896/webrev.00/ 12 lines changed: 2 ins; 0 del; 10 mod Hi all, Please review patch: Problem: the tests use only TESTVMOPTS, but jtreg propagates some flags by TESTJAVAOPTS variable Fix: usages of TESTVMOPTS were replaced by TESTOPTS which is initialized as concatenated values of TESTVMOPTS and TESTJAVAOPTS jbs: https://bugs.openjdk.java.net/browse/JDK-8051896 testing: jprt -- Igor From vladimir.kozlov at oracle.com Thu Jul 24 18:18:28 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Jul 2014 11:18:28 -0700 Subject: RFR(XS) : 8051896 : compiler/ciReplay tests don't use $TESTJAVAOPTS In-Reply-To: <53D14A95.5010009@oracle.com> References: <53D14A95.5010009@oracle.com> Message-ID: <53D14DF4.2040702@oracle.com> Looks good. Is not this a general problem for all our tests? They use only TESTVMOPTS. I thought jtreg merges TESTVMOPTS and TESTJAVAOPTS flags together. Thanks, Vladimir On 7/24/14 11:04 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8051896/webrev.00/ > 12 lines changed: 2 ins; 0 del; 10 mod > > Hi all, > > Please review patch: > > Problem: > the tests use only TESTVMOPTS, but jtreg propagates some flags by > TESTJAVAOPTS variable > > Fix: > usages of TESTVMOPTS were replaced by TESTOPTS which is initialized as > concatenated values of TESTVMOPTS and TESTJAVAOPTS > > jbs: https://bugs.openjdk.java.net/browse/JDK-8051896 > testing: jprt From vladimir.kozlov at oracle.com Thu Jul 24 20:24:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Jul 2014 13:24:42 -0700 Subject: [9] RFR(S): 8040121: Load variable through a pointer of an incompatible type in src/hotspot/src/share/vm: opto/output.cpp [...] In-Reply-To: <53D12E3B.4040304@oracle.com> References: <53D0FAA6.2080504@oracle.com> <53D12E3B.4040304@oracle.com> Message-ID: <53D16B8A.1030400@oracle.com> Christian suggested to use jlong_accessor in output.cpp, so you don't need to merge DoubleIntConv. thanks, Vladimir On 7/24/14 9:03 AM, Vladimir Kozlov wrote: > DoubleIntConv is duplicate of one from 8049043. > > Can you combine them? > > typedef union { > double d; > int i[2]; > struct { > #ifdef VM_LITTLE_ENDIAN > int lo; > int hi; > #else > int hi; > int lo; > #endif > } split; > } DoubleIntConv; > > Otherwise good. > > Thanks, > Vladimir > > On 7/24/14 5:23 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch that fixes the Parfait warnings >> listed in JDK-8040121. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8040121 >> Webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.00/ >> >> The " Load variable through a pointer of an incompatible type" >> warnings in following files were fixed: >> >> - hotspot.src.share.vm.opto.output.cpp::Compile::FillLocArray >> -> Pointer cast is replaced by union >> >> - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::copysign >> - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::scalbn >> -> JDK-8043301 moved these methods to sharedRuntimeMath.cpp, the >> warnings will be fixed with JDK-8049043 >> >> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jdouble >> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jfloat >> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jint >> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jlong >> -> Same methods are in globalDefinitions_gcc.hpp, >> globalDefinitions_sparcWorks.hpp, globalDefinitions_xlc.hpp. Because >> they are not compiler specific, I moved the methods into >> globalDefinitions.hpp. The casts are now implemented using a union. >> >> Testing: Parfait, JPRT >> >> Thanks, >> Tobias From igor.ignatyev at oracle.com Thu Jul 24 20:37:08 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 25 Jul 2014 00:37:08 +0400 Subject: RFR(S) : 8051896 : jtreg tests don't use $TESTJAVAOPTS In-Reply-To: <53D14DF4.2040702@oracle.com> References: <53D14A95.5010009@oracle.com> <53D14DF4.2040702@oracle.com> Message-ID: <53D16E74.6090504@oracle.com> // was Re: RFR(XS) : 8051896 : compiler/ciReplay tests don't use $TESTJAVAOPTS: updated webrev: http://cr.openjdk.java.net/~iignatyev/8051896/webrev.01/ 93 lines changed: 15 ins; 40 del; 38 mod; On 07/24/2014 10:18 PM, Vladimir Kozlov wrote: > Looks good. > > Is not this a general problem for all our tests? They use only > TESTVMOPTS. Yeap, it's a general problem, I've updated all tests. I thought jtreg merges TESTVMOPTS and TESTJAVAOPTS flags > together. > > Thanks, > Vladimir > > On 7/24/14 11:04 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8051896/webrev.00/ >> 12 lines changed: 2 ins; 0 del; 10 mod >> >> Hi all, >> >> Please review patch: >> >> Problem: >> the tests use only TESTVMOPTS, but jtreg propagates some flags by >> TESTJAVAOPTS variable >> >> Fix: >> usages of TESTVMOPTS were replaced by TESTOPTS which is initialized as >> concatenated values of TESTVMOPTS and TESTJAVAOPTS >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8051896 >> testing: jprt From vladimir.kozlov at oracle.com Thu Jul 24 21:38:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Jul 2014 14:38:20 -0700 Subject: RFR(S) : 8051896 : jtreg tests don't use $TESTJAVAOPTS In-Reply-To: <53D16E74.6090504@oracle.com> References: <53D14A95.5010009@oracle.com> <53D14DF4.2040702@oracle.com> <53D16E74.6090504@oracle.com> Message-ID: <53D17CCC.5010908@oracle.com> The order of flags on command line is important. I think TESTJAVAOPTS should be last to take priority: TESTOPTS="${TESTVMOPTS} ${TESTJAVAOPTS}" Please, add copyright headers to files in compiler/6894807. Otherwise look good. Thanks, Vladimir On 7/24/14 1:37 PM, Igor Ignatyev wrote: > // was Re: RFR(XS) : 8051896 : compiler/ciReplay tests don't use > $TESTJAVAOPTS: > > updated webrev: http://cr.openjdk.java.net/~iignatyev/8051896/webrev.01/ > 93 lines changed: 15 ins; 40 del; 38 mod; > > On 07/24/2014 10:18 PM, Vladimir Kozlov wrote: >> Looks good. >> >> Is not this a general problem for all our tests? They use only >> TESTVMOPTS. > Yeap, it's a general problem, I've updated all tests. > I thought jtreg merges TESTVMOPTS and TESTJAVAOPTS flags >> together. >> >> Thanks, >> Vladimir >> >> On 7/24/14 11:04 AM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8051896/webrev.00/ >>> 12 lines changed: 2 ins; 0 del; 10 mod >>> >>> Hi all, >>> >>> Please review patch: >>> >>> Problem: >>> the tests use only TESTVMOPTS, but jtreg propagates some flags by >>> TESTJAVAOPTS variable >>> >>> Fix: >>> usages of TESTVMOPTS were replaced by TESTOPTS which is initialized as >>> concatenated values of TESTVMOPTS and TESTJAVAOPTS >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8051896 >>> testing: jprt From tobias.hartmann at oracle.com Fri Jul 25 07:18:44 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 25 Jul 2014 09:18:44 +0200 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53D12AB3.4020005@oracle.com> References: <53CF98B1.9070508@oracle.com> <53CFF7C8.3090207@oracle.com> <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> <53D00EF1.7010506@oracle.com> <53D02558.5040801@oracle.com> <53D0D644.1020100@oracle.com> <53D12AB3.4020005@oracle.com> Message-ID: <53D204D4.2090409@oracle.com> Hi Vladimir, thanks for the review. On 24.07.2014 17:48, Vladimir Kozlov wrote: > Do we trust that C++ compilers keep declared order of int fields? Is > it in spec? If yes I am fine with your last code. Yes, sentence 13 of Section 9.2. (page 217) of the latest C++ standard working draft [1] says: "Nonstatic data members of a (non-union) class with the same access control (Clause 11) are allocated so that later members have higher addresses within a class object. The order of allocation of non-static data members with different access control is unspecified (Clause 11). [...]" We do not have any access control specifiers, so it should be fine. Thanks, Tobias [1] https://isocpp.org/files/papers/N3797.pdf > > typedef union { > > } DoubleIntConv; > > But that does not really improve code readability... What do you think? > > It is fine, we do that. > > > I refactored the code and added set_high(..) and set_low(..) methods > (similar to the ones defined in globalDefinitions.hpp). > > > > New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.03 > > I like set_* methods. This webrev.03 looks good. > > Thanks, > Vladimir > > On 7/24/14 2:47 AM, Tobias Hartmann wrote: >> Hi, >> >> Vladimir, David, thanks for the review. Please see comments inline. >> >>>> Tobias, why you are creating local copy 'conv' of a variable in all >>>> places? >> >> Doing it like this >> >> __HI(x) = (__HI(x)&0x7fffffff)|(__HI(y)&0x80000000); >> return x; >> >> Parfait still complained that a 32 bit value is assigned to x and it >> is then used as a 64 bit value. That's why I had to >> create a local copy of 'conv'. >> >> On 23.07.2014 21:30, David Chase wrote: >>> Vladimir, I think the mistake is instead to include the cast to the >>> type that it already is. >> >> True, the cast is not necessary. >> >> On 23.07.2014 23:12, Vladimir Kozlov wrote: >>> Or you can use union with jlong and don't mess with ENDIAN at all. >>> 64-bit is now main platform now. >>> >>> Vladimir >> >> How do we access the low and high bits then? > > >> >>> On 7/23/14 1:00 PM, David Chase wrote: >>>> It occurred to me that a cleaner way is to put the ifdef in the >>>> definition of the union: >>>> >>>> typedef union { >>>> double d; >>>> struct { >>>> #ifdef VM_LITTLE_ENDIAN >>>> int lo; >>>> int hi; >>>> #else >>>> int hi; >>>> int lo; >>>> #endif >>>> }; >>>> } DoubleIntConv; >>>> >>>> # define __HI(x) (x.hi) >>>> # define __LO(x) (x.lo) >>>> >>>> At which point, the continued use of the macro starts to look >>>> perhaps a hair silly. >>>> >>>> I was inspired to write the following test program and compile it >>>> under clang and gcc (but not under Solaris Studio >>>> yet) to see if we could instead just write a stinking static method >>>> (that would be inlined) and at clang -O3 and gcc >>>> -O4, it was indeed inlined. So we could just write clean code and >>>> to heck with the macro. >> >> I like this solution because in my opinion it is the most readable >> one and it is always a good idea to remove ugly >> macros. If the potential slowdown in slowdebug builds is not a >> problem I would like to stick to this. >> >> I removed the macros and changed all parts of the code that used them >> (unfortunately quite a lot). >> >> The parfait warnings in the files sharedRuntimeMath.hpp, >> sharedRutimeTrans.cpp and sharedRuntimeTrigg.cpp were reduced >> by 12. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.02 >> >> The problem with this solution is that some of the compilers do not >> support anonymous structs. We could name the struct >> and access it via the name, for example like this: >> >> typedef union { >> double d; >> struct { >> #ifdef VM_LITTLE_ENDIAN >> int lo; >> int hi; >> #else >> int hi; >> int lo; >> #endif >> } i; >> } DoubleIntConv; >> >> DoubleIntConv conv = { x }; >> int high = conv.i.hi; >> >> But that does not really improve code readability... What do you think? >> >> Thanks, >> Tobias >> >>>> (Aren?t you loving this review process? :-) >> >> Yes, thanks for all the testing :) >> >> Best, >> Tobias >> >>>> >>>> We would, however, suffer some slowdown in slowdebug builds. >>>> ---------------------- >>>> #define VM_LITTLE_ENDIAN 1 >>>> typedef union { >>>> double d; >>>> struct { >>>> #ifdef VM_LITTLE_ENDIAN >>>> int lo; >>>> int hi; >>>> #else >>>> int hi; >>>> int lo; >>>> #endif >>>> }; >>>> } DoubleIntConv; >>>> >>>> # define __HI(x) (x.hi) >>>> # define __LO(x) (x.lo) >>>> >>>> static int inline_low(double d) { >>>> DoubleIntConv x = { d } ; >>>> return __LO(x); >>>> } >>>> >>>> static int inline_high(double d) { >>>> DoubleIntConv x = { d } ; >>>> return __HI(x); >>>> } >>>> >>>> int low(double d) { >>>> return inline_low(d); >>>> } >>>> >>>> int high(double d) { >>>> return inline_high(d); >>>> } >>>> ---------------------- >>>> >>>> >>>> >>>> On Jul 23, 2014, at 3:37 PM, Vladimir Kozlov >>>> wrote: >>>> >>>>> David, I agree with your suggestion to pass union to _HI and _LO. >>>>> The creation of a local union var makes sense then. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 7/23/14 12:30 PM, David Chase wrote: >>>>>> Vladimir, I think the mistake is instead to include the cast to >>>>>> the type >>>>>> that it already is. >>>>>> I think performing the cast to the union type from a non-union >>>>>> address >>>>>> might get you a warning otherwise. >>>>>> I can confirm that if you write it plainly with the assignment to a >>>>>> correctly typed ?conv? >>>>>> that clang (at least) generates good code: >>>>>> >>>>>> union ca { >>>>>> double d; >>>>>> int i[2]; >>>>>> }; >>>>>> >>>>>> int la(double d) { >>>>>> union ca x = { d } ; >>>>>> return x.i[0]; >>>>>> } >>>>>> >>>>>> clang produces (-O3 -S, cleaned up) >>>>>> >>>>>> _la: ## @la >>>>>> pushq %rbp >>>>>> movq %rsp, %rbp >>>>>> movd %xmm0, %rax >>>>>> popq %rbp >>>>>> ret >>>>>> gcc 4.8.1 produces (-O4 -S, cleaned up) >>>>>> >>>>>> la: >>>>>> movsd%xmm0, -8(%rsp) >>>>>> movq-8(%rsp), %rax >>>>>> ret >>>>>> >>>>>> So I think this is generally a good idea, but the macro should be >>>>>> cleaned up to >>>>>> remove the cast that is certainly unnecessary now. E.g. >>>>>> >>>>>> 39 #ifdef VM_LITTLE_ENDIAN >>>>>> 40 # define __HI(x) ((x).i[1]) >>>>>> 41 # define __LO(x) ((x).i[0]) >>>>>> 42 #else >>>>>> 43 # define __HI(x) (x.i[0]) >>>>>> 44 # define __LO(x) (x.i[1]) >>>>>> 45 #endif >>>>>> >>>>>> The temporary is only annoying to humans using a last-millenium >>>>>> dialect >>>>>> of C. The code runs fast, and the address-of+dereference in the >>>>>> macro >>>>>> forced it to memory (lacking a lot of alias analysis) anyhow. >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 1:58 PM, Vladimir Kozlov >>>>>> >>>>> > wrote: >>>>>> >>>>>>> Tobias, why you are creating local copy 'conv' of a variable in all >>>>>>> places? >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> On 7/23/14 4:12 AM, Tobias Hartmann wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review the following patch for JDK- 8049043 (Parfait >>>>>>>> warning). >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ >>>>>>>> >>>>>>>> Problem: >>>>>>>> Parfait issues 6 warnings " Load variable through a pointer of an >>>>>>>> incompatible type" because of the __HI(x) and __LO(x) macros >>>>>>>> used in >>>>>>>> copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) >>>>>>>> to cast >>>>>>>> between double* and int*. >>>>>>>> >>>>>>>> Solution: >>>>>>>> A union 'DoubleIntConv' is used to access the high and low 32 >>>>>>>> bits of a >>>>>>>> double. >>>>>>>> The '# pragma warning( disable: 4748 )' in >>>>>>>> sharedRuntimeTrans.cpp is >>>>>>>> necessary because otherwise the VS compiler fails with the >>>>>>>> following >>>>>>>> warning: "/GS can not protect parameters and local variables >>>>>>>> from local >>>>>>>> buffer overrun because optimizations are disabled in function". >>>>>>>> There >>>>>>>> exists a bug to fix this [1]. >>>>>>>> >>>>>>>> Testing: >>>>>>>> JPRT, Parfait (all 6 warnings removed) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8046696 >>>> >> From tobias.hartmann at oracle.com Fri Jul 25 08:39:36 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 25 Jul 2014 10:39:36 +0200 Subject: [9] RFR(S): 8040121: Load variable through a pointer of an incompatible type in src/hotspot/src/share/vm: opto/output.cpp [...] In-Reply-To: <53D16B8A.1030400@oracle.com> References: <53D0FAA6.2080504@oracle.com> <53D12E3B.4040304@oracle.com> <53D16B8A.1030400@oracle.com> Message-ID: <53D217C8.8000607@oracle.com> Hi Vladimir, thanks for the review. I'm now using jlong_accessor both for the 'DoubleCon' and the 'Long' cases. New webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.01/ Thanks, Tobias On 24.07.2014 22:24, Vladimir Kozlov wrote: > Christian suggested to use jlong_accessor in output.cpp, so you don't > need to merge DoubleIntConv. > > thanks, > Vladimir > > On 7/24/14 9:03 AM, Vladimir Kozlov wrote: >> DoubleIntConv is duplicate of one from 8049043. >> >> Can you combine them? >> >> typedef union { >> double d; >> int i[2]; >> struct { >> #ifdef VM_LITTLE_ENDIAN >> int lo; >> int hi; >> #else >> int hi; >> int lo; >> #endif >> } split; >> } DoubleIntConv; >> >> Otherwise good. >> >> Thanks, >> Vladimir >> >> On 7/24/14 5:23 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch that fixes the Parfait warnings >>> listed in JDK-8040121. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040121 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.00/ >>> >>> The " Load variable through a pointer of an incompatible type" >>> warnings in following files were fixed: >>> >>> - hotspot.src.share.vm.opto.output.cpp::Compile::FillLocArray >>> -> Pointer cast is replaced by union >>> >>> - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::copysign >>> - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::scalbn >>> -> JDK-8043301 moved these methods to sharedRuntimeMath.cpp, the >>> warnings will be fixed with JDK-8049043 >>> >>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jdouble >>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jfloat >>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jint >>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jlong >>> -> Same methods are in globalDefinitions_gcc.hpp, >>> globalDefinitions_sparcWorks.hpp, globalDefinitions_xlc.hpp. Because >>> they are not compiler specific, I moved the methods into >>> globalDefinitions.hpp. The casts are now implemented using a union. >>> >>> Testing: Parfait, JPRT >>> >>> Thanks, >>> Tobias From vladimir.kozlov at oracle.com Fri Jul 25 16:09:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Jul 2014 09:09:51 -0700 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53D204D4.2090409@oracle.com> References: <53CF98B1.9070508@oracle.com> <53CFF7C8.3090207@oracle.com> <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> <53D00EF1.7010506@oracle.com> <53D02558.5040801@oracle.com> <53D0D644.1020100@oracle.com> <53D12AB3.4020005@oracle.com> <53D204D4.2090409@oracle.com> Message-ID: <53D2814F.90204@oracle.com> On 7/25/14 12:18 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > > On 24.07.2014 17:48, Vladimir Kozlov wrote: >> Do we trust that C++ compilers keep declared order of int fields? Is it in spec? If yes I am fine with your last code. > > Yes, sentence 13 of Section 9.2. (page 217) of the latest C++ standard working draft [1] says: > > "Nonstatic data members of a (non-union) class with the same access control (Clause 11) are allocated so that later > members have higher addresses within a class object. The order of allocation of non-static data members with different > access control is unspecified (Clause 11). [...]" > > We do not have any access control specifiers, so it should be fine. Good. Thank you for looking to this. Vladimir > > Thanks, > Tobias > > [1] https://isocpp.org/files/papers/N3797.pdf > >> > typedef union { >> > } DoubleIntConv; >> > But that does not really improve code readability... What do you think? >> >> It is fine, we do that. >> >> > I refactored the code and added set_high(..) and set_low(..) methods (similar to the ones defined in >> globalDefinitions.hpp). >> > >> > New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.03 >> >> I like set_* methods. This webrev.03 looks good. >> >> Thanks, >> Vladimir >> >> On 7/24/14 2:47 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> Vladimir, David, thanks for the review. Please see comments inline. >>> >>>>> Tobias, why you are creating local copy 'conv' of a variable in all places? >>> >>> Doing it like this >>> >>> __HI(x) = (__HI(x)&0x7fffffff)|(__HI(y)&0x80000000); >>> return x; >>> >>> Parfait still complained that a 32 bit value is assigned to x and it is then used as a 64 bit value. That's why I had to >>> create a local copy of 'conv'. >>> >>> On 23.07.2014 21:30, David Chase wrote: >>>> Vladimir, I think the mistake is instead to include the cast to the type that it already is. >>> >>> True, the cast is not necessary. >>> >>> On 23.07.2014 23:12, Vladimir Kozlov wrote: >>>> Or you can use union with jlong and don't mess with ENDIAN at all. 64-bit is now main platform now. >>>> >>>> Vladimir >>> >>> How do we access the low and high bits then? >> >> >>> >>>> On 7/23/14 1:00 PM, David Chase wrote: >>>>> It occurred to me that a cleaner way is to put the ifdef in the definition of the union: >>>>> >>>>> typedef union { >>>>> double d; >>>>> struct { >>>>> #ifdef VM_LITTLE_ENDIAN >>>>> int lo; >>>>> int hi; >>>>> #else >>>>> int hi; >>>>> int lo; >>>>> #endif >>>>> }; >>>>> } DoubleIntConv; >>>>> >>>>> # define __HI(x) (x.hi) >>>>> # define __LO(x) (x.lo) >>>>> >>>>> At which point, the continued use of the macro starts to look perhaps a hair silly. >>>>> >>>>> I was inspired to write the following test program and compile it under clang and gcc (but not under Solaris Studio >>>>> yet) to see if we could instead just write a stinking static method (that would be inlined) and at clang -O3 and gcc >>>>> -O4, it was indeed inlined. So we could just write clean code and to heck with the macro. >>> >>> I like this solution because in my opinion it is the most readable one and it is always a good idea to remove ugly >>> macros. If the potential slowdown in slowdebug builds is not a problem I would like to stick to this. >>> >>> I removed the macros and changed all parts of the code that used them (unfortunately quite a lot). >>> >>> The parfait warnings in the files sharedRuntimeMath.hpp, sharedRutimeTrans.cpp and sharedRuntimeTrigg.cpp were reduced >>> by 12. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.02 >>> >>> The problem with this solution is that some of the compilers do not support anonymous structs. We could name the struct >>> and access it via the name, for example like this: >>> >>> typedef union { >>> double d; >>> struct { >>> #ifdef VM_LITTLE_ENDIAN >>> int lo; >>> int hi; >>> #else >>> int hi; >>> int lo; >>> #endif >>> } i; >>> } DoubleIntConv; >>> >>> DoubleIntConv conv = { x }; >>> int high = conv.i.hi; >>> >>> But that does not really improve code readability... What do you think? >>> >>> Thanks, >>> Tobias >>> >>>>> (Aren?t you loving this review process? :-) >>> >>> Yes, thanks for all the testing :) >>> >>> Best, >>> Tobias >>> >>>>> >>>>> We would, however, suffer some slowdown in slowdebug builds. >>>>> ---------------------- >>>>> #define VM_LITTLE_ENDIAN 1 >>>>> typedef union { >>>>> double d; >>>>> struct { >>>>> #ifdef VM_LITTLE_ENDIAN >>>>> int lo; >>>>> int hi; >>>>> #else >>>>> int hi; >>>>> int lo; >>>>> #endif >>>>> }; >>>>> } DoubleIntConv; >>>>> >>>>> # define __HI(x) (x.hi) >>>>> # define __LO(x) (x.lo) >>>>> >>>>> static int inline_low(double d) { >>>>> DoubleIntConv x = { d } ; >>>>> return __LO(x); >>>>> } >>>>> >>>>> static int inline_high(double d) { >>>>> DoubleIntConv x = { d } ; >>>>> return __HI(x); >>>>> } >>>>> >>>>> int low(double d) { >>>>> return inline_low(d); >>>>> } >>>>> >>>>> int high(double d) { >>>>> return inline_high(d); >>>>> } >>>>> ---------------------- >>>>> >>>>> >>>>> >>>>> On Jul 23, 2014, at 3:37 PM, Vladimir Kozlov wrote: >>>>> >>>>>> David, I agree with your suggestion to pass union to _HI and _LO. The creation of a local union var makes sense then. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 7/23/14 12:30 PM, David Chase wrote: >>>>>>> Vladimir, I think the mistake is instead to include the cast to the type >>>>>>> that it already is. >>>>>>> I think performing the cast to the union type from a non-union address >>>>>>> might get you a warning otherwise. >>>>>>> I can confirm that if you write it plainly with the assignment to a >>>>>>> correctly typed ?conv? >>>>>>> that clang (at least) generates good code: >>>>>>> >>>>>>> union ca { >>>>>>> double d; >>>>>>> int i[2]; >>>>>>> }; >>>>>>> >>>>>>> int la(double d) { >>>>>>> union ca x = { d } ; >>>>>>> return x.i[0]; >>>>>>> } >>>>>>> >>>>>>> clang produces (-O3 -S, cleaned up) >>>>>>> >>>>>>> _la: ## @la >>>>>>> pushq %rbp >>>>>>> movq %rsp, %rbp >>>>>>> movd %xmm0, %rax >>>>>>> popq %rbp >>>>>>> ret >>>>>>> gcc 4.8.1 produces (-O4 -S, cleaned up) >>>>>>> >>>>>>> la: >>>>>>> movsd%xmm0, -8(%rsp) >>>>>>> movq-8(%rsp), %rax >>>>>>> ret >>>>>>> >>>>>>> So I think this is generally a good idea, but the macro should be >>>>>>> cleaned up to >>>>>>> remove the cast that is certainly unnecessary now. E.g. >>>>>>> >>>>>>> 39 #ifdef VM_LITTLE_ENDIAN >>>>>>> 40 # define __HI(x) ((x).i[1]) >>>>>>> 41 # define __LO(x) ((x).i[0]) >>>>>>> 42 #else >>>>>>> 43 # define __HI(x) (x.i[0]) >>>>>>> 44 # define __LO(x) (x.i[1]) >>>>>>> 45 #endif >>>>>>> >>>>>>> The temporary is only annoying to humans using a last-millenium dialect >>>>>>> of C. The code runs fast, and the address-of+dereference in the macro >>>>>>> forced it to memory (lacking a lot of alias analysis) anyhow. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>> On Jul 23, 2014, at 1:58 PM, Vladimir Kozlov >>>>>> > wrote: >>>>>>> >>>>>>>> Tobias, why you are creating local copy 'conv' of a variable in all >>>>>>>> places? >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 7/23/14 4:12 AM, Tobias Hartmann wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please review the following patch for JDK- 8049043 (Parfait warning). >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ >>>>>>>>> >>>>>>>>> Problem: >>>>>>>>> Parfait issues 6 warnings " Load variable through a pointer of an >>>>>>>>> incompatible type" because of the __HI(x) and __LO(x) macros used in >>>>>>>>> copysignA and scalbnA (share/vm/runtime/sharedRuntimeMath.hpp) to cast >>>>>>>>> between double* and int*. >>>>>>>>> >>>>>>>>> Solution: >>>>>>>>> A union 'DoubleIntConv' is used to access the high and low 32 bits of a >>>>>>>>> double. >>>>>>>>> The '# pragma warning( disable: 4748 )' in sharedRuntimeTrans.cpp is >>>>>>>>> necessary because otherwise the VS compiler fails with the following >>>>>>>>> warning: "/GS can not protect parameters and local variables from local >>>>>>>>> buffer overrun because optimizations are disabled in function". There >>>>>>>>> exists a bug to fix this [1]. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> JPRT, Parfait (all 6 warnings removed) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8046696 >>>>> >>> > From vladimir.kozlov at oracle.com Fri Jul 25 16:21:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Jul 2014 09:21:35 -0700 Subject: [9] RFR(S): 8040121: Load variable through a pointer of an incompatible type in src/hotspot/src/share/vm: opto/output.cpp [...] In-Reply-To: <53D217C8.8000607@oracle.com> References: <53D0FAA6.2080504@oracle.com> <53D12E3B.4040304@oracle.com> <53D16B8A.1030400@oracle.com> <53D217C8.8000607@oracle.com> Message-ID: <53D2840F.3010407@oracle.com> This looks good. Thanks, Vladimir On 7/25/14 1:39 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > > I'm now using jlong_accessor both for the 'DoubleCon' and the 'Long' cases. > > New webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.01/ > > Thanks, > Tobias > > On 24.07.2014 22:24, Vladimir Kozlov wrote: >> Christian suggested to use jlong_accessor in output.cpp, so you don't need to merge DoubleIntConv. >> >> thanks, >> Vladimir >> >> On 7/24/14 9:03 AM, Vladimir Kozlov wrote: >>> DoubleIntConv is duplicate of one from 8049043. >>> >>> Can you combine them? >>> >>> typedef union { >>> double d; >>> int i[2]; >>> struct { >>> #ifdef VM_LITTLE_ENDIAN >>> int lo; >>> int hi; >>> #else >>> int hi; >>> int lo; >>> #endif >>> } split; >>> } DoubleIntConv; >>> >>> Otherwise good. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/24/14 5:23 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch that fixes the Parfait warnings >>>> listed in JDK-8040121. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040121 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.00/ >>>> >>>> The " Load variable through a pointer of an incompatible type" >>>> warnings in following files were fixed: >>>> >>>> - hotspot.src.share.vm.opto.output.cpp::Compile::FillLocArray >>>> -> Pointer cast is replaced by union >>>> >>>> - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::copysign >>>> - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::scalbn >>>> -> JDK-8043301 moved these methods to sharedRuntimeMath.cpp, the >>>> warnings will be fixed with JDK-8049043 >>>> >>>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jdouble >>>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jfloat >>>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jint >>>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jlong >>>> -> Same methods are in globalDefinitions_gcc.hpp, >>>> globalDefinitions_sparcWorks.hpp, globalDefinitions_xlc.hpp. Because >>>> they are not compiler specific, I moved the methods into >>>> globalDefinitions.hpp. The casts are now implemented using a union. >>>> >>>> Testing: Parfait, JPRT >>>> >>>> Thanks, >>>> Tobias > From tobias.hartmann at oracle.com Mon Jul 28 05:57:22 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 28 Jul 2014 07:57:22 +0200 Subject: [9] RFR(S): 8040121: Load variable through a pointer of an incompatible type in src/hotspot/src/share/vm: opto/output.cpp [...] In-Reply-To: <53D2840F.3010407@oracle.com> References: <53D0FAA6.2080504@oracle.com> <53D12E3B.4040304@oracle.com> <53D16B8A.1030400@oracle.com> <53D217C8.8000607@oracle.com> <53D2840F.3010407@oracle.com> Message-ID: <53D5E642.4030709@oracle.com> Thank you, Vladimir. Best, Tobias On 25.07.2014 18:21, Vladimir Kozlov wrote: > This looks good. > > Thanks, > Vladimir > > On 7/25/14 1:39 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >> I'm now using jlong_accessor both for the 'DoubleCon' and the 'Long' >> cases. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.01/ >> >> Thanks, >> Tobias >> >> On 24.07.2014 22:24, Vladimir Kozlov wrote: >>> Christian suggested to use jlong_accessor in output.cpp, so you >>> don't need to merge DoubleIntConv. >>> >>> thanks, >>> Vladimir >>> >>> On 7/24/14 9:03 AM, Vladimir Kozlov wrote: >>>> DoubleIntConv is duplicate of one from 8049043. >>>> >>>> Can you combine them? >>>> >>>> typedef union { >>>> double d; >>>> int i[2]; >>>> struct { >>>> #ifdef VM_LITTLE_ENDIAN >>>> int lo; >>>> int hi; >>>> #else >>>> int hi; >>>> int lo; >>>> #endif >>>> } split; >>>> } DoubleIntConv; >>>> >>>> Otherwise good. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/24/14 5:23 AM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch that fixes the Parfait warnings >>>>> listed in JDK-8040121. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040121 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.00/ >>>>> >>>>> The " Load variable through a pointer of an incompatible type" >>>>> warnings in following files were fixed: >>>>> >>>>> - hotspot.src.share.vm.opto.output.cpp::Compile::FillLocArray >>>>> -> Pointer cast is replaced by union >>>>> >>>>> - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::copysign >>>>> - hotspot.src.share.vm.runtime.sharedRuntimeTrans.cpp::scalbn >>>>> -> JDK-8043301 moved these methods to sharedRuntimeMath.cpp, the >>>>> warnings will be fixed with JDK-8049043 >>>>> >>>>> - >>>>> hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jdouble >>>>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jfloat >>>>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jint >>>>> - hotspot.src.share.vm.utilities.globalDefinitions_visCPP.hpp::jlong >>>>> -> Same methods are in globalDefinitions_gcc.hpp, >>>>> globalDefinitions_sparcWorks.hpp, globalDefinitions_xlc.hpp. Because >>>>> they are not compiler specific, I moved the methods into >>>>> globalDefinitions.hpp. The casts are now implemented using a union. >>>>> >>>>> Testing: Parfait, JPRT >>>>> >>>>> Thanks, >>>>> Tobias >> From tobias.hartmann at oracle.com Mon Jul 28 05:57:48 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 28 Jul 2014 07:57:48 +0200 Subject: [9] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53D2814F.90204@oracle.com> References: <53CF98B1.9070508@oracle.com> <53CFF7C8.3090207@oracle.com> <0C5D34F8-1006-4EB7-9558-8596E496DC6A@oracle.com> <53D00EF1.7010506@oracle.com> <53D02558.5040801@oracle.com> <53D0D644.1020100@oracle.com> <53D12AB3.4020005@oracle.com> <53D204D4.2090409@oracle.com> <53D2814F.90204@oracle.com> Message-ID: <53D5E65C.6010304@oracle.com> Thank you, Vladimir. Best, Tobias On 25.07.2014 18:09, Vladimir Kozlov wrote: > On 7/25/14 12:18 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >> On 24.07.2014 17:48, Vladimir Kozlov wrote: >>> Do we trust that C++ compilers keep declared order of int fields? Is >>> it in spec? If yes I am fine with your last code. >> >> Yes, sentence 13 of Section 9.2. (page 217) of the latest C++ >> standard working draft [1] says: >> >> "Nonstatic data members of a (non-union) class with the same access >> control (Clause 11) are allocated so that later >> members have higher addresses within a class object. The order of >> allocation of non-static data members with different >> access control is unspecified (Clause 11). [...]" >> >> We do not have any access control specifiers, so it should be fine. > > Good. Thank you for looking to this. > > Vladimir > >> >> Thanks, >> Tobias >> >> [1] https://isocpp.org/files/papers/N3797.pdf >> >>> > typedef union { >>> > } DoubleIntConv; >>> > But that does not really improve code readability... What do you >>> think? >>> >>> It is fine, we do that. >>> >>> > I refactored the code and added set_high(..) and set_low(..) >>> methods (similar to the ones defined in >>> globalDefinitions.hpp). >>> > >>> > New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.03 >>> >>> I like set_* methods. This webrev.03 looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/24/14 2:47 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> Vladimir, David, thanks for the review. Please see comments inline. >>>> >>>>>> Tobias, why you are creating local copy 'conv' of a variable in >>>>>> all places? >>>> >>>> Doing it like this >>>> >>>> __HI(x) = (__HI(x)&0x7fffffff)|(__HI(y)&0x80000000); >>>> return x; >>>> >>>> Parfait still complained that a 32 bit value is assigned to x and >>>> it is then used as a 64 bit value. That's why I had to >>>> create a local copy of 'conv'. >>>> >>>> On 23.07.2014 21:30, David Chase wrote: >>>>> Vladimir, I think the mistake is instead to include the cast to >>>>> the type that it already is. >>>> >>>> True, the cast is not necessary. >>>> >>>> On 23.07.2014 23:12, Vladimir Kozlov wrote: >>>>> Or you can use union with jlong and don't mess with ENDIAN at all. >>>>> 64-bit is now main platform now. >>>>> >>>>> Vladimir >>>> >>>> How do we access the low and high bits then? >>> >>> >>>> >>>>> On 7/23/14 1:00 PM, David Chase wrote: >>>>>> It occurred to me that a cleaner way is to put the ifdef in the >>>>>> definition of the union: >>>>>> >>>>>> typedef union { >>>>>> double d; >>>>>> struct { >>>>>> #ifdef VM_LITTLE_ENDIAN >>>>>> int lo; >>>>>> int hi; >>>>>> #else >>>>>> int hi; >>>>>> int lo; >>>>>> #endif >>>>>> }; >>>>>> } DoubleIntConv; >>>>>> >>>>>> # define __HI(x) (x.hi) >>>>>> # define __LO(x) (x.lo) >>>>>> >>>>>> At which point, the continued use of the macro starts to look >>>>>> perhaps a hair silly. >>>>>> >>>>>> I was inspired to write the following test program and compile it >>>>>> under clang and gcc (but not under Solaris Studio >>>>>> yet) to see if we could instead just write a stinking static >>>>>> method (that would be inlined) and at clang -O3 and gcc >>>>>> -O4, it was indeed inlined. So we could just write clean code >>>>>> and to heck with the macro. >>>> >>>> I like this solution because in my opinion it is the most readable >>>> one and it is always a good idea to remove ugly >>>> macros. If the potential slowdown in slowdebug builds is not a >>>> problem I would like to stick to this. >>>> >>>> I removed the macros and changed all parts of the code that used >>>> them (unfortunately quite a lot). >>>> >>>> The parfait warnings in the files sharedRuntimeMath.hpp, >>>> sharedRutimeTrans.cpp and sharedRuntimeTrigg.cpp were reduced >>>> by 12. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.02 >>>> >>>> The problem with this solution is that some of the compilers do not >>>> support anonymous structs. We could name the struct >>>> and access it via the name, for example like this: >>>> >>>> typedef union { >>>> double d; >>>> struct { >>>> #ifdef VM_LITTLE_ENDIAN >>>> int lo; >>>> int hi; >>>> #else >>>> int hi; >>>> int lo; >>>> #endif >>>> } i; >>>> } DoubleIntConv; >>>> >>>> DoubleIntConv conv = { x }; >>>> int high = conv.i.hi; >>>> >>>> But that does not really improve code readability... What do you >>>> think? >>>> >>>> Thanks, >>>> Tobias >>>> >>>>>> (Aren?t you loving this review process? :-) >>>> >>>> Yes, thanks for all the testing :) >>>> >>>> Best, >>>> Tobias >>>> >>>>>> >>>>>> We would, however, suffer some slowdown in slowdebug builds. >>>>>> ---------------------- >>>>>> #define VM_LITTLE_ENDIAN 1 >>>>>> typedef union { >>>>>> double d; >>>>>> struct { >>>>>> #ifdef VM_LITTLE_ENDIAN >>>>>> int lo; >>>>>> int hi; >>>>>> #else >>>>>> int hi; >>>>>> int lo; >>>>>> #endif >>>>>> }; >>>>>> } DoubleIntConv; >>>>>> >>>>>> # define __HI(x) (x.hi) >>>>>> # define __LO(x) (x.lo) >>>>>> >>>>>> static int inline_low(double d) { >>>>>> DoubleIntConv x = { d } ; >>>>>> return __LO(x); >>>>>> } >>>>>> >>>>>> static int inline_high(double d) { >>>>>> DoubleIntConv x = { d } ; >>>>>> return __HI(x); >>>>>> } >>>>>> >>>>>> int low(double d) { >>>>>> return inline_low(d); >>>>>> } >>>>>> >>>>>> int high(double d) { >>>>>> return inline_high(d); >>>>>> } >>>>>> ---------------------- >>>>>> >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 3:37 PM, Vladimir Kozlov >>>>>> wrote: >>>>>> >>>>>>> David, I agree with your suggestion to pass union to _HI and >>>>>>> _LO. The creation of a local union var makes sense then. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 7/23/14 12:30 PM, David Chase wrote: >>>>>>>> Vladimir, I think the mistake is instead to include the cast to >>>>>>>> the type >>>>>>>> that it already is. >>>>>>>> I think performing the cast to the union type from a non-union >>>>>>>> address >>>>>>>> might get you a warning otherwise. >>>>>>>> I can confirm that if you write it plainly with the assignment >>>>>>>> to a >>>>>>>> correctly typed ?conv? >>>>>>>> that clang (at least) generates good code: >>>>>>>> >>>>>>>> union ca { >>>>>>>> double d; >>>>>>>> int i[2]; >>>>>>>> }; >>>>>>>> >>>>>>>> int la(double d) { >>>>>>>> union ca x = { d } ; >>>>>>>> return x.i[0]; >>>>>>>> } >>>>>>>> >>>>>>>> clang produces (-O3 -S, cleaned up) >>>>>>>> >>>>>>>> _la: ## @la >>>>>>>> pushq %rbp >>>>>>>> movq %rsp, %rbp >>>>>>>> movd %xmm0, %rax >>>>>>>> popq %rbp >>>>>>>> ret >>>>>>>> gcc 4.8.1 produces (-O4 -S, cleaned up) >>>>>>>> >>>>>>>> la: >>>>>>>> movsd%xmm0, -8(%rsp) >>>>>>>> movq-8(%rsp), %rax >>>>>>>> ret >>>>>>>> >>>>>>>> So I think this is generally a good idea, but the macro should be >>>>>>>> cleaned up to >>>>>>>> remove the cast that is certainly unnecessary now. E.g. >>>>>>>> >>>>>>>> 39 #ifdef VM_LITTLE_ENDIAN >>>>>>>> 40 # define __HI(x) ((x).i[1]) >>>>>>>> 41 # define __LO(x) ((x).i[0]) >>>>>>>> 42 #else >>>>>>>> 43 # define __HI(x) (x.i[0]) >>>>>>>> 44 # define __LO(x) (x.i[1]) >>>>>>>> 45 #endif >>>>>>>> >>>>>>>> The temporary is only annoying to humans using a last-millenium >>>>>>>> dialect >>>>>>>> of C. The code runs fast, and the address-of+dereference in >>>>>>>> the macro >>>>>>>> forced it to memory (lacking a lot of alias analysis) anyhow. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>> On Jul 23, 2014, at 1:58 PM, Vladimir Kozlov >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Tobias, why you are creating local copy 'conv' of a variable >>>>>>>>> in all >>>>>>>>> places? >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 7/23/14 4:12 AM, Tobias Hartmann wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please review the following patch for JDK- 8049043 (Parfait >>>>>>>>>> warning). >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.01/ >>>>>>>>>> >>>>>>>>>> Problem: >>>>>>>>>> Parfait issues 6 warnings " Load variable through a pointer >>>>>>>>>> of an >>>>>>>>>> incompatible type" because of the __HI(x) and __LO(x) macros >>>>>>>>>> used in >>>>>>>>>> copysignA and scalbnA >>>>>>>>>> (share/vm/runtime/sharedRuntimeMath.hpp) to cast >>>>>>>>>> between double* and int*. >>>>>>>>>> >>>>>>>>>> Solution: >>>>>>>>>> A union 'DoubleIntConv' is used to access the high and low 32 >>>>>>>>>> bits of a >>>>>>>>>> double. >>>>>>>>>> The '# pragma warning( disable: 4748 )' in >>>>>>>>>> sharedRuntimeTrans.cpp is >>>>>>>>>> necessary because otherwise the VS compiler fails with the >>>>>>>>>> following >>>>>>>>>> warning: "/GS can not protect parameters and local variables >>>>>>>>>> from local >>>>>>>>>> buffer overrun because optimizations are disabled in >>>>>>>>>> function". There >>>>>>>>>> exists a bug to fix this [1]. >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> JPRT, Parfait (all 6 warnings removed) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8046696 >>>>>> >>>> >> From roland.westrelin at oracle.com Tue Jul 29 02:07:49 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 29 Jul 2014 04:07:49 +0200 Subject: 8046698: assert(false) failed: only Initialize or AddP expected macro.cpp:943 In-Reply-To: <53C4146D.8080804@oracle.com> References: <539B2263.3070007@oracle.com> <53C4146D.8080804@oracle.com> Message-ID: <87oaw8x6h6.fsf@oracle.com> Thanks for the review, Vladimir. Anyone else for another review? Roland. > Yes, this version looks good I think. > > Thanks, > Vladimir > > On 6/17/14 8:33 AM, Roland Westrelin wrote: >> Thanks for reviewing this, Vladimir. >> >>> May be we should return 'this' when anything but CheckCastPP, Initialize, AddP references the raw result of Allocate? >>> See lines 2882-2899 in escape.cpp. Returning NULL when the result is referenced in other cases is bad because NULL is indication of it is not used after Initialize (lines 2792-2804 in escape.cpp). >>> >>> Could you investigate more? May be add assert to catch all cases. It could be the fix is correct because only Phi nodes could reference it. >> >> I ran ctw, refworkload reference_server, all jtreg tests, and ute?s nsk.stress, vm.compiler, vm.regression, nsk.regression, nsk.monitoring with an assert to catch uses other than CheckCastPP, Initialize, AddP. The only other use I found was a Phi for the test case that this change fixes. >> >> Should I go with this as a fix? >> >> http://cr.openjdk.java.net/~roland/8046698/webrev.01/ >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 6/13/14 8:31 AM, Roland Westrelin wrote: >>>> >>>> Because of a try/catch in a loop, a Allocate node is in the loop body while the uses of the results are outside the loop (see test case in webrev). Then loop unswitching clones the loop body (including the Allocate but not the Initialization node and other uses of the result projection) and adds a Phi to connect the Allocate nodes to the loop exit. CallNode::result_cast() doesn?t expect a Phi as output so returns NULL which to the allocation elimination code means no use for the allocation (allocation can be eliminated). The fix changes CallNode::result_cast() so it returns the CallNode when the result projection has a Phi as output which causes the allocation elimination code to skip that allocation. Every call to result_cast() is already followed by a check for is_CheckCastPP() so no other change is needed. >>>> >>>> http://cr.openjdk.java.net/~roland/8046698/webrev.00/ >>>> >>>> Roland. >>>> >> From vladimir.kozlov at oracle.com Tue Jul 29 17:54:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Jul 2014 10:54:20 -0700 Subject: [9] RFR (XS) 8049252: VerifyStack logic in Deoptimization::unpack_frames does not expect to see invoke bc at the top frame during normal deoptimization Message-ID: <53D7DFCC.8040507@oracle.com> http://cr.openjdk.java.net/~kvn/8049252/webrev/ https://bugs.openjdk.java.net/browse/JDK-8049252 The check in VerifyStack code was not updated when we added reexecute flag for C2 intrinsic code. C2 uses the flag for intrinsics to reexecute the call which is intrinsified. Such intrinsics (clone(), copyOf()) have runtime calls to allocate new object and a normal deoptimization may happen on the return from these calls. VerifyStack code does not check for such case. Add missing check for reexecute flag to VerifyStack code. Tested in JPRT with all test/compiler tests and VerifyStack flags switched on by default. Thanks, Vladimir From roland.westrelin at oracle.com Tue Jul 29 20:28:09 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 29 Jul 2014 22:28:09 +0200 Subject: RFR (S) : 8051484 : Test compiler/6932496/Test6932496.java failed to compile after JDK-8011044: 1.5 is no longer supported In-Reply-To: <53CED15C.8070909@oracle.com> References: <53CEC3D3.9070202@oracle.com> <53CECDF7.3040205@oracle.com> <53CED15C.8070909@oracle.com> Message-ID: <87fvhjap0m.fsf@oracle.com> > updated webrev: http://cr.openjdk.java.net/~iignatyev/8051484/webrev.01/ That looks good to me. Roland. From roland.westrelin at oracle.com Tue Jul 29 20:31:59 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 29 Jul 2014 22:31:59 +0200 Subject: [9] RFR (XS) 8049252: VerifyStack logic in Deoptimization::unpack_frames does not expect to see invoke bc at the top frame during normal deoptimization In-Reply-To: <53D7DFCC.8040507@oracle.com> References: <53D7DFCC.8040507@oracle.com> Message-ID: <87d2cnaou8.fsf@oracle.com> > http://cr.openjdk.java.net/~kvn/8049252/webrev/ That looks good to me. Roland. From vladimir.kozlov at oracle.com Tue Jul 29 20:38:41 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Jul 2014 13:38:41 -0700 Subject: [9] RFR (XS) 8049252: VerifyStack logic in Deoptimization::unpack_frames does not expect to see invoke bc at the top frame during normal deoptimization In-Reply-To: <87d2cnaou8.fsf@oracle.com> References: <53D7DFCC.8040507@oracle.com> <87d2cnaou8.fsf@oracle.com> Message-ID: <53D80651.9050302@oracle.com> Thank you, Roland Vladimir On 7/29/14 1:31 PM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~kvn/8049252/webrev/ > > That looks good to me. > > Roland. > From tobias.hartmann at oracle.com Wed Jul 30 10:47:18 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 30 Jul 2014 12:47:18 +0200 Subject: [9] RFR(XS): 8053915: bigapps assert failure in C2: modified node is not on IGVN._worklist Message-ID: <53D8CD36.8050207@oracle.com> Hi, please review the following patch that fixes JDK-8053915. Bug: https://bugs.openjdk.java.net/browse/JDK-8053915 Webrev: http://cr.openjdk.java.net/~thartmann/8053915/webrev.00/ == Problem == The assert in 'PhaseIterGVN::init_verifyPhaseIterGVN' is hit because a 'CountedLoopEndNode' is modified during optimization but not added to the IGVN worklist. The node is modified in 'PhaseIdealLoop::do_range_check' because the incoming BoolNode is shared and replaced by a local copy. == Solution== The node is added to the IGVN worklist. == Testing == - Weblogic + Medrec - JPRT Thanks, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Jul 30 15:37:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jul 2014 08:37:26 -0700 Subject: [9] RFR(XS): 8053915: bigapps assert failure in C2: modified node is not on IGVN._worklist In-Reply-To: <53D8CD36.8050207@oracle.com> References: <53D8CD36.8050207@oracle.com> Message-ID: <53D91136.9090202@oracle.com> Good. Thanks, Vladimir On 7/30/14 3:47 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that fixes JDK-8053915. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8053915 > Webrev: http://cr.openjdk.java.net/~thartmann/8053915/webrev.00/ > > == Problem == > The assert in 'PhaseIterGVN::init_verifyPhaseIterGVN' is hit because a 'CountedLoopEndNode' is modified during > optimization but not added to the IGVN worklist. The node is modified in 'PhaseIdealLoop::do_range_check' because the > incoming BoolNode is shared and replaced by a local copy. > > == Solution== > The node is added to the IGVN worklist. > > == Testing == > - Weblogic + Medrec > - JPRT > > Thanks, > Tobias From vladimir.kozlov at oracle.com Wed Jul 30 16:40:03 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jul 2014 09:40:03 -0700 Subject: segfault with 8u5 In-Reply-To: References: <53768534.7050601@oracle.com> Message-ID: <53D91FE3.4020403@oracle.com> 8029381 was fixed in jdk9 and 8u20 (which should be release soon): http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0b9500028980 I will look on C2 crash more. I don't remember any recent problems in catch_inline_exceptions(). Regards, Vladimir On 5/19/14 12:24 PM, Martin Traverso wrote: > The failure happened in C1 JIT compiler (first tier). You can try to switch off -XX:-TieredCompilation. > > > That seemed to have worked around this particular issue. > > However, we ran into another crash: > > Stack: [0x00000000430c8000,0x00000000431c9000], sp=0x00000000431c5980, free space=1014k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > > V [libjvm.so+0x814115] LoadKlassNode::make(PhaseGVN&, Node*, Node*, TypePtr const*, TypeKlassPtr const*)+0x45 > V [libjvm.so+0x51ab06] Parse::catch_inline_exceptions(SafePointNode*)+0x936 > > V [libjvm.so+0x8c1a5a] Parse::do_exceptions()+0xba > V [libjvm.so+0x8c6100] Parse::do_one_block()+0x180 > V [libjvm.so+0x8c6377] Parse::do_all_blocks()+0x127 > V [libjvm.so+0x8c95d3] Parse::Parse(JVMState*, ciMethod*, float, Parse*)+0x15a3 > V [libjvm.so+0x3b6529] ParseGenerator::generate(JVMState*, Parse*)+0x99 > V [libjvm.so+0x3b7202] PredictedCallGenerator::generate(JVMState*, Parse*)+0x2a2 > V [libjvm.so+0x51aefd] Parse::do_call()+0x1cd > V [libjvm.so+0x8d3c7a] Parse::do_one_bytecode()+0x32da > V [libjvm.so+0x8c60f8] Parse::do_one_block()+0x178 > > V [libjvm.so+0x8c6377] Parse::do_all_blocks()+0x127 > V [libjvm.so+0x8c95d3] Parse::Parse(JVMState*, ciMethod*, float, Parse*)+0x15a3 > > V [libjvm.so+0x3b6529] ParseGenerator::generate(JVMState*, Parse*)+0x99 > V [libjvm.so+0x46111c] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x128c > > V [libjvm.so+0x3b5008] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x198 > V [libjvm.so+0x46982a] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc8a > > V [libjvm.so+0x46c230] CompileBroker::compiler_thread_loop()+0x620 > V [libjvm.so+0x9e303f] JavaThread::thread_main_inner()+0xdf > > V [libjvm.so+0x9e3205] JavaThread::run()+0x1b5 > V [libjvm.so+0x8a00c8] java_start(Thread*)+0x108 > > > > Full dump here: https://gist.github.com/martint/783cf3e30c17fc897423 > > > The only bug I found which could be related is next: > > https://bugs.openjdk.java.net/__browse/JDK-8029381 > > > Unfortunately, I can't see this bug report. I get redirected to the login screen. > > > Thanks! > Martin > From roland.westrelin at oracle.com Wed Jul 30 16:47:55 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 30 Jul 2014 18:47:55 +0200 Subject: [9] RFR(XS): 8053915: bigapps assert failure in C2: modified node is not on IGVN._worklist In-Reply-To: <53D8CD36.8050207@oracle.com> References: <53D8CD36.8050207@oracle.com> Message-ID: <87bns6hjyc.fsf@oracle.com> > Webrev: http://cr.openjdk.java.net/~thartmann/8053915/webrev.00/ Looks good. Roland. From aleksey.shipilev at oracle.com Wed Jul 30 17:20:21 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 30 Jul 2014 10:20:21 -0700 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53D0013B.4090603@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> Message-ID: <53D92955.1020407@oracle.com> On 07/23/2014 11:38 AM, Aleksey Shipilev wrote: > On 07/23/2014 01:38 AM, Aleksey Shipilev wrote: >> * 1x4x1 Intel Core (Haswell-DT) benefits from offsetting %esp as well. >> There is an interesting hump on lower backoffs with addl (%esp-8), which >> seems to be a second-order microarchitectural effect. Unfortunately, we >> don't have large Haswells available at the moment to dive into this: >> http://cr.openjdk.java.net/~shade/8050147/micros/Intel-Haswell.data.png > > Finally managed to get the profile on this Haswell. The hottest loops > are identical, although the second variant is consistently better. > > This produces 1200.318 +- 18.520 ns/op: > > 2.65% 0x00007fdcb87190b0: mov (%rsp),%r10 > 0x00007fdcb87190b4: mov 0xc(%r10),%r10d > 0.06% 0x00007fdcb87190b8: mov %r10d,0xc(%rbp) > 2.66% 0x00007fdcb87190bc: lock addl $0x0,-0x8(%rsp) > 80.08% 95.59% 0x00007fdcb87190c2: mov %rbp,%rsi > 0x00007fdcb87190c5: xchg %ax,%ax > 0x00007fdcb87190c7: callq 0x00007fdcb85d7fe0 > 0x00007fdcb87190cc: test %eax,%eax > 0x00007fdcb87190ce: jne 0x00007fdcb87190b0 > > This produces 891.427 +- 15.277 ns/op: > > 3.52% 0.02% 0x00007ffa3918f030: mov (%rsp),%r10 > 0x00007ffa3918f034: mov 0xc(%r10),%r10d > 0.07% 0x00007ffa3918f038: mov %r10d,0xc(%rbp) > 3.68% 0x00007ffa3918f03c: lock addl $0x0,-0x48(%rsp) > 76.54% 97.13% 0x00007ffa3918f042: mov %rbp,%rsi > 0x00007ffa3918f045: xchg %ax,%ax > 0x00007ffa3918f047: callq 0x00007ffa39045fe0 > 0x00007ffa3918f04c: test %eax,%eax > 0x00007ffa3918f04e: jne 0x00007ffa3918f030 > > Full logs here: > http://cr.openjdk.java.net/~shade/8050147/haswell-barrier2.perfasm > http://cr.openjdk.java.net/~shade/8050147/haswell-barrier3.perfasm > > It is puzzling to me why do we have the difference here. In the logs > there, you may see the second-hottest method, looping(), which is called > in this busy loop. It does: > > 2.60% 0x00007fdcb871b200: sub $0x18,%rsp > 0x00007fdcb871b207: mov %rbp,0x10(%rsp) > > ...which seems to callee-save %rbp to (%rsp-8)? Any pointers how we > manage the stack in callees? It would seem we need to step back more > than -8 to dodge callee-saves, but how much? > > It seems odd this affects Haswell so much. I've checked on my > SandyBridge laptop, and we have the same code, but performance is > consistent. Barring that, it would seem like some the second-order > microarchitectural effect on Haswell. ...which makes me say this is the > mode we should switch to: > >> ...or "lock addl (%esp-CL-8), 0), pessimistically padding away from >> stack users: >> http://cr.openjdk.java.net/~shade/8050147/webrev.02/ Ping. Anyone? -Aleksey. From vladimir.kozlov at oracle.com Wed Jul 30 17:29:40 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jul 2014 10:29:40 -0700 Subject: segfault with 8u5 In-Reply-To: <53D91FE3.4020403@oracle.com> References: <53768534.7050601@oracle.com> <53D91FE3.4020403@oracle.com> Message-ID: <53D92B84.5030509@oracle.com> Martin, It would be also nice if you can build fastdebug VM and run with it. cd hotspot/make; make fastdebug LP64=1 Thanks, Vladimir On 7/30/14 9:40 AM, Vladimir Kozlov wrote: > 8029381 was fixed in jdk9 and 8u20 (which should be release soon): > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0b9500028980 > > I will look on C2 crash more. I don't remember any recent problems in > catch_inline_exceptions(). > > Regards, > Vladimir > > On 5/19/14 12:24 PM, Martin Traverso wrote: >> The failure happened in C1 JIT compiler (first tier). You can try >> to switch off -XX:-TieredCompilation. >> >> >> That seemed to have worked around this particular issue. >> >> However, we ran into another crash: >> >> Stack: [0x00000000430c8000,0x00000000431c9000], sp=0x00000000431c5980, >> free space=1014k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> >> V [libjvm.so+0x814115] LoadKlassNode::make(PhaseGVN&, Node*, Node*, >> TypePtr const*, TypeKlassPtr const*)+0x45 >> V [libjvm.so+0x51ab06] >> Parse::catch_inline_exceptions(SafePointNode*)+0x936 >> >> V [libjvm.so+0x8c1a5a] Parse::do_exceptions()+0xba >> V [libjvm.so+0x8c6100] Parse::do_one_block()+0x180 >> V [libjvm.so+0x8c6377] Parse::do_all_blocks()+0x127 >> V [libjvm.so+0x8c95d3] Parse::Parse(JVMState*, ciMethod*, float, >> Parse*)+0x15a3 >> V [libjvm.so+0x3b6529] ParseGenerator::generate(JVMState*, Parse*)+0x99 >> V [libjvm.so+0x3b7202] PredictedCallGenerator::generate(JVMState*, >> Parse*)+0x2a2 >> V [libjvm.so+0x51aefd] Parse::do_call()+0x1cd >> V [libjvm.so+0x8d3c7a] Parse::do_one_bytecode()+0x32da >> V [libjvm.so+0x8c60f8] Parse::do_one_block()+0x178 >> >> V [libjvm.so+0x8c6377] Parse::do_all_blocks()+0x127 >> V [libjvm.so+0x8c95d3] Parse::Parse(JVMState*, ciMethod*, float, >> Parse*)+0x15a3 >> >> V [libjvm.so+0x3b6529] ParseGenerator::generate(JVMState*, Parse*)+0x99 >> V [libjvm.so+0x46111c] Compile::Compile(ciEnv*, C2Compiler*, >> ciMethod*, int, bool, bool, bool)+0x128c >> >> V [libjvm.so+0x3b5008] C2Compiler::compile_method(ciEnv*, ciMethod*, >> int)+0x198 >> V [libjvm.so+0x46982a] >> CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc8a >> >> V [libjvm.so+0x46c230] CompileBroker::compiler_thread_loop()+0x620 >> V [libjvm.so+0x9e303f] JavaThread::thread_main_inner()+0xdf >> >> V [libjvm.so+0x9e3205] JavaThread::run()+0x1b5 >> V [libjvm.so+0x8a00c8] java_start(Thread*)+0x108 >> >> >> >> Full dump here: https://gist.github.com/martint/783cf3e30c17fc897423 >> >> >> The only bug I found which could be related is next: >> >> https://bugs.openjdk.java.net/__browse/JDK-8029381 >> >> >> >> Unfortunately, I can't see this bug report. I get redirected to the >> login screen. >> >> >> Thanks! >> Martin >> From roland.westrelin at oracle.com Wed Jul 30 20:43:58 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 30 Jul 2014 22:43:58 +0200 Subject: RFR(S): 8043125: compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type Message-ID: <878unah90x.fsf@oracle.com> Speculative traps recorded in a MethodData can be removed at a safepoint. During a compilation, as an MethoData is copied and translated by a compiler thread to build a ciMethodData, a safepoint can occur as speculative traps are being copied, and speculative traps may be removed. I fixed this by adding a flag to the MDO that is set when speculative traps are removed. The code that copies the speculative traps to the ciMethodData, checks the flag as it iterates over the traps and if it detects a change, it starts the copy over. I took this opportunity to clean the code a bit: args_data_limit() points right after the last ArgInfoData entry while extra_data_limit() points after the parameters profiling area. http://cr.openjdk.java.net/~roland/8043125/webrev.00/ Roland. From tobias.hartmann at oracle.com Thu Jul 31 06:36:00 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 31 Jul 2014 08:36:00 +0200 Subject: [9] RFR(XS): 8053915: bigapps assert failure in C2: modified node is not on IGVN._worklist In-Reply-To: <87bns6hjyc.fsf@oracle.com> References: <53D8CD36.8050207@oracle.com> <87bns6hjyc.fsf@oracle.com> Message-ID: <53D9E3D0.7050506@oracle.com> Vladimir, Roland, thanks for the review. Best, Tobias On 30.07.2014 18:47, Roland Westrelin wrote: >> Webrev: http://cr.openjdk.java.net/~thartmann/8053915/webrev.00/ > Looks good. > > Roland. From tobias.hartmann at oracle.com Thu Jul 31 12:35:19 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 31 Jul 2014 14:35:19 +0200 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison Message-ID: <53DA3807.50501@oracle.com> Hi, please review the following patch that fixes JDK-8043284. Bug: https://bugs.openjdk.java.net/browse/JDK-8043284 Webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.00/ == Problem == Similar to the previous implementation of unsigned integer comparison (see JDK- 8042786), signed integer comparison does only consider the general integer range [MinInt, MaxInt] instead of two ranges when comparing the result of an overflowing AddI/SubI. However, there are situations where one can prove that both resulting ranges are unequal to the tested value (see 'TestIntegerComparison::testSigned' in the webrev). In this case the comparison can be optimized. == Solution == Similar to the fix for JDK-8042786 we compute both type ranges if the add/sub overflows and compare them to the tested value. If we can prove that the value is always unequal, we replace the BoolNode by true or false (depending on the test). A jtreg test is added that triggers both the unsigned as well as the signed optimization. == Testing == - Jtreg test (TestIntegerComparison) - JPRT Thanks, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From morris.meyer at oracle.com Thu Jul 31 15:48:58 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 31 Jul 2014 11:48:58 -0400 Subject: RFR(XS): JDK-8040921: Uninitialised memory in hotspot/src/share/vm/c1/c1_LinearScan.cpp In-Reply-To: <53CEE865.6040504@oracle.com> References: <53555C8D.7090406@oracle.com> <80C84BCB-1E02-4668-9B5C-7D351BB922E9@oracle.com> <53613588.8000306@oracle.com> <305D7E38-B9F1-4A89-8C92-805DFC62DA4B@oracle.com> <536293B4.8040601@oracle.com> <3723EF44-4D7B-4E12-AA83-45EF7DA8645B@oracle.com> <53CEBF9E.7080207@oracle.com> <53CEE865.6040504@oracle.com> Message-ID: <53DA656A.5040202@oracle.com> Vladimir, I found that you cannot move the variables and initialization down to the use, as the cpu_lsw.walk() // IntervalWalker.walk_to() code changes the intervals and causes an assertion failure in LinearScan::is_sorted(). I've commented the code to note that the code cannot be moved down to where it is used. Thanks, --morris WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.08 BUG - https://bugs.openjdk.java.net/browse/JDK-8040921 On 7/22/14, 6:40 PM, Vladimir Kozlov wrote: > You did not do for fpu registers what Christian said: > > "We should move the variables and initialization down to the use" > > Vladimir > > On 7/22/14 12:46 PM, Morris Meyer wrote: >> Folks, >> >> Could I get a review of this parfait issue. It has been tested through >> JPRT. >> >> Thanks! >> >> --morris >> >> JBS - http://bugs.openjdk.java.net/browse/JDK-8040921 >> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.07 >> >> On 5/1/14, 9:51 PM, Christian Thalinger wrote: >>> >>> On May 1, 2014, at 8:34 AM, Morris Meyer >> > wrote: >>> >>>> The parfait error is with the ASSERT define blocking out >>>> initialization of a the fpu structures when that code path is enabled. >>>> >>>> I've removed the ifdef such that both paths initialized their cpu and >>>> fpu variables, and the assertion is always checked. >>> >>> But the code path using the uninitialized variables is also under: >>> >>> 1648 if (has_fpu_registers()) { >>> >>> Am I missing something? Anyway, during an earlier internal review I >>> said we should keep the assert; I take that back. We should move the >>> variables and initialization down to the use and remove the assert. >>> It doesn?t have much value anyway. >>> >>>> >>>> --mm >>>> >>>> On 4/30/14, 3:36 PM, Christian Thalinger wrote: >>>>> I don?t understand the Parfait error here. Could you explain? >>>>> >>>>> On Apr 30, 2014, at 7:40 AM, Morris Meyer >>>> > wrote: >>>>> >>>>>> Folks, >>>>>> >>>>>> Could I get a review for this Parfait uninitialized variable issue? >>>>>> This has been tested with JPRT and a clear pass with Parfait. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> --mm >>>>>> >>>>>> BUG - https://bugs.openjdk.java.net/browse/JDK-8040921 >>>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.05 >>>>>> >>>>>> >>>>>> >>>> >>> >> From vladimir.kozlov at oracle.com Thu Jul 31 15:51:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Jul 2014 08:51:36 -0700 Subject: RFR(XS): JDK-8040921: Uninitialised memory in hotspot/src/share/vm/c1/c1_LinearScan.cpp In-Reply-To: <53DA656A.5040202@oracle.com> References: <53555C8D.7090406@oracle.com> <80C84BCB-1E02-4668-9B5C-7D351BB922E9@oracle.com> <53613588.8000306@oracle.com> <305D7E38-B9F1-4A89-8C92-805DFC62DA4B@oracle.com> <536293B4.8040601@oracle.com> <3723EF44-4D7B-4E12-AA83-45EF7DA8645B@oracle.com> <53CEBF9E.7080207@oracle.com> <53CEE865.6040504@oracle.com> <53DA656A.5040202@oracle.com> Message-ID: <53DA6608.4050906@oracle.com> Morris, You left debug printing in changes. Vladimir On 7/31/14 8:48 AM, Morris Meyer wrote: > Vladimir, > > I found that you cannot move the variables and initialization down to the use, as the cpu_lsw.walk() // > IntervalWalker.walk_to() code changes the intervals and causes an assertion failure in LinearScan::is_sorted(). > > I've commented the code to note that the code cannot be moved down to where it is used. > > Thanks, > > --morris > > WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.08 > BUG - https://bugs.openjdk.java.net/browse/JDK-8040921 > > > On 7/22/14, 6:40 PM, Vladimir Kozlov wrote: >> You did not do for fpu registers what Christian said: >> >> "We should move the variables and initialization down to the use" >> >> Vladimir >> >> On 7/22/14 12:46 PM, Morris Meyer wrote: >>> Folks, >>> >>> Could I get a review of this parfait issue. It has been tested through >>> JPRT. >>> >>> Thanks! >>> >>> --morris >>> >>> JBS - http://bugs.openjdk.java.net/browse/JDK-8040921 >>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.07 >>> >>> On 5/1/14, 9:51 PM, Christian Thalinger wrote: >>>> >>>> On May 1, 2014, at 8:34 AM, Morris Meyer >>> > wrote: >>>> >>>>> The parfait error is with the ASSERT define blocking out >>>>> initialization of a the fpu structures when that code path is enabled. >>>>> >>>>> I've removed the ifdef such that both paths initialized their cpu and >>>>> fpu variables, and the assertion is always checked. >>>> >>>> But the code path using the uninitialized variables is also under: >>>> >>>> 1648 if (has_fpu_registers()) { >>>> >>>> Am I missing something? Anyway, during an earlier internal review I >>>> said we should keep the assert; I take that back. We should move the >>>> variables and initialization down to the use and remove the assert. >>>> It doesn?t have much value anyway. >>>> >>>>> >>>>> --mm >>>>> >>>>> On 4/30/14, 3:36 PM, Christian Thalinger wrote: >>>>>> I don?t understand the Parfait error here. Could you explain? >>>>>> >>>>>> On Apr 30, 2014, at 7:40 AM, Morris Meyer >>>>> > wrote: >>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> Could I get a review for this Parfait uninitialized variable issue? >>>>>>> This has been tested with JPRT and a clear pass with Parfait. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> --mm >>>>>>> >>>>>>> BUG - https://bugs.openjdk.java.net/browse/JDK-8040921 >>>>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.05 >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> > From morris.meyer at oracle.com Thu Jul 31 16:23:31 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 31 Jul 2014 12:23:31 -0400 Subject: RFR(XS): JDK-8040921: Uninitialised memory in hotspot/src/share/vm/c1/c1_LinearScan.cpp In-Reply-To: <53DA6608.4050906@oracle.com> References: <53555C8D.7090406@oracle.com> <80C84BCB-1E02-4668-9B5C-7D351BB922E9@oracle.com> <53613588.8000306@oracle.com> <305D7E38-B9F1-4A89-8C92-805DFC62DA4B@oracle.com> <536293B4.8040601@oracle.com> <3723EF44-4D7B-4E12-AA83-45EF7DA8645B@oracle.com> <53CEBF9E.7080207@oracle.com> <53CEE865.6040504@oracle.com> <53DA656A.5040202@oracle.com> <53DA6608.4050906@oracle.com> Message-ID: <53DA6D83.6070308@oracle.com> Vladimir, Sorry about that. Changes fixed inline. --mm WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.08 On 7/31/14, 11:51 AM, Vladimir Kozlov wrote: > Morris, > > You left debug printing in changes. > > Vladimir > > On 7/31/14 8:48 AM, Morris Meyer wrote: >> Vladimir, >> >> I found that you cannot move the variables and initialization down to >> the use, as the cpu_lsw.walk() // >> IntervalWalker.walk_to() code changes the intervals and causes an >> assertion failure in LinearScan::is_sorted(). >> >> I've commented the code to note that the code cannot be moved down to >> where it is used. >> >> Thanks, >> >> --morris >> >> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.08 >> BUG - https://bugs.openjdk.java.net/browse/JDK-8040921 >> >> >> On 7/22/14, 6:40 PM, Vladimir Kozlov wrote: >>> You did not do for fpu registers what Christian said: >>> >>> "We should move the variables and initialization down to the use" >>> >>> Vladimir >>> >>> On 7/22/14 12:46 PM, Morris Meyer wrote: >>>> Folks, >>>> >>>> Could I get a review of this parfait issue. It has been tested through >>>> JPRT. >>>> >>>> Thanks! >>>> >>>> --morris >>>> >>>> JBS - http://bugs.openjdk.java.net/browse/JDK-8040921 >>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.07 >>>> >>>> On 5/1/14, 9:51 PM, Christian Thalinger wrote: >>>>> >>>>> On May 1, 2014, at 8:34 AM, Morris Meyer >>>> > wrote: >>>>> >>>>>> The parfait error is with the ASSERT define blocking out >>>>>> initialization of a the fpu structures when that code path is >>>>>> enabled. >>>>>> >>>>>> I've removed the ifdef such that both paths initialized their cpu >>>>>> and >>>>>> fpu variables, and the assertion is always checked. >>>>> >>>>> But the code path using the uninitialized variables is also under: >>>>> >>>>> 1648 if (has_fpu_registers()) { >>>>> >>>>> Am I missing something? Anyway, during an earlier internal review I >>>>> said we should keep the assert; I take that back. We should move the >>>>> variables and initialization down to the use and remove the assert. >>>>> It doesn?t have much value anyway. >>>>> >>>>>> >>>>>> --mm >>>>>> >>>>>> On 4/30/14, 3:36 PM, Christian Thalinger wrote: >>>>>>> I don?t understand the Parfait error here. Could you explain? >>>>>>> >>>>>>> On Apr 30, 2014, at 7:40 AM, Morris Meyer >>>>>> > wrote: >>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> Could I get a review for this Parfait uninitialized variable >>>>>>>> issue? >>>>>>>> This has been tested with JPRT and a clear pass with Parfait. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> --mm >>>>>>>> >>>>>>>> BUG - https://bugs.openjdk.java.net/browse/JDK-8040921 >>>>>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.05 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> From vladimir.kozlov at oracle.com Thu Jul 31 16:43:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Jul 2014 09:43:06 -0700 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <53DA3807.50501@oracle.com> References: <53DA3807.50501@oracle.com> Message-ID: <53DA721A.5090009@oracle.com> Hi Tobias, You missed cop == Op_CmpI check. And add checks for r0 and r1 != TypeInt::INT (no bottom type) in addition to != NULL. You don't need t2 because there is already cmp2_type. Check cmp2_type for != TypeInt::INT too. Use as_Sub() (which is cast) instead of isa_Sub() because there is is_Sub() check at the beginning already. I don't see how second condition could happen because tr1 < tr2: sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT Instead of ConINode::make() you can use phase->intcon(). Thanks, Vladimir On 7/31/14 5:35 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that fixes JDK-8043284. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8043284 > Webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.00/ > > == Problem == > Similar to the previous implementation of unsigned integer comparison (see JDK- 8042786), signed integer comparison does > only consider the general integer range [MinInt, MaxInt] instead of two ranges when comparing the result of an > overflowing AddI/SubI. However, there are situations where one can prove that both resulting ranges are unequal to the > tested value (see 'TestIntegerComparison::testSigned' in the webrev). In this case the comparison can be optimized. > > == Solution == > Similar to the fix for JDK-8042786 we compute both type ranges if the add/sub overflows and compare them to the tested > value. If we can prove that the value is always unequal, we replace the BoolNode by true or false (depending on the test). > A jtreg test is added that triggers both the unsigned as well as the signed optimization. > > == Testing == > - Jtreg test (TestIntegerComparison) > - JPRT > > Thanks, > Tobias From vladimir.kozlov at oracle.com Thu Jul 31 16:43:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Jul 2014 09:43:53 -0700 Subject: RFR(XS): JDK-8040921: Uninitialised memory in hotspot/src/share/vm/c1/c1_LinearScan.cpp In-Reply-To: <53DA6D83.6070308@oracle.com> References: <53555C8D.7090406@oracle.com> <80C84BCB-1E02-4668-9B5C-7D351BB922E9@oracle.com> <53613588.8000306@oracle.com> <305D7E38-B9F1-4A89-8C92-805DFC62DA4B@oracle.com> <536293B4.8040601@oracle.com> <3723EF44-4D7B-4E12-AA83-45EF7DA8645B@oracle.com> <53CEBF9E.7080207@oracle.com> <53CEE865.6040504@oracle.com> <53DA656A.5040202@oracle.com> <53DA6608.4050906@oracle.com> <53DA6D83.6070308@oracle.com> Message-ID: <53DA7249.3030901@oracle.com> Good. Thanks, vladimir On 7/31/14 9:23 AM, Morris Meyer wrote: > Vladimir, > > Sorry about that. Changes fixed inline. > > --mm > > WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.08 > > On 7/31/14, 11:51 AM, Vladimir Kozlov wrote: >> Morris, >> >> You left debug printing in changes. >> >> Vladimir >> >> On 7/31/14 8:48 AM, Morris Meyer wrote: >>> Vladimir, >>> >>> I found that you cannot move the variables and initialization down to the use, as the cpu_lsw.walk() // >>> IntervalWalker.walk_to() code changes the intervals and causes an assertion failure in LinearScan::is_sorted(). >>> >>> I've commented the code to note that the code cannot be moved down to where it is used. >>> >>> Thanks, >>> >>> --morris >>> >>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.08 >>> BUG - https://bugs.openjdk.java.net/browse/JDK-8040921 >>> >>> >>> On 7/22/14, 6:40 PM, Vladimir Kozlov wrote: >>>> You did not do for fpu registers what Christian said: >>>> >>>> "We should move the variables and initialization down to the use" >>>> >>>> Vladimir >>>> >>>> On 7/22/14 12:46 PM, Morris Meyer wrote: >>>>> Folks, >>>>> >>>>> Could I get a review of this parfait issue. It has been tested through >>>>> JPRT. >>>>> >>>>> Thanks! >>>>> >>>>> --morris >>>>> >>>>> JBS - http://bugs.openjdk.java.net/browse/JDK-8040921 >>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.07 >>>>> >>>>> On 5/1/14, 9:51 PM, Christian Thalinger wrote: >>>>>> >>>>>> On May 1, 2014, at 8:34 AM, Morris Meyer >>>>> > wrote: >>>>>> >>>>>>> The parfait error is with the ASSERT define blocking out >>>>>>> initialization of a the fpu structures when that code path is enabled. >>>>>>> >>>>>>> I've removed the ifdef such that both paths initialized their cpu and >>>>>>> fpu variables, and the assertion is always checked. >>>>>> >>>>>> But the code path using the uninitialized variables is also under: >>>>>> >>>>>> 1648 if (has_fpu_registers()) { >>>>>> >>>>>> Am I missing something? Anyway, during an earlier internal review I >>>>>> said we should keep the assert; I take that back. We should move the >>>>>> variables and initialization down to the use and remove the assert. >>>>>> It doesn?t have much value anyway. >>>>>> >>>>>>> >>>>>>> --mm >>>>>>> >>>>>>> On 4/30/14, 3:36 PM, Christian Thalinger wrote: >>>>>>>> I don?t understand the Parfait error here. Could you explain? >>>>>>>> >>>>>>>> On Apr 30, 2014, at 7:40 AM, Morris Meyer >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> Could I get a review for this Parfait uninitialized variable issue? >>>>>>>>> This has been tested with JPRT and a clear pass with Parfait. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> --mm >>>>>>>>> >>>>>>>>> BUG - https://bugs.openjdk.java.net/browse/JDK-8040921 >>>>>>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.05 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Thu Jul 31 18:58:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Jul 2014 11:58:11 -0700 Subject: RFR(S): 8043125: compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type In-Reply-To: <878unah90x.fsf@oracle.com> References: <878unah90x.fsf@oracle.com> Message-ID: <53DA91C3.4090700@oracle.com> Can you add set_speculative_traps_cleaned_up() setter method? Can you also change suffix _cleaned_up to _modified or _updated? Otherwise clear_*_cleaned_up sounds strange. The comment said that new traps can be added but I don't see the flag state change for such case. So safepoint can happen during translate_from() call. Right? Please say it in your comment? Thanks, Vladimir On 7/30/14 1:43 PM, Roland Westrelin wrote: > > Speculative traps recorded in a MethodData can be removed at a > safepoint. During a compilation, as an MethoData is copied and > translated by a compiler thread to build a ciMethodData, a safepoint can > occur as speculative traps are being copied, and speculative traps may > be removed. I fixed this by adding a flag to the MDO that is set when > speculative traps are removed. The code that copies the speculative > traps to the ciMethodData, checks the flag as it iterates over the traps > and if it detects a change, it starts the copy over. I took this > opportunity to clean the code a bit: args_data_limit() points right > after the last ArgInfoData entry while extra_data_limit() points after > the parameters profiling area. > > http://cr.openjdk.java.net/~roland/8043125/webrev.00/ > > Roland. >