From roland.westrelin at oracle.com Fri Aug 1 00:28:45 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 01 Aug 2014 02:28:45 +0200 Subject: RFR(XS): 8054054: 8040121 is broken Message-ID: <87tx5xf3ya.fsf@oracle.com> The code pattern introduced by 8040121 doesn't behave as expected (at least with gcc). This fix uses a more robust code pattern: http://cr.openjdk.java.net/~roland/8054054/webrev.00/ Roland. From vladimir.kozlov at oracle.com Fri Aug 1 00:37:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Jul 2014 17:37:47 -0700 Subject: RFR(XS): 8054054: 8040121 is broken In-Reply-To: <87tx5xf3ya.fsf@oracle.com> References: <87tx5xf3ya.fsf@oracle.com> Message-ID: <53DAE15B.1090705@oracle.com> Good. Thanks, Vladimir On 7/31/14 5:28 PM, Roland Westrelin wrote: > > The code pattern introduced by 8040121 doesn't behave as expected (at > least with gcc). This fix uses a more robust code pattern: > > http://cr.openjdk.java.net/~roland/8054054/webrev.00/ > > Roland. > From roland.westrelin at oracle.com Fri Aug 1 00:38:24 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 01 Aug 2014 02:38:24 +0200 Subject: RFR(XS): 8054054: 8040121 is broken In-Reply-To: <53DAE15B.1090705@oracle.com> References: <87tx5xf3ya.fsf@oracle.com> <53DAE15B.1090705@oracle.com> Message-ID: <87r411f3i7.fsf@oracle.com> Thanks Vladimir. Roland. From roland.westrelin at oracle.com Sat Aug 2 04:46:14 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Sat, 02 Aug 2014 06:46:14 +0200 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: <87bns3fqi1.fsf@oracle.com> Here is a new webrev with the gvn_transform_ctrl -> record_for_igvn renaming: http://cr.openjdk.java.net/~roland/7173584/webrev.04/ Roland. Roland Westrelin writes: > 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 roland.westrelin at oracle.com Sat Aug 2 05:00:11 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Sat, 02 Aug 2014 07:00:11 +0200 Subject: RFR(S): 8043125: compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type In-Reply-To: <53DA91C3.4090700@oracle.com> References: <878unah90x.fsf@oracle.com> <53DA91C3.4090700@oracle.com> Message-ID: <878un7fpus.fsf@oracle.com> Thanks for reviewing this, Vladimir. > 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. > So safepoint can happen during translate_from() call. Right? Please say > it in your comment? I made the changes you suggested above: http://cr.openjdk.java.net/~roland/8043125/webrev.01/ Regarding this: > The comment said that new traps can be added but I don't see the flag > state change for such case. A trap is added during deoptimization. When a trap is added the extra_data_lock is acquired (in MethodData::bci_to_extra_data()). In ciMethodData::load_extra_data_helper(), once the extra_data_lock is acquired, we are guaranteed that no new traps can be added so there's no need to flag the state change for new traps. New traps may have been added before the extra_data_lock is acquired. I updated the comment to make this clearer. Roland. > > 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. >> From vladimir.kozlov at oracle.com Sat Aug 2 18:10:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 02 Aug 2014 11:10:56 -0700 Subject: RFR (L): 7173584: Implement arraycopy as a macro node In-Reply-To: <87bns3fqi1.fsf@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> <87bns3fqi1.fsf@oracle.com> Message-ID: <53DD29B0.7000709@oracle.com> This looks good. Thank you for finishing this. Vladimir On 8/1/14 9:46 PM, Roland Westrelin wrote: > > Here is a new webrev with the gvn_transform_ctrl -> record_for_igvn renaming: > > http://cr.openjdk.java.net/~roland/7173584/webrev.04/ > > Roland. > > Roland Westrelin writes: > >> 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.kozlov at oracle.com Sat Aug 2 18:25:08 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 02 Aug 2014 11:25:08 -0700 Subject: RFR(S): 8043125: compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type In-Reply-To: <878un7fpus.fsf@oracle.com> References: <878unah90x.fsf@oracle.com> <53DA91C3.4090700@oracle.com> <878un7fpus.fsf@oracle.com> Message-ID: <53DD2D04.8060201@oracle.com> On 8/1/14 10:00 PM, Roland Westrelin wrote: > > Thanks for reviewing this, Vladimir. > >> 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. >> So safepoint can happen during translate_from() call. Right? Please say >> it in your comment? > > I made the changes you suggested above: > > http://cr.openjdk.java.net/~roland/8043125/webrev.01/ Looks good. > > Regarding this: > >> The comment said that new traps can be added but I don't see the flag >> state change for such case. > > A trap is added during deoptimization. When a trap is added the > extra_data_lock is acquired (in MethodData::bci_to_extra_data()). In > ciMethodData::load_extra_data_helper(), once the extra_data_lock is > acquired, we are guaranteed that no new traps can be added so there's no > need to flag the state change for new traps. New traps may have been > added before the extra_data_lock is acquired. I updated the comment to > make this clearer. Thanks, Vladimir > > Roland. > >> >> 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. >>> From tobias.hartmann at oracle.com Mon Aug 4 13:05:21 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 04 Aug 2014 15:05:21 +0200 Subject: [9] RFR(M): 8054033: Remove unused references to Compile* Message-ID: <53DF8511.2060701@oracle.com> Hi, please review the following patch that fixes JDK-8054033. Bug: https://bugs.openjdk.java.net/browse/JDK-8054033 Webrev: http://cr.openjdk.java.net/~thartmann/8054033/webrev.00/ Problem: JDK-8034812 removed the Compile* parameter from the Nodes new operator. Some dependent parts of the code were not updated and still define Compile* without using it (see for example 'ConINode::make'). All unused references should be removed. Solution: Removed all unused references to Compile* including those from generated code (see changes in /share/vm/adlc/*). Testing: - JPRT Thanks, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Mon Aug 4 13:06:11 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 04 Aug 2014 15:06:11 +0200 Subject: [9] RFR(XS): 8054081: Crashes with assert "modified node is not on IGVN._worklist" Message-ID: <53DF8543.3010600@oracle.com> Hi, please review the following patch that fixes JDK-8054081. Bug: https://bugs.openjdk.java.net/browse/JDK-8054081 Webrev: http://cr.openjdk.java.net/~thartmann/8054081/webrev.00/ Problem: If elimination of an AllocateNode fails in 'PhaseMacroExpand::scalar_replacement()' because the value of a field cannot be found, a rollback is initiated that removes all previously added inputs to the safepoint nodes. The modified safepoint nodes are not added to the IGVN worklist. Solution: Add modified safepoint nodes to the IGVN worklist. Testing: - JPRT - Failing tests: - ctw/jre/lib/rt_jar/sun_java2d_xr_XRPMBlitLoops - ctw/jre/lib/rt_jar/com_sun_org_apache_xerces_internal_impl_xs_traversers_XSAttributeChecker - java/util/Base64/TestBase64.java - java/util/logging/LocalizedLevelName.java Thanks, Tobias From tobias.hartmann at oracle.com Mon Aug 4 14:41:00 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 04 Aug 2014 16:41:00 +0200 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <53DA721A.5090009@oracle.com> References: <53DA3807.50501@oracle.com> <53DA721A.5090009@oracle.com> Message-ID: <53DF9B7C.30701@oracle.com> Hi Vladimir, thanks for the review. Please see comments inline. On 31.07.2014 18:43, Vladimir Kozlov wrote: > You missed cop == Op_CmpI check. Thanks, I added the check. > And add checks for r0 and r1 != TypeInt::INT (no bottom type) in > addition to != NULL. Done. > You don't need t2 because there is already cmp2_type. Check cmp2_type > for != TypeInt::INT too. Done. > Use as_Sub() (which is cast) instead of isa_Sub() because there is > is_Sub() check at the beginning already. Done. > I don't see how second condition could happen because tr1 < tr2: > > sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT Of course, you are right. I removed the second condition. > Instead of ConINode::make() you can use phase->intcon(). I first used phase->intcon() but this method may return a cached ConINode and hit the assert "Idealize should return new nodes, use Identity to return old nodes" in 'PhaseIterGVN::transform_old()'. That's why I directly create the ConINode. New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.01/ Thanks, Tobias > > 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 tobias.hartmann at oracle.com Mon Aug 4 14:45:37 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 04 Aug 2014 16:45:37 +0200 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <20140731171722.GA3736@rbackman> References: <53DA3807.50501@oracle.com> <20140731171722.GA3736@rbackman> Message-ID: <53DF9C91.7010304@oracle.com> Hi Rickard, thanks for the review. > could we add the logic to a new method and make a method call instead? Sure, but if we want to reuse the local variables from 'BoolNode::Ideal' (for example, 'cmp2_type') as Vladimir suggested, we would have a signature similar to this: Node* BoolNode::my_optimization(PhaseGVN* phase, Node* cmp, Node* cmp1, Node* cmp2, int cmp_op, int cmp1_op, const TypeInt* cmp2_type) { An alternative would be to only pass (PhaseGVN* phase, Node* cmp) and re-compute the other variables. What do you prefer? Thanks, Tobias > > Thanks > /R > > On 07/31, 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 Mon Aug 4 16:16:09 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Aug 2014 09:16:09 -0700 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <53DF9B7C.30701@oracle.com> References: <53DA3807.50501@oracle.com> <53DA721A.5090009@oracle.com> <53DF9B7C.30701@oracle.com> Message-ID: <53DFB1C9.6000000@oracle.com> You are right about ConINode::make(), I forgot that it is Ideal() method. The second condition is still in webrev: >> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT Thanks, Vladimir On 8/4/14 7:41 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. Please see comments inline. > > On 31.07.2014 18:43, Vladimir Kozlov wrote: >> You missed cop == Op_CmpI check. > > Thanks, I added the check. > >> And add checks for r0 and r1 != TypeInt::INT (no bottom type) in addition to != NULL. > > Done. > >> You don't need t2 because there is already cmp2_type. Check cmp2_type for != TypeInt::INT too. > > Done. > >> Use as_Sub() (which is cast) instead of isa_Sub() because there is is_Sub() check at the beginning already. > > Done. > >> I don't see how second condition could happen because tr1 < tr2: >> >> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT > > Of course, you are right. I removed the second condition. > >> Instead of ConINode::make() you can use phase->intcon(). > > I first used phase->intcon() but this method may return a cached ConINode and hit the assert "Idealize should return new > nodes, use Identity to return old nodes" in 'PhaseIterGVN::transform_old()'. That's why I directly create the ConINode. > > New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.01/ > > Thanks, > Tobias > >> >> 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 Mon Aug 4 17:00:17 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Aug 2014 10:00:17 -0700 Subject: [9] RFR(M): 8054033: Remove unused references to Compile* In-Reply-To: <53DF8511.2060701@oracle.com> References: <53DF8511.2060701@oracle.com> Message-ID: <53DFBC21.9050706@oracle.com> Looks good. Thanks, Vladimir On 8/4/14 6:05 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that fixes JDK-8054033. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8054033 > Webrev: http://cr.openjdk.java.net/~thartmann/8054033/webrev.00/ > > Problem: > JDK-8034812 removed the Compile* parameter from the Nodes new operator. Some dependent parts of the code were not > updated and still define Compile* without using it (see for example 'ConINode::make'). All unused references should be > removed. > > Solution: > Removed all unused references to Compile* including those from generated code (see changes in /share/vm/adlc/*). > > Testing: > - JPRT > > Thanks, > Tobias From vladimir.kozlov at oracle.com Mon Aug 4 17:01:23 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Aug 2014 10:01:23 -0700 Subject: [9] RFR(XS): 8054081: Crashes with assert "modified node is not on IGVN._worklist" In-Reply-To: <53DF8543.3010600@oracle.com> References: <53DF8543.3010600@oracle.com> Message-ID: <53DFBC63.7070601@oracle.com> Good. Thanks, Vladimir On 8/4/14 6:06 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that fixes JDK-8054081. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8054081 > Webrev: http://cr.openjdk.java.net/~thartmann/8054081/webrev.00/ > > Problem: > If elimination of an AllocateNode fails in 'PhaseMacroExpand::scalar_replacement()' because the value of a field cannot > be found, a rollback is initiated that removes all previously added inputs to the safepoint nodes. The modified > safepoint nodes are not added to the IGVN worklist. > > Solution: > Add modified safepoint nodes to the IGVN worklist. > > Testing: > - JPRT > - Failing tests: > - ctw/jre/lib/rt_jar/sun_java2d_xr_XRPMBlitLoops > - ctw/jre/lib/rt_jar/com_sun_org_apache_xerces_internal_impl_xs_traversers_XSAttributeChecker > - java/util/Base64/TestBase64.java > - java/util/logging/LocalizedLevelName.java > > Thanks, > Tobias From vladimir.kozlov at oracle.com Mon Aug 4 21:47:50 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Aug 2014 14:47:50 -0700 Subject: [9] RFR (M) 8052081: Optimize generated by C2 code for Intel's Atom processor Message-ID: <53DFFF86.5000302@oracle.com> http://cr.openjdk.java.net/~kvn/8052081/webrev/ https://bugs.openjdk.java.net/browse/JDK-8052081 Atom processor does not have AVX unit but it has SSE so we still can do vectorization. General changes in lcm.cpp and superword.cpp we done to improve vectorization. CRC32 assembler code was modified to use only SSE instructions to execute it on Atom processors too. Performance numbers show that we benefit from UseFPUForSpilling on general x86 cpus too. Its setting was moved from under AggressiveOpts. Note, we are regularly testing AggressiveOpts so this part of code was tested before. OptoScheduling has negative effect on general x86 cpus so it is switched on only for Atom processor which benefits from it. I did performance runs and JPRT testing (with UseAVX=0 and default). Thanks, Vladimir From roland.westrelin at oracle.com Mon Aug 4 23:48:53 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 05 Aug 2014 01:48:53 +0200 Subject: [9] RFR(M): 8054033: Remove unused references to Compile* In-Reply-To: <53DF8511.2060701@oracle.com> References: <53DF8511.2060701@oracle.com> Message-ID: <87mwbj95p6.fsf@oracle.com> Hi Tobias, > Webrev: http://cr.openjdk.java.net/~thartmann/8054033/webrev.00/ That looks good. You could have also cleaned up coding style in some places you touch, like: 50 Node *method_node = _gvn.transform( ConNode::make(C, method_type) ); (no space before/after parenthesis) No need to send an updated webrev if you do. Roland. From roland.westrelin at oracle.com Mon Aug 4 23:50:07 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 05 Aug 2014 01:50:07 +0200 Subject: [9] RFR(XS): 8054081: Crashes with assert "modified node is not on IGVN._worklist" In-Reply-To: <53DF8543.3010600@oracle.com> References: <53DF8543.3010600@oracle.com> Message-ID: <87k36n95n4.fsf@oracle.com> > Webrev: http://cr.openjdk.java.net/~thartmann/8054081/webrev.00/ That looks good to me. Roland. From roland.westrelin at oracle.com Tue Aug 5 00:07:00 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 05 Aug 2014 02:07:00 +0200 Subject: [9] RFR (M) 8052081: Optimize generated by C2 code for Intel's Atom processor In-Reply-To: <53DFFF86.5000302@oracle.com> References: <53DFFF86.5000302@oracle.com> Message-ID: <87d2cf94uz.fsf@oracle.com> > http://cr.openjdk.java.net/~kvn/8052081/webrev/ Looks good to me. Roland. From roland.westrelin at oracle.com Tue Aug 5 00:07:36 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 05 Aug 2014 02:07:36 +0200 Subject: RFR (L): 7173584: Implement arraycopy as a macro node In-Reply-To: <53DD29B0.7000709@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> <87bns3fqi1.fsf@oracle.com> <53DD29B0.7000709@oracle.com> Message-ID: <87a97j94tz.fsf@oracle.com> > This looks good. Thank you for finishing this. Thanks for the review, Vladimir. Roland. From roland.westrelin at oracle.com Tue Aug 5 00:57:19 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 05 Aug 2014 02:57:19 +0200 Subject: RFR(S): 8043125: compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type In-Reply-To: <53DD2D04.8060201@oracle.com> References: <878unah90x.fsf@oracle.com> <53DA91C3.4090700@oracle.com> <878un7fpus.fsf@oracle.com> <53DD2D04.8060201@oracle.com> Message-ID: <877g2n92j4.fsf@oracle.com> >> http://cr.openjdk.java.net/~roland/8043125/webrev.01/ > > Looks good. Thanks Vladimir. Roland. From vladimir.kozlov at oracle.com Tue Aug 5 01:03:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Aug 2014 18:03:16 -0700 Subject: [9] RFR (M) 8052081: Optimize generated by C2 code for Intel's Atom processor In-Reply-To: <87d2cf94uz.fsf@oracle.com> References: <53DFFF86.5000302@oracle.com> <87d2cf94uz.fsf@oracle.com> Message-ID: <53E02D54.2000500@oracle.com> Thank you, Roland Vladimir On 8/4/14 5:07 PM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~kvn/8052081/webrev/ > > Looks good to me. > > Roland. > From tobias.hartmann at oracle.com Tue Aug 5 06:21:37 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 05 Aug 2014 08:21:37 +0200 Subject: [9] RFR(XS): 8054081: Crashes with assert "modified node is not on IGVN._worklist" In-Reply-To: <87k36n95n4.fsf@oracle.com> References: <53DF8543.3010600@oracle.com> <87k36n95n4.fsf@oracle.com> Message-ID: <53E077F1.7070602@oracle.com> Vladimir, Roland, thanks for the reviews. Best, Tobias On 05.08.2014 01:50, Roland Westrelin wrote: >> Webrev: http://cr.openjdk.java.net/~thartmann/8054081/webrev.00/ > That looks good to me. > > Roland. From tobias.hartmann at oracle.com Tue Aug 5 06:40:03 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 05 Aug 2014 08:40:03 +0200 Subject: [9] RFR(M): 8054033: Remove unused references to Compile* In-Reply-To: <87mwbj95p6.fsf@oracle.com> References: <53DF8511.2060701@oracle.com> <87mwbj95p6.fsf@oracle.com> Message-ID: <53E07C43.1050308@oracle.com> Vladimir, Roland, thanks for the review. @Roland: I will clean up the coding style of the affected statements before pushing. Best, Tobias On 05.08.2014 01:48, Roland Westrelin wrote: > Hi Tobias, > >> Webrev: http://cr.openjdk.java.net/~thartmann/8054033/webrev.00/ > That looks good. You could have also cleaned up coding style in some > places you touch, like: > > 50 Node *method_node = _gvn.transform( ConNode::make(C, method_type) ); > > (no space before/after parenthesis) > > No need to send an updated webrev if you do. > > Roland. From tobias.hartmann at oracle.com Tue Aug 5 07:55:25 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 05 Aug 2014 09:55:25 +0200 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <53DFB1C9.6000000@oracle.com> References: <53DA3807.50501@oracle.com> <53DA721A.5090009@oracle.com> <53DF9B7C.30701@oracle.com> <53DFB1C9.6000000@oracle.com> Message-ID: <53E08DED.60400@oracle.com> Hi Vladimir, thanks for the review. > The second condition is still in webrev: > > >> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT Sorry, I forgot to update the webrev after removing the condition. As Rickard suggested, I moved the code into a separate method called 'fold_cmpI'. If you think that the method has too many arguments, we could reduce them to '(PhaseGVN* phase, Node* cmp)' and re-compute the other values locally. New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.02/ Thanks, Tobias > > Thanks, > Vladimir > > On 8/4/14 7:41 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. Please see comments inline. >> >> On 31.07.2014 18:43, Vladimir Kozlov wrote: >>> You missed cop == Op_CmpI check. >> >> Thanks, I added the check. >> >>> And add checks for r0 and r1 != TypeInt::INT (no bottom type) in >>> addition to != NULL. >> >> Done. >> >>> You don't need t2 because there is already cmp2_type. Check >>> cmp2_type for != TypeInt::INT too. >> >> Done. >> >>> Use as_Sub() (which is cast) instead of isa_Sub() because there is >>> is_Sub() check at the beginning already. >> >> Done. >> >>> I don't see how second condition could happen because tr1 < tr2: >>> >>> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT >> >> Of course, you are right. I removed the second condition. >> >>> Instead of ConINode::make() you can use phase->intcon(). >> >> I first used phase->intcon() but this method may return a cached >> ConINode and hit the assert "Idealize should return new >> nodes, use Identity to return old nodes" in >> 'PhaseIterGVN::transform_old()'. That's why I directly create the >> ConINode. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.01/ >> >> Thanks, >> Tobias >> >>> >>> 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 Tue Aug 5 16:47:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Aug 2014 09:47:52 -0700 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <53E08DED.60400@oracle.com> References: <53DA3807.50501@oracle.com> <53DA721A.5090009@oracle.com> <53DF9B7C.30701@oracle.com> <53DFB1C9.6000000@oracle.com> <53E08DED.60400@oracle.com> Message-ID: <53E10AB8.3040509@oracle.com> On 8/5/14 12:55 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > >> The second condition is still in webrev: >> >> >> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT > > Sorry, I forgot to update the webrev after removing the condition. > > As Rickard suggested, I moved the code into a separate method called 'fold_cmpI'. If you think that the method has too > many arguments, we could reduce them to '(PhaseGVN* phase, Node* cmp)' and re-compute the other values locally. I can't find Rickard's review. I am fine with this since BoolNode::Ideal() become too large. cmp2 is not used, don't need to pass it. Declare cmp argument as SubNode* and pass cmp->as_Sub() so you don't need to do it inside. Thanks, Vladimir > > New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.02/ > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >> On 8/4/14 7:41 AM, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> thanks for the review. Please see comments inline. >>> >>> On 31.07.2014 18:43, Vladimir Kozlov wrote: >>>> You missed cop == Op_CmpI check. >>> >>> Thanks, I added the check. >>> >>>> And add checks for r0 and r1 != TypeInt::INT (no bottom type) in addition to != NULL. >>> >>> Done. >>> >>>> You don't need t2 because there is already cmp2_type. Check cmp2_type for != TypeInt::INT too. >>> >>> Done. >>> >>>> Use as_Sub() (which is cast) instead of isa_Sub() because there is is_Sub() check at the beginning already. >>> >>> Done. >>> >>>> I don't see how second condition could happen because tr1 < tr2: >>>> >>>> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT >>> >>> Of course, you are right. I removed the second condition. >>> >>>> Instead of ConINode::make() you can use phase->intcon(). >>> >>> I first used phase->intcon() but this method may return a cached ConINode and hit the assert "Idealize should return new >>> nodes, use Identity to return old nodes" in 'PhaseIterGVN::transform_old()'. That's why I directly create the ConINode. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.01/ >>> >>> Thanks, >>> Tobias >>> >>>> >>>> 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 morris.meyer at oracle.com Tue Aug 5 17:28:53 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 05 Aug 2014 13:28:53 -0400 Subject: RFR(S): 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp In-Reply-To: <53CEEE3D.4070501@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> <53CEEE3D.4070501@oracle.com> Message-ID: <53E11455.4010501@oracle.com> Vladimir, Here is a revised version with your suggestions. I added outer ResourceMarks to void Dependencies::log_all_dependencies() and void Dependencies::write_dependency_to(CompileLog* log, DepType dept, GrowableArray* args, Klass* witness) as they are the only callers to void Dependencies::write_dependency_to(CompileLog* log, DepType dept, GrowableArray* args, Klass* witness); which does not have a ResourceMark - so these aren't nested cases. void Dependencies::DepStream::log_dependency(Klass* witness) does call void Dependencies::write_dependency_to(CompileLog* log, DepType dept, GrowableArray* args, Klass* witness) which makes it a nested usage of ResourceMark - and I've added a guarantee() to ensure the outer ResourceMark is not affected by the inner callee. void Dependencies::DepStream::print_dependency(Klass* witness, bool verbose); has a new GrowableArray usage and I also added an outer ResourceMark here - and a guarantee() that goes along with the inner ResourceMark used in the existing code of void Dependencies::print_dependency(DepType dept, GrowableArray* args, Klass* witness); This revision has been tested with JPRT. Thanks for the review! --morris JBS - https://bug.openjdk.java.net/browse/JDK-8040920 WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.08 On 7/22/14, 7:05 PM, Vladimir Kozlov wrote: > 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 igor.veresov at oracle.com Wed Aug 6 05:46:13 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Aug 2014 22:46:13 -0700 Subject: RFR (L): 7173584: Implement arraycopy as a macro node In-Reply-To: <87bns3fqi1.fsf@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> <87bns3fqi1.fsf@oracle.com> Message-ID: Seems very nice. I wonder if there are measurable compile speed improvements? igor On Aug 1, 2014, at 9:46 PM, Roland Westrelin wrote: > > Here is a new webrev with the gvn_transform_ctrl -> record_for_igvn renaming: > > http://cr.openjdk.java.net/~roland/7173584/webrev.04/ > > Roland. > > Roland Westrelin writes: > >> 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 tobias.hartmann at oracle.com Wed Aug 6 07:38:56 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 06 Aug 2014 09:38:56 +0200 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <53E10AB8.3040509@oracle.com> References: <53DA3807.50501@oracle.com> <53DA721A.5090009@oracle.com> <53DF9B7C.30701@oracle.com> <53DFB1C9.6000000@oracle.com> <53E08DED.60400@oracle.com> <53E10AB8.3040509@oracle.com> Message-ID: <53E1DB90.9030602@oracle.com> Hi Vladimir, thanks for the review. On 05.08.2014 18:47, Vladimir Kozlov wrote: > On 8/5/14 12:55 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >>> The second condition is still in webrev: >>> >>> >> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT >> >> Sorry, I forgot to update the webrev after removing the condition. >> >> As Rickard suggested, I moved the code into a separate method called >> 'fold_cmpI'. If you think that the method has too >> many arguments, we could reduce them to '(PhaseGVN* phase, Node* >> cmp)' and re-compute the other values locally. > > I can't find Rickard's review. I am fine with this since > BoolNode::Ideal() become too large. > cmp2 is not used, don't need to pass it. Declare cmp argument as > SubNode* and pass cmp->as_Sub() so you don't need to do it inside. Done. New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.03/ Thanks, Tobias > > Thanks, > Vladimir > >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.02/ >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Vladimir >>> >>> On 8/4/14 7:41 AM, Tobias Hartmann wrote: >>>> Hi Vladimir, >>>> >>>> thanks for the review. Please see comments inline. >>>> >>>> On 31.07.2014 18:43, Vladimir Kozlov wrote: >>>>> You missed cop == Op_CmpI check. >>>> >>>> Thanks, I added the check. >>>> >>>>> And add checks for r0 and r1 != TypeInt::INT (no bottom type) in >>>>> addition to != NULL. >>>> >>>> Done. >>>> >>>>> You don't need t2 because there is already cmp2_type. Check >>>>> cmp2_type for != TypeInt::INT too. >>>> >>>> Done. >>>> >>>>> Use as_Sub() (which is cast) instead of isa_Sub() because there is >>>>> is_Sub() check at the beginning already. >>>> >>>> Done. >>>> >>>>> I don't see how second condition could happen because tr1 < tr2: >>>>> >>>>> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT >>>> >>>> Of course, you are right. I removed the second condition. >>>> >>>>> Instead of ConINode::make() you can use phase->intcon(). >>>> >>>> I first used phase->intcon() but this method may return a cached >>>> ConINode and hit the assert "Idealize should return new >>>> nodes, use Identity to return old nodes" in >>>> 'PhaseIterGVN::transform_old()'. That's why I directly create the >>>> ConINode. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.01/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> 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 igor.ignatyev at oracle.com Wed Aug 6 11:15:18 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 06 Aug 2014 15:15:18 +0400 Subject: RFR(XXS) : 8054410 : compiler/7068051/Test7068051.java fails with FileNotFoundException: f3oo.jar Message-ID: <53E20E46.6040908@oracle.com> http://cr.openjdk.java.net/~iignatyev/8054410/webrev.00/ 1 line changed: 0 ins; 0 del; 1 mod; Hi all, Please review patch: Problem: the fix for JDK-8051896[1] introduced a typo[2] in compiler/7068051/Test7068051.sh jbs: https://bugs.openjdk.java.net/browse/JDK-8054410 testing: jprt [1] https://bugs.openjdk.java.net/browse/JDK-8051896 [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fcb6c71678c9#l5.16 -- Igor From vladimir.kozlov at oracle.com Wed Aug 6 16:44:40 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Aug 2014 09:44:40 -0700 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <53E1DB90.9030602@oracle.com> References: <53DA3807.50501@oracle.com> <53DA721A.5090009@oracle.com> <53DF9B7C.30701@oracle.com> <53DFB1C9.6000000@oracle.com> <53E08DED.60400@oracle.com> <53E10AB8.3040509@oracle.com> <53E1DB90.9030602@oracle.com> Message-ID: <53E25B78.4080803@oracle.com> Good. Thanks, Vladimir On 8/6/14 12:38 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > > On 05.08.2014 18:47, Vladimir Kozlov wrote: >> On 8/5/14 12:55 AM, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> thanks for the review. >>> >>>> The second condition is still in webrev: >>>> >>>> >> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT >>> >>> Sorry, I forgot to update the webrev after removing the condition. >>> >>> As Rickard suggested, I moved the code into a separate method called 'fold_cmpI'. If you think that the method has too >>> many arguments, we could reduce them to '(PhaseGVN* phase, Node* cmp)' and re-compute the other values locally. >> >> I can't find Rickard's review. I am fine with this since BoolNode::Ideal() become too large. >> cmp2 is not used, don't need to pass it. Declare cmp argument as SubNode* and pass cmp->as_Sub() so you don't need to >> do it inside. > > Done. New webrev: > > http://cr.openjdk.java.net/~thartmann/8043284/webrev.03/ > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.02/ >>> >>> Thanks, >>> Tobias >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/4/14 7:41 AM, Tobias Hartmann wrote: >>>>> Hi Vladimir, >>>>> >>>>> thanks for the review. Please see comments inline. >>>>> >>>>> On 31.07.2014 18:43, Vladimir Kozlov wrote: >>>>>> You missed cop == Op_CmpI check. >>>>> >>>>> Thanks, I added the check. >>>>> >>>>>> And add checks for r0 and r1 != TypeInt::INT (no bottom type) in addition to != NULL. >>>>> >>>>> Done. >>>>> >>>>>> You don't need t2 because there is already cmp2_type. Check cmp2_type for != TypeInt::INT too. >>>>> >>>>> Done. >>>>> >>>>>> Use as_Sub() (which is cast) instead of isa_Sub() because there is is_Sub() check at the beginning already. >>>>> >>>>> Done. >>>>> >>>>>> I don't see how second condition could happen because tr1 < tr2: >>>>>> >>>>>> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT >>>>> >>>>> Of course, you are right. I removed the second condition. >>>>> >>>>>> Instead of ConINode::make() you can use phase->intcon(). >>>>> >>>>> I first used phase->intcon() but this method may return a cached ConINode and hit the assert "Idealize should >>>>> return new >>>>> nodes, use Identity to return old nodes" in 'PhaseIterGVN::transform_old()'. That's why I directly create the >>>>> ConINode. >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.01/ >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> >>>>>> 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 Wed Aug 6 16:45:39 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Aug 2014 09:45:39 -0700 Subject: RFR(XXS) : 8054410 : compiler/7068051/Test7068051.java fails with FileNotFoundException: f3oo.jar In-Reply-To: <53E20E46.6040908@oracle.com> References: <53E20E46.6040908@oracle.com> Message-ID: <53E25BB3.6020105@oracle.com> Okay. Thanks, Vladimir On 8/6/14 4:15 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8054410/webrev.00/ > 1 line changed: 0 ins; 0 del; 1 mod; > > Hi all, > > Please review patch: > > Problem: > the fix for JDK-8051896[1] introduced a typo[2] in compiler/7068051/Test7068051.sh > > jbs: https://bugs.openjdk.java.net/browse/JDK-8054410 > testing: jprt > > [1] https://bugs.openjdk.java.net/browse/JDK-8051896 > [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fcb6c71678c9#l5.16 > From david.r.chase at oracle.com Wed Aug 6 16:56:43 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 6 Aug 2014 12:56:43 -0400 Subject: [9] RFR (M) 8052081: Optimize generated by C2 code for Intel's Atom processor In-Reply-To: <53E02D54.2000500@oracle.com> References: <53DFFF86.5000302@oracle.com> <87d2cf94uz.fsf@oracle.com> <53E02D54.2000500@oracle.com> Message-ID: <31652E93-E71F-448F-901E-34B9D971B187@oracle.com> Does it make sense to revise this diagnostic (since it is now not quite strictly true), or is that a little too picky? 568 warning("CRC32 Intrinsics requires AVX and CLMUL instructions (not available on this CPU)"); I looked at all the CRC stuff, and it seemed correct to me. David On 2014-08-04, at 9:03 PM, Vladimir Kozlov wrote: > Thank you, Roland > > Vladimir > > On 8/4/14 5:07 PM, Roland Westrelin wrote: >> >>> http://cr.openjdk.java.net/~kvn/8052081/webrev/ >> >> Looks good to me. >> >> Roland. >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Wed Aug 6 17:02:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Aug 2014 10:02:14 -0700 Subject: [9] RFR (M) 8052081: Optimize generated by C2 code for Intel's Atom processor In-Reply-To: <31652E93-E71F-448F-901E-34B9D971B187@oracle.com> References: <53DFFF86.5000302@oracle.com> <87d2cf94uz.fsf@oracle.com> <53E02D54.2000500@oracle.com> <31652E93-E71F-448F-901E-34B9D971B187@oracle.com> Message-ID: <53E25F96.3060109@oracle.com> Thank you, David I agree with your suggestion about the warning but unfortunately I already pushed it. And thank you for looking on code changes. Regards, Vladimir On 8/6/14 9:56 AM, David Chase wrote: > Does it make sense to revise this diagnostic (since it is now not quite strictly true), > or is that a little too picky? > > 568 warning("CRC32 Intrinsics requires AVX and CLMUL instructions (not available on this CPU)"); > > I looked at all the CRC stuff, and it seemed correct to me. > > David > > On 2014-08-04, at 9:03 PM, Vladimir Kozlov wrote: > >> Thank you, Roland >> >> Vladimir >> >> On 8/4/14 5:07 PM, Roland Westrelin wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/8052081/webrev/ >>> >>> Looks good to me. >>> >>> Roland. >>> > From igor.ignatyev at oracle.com Wed Aug 6 17:22:03 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 06 Aug 2014 21:22:03 +0400 Subject: RFR(XXS) : 8054410 : compiler/7068051/Test7068051.java fails with FileNotFoundException: f3oo.jar In-Reply-To: <53E25BB3.6020105@oracle.com> References: <53E20E46.6040908@oracle.com> <53E25BB3.6020105@oracle.com> Message-ID: <53E2643B.5090606@oracle.com> Vladimir, thanks for review. Igor On 08/06/2014 08:45 PM, Vladimir Kozlov wrote: > Okay. > > Thanks, > Vladimir > > On 8/6/14 4:15 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8054410/webrev.00/ >> 1 line changed: 0 ins; 0 del; 1 mod; >> >> Hi all, >> >> Please review patch: >> >> Problem: >> the fix for JDK-8051896[1] introduced a typo[2] in >> compiler/7068051/Test7068051.sh >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8054410 >> testing: jprt >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8051896 >> [2] >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fcb6c71678c9#l5.16 >> From roland.westrelin at oracle.com Wed Aug 6 17:36:22 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 06 Aug 2014 19:36:22 +0200 Subject: RFR(XXS) : 8054410 : compiler/7068051/Test7068051.java fails with FileNotFoundException: f3oo.jar In-Reply-To: <53E20E46.6040908@oracle.com> References: <53E20E46.6040908@oracle.com> Message-ID: <87oavxmsfd.fsf@oracle.com> > http://cr.openjdk.java.net/~iignatyev/8054410/webrev.00/ That looks good to me. Roland. From vladimir.kozlov at oracle.com Wed Aug 6 22:09:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Aug 2014 15:09:35 -0700 Subject: RFR(S): 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp In-Reply-To: <53E11455.4010501@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> <53CEEE3D.4070501@oracle.com> <53E11455.4010501@oracle.com> Message-ID: <53E2A79F.9010402@oracle.com> On 8/5/14 10:28 AM, Morris Meyer wrote: > Vladimir, > > Here is a revised version with your suggestions. > > I added outer ResourceMarks to > > void Dependencies::log_all_dependencies() > > and > > void Dependencies::write_dependency_to(CompileLog* log, > DepType dept, > GrowableArray* args, > Klass* witness) > > as they are the only callers to No, it is also called from log_dependency() (the one in dependencies.hpp). That is why asked about missed RM in it. > > void Dependencies::write_dependency_to(CompileLog* log, > DepType dept, > GrowableArray* args, > Klass* witness); > > which does not have a ResourceMark - so these aren't nested cases. > > void Dependencies::DepStream::log_dependency(Klass* witness) > > does call > > void Dependencies::write_dependency_to(CompileLog* log, > DepType dept, > GrowableArray* args, > Klass* witness) > > which makes it a nested usage of ResourceMark - and I've added a > guarantee() to ensure the outer ResourceMark is not affected by the > inner callee. > > void Dependencies::DepStream::print_dependency(Klass* witness, bool > verbose); > > has a new GrowableArray usage and I also added an outer ResourceMark > here - and a guarantee() that goes along with the inner ResourceMark > used in the existing code of > > void Dependencies::print_dependency(DepType dept, > GrowableArray* args, > Klass* witness); New guarantees are fine. Thanks, Vladimir > > This revision has been tested with JPRT. > > Thanks for the review! > > --morris > > JBS - https://bug.openjdk.java.net/browse/JDK-8040920 > WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.08 > > On 7/22/14, 7:05 PM, Vladimir Kozlov wrote: >> 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 Thu Aug 7 06:18:25 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 07 Aug 2014 08:18:25 +0200 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <53E25B78.4080803@oracle.com> References: <53DA3807.50501@oracle.com> <53DA721A.5090009@oracle.com> <53DF9B7C.30701@oracle.com> <53DFB1C9.6000000@oracle.com> <53E08DED.60400@oracle.com> <53E10AB8.3040509@oracle.com> <53E1DB90.9030602@oracle.com> <53E25B78.4080803@oracle.com> Message-ID: <53E31A31.8060100@oracle.com> Thank you, Vladimir. Best, Tobias On 06.08.2014 18:44, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 8/6/14 12:38 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >> On 05.08.2014 18:47, Vladimir Kozlov wrote: >>> On 8/5/14 12:55 AM, Tobias Hartmann wrote: >>>> Hi Vladimir, >>>> >>>> thanks for the review. >>>> >>>>> The second condition is still in webrev: >>>>> >>>>> >> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT >>>> >>>> Sorry, I forgot to update the webrev after removing the condition. >>>> >>>> As Rickard suggested, I moved the code into a separate method >>>> called 'fold_cmpI'. If you think that the method has too >>>> many arguments, we could reduce them to '(PhaseGVN* phase, Node* >>>> cmp)' and re-compute the other values locally. >>> >>> I can't find Rickard's review. I am fine with this since >>> BoolNode::Ideal() become too large. >>> cmp2 is not used, don't need to pass it. Declare cmp argument as >>> SubNode* and pass cmp->as_Sub() so you don't need to >>> do it inside. >> >> Done. New webrev: >> >> http://cr.openjdk.java.net/~thartmann/8043284/webrev.03/ >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.02/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/4/14 7:41 AM, Tobias Hartmann wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> thanks for the review. Please see comments inline. >>>>>> >>>>>> On 31.07.2014 18:43, Vladimir Kozlov wrote: >>>>>>> You missed cop == Op_CmpI check. >>>>>> >>>>>> Thanks, I added the check. >>>>>> >>>>>>> And add checks for r0 and r1 != TypeInt::INT (no bottom type) in >>>>>>> addition to != NULL. >>>>>> >>>>>> Done. >>>>>> >>>>>>> You don't need t2 because there is already cmp2_type. Check >>>>>>> cmp2_type for != TypeInt::INT too. >>>>>> >>>>>> Done. >>>>>> >>>>>>> Use as_Sub() (which is cast) instead of isa_Sub() because there >>>>>>> is is_Sub() check at the beginning already. >>>>>> >>>>>> Done. >>>>>> >>>>>>> I don't see how second condition could happen because tr1 < tr2: >>>>>>> >>>>>>> sub_tr1 == TypeInt::CC_GT && sub_tr2 == TypeInt::CC_LT >>>>>> >>>>>> Of course, you are right. I removed the second condition. >>>>>> >>>>>>> Instead of ConINode::make() you can use phase->intcon(). >>>>>> >>>>>> I first used phase->intcon() but this method may return a cached >>>>>> ConINode and hit the assert "Idealize should >>>>>> return new >>>>>> nodes, use Identity to return old nodes" in >>>>>> 'PhaseIterGVN::transform_old()'. That's why I directly create the >>>>>> ConINode. >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> >>>>>>> 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 igor.ignatyev at oracle.com Thu Aug 7 12:12:50 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 07 Aug 2014 16:12:50 +0400 Subject: [8u40] Request for approval: backports of 8029070(XS), 8038756(S) In-Reply-To: <53DDD5FD.2070907@oracle.com> References: <53DDD5FD.2070907@oracle.com> Message-ID: <53E36D42.8070405@oracle.com> // adding hotspot-compiler-dev at openjdk.java.net Igor On 08/03/2014 10:26 AM, Igor Ignatyev wrote: > Hi all, > > I would like to request backports of fixes for JDK-8029070[1-3] and > JDK-8038756[4-6] to 8u40. The original patches were applied cleanly. > > testing: jprt > > [1] https://bugs.openjdk.java.net/browse/JDK-8029070 > [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6c583aa36bc9 > [3] http://cr.openjdk.java.net/~iignatyev/8029070/webrev.01/ > [4] https://bugs.openjdk.java.net/browse/JDK-8038756 > [5] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7daf195e6193 > [6] http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ > > Thanks, > Igor From vladimir.kozlov at oracle.com Thu Aug 7 17:34:03 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Aug 2014 10:34:03 -0700 Subject: [8u40] Request for approval: backports of 8029070(XS), 8038756(S) In-Reply-To: <53E36D42.8070405@oracle.com> References: <53DDD5FD.2070907@oracle.com> <53E36D42.8070405@oracle.com> Message-ID: <53E3B88B.60608@oracle.com> Looks good. Thanks, Vladimir On 8/7/14 5:12 AM, Igor Ignatyev wrote: > // adding hotspot-compiler-dev at openjdk.java.net > > Igor > > On 08/03/2014 10:26 AM, Igor Ignatyev wrote: >> Hi all, >> >> I would like to request backports of fixes for JDK-8029070[1-3] and >> JDK-8038756[4-6] to 8u40. The original patches were applied cleanly. >> >> testing: jprt >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8029070 >> [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6c583aa36bc9 >> [3] http://cr.openjdk.java.net/~iignatyev/8029070/webrev.01/ >> [4] https://bugs.openjdk.java.net/browse/JDK-8038756 >> [5] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7daf195e6193 >> [6] http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ >> >> Thanks, >> Igor From roland.westrelin at oracle.com Thu Aug 7 17:42:16 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 07 Aug 2014 19:42:16 +0200 Subject: RFR(S): 8043125: compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type In-Reply-To: <877g2n92j4.fsf@oracle.com> References: <878unah90x.fsf@oracle.com> <53DA91C3.4090700@oracle.com> <878un7fpus.fsf@oracle.com> <53DD2D04.8060201@oracle.com> <877g2n92j4.fsf@oracle.com> Message-ID: <87mwbgdwnb.fsf@oracle.com> I'm withdrawing this RFR. Igor V. pointed that there's no way an already translated SpeculativeTrapData or a SpeculativeTrapData that is being translated could go away. After further investigation, I found that this bug is actually caused by a WB api call that the test uses. That WB api call triggers a VM operation that unconditionally cleans all profile entries. If there's a compilation on the fly, a safepoint may happen during SpeculativeTrapData translation and entries being translated are then removed. This really is a WB api bug. Some of the changes in this RFR are valid anyway and make the code more robust and I'll send them for review in a different RFR under another bug. Roland. From morris.meyer at oracle.com Thu Aug 7 18:26:27 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 07 Aug 2014 14:26:27 -0400 Subject: RFR(S): 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp In-Reply-To: <53E2A79F.9010402@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> <53CEEE3D.4070501@oracle.com> <53E11455.4010501@oracle.com> <53E2A79F.9010402@oracle.com> Message-ID: <53E3C4D3.3030503@oracle.com> Vladimir, Enclosed is the version that takes into account your issues with log_dependency(). This has been tested with JPRT. Thanks for the review. --morris meyer WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.09 JBS - https://bug.openjdk.java.net/browse/JDK-8040920 On 8/6/14, 6:09 PM, Vladimir Kozlov wrote: > On 8/5/14 10:28 AM, Morris Meyer wrote: >> Vladimir, >> >> Here is a revised version with your suggestions. >> >> I added outer ResourceMarks to >> >> void Dependencies::log_all_dependencies() >> >> and >> >> void Dependencies::write_dependency_to(CompileLog* log, >> DepType dept, >> GrowableArray* args, >> Klass* witness) >> >> as they are the only callers to > > No, it is also called from log_dependency() (the one in > dependencies.hpp). That is why asked about missed RM in it. > >> >> void Dependencies::write_dependency_to(CompileLog* log, >> DepType dept, >> GrowableArray* args, >> Klass* witness); >> >> which does not have a ResourceMark - so these aren't nested cases. >> >> void Dependencies::DepStream::log_dependency(Klass* witness) >> >> does call >> >> void Dependencies::write_dependency_to(CompileLog* log, >> DepType dept, >> GrowableArray* args, >> Klass* witness) >> >> which makes it a nested usage of ResourceMark - and I've added a >> guarantee() to ensure the outer ResourceMark is not affected by the >> inner callee. >> >> void Dependencies::DepStream::print_dependency(Klass* witness, bool >> verbose); >> >> has a new GrowableArray usage and I also added an outer ResourceMark >> here - and a guarantee() that goes along with the inner ResourceMark >> used in the existing code of >> >> void Dependencies::print_dependency(DepType dept, >> GrowableArray* args, >> Klass* witness); > > New guarantees are fine. > > Thanks, > Vladimir > >> >> This revision has been tested with JPRT. >> >> Thanks for the review! >> >> --morris >> >> JBS - https://bug.openjdk.java.net/browse/JDK-8040920 >> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.08 >> >> On 7/22/14, 7:05 PM, Vladimir Kozlov wrote: >>> 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 roland.westrelin at oracle.com Thu Aug 7 18:33:02 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 07 Aug 2014 20:33:02 +0200 Subject: RFR (L): 7173584: Implement arraycopy as a macro node In-Reply-To: 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> <87bns3fqi1.fsf@oracle.com> Message-ID: <87k36kduap.fsf@oracle.com> > Seems very nice. I wonder if there are measurable compile speed improvements? Thanks for looking at this. I haven't done any compile speed measurements with this. Roland. From roland.westrelin at oracle.com Thu Aug 7 18:35:50 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 07 Aug 2014 20:35:50 +0200 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <53E1DB90.9030602@oracle.com> References: <53DA3807.50501@oracle.com> <53DA721A.5090009@oracle.com> <53DF9B7C.30701@oracle.com> <53DFB1C9.6000000@oracle.com> <53E08DED.60400@oracle.com> <53E10AB8.3040509@oracle.com> <53E1DB90.9030602@oracle.com> Message-ID: <87ha1odu61.fsf@oracle.com> > http://cr.openjdk.java.net/~thartmann/8043284/webrev.03/ That looks good to me. I don't think the test should go to a directory named IntegerComparison. The idea is to keep similar tests together. It doesn't seem likely that we'll add a lot more IntegerComparison tests. That seems too specific to me. IntegerArithmetic maybe? Roland. From igor.ignatyev at oracle.com Thu Aug 7 20:29:27 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 08 Aug 2014 00:29:27 +0400 Subject: [8u40] Request for approval: backports of 8029070(XS), 8038756(S) In-Reply-To: <53E3B88B.60608@oracle.com> References: <53DDD5FD.2070907@oracle.com> <53E36D42.8070405@oracle.com> <53E3B88B.60608@oracle.com> Message-ID: <53E3E1A7.8050004@oracle.com> Vladimir, thank you. Igor On 08/07/2014 09:34 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 8/7/14 5:12 AM, Igor Ignatyev wrote: >> // adding hotspot-compiler-dev at openjdk.java.net >> >> Igor >> >> On 08/03/2014 10:26 AM, Igor Ignatyev wrote: >>> Hi all, >>> >>> I would like to request backports of fixes for JDK-8029070[1-3] and >>> JDK-8038756[4-6] to 8u40. The original patches were applied cleanly. >>> >>> testing: jprt >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8029070 >>> [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6c583aa36bc9 >>> [3] http://cr.openjdk.java.net/~iignatyev/8029070/webrev.01/ >>> [4] https://bugs.openjdk.java.net/browse/JDK-8038756 >>> [5] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7daf195e6193 >>> [6] http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ >>> >>> Thanks, >>> Igor From john.r.rose at oracle.com Thu Aug 7 21:28:38 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 7 Aug 2014 14:28:38 -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: <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> On Jul 23, 2014, at 11:38 AM, Aleksey Shipilev wrote: > 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/ It's plausible, safe, clean, well-documented, and helps with real chips. What's not to like? You can count me as a reviewer. Nit: sp+C made me itchy, even though it is clarified several sentences down that C<0. Might as well lead off with sp-C. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Thu Aug 7 22:23:02 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 08 Aug 2014 02:23:02 +0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> Message-ID: <53E3FC46.3000008@oracle.com> On 08/08/2014 01:28 AM, John Rose wrote: > On Jul 23, 2014, at 11:38 AM, Aleksey Shipilev > > wrote: > >> 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/ >>> > > It's plausible, safe, clean, well-documented, and helps with real chips. > What's not to like? > You can count me as a reviewer. Thanks John. I have second thoughts about this, however. Since the effect seems to be related to callee-saves, I would rather step back for some machine-independent constant. Tying in the cache line size seems not to be future proof, especially if we ever come across the machine with >128 byte cache lines, which will blow up the instruction encoding with unknown effects. Vladimir pointed where to look for frame structure [1], but I still haven't parsed it to make an educated guess about how much to step back. Any ideas? > Nit: sp+C made me itchy, even though it is clarified several sentences > down that C<0. Might as well lead off with sp-C. Yes, needs fixing in the comments. Thanks, -Aleksey. [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/0b9afe536f5c/src/cpu/x86/vm/x86_64.ad#l2549 From vladimir.kozlov at oracle.com Thu Aug 7 22:49:22 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Aug 2014 15:49:22 -0700 Subject: RFR(S): 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp In-Reply-To: <53E3C4D3.3030503@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> <53CEEE3D.4070501@oracle.com> <53E11455.4010501@oracle.com> <53E2A79F.9010402@oracle.com> <53E3C4D3.3030503@oracle.com> Message-ID: <53E40272.3090908@oracle.com> You don't need guarante() in caller log_dependency() at line 403 because you already have one in callee log_dependency() at line 377. Otherwise it seems fine. Thanks, Vladimir On 8/7/14 11:26 AM, Morris Meyer wrote: > Vladimir, > > Enclosed is the version that takes into account your issues with > log_dependency(). This has been tested with JPRT. > > Thanks for the review. > > --morris meyer > > WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.09 > JBS - https://bug.openjdk.java.net/browse/JDK-8040920 > > On 8/6/14, 6:09 PM, Vladimir Kozlov wrote: >> On 8/5/14 10:28 AM, Morris Meyer wrote: >>> Vladimir, >>> >>> Here is a revised version with your suggestions. >>> >>> I added outer ResourceMarks to >>> >>> void Dependencies::log_all_dependencies() >>> >>> and >>> >>> void Dependencies::write_dependency_to(CompileLog* log, >>> DepType dept, >>> GrowableArray* args, >>> Klass* witness) >>> >>> as they are the only callers to >> >> No, it is also called from log_dependency() (the one in >> dependencies.hpp). That is why asked about missed RM in it. >> >>> >>> void Dependencies::write_dependency_to(CompileLog* log, >>> DepType dept, >>> GrowableArray* args, >>> Klass* witness); >>> >>> which does not have a ResourceMark - so these aren't nested cases. >>> >>> void Dependencies::DepStream::log_dependency(Klass* witness) >>> >>> does call >>> >>> void Dependencies::write_dependency_to(CompileLog* log, >>> DepType dept, >>> GrowableArray* args, >>> Klass* witness) >>> >>> which makes it a nested usage of ResourceMark - and I've added a >>> guarantee() to ensure the outer ResourceMark is not affected by the >>> inner callee. >>> >>> void Dependencies::DepStream::print_dependency(Klass* witness, bool >>> verbose); >>> >>> has a new GrowableArray usage and I also added an outer ResourceMark >>> here - and a guarantee() that goes along with the inner ResourceMark >>> used in the existing code of >>> >>> void Dependencies::print_dependency(DepType dept, >>> GrowableArray* args, >>> Klass* witness); >> >> New guarantees are fine. >> >> Thanks, >> Vladimir >> >>> >>> This revision has been tested with JPRT. >>> >>> Thanks for the review! >>> >>> --morris >>> >>> JBS - https://bug.openjdk.java.net/browse/JDK-8040920 >>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.08 >>> >>> On 7/22/14, 7:05 PM, Vladimir Kozlov wrote: >>>> 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 john.r.rose at oracle.com Thu Aug 7 22:57:16 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 7 Aug 2014 15:57:16 -0700 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53E3FC46.3000008@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> Message-ID: <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> On Aug 7, 2014, at 3:23 PM, Aleksey Shipilev wrote: > On 08/08/2014 01:28 AM, John Rose wrote: >> On Jul 23, 2014, at 11:38 AM, Aleksey Shipilev >> > wrote: >> >>> 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/ >>>> >> >> It's plausible, safe, clean, well-documented, and helps with real chips. >> What's not to like? >> You can count me as a reviewer. > > Thanks John. I have second thoughts about this, however. > > Since the effect seems to be related to callee-saves, I would rather > step back for some machine-independent constant. Tying in the cache line > size seems not to be future proof, especially if we ever come across the > machine with >128 byte cache lines, which will blow up the instruction > encoding with unknown effects. This can be partially future-proofed by adding a tuning parameter which defaults to the cache line size. That way we can easily re-test if we think the tuning point changes. > Vladimir pointed where to look for frame structure [1], but I still > haven't parsed it to make an educated guess about how much to step back. > Any ideas? Callee saves will get spilled in the general spill area, IIRC. That will be near the callee SP, which is unpredictable. I don't see any area in the generic frame layout which is reliably better than SP - CLSize. Maybe SP - MaxTinyImmediateOffset, or the min of the two. ? John >> Nit: sp+C made me itchy, even though it is clarified several sentences >> down that C<0. Might as well lead off with sp-C. > > Yes, needs fixing in the comments. > > Thanks, > -Aleksey. > > [1] > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/0b9afe536f5c/src/cpu/x86/vm/x86_64.ad#l2549 > From tobias.hartmann at oracle.com Fri Aug 8 05:11:57 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 08 Aug 2014 07:11:57 +0200 Subject: [9] RFR(S): 8043284: Optimize signed integer comparison In-Reply-To: <87ha1odu61.fsf@oracle.com> References: <53DA3807.50501@oracle.com> <53DA721A.5090009@oracle.com> <53DF9B7C.30701@oracle.com> <53DFB1C9.6000000@oracle.com> <53E08DED.60400@oracle.com> <53E10AB8.3040509@oracle.com> <53E1DB90.9030602@oracle.com> <87ha1odu61.fsf@oracle.com> Message-ID: <53E45C1D.1000209@oracle.com> Hi Roland, thanks for the review. You are right, 'IntegerComparison' is too specific. As you suggested, I changed the name of the directory to 'IntegerArithmetic'. New webrev: http://cr.openjdk.java.net/~thartmann/8043284/webrev.04/ Best, Tobias On 07.08.2014 20:35, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~thartmann/8043284/webrev.03/ > That looks good to me. I don't think the test should go to a directory > named IntegerComparison. The idea is to keep similar tests together. It > doesn't seem likely that we'll add a lot more IntegerComparison > tests. That seems too specific to me. IntegerArithmetic maybe? > > Roland. From aleksey.shipilev at oracle.com Fri Aug 8 12:01:02 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 08 Aug 2014 16:01:02 +0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> Message-ID: <53E4BBFE.20705@oracle.com> On 08/08/2014 02:57 AM, John Rose wrote: >> Vladimir pointed where to look for frame structure [1], but I >> still haven't parsed it to make an educated guess about how much to >> step back. Any ideas? > > Callee saves will get spilled in the general spill area, IIRC. That > will be near the callee SP, which is unpredictable. > > I don't see any area in the generic frame layout which is reliably > better than SP - CLSize. Maybe SP - MaxTinyImmediateOffset, or the > min of the two. Okay, let's go with this one then: http://cr.openjdk.java.net/~shade/8050147/webrev.03/ This test passes JPRT. Rechecked the effect on my Sandy Bridge laptop. No other testing since this offset was already thoroughly tested before. Do I need a second Reviewer? Thanks, -Aleksey. From morris.meyer at oracle.com Fri Aug 8 15:46:05 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Fri, 08 Aug 2014 11:46:05 -0400 Subject: [8u40] RFA(S): 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp Message-ID: <53E4F0BD.9050407@oracle.com> Folks, Could I get approval to backport this parfait fix to 8u40? The original patches were applied cleanly. Thanks. --morris JDK9 - http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3e24ce3b2486 JBS - https://bugs.openjdk.java.net/browse/JDK-8040920 WEBREV - http://cr.openjdk.java.net/~morris/Backport-8040920.10 From john.r.rose at oracle.com Fri Aug 8 19:38:00 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 8 Aug 2014 12:38:00 -0700 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53E4BBFE.20705@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> Message-ID: <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> On Aug 8, 2014, at 5:01 AM, Aleksey Shipilev wrote: > On 08/08/2014 02:57 AM, John Rose wrote: >>> Vladimir pointed where to look for frame structure [1], but I >>> still haven't parsed it to make an educated guess about how much to >>> step back. Any ideas? >> >> Callee saves will get spilled in the general spill area, IIRC. That >> will be near the callee SP, which is unpredictable. >> >> I don't see any area in the generic frame layout which is reliably >> better than SP - CLSize. Maybe SP - MaxTinyImmediateOffset, or the >> min of the two. > > Okay, let's go with this one then: > http://cr.openjdk.java.net/~shade/8050147/webrev.03/ Why 8+CLSize (40/72/136) instead of just CLSize (32/64/128)? Is there usually something hovering at sp(-8), like a frequently pushed temp? ? John From vladimir.kozlov at oracle.com Fri Aug 8 21:37:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Aug 2014 14:37:56 -0700 Subject: [8u40] RFR (XS) 8054376: Move RTM flags out from Experimental to Product Message-ID: <53E54334.3000503@oracle.com> http://cr.openjdk.java.net/~kvn/8054376_8u/webrev/ https://bugs.openjdk.java.net/browse/JDK-8054376 In JDK 8u20 RTM instructions and associated flags were added to Hotspot as experimental. For 8u40 we can move following flags to Product (as in jdk9): UseRTMLocking, UseRTMDeopt and RTMRetryCount. We do regular testing of RTM in jdk 9 and did not find major problems. This change is only for 8u because in jdk9 these flags are already product. Thanks, Vladimir From roland.westrelin at oracle.com Mon Aug 11 07:35:11 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 11 Aug 2014 09:35:11 +0200 Subject: [8u40] RFR (XS) 8054376: Move RTM flags out from Experimental to Product In-Reply-To: <53E54334.3000503@oracle.com> References: <53E54334.3000503@oracle.com> Message-ID: <20E7FF05-6D2D-446E-88C7-FF4348449F4A@oracle.com> Ok. Roland. On Aug 8, 2014, at 11:37 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8054376_8u/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8054376 > > In JDK 8u20 RTM instructions and associated flags were added to Hotspot as experimental. For 8u40 we can move following flags to Product (as in jdk9): UseRTMLocking, UseRTMDeopt and RTMRetryCount. > > We do regular testing of RTM in jdk 9 and did not find major problems. > > This change is only for 8u because in jdk9 these flags are already product. > > Thanks, > Vladimir From aleksey.shipilev at oracle.com Mon Aug 11 08:18:46 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 11 Aug 2014 12:18:46 +0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> Message-ID: <53E87C66.7000702@oracle.com> On 08/08/2014 11:38 PM, John Rose wrote: > On Aug 8, 2014, at 5:01 AM, Aleksey Shipilev wrote: > >> On 08/08/2014 02:57 AM, John Rose wrote: >>>> Vladimir pointed where to look for frame structure [1], but I >>>> still haven't parsed it to make an educated guess about how much to >>>> step back. Any ideas? >>> >>> Callee saves will get spilled in the general spill area, IIRC. That >>> will be near the callee SP, which is unpredictable. >>> >>> I don't see any area in the generic frame layout which is reliably >>> better than SP - CLSize. Maybe SP - MaxTinyImmediateOffset, or the >>> min of the two. >> >> Okay, let's go with this one then: >> http://cr.openjdk.java.net/~shade/8050147/webrev.03/ > > Why 8+CLSize (40/72/136) instead of just CLSize (32/64/128)? > Is there usually something hovering at sp(-8), like a frequently pushed temp? The original experiment was taken without any knowledge if SP was aligned to >8 or not. If 8-byte read from SP(0) splits the cache line, then 8-byte read from SP(-CL) also splits the cache line *and* shares it with SP(0). Additional 8-byte push back was to dodge this. But, it appears the SP is aligned to 16 bytes? If so, we can go with this: http://cr.openjdk.java.net/~shade/8050147/webrev.04/ -Aleksey. From dave.dice at oracle.com Mon Aug 11 12:29:46 2014 From: dave.dice at oracle.com (Dave Dice) Date: Mon, 11 Aug 2014 08:29:46 -0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53E87C66.7000702@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> <53E87C66.7000702@oracle.com> Message-ID: On 2014-8-11, at 4:18 AM, Aleksey Shipilev wrote: > On 08/08/2014 11:38 PM, John Rose wrote: >> On Aug 8, 2014, at 5:01 AM, Aleksey Shipilev wrote: >> >>> On 08/08/2014 02:57 AM, John Rose wrote: >>>>> Vladimir pointed where to look for frame structure [1], but I >>>>> still haven't parsed it to make an educated guess about how much to >>>>> step back. Any ideas? >>>> >>>> Callee saves will get spilled in the general spill area, IIRC. That >>>> will be near the callee SP, which is unpredictable. >>>> >>>> I don't see any area in the generic frame layout which is reliably >>>> better than SP - CLSize. Maybe SP - MaxTinyImmediateOffset, or the >>>> min of the two. >>> >>> Okay, let's go with this one then: >>> http://cr.openjdk.java.net/~shade/8050147/webrev.03/ >> >> Why 8+CLSize (40/72/136) instead of just CLSize (32/64/128)? >> Is there usually something hovering at sp(-8), like a frequently pushed temp? > > The original experiment was taken without any knowledge if SP was > aligned to >8 or not. If 8-byte read from SP(0) splits the cache line, > then 8-byte read from SP(-CL) also splits the cache line *and* shares it > with SP(0). Additional 8-byte push back was to dodge this. But, it > appears the SP is aligned to 16 bytes? IIRC all compilers keep at least 8 byte alignment, but that number has been increasing in order to better allow SSE/MMX auto variables. Hopefully we?ll never see cases where a misaligned atomic falls on two underlying lines. Intel supports this for legacy operations, but effectively they quiesce the system in order to do it. See https://blogs.oracle.com/dave/entry/qpi_quiescence. We could always switch to a locked byte add, but that can cause stalls if we re-access the same location in short order as a non-byte. Regards Dave > > If so, we can go with this: > http://cr.openjdk.java.net/~shade/8050147/webrev.04/ > > -Aleksey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Mon Aug 11 16:32:50 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 11 Aug 2014 20:32:50 +0400 Subject: [8u40] RFR (S): 8054805: Update CLI tests on RTM options to reflect changes from JDK-8054376 Message-ID: <53E8F032.4000005@oracle.com> Hi all, please review fix for "8054805: Update CLI tests on RTM options to reflect changes from JDK-8054376". Before JDK-8054376 [*] all RTM-related VM options were 'experimental' and after integration of JDK-8054376 three of them will be 'product'. Corresponding CLI tests verify that options are experimental, so after 8054376 several tests will start failing. This fix (8054805) will update such tests so they become identical to CLI tests for jdk9 where UseRTMLocking, UseRTMDeopt and RTMRetryCount options were always 'product'. Webrev: http://cr.openjdk.java.net/~fzhinkin/8054805/webrev.00/ Bug id: https://bugs.openjdk.java.net/browse/JDK-8054805 Testing: manual, JPRT, automated. [*] https://bugs.openjdk.java.net/browse/JDK-8054376 Thanks, Filipp. From vladimir.kozlov at oracle.com Mon Aug 11 16:45:13 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Aug 2014 09:45:13 -0700 Subject: [8u40] RFR (S): 8054805: Update CLI tests on RTM options to reflect changes from JDK-8054376 In-Reply-To: <53E8F032.4000005@oracle.com> References: <53E8F032.4000005@oracle.com> Message-ID: <53E8F319.2060205@oracle.com> Thank you, Filipp, for fixing these tests. Looks good. Do you need sponsor? Thanks, Vladimir On 8/11/14 9:32 AM, Filipp Zhinkin wrote: > Hi all, > > please review fix for "8054805: Update CLI tests on RTM options > to reflect changes from JDK-8054376". > > Before JDK-8054376 [*] all RTM-related VM options were 'experimental' > and after integration of JDK-8054376 three of them will be 'product'. > > Corresponding CLI tests verify that options are experimental, > so after 8054376 several tests will start failing. > > This fix (8054805) will update such tests so they become > identical to CLI tests for jdk9 where UseRTMLocking, UseRTMDeopt > and RTMRetryCount options were always 'product'. > > > Webrev: http://cr.openjdk.java.net/~fzhinkin/8054805/webrev.00/ > Bug id: https://bugs.openjdk.java.net/browse/JDK-8054805 > Testing: manual, JPRT, automated. > > [*] https://bugs.openjdk.java.net/browse/JDK-8054376 > > Thanks, > Filipp. From filipp.zhinkin at oracle.com Mon Aug 11 17:06:04 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 11 Aug 2014 21:06:04 +0400 Subject: [8u40] RFR (S): 8054805: Update CLI tests on RTM options to reflect changes from JDK-8054376 In-Reply-To: <53E8F319.2060205@oracle.com> References: <53E8F032.4000005@oracle.com> <53E8F319.2060205@oracle.com> Message-ID: <53E8F7FC.50301@oracle.com> Vladimir, thank you for the review. On 08/11/2014 08:45 PM, Vladimir Kozlov wrote: > Thank you, Filipp, for fixing these tests. > > Looks good. Do you need sponsor? Yes. Would you mind sponsoring this change? Thanks, Filipp. > > Thanks, > Vladimir > > On 8/11/14 9:32 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review fix for "8054805: Update CLI tests on RTM options >> to reflect changes from JDK-8054376". >> >> Before JDK-8054376 [*] all RTM-related VM options were 'experimental' >> and after integration of JDK-8054376 three of them will be 'product'. >> >> Corresponding CLI tests verify that options are experimental, >> so after 8054376 several tests will start failing. >> >> This fix (8054805) will update such tests so they become >> identical to CLI tests for jdk9 where UseRTMLocking, UseRTMDeopt >> and RTMRetryCount options were always 'product'. >> >> >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8054805/webrev.00/ >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8054805 >> Testing: manual, JPRT, automated. >> >> [*] https://bugs.openjdk.java.net/browse/JDK-8054376 >> >> Thanks, >> Filipp. From vladimir.kozlov at oracle.com Mon Aug 11 18:33:45 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Aug 2014 11:33:45 -0700 Subject: [8u40] RFR (XS) 8054376: Move RTM flags out from Experimental to Product In-Reply-To: <20E7FF05-6D2D-446E-88C7-FF4348449F4A@oracle.com> References: <53E54334.3000503@oracle.com> <20E7FF05-6D2D-446E-88C7-FF4348449F4A@oracle.com> Message-ID: <53E90C89.5000103@oracle.com> Thank you, Roland Vladimir On 8/11/14 12:35 AM, Roland Westrelin wrote: > Ok. > > Roland. > > On Aug 8, 2014, at 11:37 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8054376_8u/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8054376 >> >> In JDK 8u20 RTM instructions and associated flags were added to Hotspot as experimental. For 8u40 we can move following flags to Product (as in jdk9): UseRTMLocking, UseRTMDeopt and RTMRetryCount. >> >> We do regular testing of RTM in jdk 9 and did not find major problems. >> >> This change is only for 8u because in jdk9 these flags are already product. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Mon Aug 11 19:22:13 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Aug 2014 12:22:13 -0700 Subject: [8u40] RFA(S): 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp In-Reply-To: <53E4F0BD.9050407@oracle.com> References: <53E4F0BD.9050407@oracle.com> Message-ID: <53E917E5.6060808@oracle.com> Good for backport. Thanks, Vladimir On 8/8/14 8:46 AM, Morris Meyer wrote: > Folks, > > Could I get approval to backport this parfait fix to 8u40? The > original patches were applied cleanly. > > Thanks. > > --morris > > JDK9 - http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3e24ce3b2486 > JBS - https://bugs.openjdk.java.net/browse/JDK-8040920 > WEBREV - http://cr.openjdk.java.net/~morris/Backport-8040920.10 From john.r.rose at oracle.com Mon Aug 11 21:44:50 2014 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Aug 2014 14:44:50 -0700 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53E87C66.7000702@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> <53E87C66.7000702@oracle.com> Message-ID: On Aug 11, 2014, at 1:18 AM, Aleksey Shipilev wrote: > The original experiment was taken without any knowledge if SP was > aligned to >8 or not. If 8-byte read from SP(0) splits the cache line, > then 8-byte read from SP(-CL) also splits the cache line *and* shares it > with SP(0). Additional 8-byte push back was to dodge this. But, it > appears the SP is aligned to 16 bytes? That is true. It is enforced and commented in several places, such as the definition 'StackAlignmentInBytes = 16'. In any case, a native-size (8-byte, 64-bit) read or write at SP(0) will never split a cache line, since that's where a 'call' instruction pushes the return pc, and we'd be badly broken if that did a split. > If so, we can go with this: > http://cr.openjdk.java.net/~shade/8050147/webrev.04/ Yes, please. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Mon Aug 11 21:49:54 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 12 Aug 2014 01:49:54 +0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> <53E87C66.7000702@oracle.com> Message-ID: <53E93A82.4060101@oracle.com> On 08/12/2014 01:44 AM, John Rose wrote: >> If so, we can go with this: >> http://cr.openjdk.java.net/~shade/8050147/webrev.04/ >> > > Yes, please. Thanks for the review! This patch passes full JPRT, works fine with benchmarks on my laptop. I would assume it works well on larger workloads and larger machines, since we have already tested SP(CL-8) and SP(-8) with similar characteristics. I need a sponsor. Thanks, -Aleksey. From vladimir.kozlov at oracle.com Mon Aug 11 22:30:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Aug 2014 15:30:53 -0700 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53E93A82.4060101@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> <53E87C66.7000702@oracle.com> <53E93A82.4060101@oracle.com> Message-ID: <53E9441D.8060209@oracle.com> Hi, Aleksey You may need to modify Compile::bang_size_in_bytes() and LIR_Assembler::bang_size_in_bytes() to bang correct number of pages. Try to test with small stacks and see test/compiler/uncommontrap/StackOverflowGuardPagesOff.java. Related problems fixed recently: https://bugs.openjdk.java.net/browse/JDK-8026775 https://bugs.openjdk.java.net/browse/JDK-8032410 Thanks, Vladimir On 8/11/14 2:49 PM, Aleksey Shipilev wrote: > On 08/12/2014 01:44 AM, John Rose wrote: >>> If so, we can go with this: >>> http://cr.openjdk.java.net/~shade/8050147/webrev.04/ >>> >> >> Yes, please. > > Thanks for the review! > > This patch passes full JPRT, works fine with benchmarks on my laptop. I > would assume it works well on larger workloads and larger machines, > since we have already tested SP(CL-8) and SP(-8) with similar > characteristics. > > I need a sponsor. > > Thanks, > -Aleksey. > From zoltan.majo at oracle.com Tue Aug 12 07:12:48 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 12 Aug 2014 09:12:48 +0200 Subject: [9] RFR(S): 8043913: remove legacy code in SPARC's VM_Version::platform_features Message-ID: <53E9BE70.50305@oracle.com> Hi, please remove the following patch. Problem: Since on SPARC we are now building/running on Solaris 10 and up, legacy code in the method VM_Version::platform_features can be removed. Solution: The getisax(2) call is available from Solaris 10, therefore legacy code to determine platform features can be removed. Solaris 10 defines some of the AV* constants used in the method. Some of these defines could have been removed as well, but different versions of Solaris 10 define different subsets of the constants, therefore it is better to leave the defines for now. Webrev: http://cr.openjdk.java.net/~thartmann/8043913/webrev.00/ Testing: - built JVM on solaris_sparc_5.10u5 and on solaris_sparc_5.11.1; - ran all JPRT tests on the solaris_sparcv9* platform; - ran test/sanity/ExecuteInternalVMTests.java (the test executed by the "hotspot_compiler" JPRT test) on solaris_sparc_5.11.1, solaris_sparc_5.10u5, and solaris_sparc_5.10u6 Thank you and best regards, Zoltan From roland.westrelin at oracle.com Tue Aug 12 08:40:58 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 12 Aug 2014 10:40:58 +0200 Subject: RFR(S): 8054224: Recursive method that was compiled by C1 is unable to catch StackOverflowError Message-ID: http://cr.openjdk.java.net/~roland/8054224/webrev.00/ When processing a StackOverflowError, a call to SharedRuntime::compute_compiled_exc_handler() triggers another StackOverflowError which replaces the current exception and causes the frame to be unwounded. The exception cache is wrongly updated to record that a StackOverflowError at this pc should be handled by unwinding the stack. When the StackOverflowError propagates to the caller (same method at same pc), the caller unwinds when it should jump to the exception handler. Fixed by setting the exception cache only when the exception wasn?t replaced using the same check opto/runtime.cpp does. Roland. From vladimir.kozlov at oracle.com Tue Aug 12 13:08:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 06:08:35 -0700 Subject: [9] RFR(S): 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: <53E9BE70.50305@oracle.com> References: <53E9BE70.50305@oracle.com> Message-ID: <53EA11D3.3030202@oracle.com> Hi, Zoltan I would suggest to replace next removed check with assert to make sure we have getisax: if (os::Solaris::supports_getisax()) Otherwise it looks good. Thanks, Vladimir On 8/12/14 12:12 AM, Zolt?n Maj? wrote: > Hi, > > > please remove the following patch. > > Problem: Since on SPARC we are now building/running on Solaris 10 and up, legacy code in the method > VM_Version::platform_features can be removed. > > Solution: The getisax(2) call is available from Solaris 10, therefore legacy code to determine platform features can be > removed. Solaris 10 defines some of the AV* constants used in the method. Some of these defines could have been removed > as well, but different versions of Solaris 10 define different subsets of the constants, therefore it is better to leave > the defines for now. > > Webrev: http://cr.openjdk.java.net/~thartmann/8043913/webrev.00/ > > Testing: > > - built JVM on solaris_sparc_5.10u5 and on solaris_sparc_5.11.1; > - ran all JPRT tests on the solaris_sparcv9* platform; > - ran test/sanity/ExecuteInternalVMTests.java (the test executed by the "hotspot_compiler" JPRT test) on > solaris_sparc_5.11.1, solaris_sparc_5.10u5, and solaris_sparc_5.10u6 > > Thank you and best regards, > > > Zoltan > From vladimir.kozlov at oracle.com Tue Aug 12 13:56:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 06:56:58 -0700 Subject: RFR(S): 8054224: Recursive method that was compiled by C1 is unable to catch StackOverflowError In-Reply-To: References: Message-ID: <53EA1D2A.9060302@oracle.com> Looks fine. Make sure Client (C1) VM recognize test's flags. Thanks, Vladimir On 8/12/14 1:40 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8054224/webrev.00/ > > When processing a StackOverflowError, a call to SharedRuntime::compute_compiled_exc_handler() triggers another StackOverflowError which replaces the current exception and causes the frame to be unwounded. The exception cache is wrongly updated to record that a StackOverflowError at this pc should be handled by unwinding the stack. When the StackOverflowError propagates to the caller (same method at same pc), the caller unwinds when it should jump to the exception handler. Fixed by setting the exception cache only when the exception wasn?t replaced using the same check opto/runtime.cpp does. > > Roland. > From mark.reinhold at oracle.com Tue Aug 12 15:14:49 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 12 Aug 2014 08:14:49 -0700 (PDT) Subject: JEP 210: LambdaForm Reduction and Caching Message-ID: <20140812151449.EBCD43400E@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/210 - Mark From christian.thalinger at oracle.com Tue Aug 12 16:23:48 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 12 Aug 2014 09:23:48 -0700 Subject: [9] RFR(S): 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: <53E9BE70.50305@oracle.com> References: <53E9BE70.50305@oracle.com> Message-ID: <1739343A-489A-4094-A70B-A35B343E90D9@oracle.com> On Aug 12, 2014, at 12:12 AM, Zolt?n Maj? wrote: > Hi, > > > please remove the following patch. > > Problem: Since on SPARC we are now building/running on Solaris 10 and up, legacy code in the method VM_Version::platform_features can be removed. > > Solution: The getisax(2) call is available from Solaris 10, therefore legacy code to determine platform features can be removed. Solaris 10 defines some of the AV* constants used in the method. Some of these defines could have been removed as well, but different versions of Solaris 10 define different subsets of the constants, therefore it is better to leave the defines for now. Can you file an Enhancement to keep track of this? > > Webrev: http://cr.openjdk.java.net/~thartmann/8043913/webrev.00/ > > Testing: > > - built JVM on solaris_sparc_5.10u5 and on solaris_sparc_5.11.1; > - ran all JPRT tests on the solaris_sparcv9* platform; > - ran test/sanity/ExecuteInternalVMTests.java (the test executed by the "hotspot_compiler" JPRT test) on solaris_sparc_5.11.1, solaris_sparc_5.10u5, and solaris_sparc_5.10u6 > > Thank you and best regards, > > > Zoltan > From igor.veresov at oracle.com Tue Aug 12 17:11:14 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 12 Aug 2014 10:11:14 -0700 Subject: RFR(S): 8054224: Recursive method that was compiled by C1 is unable to catch StackOverflowError In-Reply-To: References: Message-ID: <414F5CB2-A1D7-4589-9275-27B4528998E3@oracle.com> Looks good. igor On Aug 12, 2014, at 1:40 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8054224/webrev.00/ > > When processing a StackOverflowError, a call to SharedRuntime::compute_compiled_exc_handler() triggers another StackOverflowError which replaces the current exception and causes the frame to be unwounded. The exception cache is wrongly updated to record that a StackOverflowError at this pc should be handled by unwinding the stack. When the StackOverflowError propagates to the caller (same method at same pc), the caller unwinds when it should jump to the exception handler. Fixed by setting the exception cache only when the exception wasn?t replaced using the same check opto/runtime.cpp does. > > Roland. From vladimir.kozlov at oracle.com Tue Aug 12 17:52:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 10:52:27 -0700 Subject: [9] RFR (S) 8054927: Missing MemNode::acquire ordering in some volatile Load nodes In-Reply-To: <53EA2886.6050400@oracle.com> References: <53DECAF3.4010203@oracle.com> <53DFF783.2020703@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566ACC2DB7@DEWDFEMB19C.global.corp.sap> <53EA2886.6050400@oracle.com> Message-ID: <53EA545B.6030504@oracle.com> http://cr.openjdk.java.net/~kvn/8054927/webrev/ https://bugs.openjdk.java.net/browse/JDK-8054927 Fixed memory ordering parameter and added missing barriers for volatile loads. Thanks, Vladimir From zoltan.majo at oracle.com Tue Aug 12 18:54:54 2014 From: zoltan.majo at oracle.com (Zoltan Majo) Date: Tue, 12 Aug 2014 20:54:54 +0200 Subject: [9] RFR(S): 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: <1739343A-489A-4094-A70B-A35B343E90D9@oracle.com> References: <53E9BE70.50305@oracle.com> <1739343A-489A-4094-A70B-A35B343E90D9@oracle.com> Message-ID: <53EA62FE.6030804@oracle.com> Hi, On 12.08.2014 18:23, Christian Thalinger wrote: > On Aug 12, 2014, at 12:12 AM, Zolt?n Maj? wrote: > >> Hi, >> >> >> please remove the following patch. >> >> Problem: Since on SPARC we are now building/running on Solaris 10 and up, legacy code in the method VM_Version::platform_features can be removed. >> >> Solution: The getisax(2) call is available from Solaris 10, therefore legacy code to determine platform features can be removed. Solaris 10 defines some of the AV* constants used in the method. Some of these defines could have been removed as well, but different versions of Solaris 10 define different subsets of the constants, therefore it is better to leave the defines for now. > Can you file an Enhancement to keep track of this? Issue 8043913 is currently filed as an enhancement. Did you mean to file an enhancement for the time when we decide to drop support for Solaris < 11 (and add some notes there on what could still be done)? Or should I add notes already to the current issue? Thank you! Best, Zoltan >> Webrev: http://cr.openjdk.java.net/~thartmann/8043913/webrev.00/ >> >> Testing: >> >> - built JVM on solaris_sparc_5.10u5 and on solaris_sparc_5.11.1; >> - ran all JPRT tests on the solaris_sparcv9* platform; >> - ran test/sanity/ExecuteInternalVMTests.java (the test executed by the "hotspot_compiler" JPRT test) on solaris_sparc_5.11.1, solaris_sparc_5.10u5, and solaris_sparc_5.10u6 >> >> Thank you and best regards, >> >> >> Zoltan >> From christian.thalinger at oracle.com Tue Aug 12 19:31:38 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 12 Aug 2014 12:31:38 -0700 Subject: [9] RFR(S): 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: <53EA62FE.6030804@oracle.com> References: <53E9BE70.50305@oracle.com> <1739343A-489A-4094-A70B-A35B343E90D9@oracle.com> <53EA62FE.6030804@oracle.com> Message-ID: <6D206911-904A-4739-AB32-50AED342F8E6@oracle.com> On Aug 12, 2014, at 11:54 AM, Zoltan Majo wrote: > Hi, > > > On 12.08.2014 18:23, Christian Thalinger wrote: >> On Aug 12, 2014, at 12:12 AM, Zolt?n Maj? wrote: >> >>> Hi, >>> >>> >>> please remove the following patch. >>> >>> Problem: Since on SPARC we are now building/running on Solaris 10 and up, legacy code in the method VM_Version::platform_features can be removed. >>> >>> Solution: The getisax(2) call is available from Solaris 10, therefore legacy code to determine platform features can be removed. Solaris 10 defines some of the AV* constants used in the method. Some of these defines could have been removed as well, but different versions of Solaris 10 define different subsets of the constants, therefore it is better to leave the defines for now. >> Can you file an Enhancement to keep track of this? > > Issue 8043913 is currently filed as an enhancement. Did you mean to file an enhancement for the time when we decide to drop support for Solaris < 11 (and add some notes there on what could still be done)? Yes, that. > Or should I add notes already to the current issue? > > Thank you! > > Best, > > > Zoltan > > >>> Webrev: http://cr.openjdk.java.net/~thartmann/8043913/webrev.00/ >>> >>> Testing: >>> >>> - built JVM on solaris_sparc_5.10u5 and on solaris_sparc_5.11.1; >>> - ran all JPRT tests on the solaris_sparcv9* platform; >>> - ran test/sanity/ExecuteInternalVMTests.java (the test executed by the "hotspot_compiler" JPRT test) on solaris_sparc_5.11.1, solaris_sparc_5.10u5, and solaris_sparc_5.10u6 >>> >>> Thank you and best regards, >>> >>> >>> Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: From morris.meyer at oracle.com Tue Aug 12 21:30:54 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 12 Aug 2014 17:30:54 -0400 Subject: [8u40] RFA(S): 8039498: Add iterators to GrowableArray Message-ID: <53EA878E.8040508@oracle.com> Folks, Could I get approval to backport 8039498 into 8u40? This change set is necessary for the backport of 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp The original patch applied cleanly. Thanks. --morris JDK9 - http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/758ec32bde1b JBS - https://bugs.openjdk.java.net/browse/JDK-8039498 -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Aug 12 22:12:49 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 12 Aug 2014 18:12:49 -0400 Subject: Question about nmethod flushing Message-ID: <53EA9161.7020009@oracle.com> I have a question about nmethod flushing wrt to RedefineClasses (no, no, no, please keep reading!) When we redefine a class, there is code to deoptimize the methods, and make them non-entrant. Non-entrant methods are still considered alive, so for class redefinition we walk the code cache so that we don't delete the metadata for any methods while some nmethod is still referring to it. Eventually the sweeper will come along and mark the methods as zombies so we don't have to deal with them anymore, but for class redefinition, can we force methods to go to zombie's earlier? Or make the sweeper more aggressive after a class redefinition? This code cache walking isn't that expensive, but we keep around a lot of metadata as a result that could be more eagerly deleted. Thanks, Coleen From vladimir.kozlov at oracle.com Tue Aug 12 23:58:41 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 16:58:41 -0700 Subject: Question about nmethod flushing In-Reply-To: <53EA9161.7020009@oracle.com> References: <53EA9161.7020009@oracle.com> Message-ID: <53EAAA31.3070400@oracle.com> nmethods are alive when there are corresponding stack frames on java execution stacks. We can't make them zombie until we 100% sure they are not used. Is it possible that we are reaching a nmethod even if it is not present on call stack? The main method for marking is nmethod::mark_as_seen_on_stack() and it is called from a lot of places. May be with class redefinition there is some kind of a loop - we can't unload metadata <-> nmethod is reachable. Also I thought that we keep the original class when do redefinition (at least Serguei Spitsyn told me that, I think). Thanks, Vladimir On 8/12/14 3:12 PM, Coleen Phillimore wrote: > > I have a question about nmethod flushing wrt to RedefineClasses (no, no, > no, please keep reading!) > > When we redefine a class, there is code to deoptimize the methods, and > make them non-entrant. Non-entrant methods are still considered alive, > so for class redefinition we walk the code cache so that we don't delete > the metadata for any methods while some nmethod is still referring to > it. Eventually the sweeper will come along and mark the methods as > zombies so we don't have to deal with them anymore, but for class > redefinition, can we force methods to go to zombie's earlier? Or make > the sweeper more aggressive after a class redefinition? > > This code cache walking isn't that expensive, but we keep around a lot > of metadata as a result that could be more eagerly deleted. > > Thanks, > Coleen From albert.noll at oracle.com Wed Aug 13 05:26:30 2014 From: albert.noll at oracle.com (Albert) Date: Wed, 13 Aug 2014 07:26:30 +0200 Subject: Question about nmethod flushing In-Reply-To: <53EAAA31.3070400@oracle.com> References: <53EA9161.7020009@oracle.com> <53EAAA31.3070400@oracle.com> Message-ID: <53EAF706.8050802@oracle.com> Hi, the code cache sweeper is not very aggressive in removing nmethods from the code cache, if there is enough free space in the code cache. I.e., the sweeper runs only if we (1) compile methods and (2) there is 'enough' state change in the code cache (e.g., 1% of the methods change the state from 'alive' -> 'not-entrant'). The reason behind this is that sweeping is done by compiler threads and we do not want to spend time sweeping the code cache (if there is enough free space) if we can use the compiler threads to compile methods. We could adapt the code cache sweeper to do more aggressive sweeping, if a nmethod is made not entrant due to class redefinition. I can look into this. Is there a particular benchmark you are using? Best, Albert On 08/13/2014 01:58 AM, Vladimir Kozlov wrote: > nmethods are alive when there are corresponding stack frames on java > execution stacks. We can't make them zombie until we 100% sure they > are not used. > Is it possible that we are reaching a nmethod even if it is not > present on call stack? The main method for marking is > nmethod::mark_as_seen_on_stack() and it is called from a lot of > places. May be with class redefinition there is some kind of a loop - > we can't unload metadata <-> nmethod is reachable. > > Also I thought that we keep the original class when do redefinition > (at least Serguei Spitsyn told me that, I think). > > Thanks, > Vladimir > > On 8/12/14 3:12 PM, Coleen Phillimore wrote: >> >> I have a question about nmethod flushing wrt to RedefineClasses (no, no, >> no, please keep reading!) >> >> When we redefine a class, there is code to deoptimize the methods, and >> make them non-entrant. Non-entrant methods are still considered alive, >> so for class redefinition we walk the code cache so that we don't delete >> the metadata for any methods while some nmethod is still referring to >> it. Eventually the sweeper will come along and mark the methods as >> zombies so we don't have to deal with them anymore, but for class >> redefinition, can we force methods to go to zombie's earlier? Or make >> the sweeper more aggressive after a class redefinition? >> >> This code cache walking isn't that expensive, but we keep around a lot >> of metadata as a result that could be more eagerly deleted. >> >> Thanks, >> Coleen From igor.veresov at oracle.com Wed Aug 13 05:52:44 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 12 Aug 2014 22:52:44 -0700 Subject: [9] RFR (S) 8054927: Missing MemNode::acquire ordering in some volatile Load nodes In-Reply-To: <53EA545B.6030504@oracle.com> References: <53DECAF3.4010203@oracle.com> <53DFF783.2020703@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566ACC2DB7@DEWDFEMB19C.global.corp.sap> <53EA2886.6050400@oracle.com> <53EA545B.6030504@oracle.com> Message-ID: <8C55B7DC-FDC0-4D81-A447-2204C33620D6@oracle.com> Looks good. igor > On Aug 12, 2014, at 10:52 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8054927/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8054927 > > Fixed memory ordering parameter and added missing barriers for volatile loads. > > Thanks, > Vladimir From zoltan.majo at oracle.com Wed Aug 13 07:19:55 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 13 Aug 2014 09:19:55 +0200 Subject: [9] RFR(S): 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: <53EA11D3.3030202@oracle.com> References: <53E9BE70.50305@oracle.com> <53EA11D3.3030202@oracle.com> Message-ID: <53EB119B.6040804@oracle.com> Hi Vladimir, thank you for the review! On 08/12/2014 03:08 PM, Vladimir Kozlov wrote: > I would suggest to replace next removed check with assert to make sure > we have getisax: > > if (os::Solaris::supports_getisax()) I added the assert, here is the updated webrev: http://cr.openjdk.java.net/~thartmann/8043913/webrev.01/ I ran again the JPRT "hotspot_compiler" test on solaris_sparc_v9*. Best regards, Zoltan > > Otherwise it looks good. > > Thanks, > Vladimir > > On 8/12/14 12:12 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please remove the following patch. >> >> Problem: Since on SPARC we are now building/running on Solaris 10 and >> up, legacy code in the method >> VM_Version::platform_features can be removed. >> >> Solution: The getisax(2) call is available from Solaris 10, therefore >> legacy code to determine platform features can be >> removed. Solaris 10 defines some of the AV* constants used in the >> method. Some of these defines could have been removed >> as well, but different versions of Solaris 10 define different >> subsets of the constants, therefore it is better to leave >> the defines for now. >> >> Webrev: http://cr.openjdk.java.net/~thartmann/8043913/webrev.00/ >> >> Testing: >> >> - built JVM on solaris_sparc_5.10u5 and on solaris_sparc_5.11.1; >> - ran all JPRT tests on the solaris_sparcv9* platform; >> - ran test/sanity/ExecuteInternalVMTests.java (the test executed by >> the "hotspot_compiler" JPRT test) on >> solaris_sparc_5.11.1, solaris_sparc_5.10u5, and solaris_sparc_5.10u6 >> >> Thank you and best regards, >> >> >> Zoltan >> From zoltan.majo at oracle.com Wed Aug 13 07:34:29 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Wed, 13 Aug 2014 09:34:29 +0200 Subject: [9] RFR(S): 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: <6D206911-904A-4739-AB32-50AED342F8E6@oracle.com> References: <53E9BE70.50305@oracle.com> <1739343A-489A-4094-A70B-A35B343E90D9@oracle.com> <53EA62FE.6030804@oracle.com> <6D206911-904A-4739-AB32-50AED342F8E6@oracle.com> Message-ID: <53EB1505.60705@oracle.com> On 08/12/2014 09:31 PM, Christian Thalinger wrote: > >>> Can you file an Enhancement to keep track of this? >> >> Issue 8043913 is currently filed as an enhancement. Did you mean to >> file an enhancement for the time when we decide to drop support for >> Solaris < 11 (and add some notes there on what could still be done)? > > Yes, that. I filed enhancement JDK-8054979. Best regards, Zoltan From vladimir.kozlov at oracle.com Wed Aug 13 07:37:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Aug 2014 00:37:06 -0700 Subject: [9] RFR (S) 8054927: Missing MemNode::acquire ordering in some volatile Load nodes In-Reply-To: <8C55B7DC-FDC0-4D81-A447-2204C33620D6@oracle.com> References: <53DECAF3.4010203@oracle.com> <53DFF783.2020703@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566ACC2DB7@DEWDFEMB19C.global.corp.sap> <53EA2886.6050400@oracle.com> <53EA545B.6030504@oracle.com> <8C55B7DC-FDC0-4D81-A447-2204C33620D6@oracle.com> Message-ID: <53EB15A2.3090104@oracle.com> Thank you, Igor Vladimir On 8/12/14 10:52 PM, Igor Veresov wrote: > Looks good. > > igor > >> On Aug 12, 2014, at 10:52 AM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8054927/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8054927 >> >> Fixed memory ordering parameter and added missing barriers for volatile loads. >> >> Thanks, >> Vladimir From vladimir.kozlov at oracle.com Wed Aug 13 07:40:12 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Aug 2014 00:40:12 -0700 Subject: [9] RFR(S): 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: <53EB119B.6040804@oracle.com> References: <53E9BE70.50305@oracle.com> <53EA11D3.3030202@oracle.com> <53EB119B.6040804@oracle.com> Message-ID: <53EB165C.3080101@oracle.com> Looks good. Thanks, Vladimir On 8/13/14 12:19 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for the review! > > > On 08/12/2014 03:08 PM, Vladimir Kozlov wrote: >> I would suggest to replace next removed check with assert to make sure we have getisax: >> >> if (os::Solaris::supports_getisax()) > > I added the assert, here is the updated webrev: > > http://cr.openjdk.java.net/~thartmann/8043913/webrev.01/ > > I ran again the JPRT "hotspot_compiler" test on solaris_sparc_v9*. > > Best regards, > > > Zoltan > >> >> Otherwise it looks good. >> >> Thanks, >> Vladimir >> >> On 8/12/14 12:12 AM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please remove the following patch. >>> >>> Problem: Since on SPARC we are now building/running on Solaris 10 and up, legacy code in the method >>> VM_Version::platform_features can be removed. >>> >>> Solution: The getisax(2) call is available from Solaris 10, therefore legacy code to determine platform features can be >>> removed. Solaris 10 defines some of the AV* constants used in the method. Some of these defines could have been removed >>> as well, but different versions of Solaris 10 define different subsets of the constants, therefore it is better to leave >>> the defines for now. >>> >>> Webrev: http://cr.openjdk.java.net/~thartmann/8043913/webrev.00/ >>> >>> Testing: >>> >>> - built JVM on solaris_sparc_5.10u5 and on solaris_sparc_5.11.1; >>> - ran all JPRT tests on the solaris_sparcv9* platform; >>> - ran test/sanity/ExecuteInternalVMTests.java (the test executed by the "hotspot_compiler" JPRT test) on >>> solaris_sparc_5.11.1, solaris_sparc_5.10u5, and solaris_sparc_5.10u6 >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > From roland.westrelin at oracle.com Wed Aug 13 08:34:52 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 13 Aug 2014 10:34:52 +0200 Subject: [9] RFR(S): 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: <53EB119B.6040804@oracle.com> References: <53E9BE70.50305@oracle.com> <53EA11D3.3030202@oracle.com> <53EB119B.6040804@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/8043913/webrev.01/ That looks good to me. Roland. From roland.westrelin at oracle.com Wed Aug 13 08:38:58 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 13 Aug 2014 10:38:58 +0200 Subject: RFR(S): 8054224: Recursive method that was compiled by C1 is unable to catch StackOverflowError In-Reply-To: <414F5CB2-A1D7-4589-9275-27B4528998E3@oracle.com> References: <414F5CB2-A1D7-4589-9275-27B4528998E3@oracle.com> Message-ID: <8EF58FFE-D759-4EDB-B632-C9A04B04482D@oracle.com> Thanks for the review Vladimir & Igor. Vladimir: I tried to run the test with a client VM and it runs fine. Roland. On Aug 12, 2014, at 7:11 PM, Igor Veresov wrote: > Looks good. > > igor > > On Aug 12, 2014, at 1:40 AM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~roland/8054224/webrev.00/ >> >> When processing a StackOverflowError, a call to SharedRuntime::compute_compiled_exc_handler() triggers another StackOverflowError which replaces the current exception and causes the frame to be unwounded. The exception cache is wrongly updated to record that a StackOverflowError at this pc should be handled by unwinding the stack. When the StackOverflowError propagates to the caller (same method at same pc), the caller unwinds when it should jump to the exception handler. Fixed by setting the exception cache only when the exception wasn?t replaced using the same check opto/runtime.cpp does. >> >> Roland. > From roland.westrelin at oracle.com Wed Aug 13 08:41:29 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 13 Aug 2014 10:41:29 +0200 Subject: [9] RFR (S) 8054927: Missing MemNode::acquire ordering in some volatile Load nodes In-Reply-To: <53EA545B.6030504@oracle.com> References: <53DECAF3.4010203@oracle.com> <53DFF783.2020703@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566ACC2DB7@DEWDFEMB19C.global.corp.sap> <53EA2886.6050400@oracle.com> <53EA545B.6030504@oracle.com> Message-ID: > http://cr.openjdk.java.net/~kvn/8054927/webrev/ Looks good to me. Roland. From zoltan.majo at oracle.com Wed Aug 13 08:48:19 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Wed, 13 Aug 2014 10:48:19 +0200 Subject: [9] RFR(S): 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: References: <53E9BE70.50305@oracle.com> <53EA11D3.3030202@oracle.com> <53EB119B.6040804@oracle.com> Message-ID: <53EB2653.1030105@oracle.com> Vladimir, Roland, thank you for the review. Zoltan On 08/13/2014 10:34 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~thartmann/8043913/webrev.01/ > That looks good to me. > > Roland. From vladimir.kozlov at oracle.com Wed Aug 13 16:08:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Aug 2014 09:08:29 -0700 Subject: RFR(S): 8054224: Recursive method that was compiled by C1 is unable to catch StackOverflowError In-Reply-To: <8EF58FFE-D759-4EDB-B632-C9A04B04482D@oracle.com> References: <414F5CB2-A1D7-4589-9275-27B4528998E3@oracle.com> <8EF58FFE-D759-4EDB-B632-C9A04B04482D@oracle.com> Message-ID: <53EB8D7D.4020806@oracle.com> On 8/13/14 1:38 AM, Roland Westrelin wrote: > Thanks for the review Vladimir & Igor. > > Vladimir: I tried to run the test with a client VM and it runs fine. Thanks Vladimir > > Roland. > > > On Aug 12, 2014, at 7:11 PM, Igor Veresov wrote: > >> Looks good. >> >> igor >> >> On Aug 12, 2014, at 1:40 AM, Roland Westrelin wrote: >> >>> http://cr.openjdk.java.net/~roland/8054224/webrev.00/ >>> >>> When processing a StackOverflowError, a call to SharedRuntime::compute_compiled_exc_handler() triggers another StackOverflowError which replaces the current exception and causes the frame to be unwounded. The exception cache is wrongly updated to record that a StackOverflowError at this pc should be handled by unwinding the stack. When the StackOverflowError propagates to the caller (same method at same pc), the caller unwinds when it should jump to the exception handler. Fixed by setting the exception cache only when the exception wasn?t replaced using the same check opto/runtime.cpp does. >>> >>> Roland. >> > From vladimir.kozlov at oracle.com Wed Aug 13 16:09:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Aug 2014 09:09:01 -0700 Subject: [9] RFR (S) 8054927: Missing MemNode::acquire ordering in some volatile Load nodes In-Reply-To: References: <53DECAF3.4010203@oracle.com> <53DFF783.2020703@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566ACC2DB7@DEWDFEMB19C.global.corp.sap> <53EA2886.6050400@oracle.com> <53EA545B.6030504@oracle.com> Message-ID: <53EB8D9D.1010409@oracle.com> Thanks you, Roland Vladimir On 8/13/14 1:41 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/8054927/webrev/ > > Looks good to me. > > Roland. > From david.r.chase at oracle.com Wed Aug 13 16:13:57 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 13 Aug 2014 12:13:57 -0400 Subject: RFR/advice: 8054292 : Code comments leak in fastdebug builds Message-ID: webrev: http://cr.openjdk.java.net/~drchase/8054292/webrev-for-leak-checks.04/ bug: https://bugs.openjdk.java.net/browse/JDK-8054292 There?s a problem with CodeBuffers leaking strings, and three possible solutions, and I?m looking for advice/discussion as to which solution might be best. The root cause is that though a CodeBuffer is supposed to exist for resource management purposes, it was not properly coded that way. It?s currently coded to leak code comment strings, but the ?clean fix? (free strings in destructor) might cause dangling pointers, and it?s difficult to prove that it won?t because it?s unlikely that I have tested down all the squirrelly paths I think there are three possible fixes with different risks: 1) ?Clean fix?, reclaim resources in destructor. Risk: dangling pointer, bites us probably when someone is debugging and prints something, otherwise the code comment strings are ignored. That bug will be annoying as heck when it happens. 2) ?Dutch Boy with asserts?, zero/free strings at critical points in the lifecycle of a CodeBuffer, assert if a CodeBuffer is destroyed with unzeroed stings. Risk: we are still leaking, and a test will fail, probably when execution goes down some weird and untested path. But we?ll get an hs_err that explains the problem, so we can take steps to repair it. 3) ?Dutch boy without asserts?, same as 2), but with no asserts. Instead of failing, it will sometimes leak (but this will probably not occur that often) but it will not dangle pointers and it will not crash for leaking. The webrev illustrates the (potential) changes for all three solutions. I started by trying to identify all sources of leaks (to prove that there was a leak, in particular) by zeroing the string pointer when it was copied out, and then asserting it was zero in the destructor. A leak, or failure to identify a point where strings are copied out, is then identified by a crash. Next I tried the clean fix (a one-liner on top of the changes for the one-leak-at-a-time code), to see if it would cause any crashes. This was not entirely satisfactory since the strings are for debugging purposes and most tests don?t check them; I did a run of jtreg with PrintOptoAssembly turned on to see if this would provoke a crash, and it did not. Testing: jtreg of compiler, gc, runtime jtreg of compiler w/ PrintOptoAssembly and ?clean fix?. ute vm.quick.testlist I tried to run kitchensink, but it failed for lack of jrockit.qa.stress.kitchensink.process.stress.main . Local ute command was: bin/ute -jdk $ff -testbase local/testbase/bigapps/Kitchensink -test bigapps/Kitchensink -env EXEC_DURATION=960 and I had previously done bin/ute fetch all -site east -jdkrelease 9 Any ideas what I might be doing wrong with ute? This was a problem on both Linux (Ubuntu) and MacOS (Mavericks) I?m leaning towards ?clean fix?, partly because I never saw anything that looked like creation of a dangling pointer. -------------- 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 morris.meyer at oracle.com Wed Aug 13 16:48:08 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Wed, 13 Aug 2014 12:48:08 -0400 Subject: RFR(XS): 8054530: C2: assert(res == old_res) failed: Inconsistency between old and new Message-ID: <53EB96C8.9050703@oracle.com> Folks, Could I get a review for this issue? On Linux-SparcV9 7u72 with Gcc 4.4 compilers (circa 2010), the asserted calculation leaves the high order bit set in the variable old_res, which causes the bug. align_size_up() calls for size_t and fixing array_size(int length) to properly pass unsigned ints fixes this issue. This patch has been tested with JPRT against 7u-dev repositories. Thanks, --morris WEBREV - http://cr.openjdk.java.net/~morris/8054530.01/ JBS - http://bugs.openjdk.java.net/browse/JDK-8054530 From david.r.chase at oracle.com Wed Aug 13 17:20:20 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 13 Aug 2014 13:20:20 -0400 Subject: RFR(XS): 8054530: C2: assert(res == old_res) failed: Inconsistency between old and new In-Reply-To: <53EB96C8.9050703@oracle.com> References: <53EB96C8.9050703@oracle.com> Message-ID: <8FD55197-00C9-4701-AFEA-4EB27521A957@oracle.com> Minor nit, would you consider moving the assignment to ?res? up above the #ifdef ASSERT, and then sucking the assert(res == old_res) inside the #ifdef ASSERT/#endif ? That way the apparent reference to ?old_res? occurs within the same ifdef that defines it, even though we know that (right now, at least) assert is a macro that makes its first parameter go away if ASSERT is not defined. And could HeapWordsPerOop also be unsigned? David On 2014-08-13, at 12:48 PM, Morris Meyer wrote: > Folks, > > Could I get a review for this issue? On Linux-SparcV9 7u72 with Gcc 4.4 compilers (circa 2010), the asserted calculation leaves the high order bit set in the variable old_res, which causes the bug. align_size_up() calls for size_t and fixing array_size(int length) to properly pass unsigned ints fixes this issue. > > This patch has been tested with JPRT against 7u-dev repositories. > > Thanks, > > --morris > > > WEBREV - http://cr.openjdk.java.net/~morris/8054530.01/ > JBS - http://bugs.openjdk.java.net/browse/JDK-8054530 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Wed Aug 13 17:36:55 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Aug 2014 10:36:55 -0700 Subject: RFR(XS): 8054530: C2: assert(res == old_res) failed: Inconsistency between old and new In-Reply-To: <8FD55197-00C9-4701-AFEA-4EB27521A957@oracle.com> References: <53EB96C8.9050703@oracle.com> <8FD55197-00C9-4701-AFEA-4EB27521A957@oracle.com> Message-ID: <53EBA237.2070907@oracle.com> On 8/13/14 10:20 AM, David Chase wrote: > Minor nit, would you consider moving the assignment to ?res? up above the #ifdef ASSERT, > and then sucking the assert(res == old_res) inside the #ifdef ASSERT/#endif ? > That way the apparent reference to ?old_res? occurs within the same ifdef that defines it, > even though we know that (right now, at least) assert is a macro that makes its first > parameter go away if ASSERT is not defined. > > And could HeapWordsPerOop also be unsigned? +1 Vladimir > > David > > On 2014-08-13, at 12:48 PM, Morris Meyer wrote: > >> Folks, >> >> Could I get a review for this issue? On Linux-SparcV9 7u72 with Gcc 4.4 compilers (circa 2010), the asserted calculation leaves the high order bit set in the variable old_res, which causes the bug. align_size_up() calls for size_t and fixing array_size(int length) to properly pass unsigned ints fixes this issue. >> >> This patch has been tested with JPRT against 7u-dev repositories. >> >> Thanks, >> >> --morris >> >> >> WEBREV - http://cr.openjdk.java.net/~morris/8054530.01/ >> JBS - http://bugs.openjdk.java.net/browse/JDK-8054530 > From morris.meyer at oracle.com Wed Aug 13 18:56:20 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Wed, 13 Aug 2014 14:56:20 -0400 Subject: RFR(XS): 8054530: C2: assert(res == old_res) failed: Inconsistency between old and new In-Reply-To: <53EBA237.2070907@oracle.com> References: <53EB96C8.9050703@oracle.com> <8FD55197-00C9-4701-AFEA-4EB27521A957@oracle.com> <53EBA237.2070907@oracle.com> Message-ID: <53EBB4D4.70504@oracle.com> David and Vladimir, Thanks for the review. Here is a newer version that has those changes and has been tested with JPRT. --morris WEBREV - http://cr.openjdk.java.net/~morris/8054530.02 JBS - http://bugs.openjdk.java.net/browse/JDK-8054530 On 8/13/14, 1:36 PM, Vladimir Kozlov wrote: > On 8/13/14 10:20 AM, David Chase wrote: >> Minor nit, would you consider moving the assignment to ?res? up above >> the #ifdef ASSERT, >> and then sucking the assert(res == old_res) inside the #ifdef >> ASSERT/#endif ? >> That way the apparent reference to ?old_res? occurs within the same >> ifdef that defines it, >> even though we know that (right now, at least) assert is a macro that >> makes its first >> parameter go away if ASSERT is not defined. >> >> And could HeapWordsPerOop also be unsigned? > > +1 > > Vladimir > >> >> David >> >> On 2014-08-13, at 12:48 PM, Morris Meyer >> wrote: >> >>> Folks, >>> >>> Could I get a review for this issue? On Linux-SparcV9 7u72 with Gcc >>> 4.4 compilers (circa 2010), the asserted calculation leaves the high >>> order bit set in the variable old_res, which causes the bug. >>> align_size_up() calls for size_t and fixing array_size(int length) >>> to properly pass unsigned ints fixes this issue. >>> >>> This patch has been tested with JPRT against 7u-dev repositories. >>> >>> Thanks, >>> >>> --morris >>> >>> >>> WEBREV - http://cr.openjdk.java.net/~morris/8054530.01/ >>> JBS - http://bugs.openjdk.java.net/browse/JDK-8054530 >> From vladimir.kozlov at oracle.com Wed Aug 13 18:59:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Aug 2014 11:59:30 -0700 Subject: RFR/advice: 8054292 : Code comments leak in fastdebug builds In-Reply-To: References: Message-ID: <53EBB592.2050803@oracle.com> Hi David, Yes, the clean solution but more memory usage would be to duplicate strings (and corresponding structures) when we copy them instead of copying only a pointer. Then we will not get dangling pointers when we always free them in destructors. I agree that current changes are fragile and reactive to results of testing. It could be long tail of additional fixes after this as we find other cases. Can you estimate how much memory we use for strings per compilation? If it is not much we can go with "clean solution" to copy stings and free in destructors. You added _code.free_strings() in C1 but you missed the same case in C2 when compilation is bailed out and strings are not copied to nmethod. CodeBuffer::free_strings() should set _Strings to NULL after freeing them. Indention is wrong in new code - should be 2 spaces. And no spaces around arrow: "cb -> ". In scratch_emit_size() you should free strings instead of setting NULL since they are not copied at that place. Thanks, Vladimir On 8/13/14 9:13 AM, David Chase wrote: > webrev: http://cr.openjdk.java.net/~drchase/8054292/webrev-for-leak-checks.04/ > bug: https://bugs.openjdk.java.net/browse/JDK-8054292 > > There?s a problem with CodeBuffers leaking strings, and three possible solutions, > and I?m looking for advice/discussion as to which solution might be best. > > The root cause is that though a CodeBuffer is supposed to exist for resource > management purposes, it was not properly coded that way. It?s currently coded > to leak code comment strings, but the ?clean fix? (free strings in destructor) might > cause dangling pointers, and it?s difficult to prove that it won?t because it?s unlikely > that I have tested down all the squirrelly paths > > I think there are three possible fixes with different risks: > > 1) ?Clean fix?, reclaim resources in destructor. Risk: dangling pointer, bites us probably when > someone is debugging and prints something, otherwise the code comment strings are ignored. > That bug will be annoying as heck when it happens. > > 2) ?Dutch Boy with asserts?, zero/free strings at critical points in the lifecycle of a CodeBuffer, > assert if a CodeBuffer is destroyed with unzeroed stings. Risk: we are still leaking, and a test will > fail, probably when execution goes down some weird and untested path. But we?ll get an hs_err > that explains the problem, so we can take steps to repair it. > > 3) ?Dutch boy without asserts?, same as 2), but with no asserts. Instead of failing, it will > sometimes leak (but this will probably not occur that often) but it will not dangle pointers > and it will not crash for leaking. > > The webrev illustrates the (potential) changes for all three solutions. > > I started by trying to identify all sources of leaks (to prove that there was a leak, in particular) > by zeroing the string pointer when it was copied out, and then asserting it was zero in the > destructor. A leak, or failure to identify a point where strings are copied out, is then identified > by a crash. > > Next I tried the clean fix (a one-liner on top of the changes for the one-leak-at-a-time code), > to see if it would cause any crashes. This was not entirely satisfactory since the strings are > for debugging purposes and most tests don?t check them; I did a run of jtreg with > PrintOptoAssembly turned on to see if this would provoke a crash, and it did not. > > Testing: > > jtreg of compiler, gc, runtime > jtreg of compiler w/ PrintOptoAssembly and ?clean fix?. > ute vm.quick.testlist > > I tried to run kitchensink, but it failed for lack of jrockit.qa.stress.kitchensink.process.stress.main . > Local ute command was: > > bin/ute -jdk $ff -testbase local/testbase/bigapps/Kitchensink -test bigapps/Kitchensink -env EXEC_DURATION=960 > > and I had previously done > > bin/ute fetch all -site east -jdkrelease 9 > > Any ideas what I might be doing wrong with ute? > This was a problem on both Linux (Ubuntu) and MacOS (Mavericks) > > I?m leaning towards ?clean fix?, partly because I never saw anything that looked like creation of a dangling pointer. > From david.r.chase at oracle.com Wed Aug 13 19:17:59 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 13 Aug 2014 15:17:59 -0400 Subject: RFR(XS): 8054530: C2: assert(res == old_res) failed: Inconsistency between old and new In-Reply-To: <53EBB4D4.70504@oracle.com> References: <53EB96C8.9050703@oracle.com> <8FD55197-00C9-4701-AFEA-4EB27521A957@oracle.com> <53EBA237.2070907@oracle.com> <53EBB4D4.70504@oracle.com> Message-ID: On 2014-08-13, at 2:56 PM, Morris Meyer wrote: > David and Vladimir, > > Thanks for the review. Here is a newer version that has those changes and has been tested with JPRT. > > --morris > > WEBREV - http://cr.openjdk.java.net/~morris/8054530.02 > JBS - http://bugs.openjdk.java.net/browse/JDK-8054530 Looks good to me. (beware, I am not a Reviewer) David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Wed Aug 13 19:48:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Aug 2014 12:48:16 -0700 Subject: RFR(XS): 8054530: C2: assert(res == old_res) failed: Inconsistency between old and new In-Reply-To: <53EBB4D4.70504@oracle.com> References: <53EB96C8.9050703@oracle.com> <8FD55197-00C9-4701-AFEA-4EB27521A957@oracle.com> <53EBA237.2070907@oracle.com> <53EBB4D4.70504@oracle.com> Message-ID: <53EBC100.6090608@oracle.com> Good. Thanks, Vladimir On 8/13/14 11:56 AM, Morris Meyer wrote: > David and Vladimir, > > Thanks for the review. Here is a newer version that has those changes > and has been tested with JPRT. > > --morris > > WEBREV - http://cr.openjdk.java.net/~morris/8054530.02 > JBS - http://bugs.openjdk.java.net/browse/JDK-8054530 > > On 8/13/14, 1:36 PM, Vladimir Kozlov wrote: >> On 8/13/14 10:20 AM, David Chase wrote: >>> Minor nit, would you consider moving the assignment to ?res? up above >>> the #ifdef ASSERT, >>> and then sucking the assert(res == old_res) inside the #ifdef >>> ASSERT/#endif ? >>> That way the apparent reference to ?old_res? occurs within the same >>> ifdef that defines it, >>> even though we know that (right now, at least) assert is a macro that >>> makes its first >>> parameter go away if ASSERT is not defined. >>> >>> And could HeapWordsPerOop also be unsigned? >> >> +1 >> >> Vladimir >> >>> >>> David >>> >>> On 2014-08-13, at 12:48 PM, Morris Meyer >>> wrote: >>> >>>> Folks, >>>> >>>> Could I get a review for this issue? On Linux-SparcV9 7u72 with Gcc >>>> 4.4 compilers (circa 2010), the asserted calculation leaves the high >>>> order bit set in the variable old_res, which causes the bug. >>>> align_size_up() calls for size_t and fixing array_size(int length) >>>> to properly pass unsigned ints fixes this issue. >>>> >>>> This patch has been tested with JPRT against 7u-dev repositories. >>>> >>>> Thanks, >>>> >>>> --morris >>>> >>>> >>>> WEBREV - http://cr.openjdk.java.net/~morris/8054530.01/ >>>> JBS - http://bugs.openjdk.java.net/browse/JDK-8054530 >>> > From coleen.phillimore at oracle.com Wed Aug 13 21:26:09 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 13 Aug 2014 17:26:09 -0400 Subject: Question about nmethod flushing In-Reply-To: <53EAAA31.3070400@oracle.com> References: <53EA9161.7020009@oracle.com> <53EAAA31.3070400@oracle.com> Message-ID: <53EBD7F1.4070608@oracle.com> Hi Vladimir, Thanks for answering my question. In my case, the sweeper's stack traversal doesn't seem to be frequent enough, but if I run a fastdebug jvm rather than a debug jvm and helping it along with -XX:NMethodSweepFraction=1, I can get my redefined methods finally swept so I can deallocate their metadata. For class redefinition, it seems that I want to make sweeping more frequent, but I'm not sure how to do this. Also, I am testing this with a small test case so maybe practically, this isn't really an issue. On 8/12/14, 7:58 PM, Vladimir Kozlov wrote: > nmethods are alive when there are corresponding stack frames on java > execution stacks. We can't make them zombie until we 100% sure they > are not used. > Is it possible that we are reaching a nmethod even if it is not > present on call stack? The main method for marking is > nmethod::mark_as_seen_on_stack() and it is called from a lot of > places. May be with class redefinition there is some kind of a loop - > we can't unload metadata <-> nmethod is reachable. > > Also I thought that we keep the original class when do redefinition > (at least Serguei Spitsyn told me that, I think). Yes, we keep the original class and swap the new methods and their constant pool to the original class. The scratch_class gets the old methods and old constant pool attached to it and they're deleted together (implicitly). The irony is that redefine classes also does a stack traversal so we know which methods are on the stack but I've spent most of the day trying to figure out how to pre-zombie these nmethods but I haven't thought of anything that would work better for this test case I wrote. The sweeper runs during safepoints, doesn't it? Thanks! Coleen > > Thanks, > Vladimir > > On 8/12/14 3:12 PM, Coleen Phillimore wrote: >> >> I have a question about nmethod flushing wrt to RedefineClasses (no, no, >> no, please keep reading!) >> >> When we redefine a class, there is code to deoptimize the methods, and >> make them non-entrant. Non-entrant methods are still considered alive, >> so for class redefinition we walk the code cache so that we don't delete >> the metadata for any methods while some nmethod is still referring to >> it. Eventually the sweeper will come along and mark the methods as >> zombies so we don't have to deal with them anymore, but for class >> redefinition, can we force methods to go to zombie's earlier? Or make >> the sweeper more aggressive after a class redefinition? >> >> This code cache walking isn't that expensive, but we keep around a lot >> of metadata as a result that could be more eagerly deleted. >> >> Thanks, >> Coleen From igor.veresov at oracle.com Wed Aug 13 23:23:02 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 13 Aug 2014 16:23:02 -0700 Subject: [9] RFR(XS): 8054883 Segmentation error while running program Message-ID: <81D063C7-C1BA-43B7-95A8-D8BBD9E85A44@oracle.com> The problem is with finding and widening dominating range checks. The widening machinery expects to see certain forms of range checks - in one of the cases (index + offset < array_length) it checks that the operator in the pattern is an add by calling is_Add(). However it just means that the node is a subclass of AddNode and that it shares the same algebraic properties. In that particular case it would confuse an XorI with AddI. What this code needs, is to check the opcode of the node. Webrev: http://cr.openjdk.java.net/~iveresov/8054883/webrev.00/ Thanks! igor From vladimir.kozlov at oracle.com Thu Aug 14 00:04:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Aug 2014 17:04:33 -0700 Subject: [9] RFR(XS): 8054883 Segmentation error while running program In-Reply-To: <81D063C7-C1BA-43B7-95A8-D8BBD9E85A44@oracle.com> References: <81D063C7-C1BA-43B7-95A8-D8BBD9E85A44@oracle.com> Message-ID: <53EBFD11.305@oracle.com> Good. Thanks, Vladimir On 8/13/14 4:23 PM, Igor Veresov wrote: > The problem is with finding and widening dominating range checks. The widening machinery expects to see certain forms of range checks - in one of the cases (index + offset < array_length) it checks that the operator in the pattern is an add by calling is_Add(). However it just means that the node is a subclass of AddNode and that it shares the same algebraic properties. In that particular case it would confuse an XorI with AddI. What this code needs, is to check the opcode of the node. > > Webrev: http://cr.openjdk.java.net/~iveresov/8054883/webrev.00/ > > Thanks! > igor > From igor.veresov at oracle.com Thu Aug 14 00:27:07 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 13 Aug 2014 17:27:07 -0700 Subject: [9] RFR(XS): 8054883 Segmentation error while running program In-Reply-To: <53EBFD11.305@oracle.com> References: <81D063C7-C1BA-43B7-95A8-D8BBD9E85A44@oracle.com> <53EBFD11.305@oracle.com> Message-ID: Thanks, Vladimir! igor On Aug 13, 2014, at 5:04 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 8/13/14 4:23 PM, Igor Veresov wrote: >> The problem is with finding and widening dominating range checks. The widening machinery expects to see certain forms of range checks - in one of the cases (index + offset < array_length) it checks that the operator in the pattern is an add by calling is_Add(). However it just means that the node is a subclass of AddNode and that it shares the same algebraic properties. In that particular case it would confuse an XorI with AddI. What this code needs, is to check the opcode of the node. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8054883/webrev.00/ >> >> Thanks! >> igor >> From albert.noll at oracle.com Thu Aug 14 02:25:56 2014 From: albert.noll at oracle.com (albert noll) Date: Thu, 14 Aug 2014 04:25:56 +0200 Subject: Question about nmethod flushing In-Reply-To: <53EBD7F1.4070608@oracle.com> References: <53EA9161.7020009@oracle.com> <53EAAA31.3070400@oracle.com> <53EBD7F1.4070608@oracle.com> Message-ID: <53EC1E34.9030203@oracle.com> On 13.08.2014 23:26, Coleen Phillimore wrote: > > Hi Vladimir, > > Thanks for answering my question. In my case, the sweeper's stack > traversal doesn't seem to be frequent enough, but if I run a fastdebug > jvm rather than a debug jvm and helping it along with > -XX:NMethodSweepFraction=1, I can get my redefined methods finally > swept so I can deallocate their metadata. > > For class redefinition, it seems that I want to make sweeping more > frequent, but I'm not sure how to do this. Also, I am testing this > with a small test case so maybe practically, this isn't really an issue. > > On 8/12/14, 7:58 PM, Vladimir Kozlov wrote: >> nmethods are alive when there are corresponding stack frames on java >> execution stacks. We can't make them zombie until we 100% sure they >> are not used. >> Is it possible that we are reaching a nmethod even if it is not >> present on call stack? The main method for marking is >> nmethod::mark_as_seen_on_stack() and it is called from a lot of >> places. May be with class redefinition there is some kind of a loop - >> we can't unload metadata <-> nmethod is reachable. >> >> Also I thought that we keep the original class when do redefinition >> (at least Serguei Spitsyn told me that, I think). > > Yes, we keep the original class and swap the new methods and their > constant pool to the original class. The scratch_class gets the old > methods and old constant pool attached to it and they're deleted > together (implicitly). > > The irony is that redefine classes also does a stack traversal so we > know which methods are on the stack but I've spent most of the day > trying to figure out how to pre-zombie these nmethods but I haven't > thought of anything that would work better for this test case I wrote. > > The sweeper runs during safepoints, doesn't it? Only marking nmethods as 'seen_on_stack' is done at safepoints. Best, Albert > > Thanks! > Coleen > >> >> Thanks, >> Vladimir >> >> On 8/12/14 3:12 PM, Coleen Phillimore wrote: >>> >>> I have a question about nmethod flushing wrt to RedefineClasses (no, >>> no, >>> no, please keep reading!) >>> >>> When we redefine a class, there is code to deoptimize the methods, and >>> make them non-entrant. Non-entrant methods are still considered >>> alive, >>> so for class redefinition we walk the code cache so that we don't >>> delete >>> the metadata for any methods while some nmethod is still referring to >>> it. Eventually the sweeper will come along and mark the methods as >>> zombies so we don't have to deal with them anymore, but for class >>> redefinition, can we force methods to go to zombie's earlier? Or make >>> the sweeper more aggressive after a class redefinition? >>> >>> This code cache walking isn't that expensive, but we keep around a lot >>> of metadata as a result that could be more eagerly deleted. >>> >>> Thanks, >>> Coleen > From roland.westrelin at oracle.com Thu Aug 14 12:07:40 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 14 Aug 2014 14:07:40 +0200 Subject: [9] RFR(XS): 8054883 Segmentation error while running program In-Reply-To: <81D063C7-C1BA-43B7-95A8-D8BBD9E85A44@oracle.com> References: <81D063C7-C1BA-43B7-95A8-D8BBD9E85A44@oracle.com> Message-ID: <87egwje0kz.fsf@oracle.com> > Webrev: http://cr.openjdk.java.net/~iveresov/8054883/webrev.00/ That looks good. Roland. From coleen.phillimore at oracle.com Thu Aug 14 14:52:02 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 14 Aug 2014 10:52:02 -0400 Subject: Question about nmethod flushing In-Reply-To: <53EAAA31.3070400@oracle.com> References: <53EA9161.7020009@oracle.com> <53EAAA31.3070400@oracle.com> Message-ID: <53ECCD12.5060004@oracle.com> Hi, So I'm still worried about this. In Universe::flush_evol_dependents_on() I think it's probably fine to make the redefined (old) methods into zombies and not just not-entrant. But this doesn't make them swept any sooner. With NmethodSweepFraction=1, they are finally swept after 71 GCs and without this option they are never swept. Is there any way to programmatically tell the sweeper to run to completion just after a class redefinition? Sort of like telling GC to run a full GC? Thanks, Coleen On 8/12/14, 7:58 PM, Vladimir Kozlov wrote: > nmethods are alive when there are corresponding stack frames on java > execution stacks. We can't make them zombie until we 100% sure they > are not used. > Is it possible that we are reaching a nmethod even if it is not > present on call stack? The main method for marking is > nmethod::mark_as_seen_on_stack() and it is called from a lot of > places. May be with class redefinition there is some kind of a loop - > we can't unload metadata <-> nmethod is reachable. > > Also I thought that we keep the original class when do redefinition > (at least Serguei Spitsyn told me that, I think). > > Thanks, > Vladimir > > On 8/12/14 3:12 PM, Coleen Phillimore wrote: >> >> I have a question about nmethod flushing wrt to RedefineClasses (no, no, >> no, please keep reading!) >> >> When we redefine a class, there is code to deoptimize the methods, and >> make them non-entrant. Non-entrant methods are still considered alive, >> so for class redefinition we walk the code cache so that we don't delete >> the metadata for any methods while some nmethod is still referring to >> it. Eventually the sweeper will come along and mark the methods as >> zombies so we don't have to deal with them anymore, but for class >> redefinition, can we force methods to go to zombie's earlier? Or make >> the sweeper more aggressive after a class redefinition? >> >> This code cache walking isn't that expensive, but we keep around a lot >> of metadata as a result that could be more eagerly deleted. >> >> Thanks, >> Coleen From david.r.chase at oracle.com Thu Aug 14 17:51:27 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 14 Aug 2014 13:51:27 -0400 Subject: RFR/advice: 8054292 : Code comments leak in fastdebug builds In-Reply-To: <53EBB592.2050803@oracle.com> References: <53EBB592.2050803@oracle.com> Message-ID: <58D1E7F8-880C-4260-BF88-FEC652D4CFE0@oracle.com> Correction ? we do NOT copy strings out, we instead copy the pointer, hence the need to zero the strings in the CodeBuffer after a copy-out if we reclaim non-zeroes strings in the destructor. > You added _code.free_strings() in C1 but you missed the same case in C2 when compilation is bailed out and strings are not copied to nmethod. > In scratch_emit_size() you should free strings instead of setting NULL since they are not copied at that place. I think I will modify the code to do the reclamation in the destructor, because otherwise I?ll lose track of all the places where the strings go uncopied (and if I don?t, the next guy will). There?s many more failure paths than success paths, so it is easier to track success and zero the pointer after copying, and I can be pretty sure that I have executed the success paths (but not the failure paths). Or are you saying that safest is simply to deep-copy always and always free strings in the destructor and never set them NULL? > CodeBuffer::free_strings() should set _Strings to NULL after freeing them. A side-effect of free_strings is that _Strings.isNull becomes true. I?ll comment this. > Indention is wrong in new code - should be 2 spaces. Will fix. > And no spaces around arrow: "cb -> ?. Fixed. I?ll come around with another webrev after another round of testing. -------------- 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 Thu Aug 14 18:18:46 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Aug 2014 11:18:46 -0700 Subject: RFR/advice: 8054292 : Code comments leak in fastdebug builds In-Reply-To: <58D1E7F8-880C-4260-BF88-FEC652D4CFE0@oracle.com> References: <53EBB592.2050803@oracle.com> <58D1E7F8-880C-4260-BF88-FEC652D4CFE0@oracle.com> Message-ID: <53ECFD86.2040609@oracle.com> On 8/14/14 10:51 AM, David Chase wrote: > Correction ? we do NOT copy strings out, we instead copy the pointer, > hence the need to zero the strings in the CodeBuffer after a copy-out > if we reclaim non-zeroes strings in the destructor. > >> You added _code.free_strings() in C1 but you missed the same case in C2 when compilation is bailed out and strings are not copied to nmethod. > >> In scratch_emit_size() you should free strings instead of setting NULL since they are not copied at that place. > > I think I will modify the code to do the reclamation in the destructor, because otherwise > I?ll lose track of all the places where the strings go uncopied (and if I don?t, the next guy > will). There?s many more failure paths than success paths, so it is easier to track success > and zero the pointer after copying, and I can be pretty sure that I have executed the > success paths (but not the failure paths). Yes, if you always zero after a copy (it is only one place free_strings(), right?). And do not zero in other places (to not create dangling pointers) this should work. > > Or are you saying that safest is simply to deep-copy always and always free strings > in the destructor and never set them NULL? I meant it would be simplest and clean solution from language point of view but you will pay performance and memory for that. So I prefer your suggestion above. > >> CodeBuffer::free_strings() should set _Strings to NULL after freeing them. > > A side-effect of free_strings is that _Strings.isNull becomes true. > I?ll comment this. > >> Indention is wrong in new code - should be 2 spaces. > > Will fix. > >> And no spaces around arrow: "cb -> ?. > > Fixed. > > I?ll come around with another webrev after another round of testing. > Thanks, Vladimir From tobias.hartmann at oracle.com Mon Aug 18 06:07:20 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 18 Aug 2014 08:07:20 +0200 Subject: [9] RFR(S): 8048879: "unexpected yanked node" opto/postaloc.cpp:139 Message-ID: <53F19818.3030205@oracle.com> Hi, please review the following patch that fixes JDK-8048879. Bug: https://bugs.openjdk.java.net/browse/JDK-8048879 Webrev: http://cr.openjdk.java.net/~thartmann/8048879/webrev.00/ == Problem == The problem is caused by the following steps: 1) A volatile field access adds a LoadNNode (35) to the graph that is connected to a MemBarAcquireNode (37) to prevent following loads from floating up past. The result of the load is used by a StoreNNode (44) (see [1]). 2) During optimization the StoreNNode (44) is removed because a following StoreNNode (55) writes to the same memory location. The LoadNNode (35) is now useless but still connected to the MemBarAcquireNode (see [2]). 3) During matching a loadConP_load (9) is added together with a MachConstantBaseNode (10) to compute the address for the LoadNNode (see [3]). 4) During register allocation the assert in 'PhaseChaitin::yank_if_dead_recurse' is hit because a dead MachConstantBaseNode is not expected at this point. The unused LoadNNode (35) should have been removed during IGVN. However, the corresponding optimization in 'MemBarNode::Ideal()' (see line 2954 of memnode.cpp) does not apply because at this point the LoadNNode (35) is still connected to the StoreNNode (44). After removing the StoreNNode (44) the MemBarAcquireNode (37) should be added to the IGVN worklist to be processed again. == Solution == The implementation of 'StoreNode::Ideal' is changed to add the users of the LoadNode to the IGVN worklist if the StoreNode is removed. This allows MemBarNode::Ideal to remove the LoadNode from its precedent input if it is dead (see [4]). I added a jtreg test 'TestMemBarAcquire.java' that triggers the optimization. However, the test does not trigger the original bug because if 'PhaseChaitin::yank_if_dead_recurse' is executed on the MachConstantBaseNode highly depends on the execution of the register allocator. The graphs [1-3] correspond to an execution of the test without the fix. Graph [4] == Testing == - Failing test (Weblogic + medrec) - JPRT Thanks, Tobias [1] https://bugs.openjdk.java.net/secure/attachment/21801/graph_after_parsing.png [2] https://bugs.openjdk.java.net/secure/attachment/21799/graph_after_IGVN.png [3] https://bugs.openjdk.java.net/secure/attachment/21802/graph_before_reg_alloc.png [4] https://bugs.openjdk.java.net/secure/attachment/21800/graph_after_IGVN_fixed.png -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Aug 18 07:44:54 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Aug 2014 00:44:54 -0700 Subject: [9] RFR(S): 8048879: "unexpected yanked node" opto/postaloc.cpp:139 In-Reply-To: <53F19818.3030205@oracle.com> References: <53F19818.3030205@oracle.com> Message-ID: <53F1AEF6.8000201@oracle.com> set_req_X() places dead store on _worklist. Look on remove_globally_dead_node() at lines 1246-1248. You can add new check into has_special_unique_user() to place membar on worklist. You don't need next test's flags: -Xbootclasspath/a:. -server -server should not be specified in jtreg tests. Thanks, Vladimir On 8/17/14 11:07 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch that fixes JDK-8048879. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048879 > Webrev: http://cr.openjdk.java.net/~thartmann/8048879/webrev.00/ > > == Problem == > The problem is caused by the following steps: > 1) A volatile field access adds a LoadNNode (35) to the graph that is connected to a MemBarAcquireNode (37) to prevent > following loads from floating up past. The result of the load is used by a StoreNNode (44) (see [1]). > 2) During optimization the StoreNNode (44) is removed because a following StoreNNode (55) writes to the same memory > location. The LoadNNode (35) is now useless but still connected to the MemBarAcquireNode (see [2]). > 3) During matching a loadConP_load (9) is added together with a MachConstantBaseNode (10) to compute the address for the > LoadNNode (see [3]). > 4) During register allocation the assert in 'PhaseChaitin::yank_if_dead_recurse' is hit because a dead > MachConstantBaseNode is not expected at this point. > > The unused LoadNNode (35) should have been removed during IGVN. However, the corresponding optimization in > 'MemBarNode::Ideal()' (see line 2954 of memnode.cpp) does not apply because at this point the LoadNNode (35) is still > connected to the StoreNNode (44). After removing the StoreNNode (44) the MemBarAcquireNode (37) should be added to the > IGVN worklist to be processed again. > > == Solution == > The implementation of 'StoreNode::Ideal' is changed to add the users of the LoadNode to the IGVN worklist if the > StoreNode is removed. This allows MemBarNode::Ideal to remove the LoadNode from its precedent input if it is dead (see [4]). > > I added a jtreg test 'TestMemBarAcquire.java' that triggers the optimization. However, the test does not trigger the > original bug because if 'PhaseChaitin::yank_if_dead_recurse' is executed on the MachConstantBaseNode highly depends on > the execution of the register allocator. The graphs [1-3] correspond to an execution of the test without the fix. Graph [4] > > == Testing == > - Failing test (Weblogic + medrec) > - JPRT > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/secure/attachment/21801/graph_after_parsing.png > [2] https://bugs.openjdk.java.net/secure/attachment/21799/graph_after_IGVN.png > [3] https://bugs.openjdk.java.net/secure/attachment/21802/graph_before_reg_alloc.png > [4] https://bugs.openjdk.java.net/secure/attachment/21800/graph_after_IGVN_fixed.png From tobias.hartmann at oracle.com Mon Aug 18 10:31:23 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 18 Aug 2014 12:31:23 +0200 Subject: [9] RFR(S): 8048879: "unexpected yanked node" opto/postaloc.cpp:139 In-Reply-To: <53F1AEF6.8000201@oracle.com> References: <53F19818.3030205@oracle.com> <53F1AEF6.8000201@oracle.com> Message-ID: <53F1D5FB.5020207@oracle.com> Hi Vladimir, thanks for the review. > set_req_X() places dead store on _worklist. Look on > remove_globally_dead_node() at lines 1246-1248. You can add new check > into has_special_unique_user() to place membar on worklist. Right, that's a better solution. I added a new check for a LoadNode uniquely used by a MemBarAcquireNode. > You don't need next test's flags: > -Xbootclasspath/a:. -server > > -server should not be specified in jtreg tests. I removed the flags. Tested with the failing test and JPRT. New webrev: http://cr.openjdk.java.net/~thartmann/8048879/webrev.01/ Thanks, Tobias > > Thanks, > Vladimir > > On 8/17/14 11:07 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch that fixes JDK-8048879. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048879 >> Webrev: http://cr.openjdk.java.net/~thartmann/8048879/webrev.00/ >> >> == Problem == >> The problem is caused by the following steps: >> 1) A volatile field access adds a LoadNNode (35) to the graph that is >> connected to a MemBarAcquireNode (37) to prevent >> following loads from floating up past. The result of the load is used >> by a StoreNNode (44) (see [1]). >> 2) During optimization the StoreNNode (44) is removed because a >> following StoreNNode (55) writes to the same memory >> location. The LoadNNode (35) is now useless but still connected to >> the MemBarAcquireNode (see [2]). >> 3) During matching a loadConP_load (9) is added together with a >> MachConstantBaseNode (10) to compute the address for the >> LoadNNode (see [3]). >> 4) During register allocation the assert in >> 'PhaseChaitin::yank_if_dead_recurse' is hit because a dead >> MachConstantBaseNode is not expected at this point. >> >> The unused LoadNNode (35) should have been removed during IGVN. >> However, the corresponding optimization in >> 'MemBarNode::Ideal()' (see line 2954 of memnode.cpp) does not apply >> because at this point the LoadNNode (35) is still >> connected to the StoreNNode (44). After removing the StoreNNode (44) >> the MemBarAcquireNode (37) should be added to the >> IGVN worklist to be processed again. >> >> == Solution == >> The implementation of 'StoreNode::Ideal' is changed to add the users >> of the LoadNode to the IGVN worklist if the >> StoreNode is removed. This allows MemBarNode::Ideal to remove the >> LoadNode from its precedent input if it is dead (see [4]). >> >> I added a jtreg test 'TestMemBarAcquire.java' that triggers the >> optimization. However, the test does not trigger the >> original bug because if 'PhaseChaitin::yank_if_dead_recurse' is >> executed on the MachConstantBaseNode highly depends on >> the execution of the register allocator. The graphs [1-3] correspond >> to an execution of the test without the fix. Graph [4] >> >> == Testing == >> - Failing test (Weblogic + medrec) >> - JPRT >> >> Thanks, >> Tobias >> >> [1] >> https://bugs.openjdk.java.net/secure/attachment/21801/graph_after_parsing.png >> [2] >> https://bugs.openjdk.java.net/secure/attachment/21799/graph_after_IGVN.png >> [3] >> https://bugs.openjdk.java.net/secure/attachment/21802/graph_before_reg_alloc.png >> [4] >> https://bugs.openjdk.java.net/secure/attachment/21800/graph_after_IGVN_fixed.png From vitalyd at gmail.com Mon Aug 18 15:20:46 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 18 Aug 2014 11:20:46 -0400 Subject: popcnt false data dependency on recent intel Message-ID: Hi guys, Came across this SO thread recently: http://stackoverflow.com/questions/25078285/replacing-a-32-bit-loop-count-variable-with-64-bit-introduces-crazy-performance I know hotspot has intrinsic that emits popcnt so thought I'd share in case similar adjustment needs to be made to hotspot compilers. Thanks Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Aug 18 17:53:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Aug 2014 10:53:31 -0700 Subject: [9] RFR(S): 8048879: "unexpected yanked node" opto/postaloc.cpp:139 In-Reply-To: <53F1D5FB.5020207@oracle.com> References: <53F19818.3030205@oracle.com> <53F1AEF6.8000201@oracle.com> <53F1D5FB.5020207@oracle.com> Message-ID: <53F23D9B.8010303@oracle.com> Perfect. Thanks, Vladimir On 8/18/14 3:31 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > >> set_req_X() places dead store on _worklist. Look on remove_globally_dead_node() at lines 1246-1248. You can add new >> check into has_special_unique_user() to place membar on worklist. > > Right, that's a better solution. I added a new check for a LoadNode uniquely used by a MemBarAcquireNode. > >> You don't need next test's flags: >> -Xbootclasspath/a:. -server >> >> -server should not be specified in jtreg tests. > > I removed the flags. > > Tested with the failing test and JPRT. > > New webrev: http://cr.openjdk.java.net/~thartmann/8048879/webrev.01/ > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >> On 8/17/14 11:07 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch that fixes JDK-8048879. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048879 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8048879/webrev.00/ >>> >>> == Problem == >>> The problem is caused by the following steps: >>> 1) A volatile field access adds a LoadNNode (35) to the graph that is connected to a MemBarAcquireNode (37) to prevent >>> following loads from floating up past. The result of the load is used by a StoreNNode (44) (see [1]). >>> 2) During optimization the StoreNNode (44) is removed because a following StoreNNode (55) writes to the same memory >>> location. The LoadNNode (35) is now useless but still connected to the MemBarAcquireNode (see [2]). >>> 3) During matching a loadConP_load (9) is added together with a MachConstantBaseNode (10) to compute the address for the >>> LoadNNode (see [3]). >>> 4) During register allocation the assert in 'PhaseChaitin::yank_if_dead_recurse' is hit because a dead >>> MachConstantBaseNode is not expected at this point. >>> >>> The unused LoadNNode (35) should have been removed during IGVN. However, the corresponding optimization in >>> 'MemBarNode::Ideal()' (see line 2954 of memnode.cpp) does not apply because at this point the LoadNNode (35) is still >>> connected to the StoreNNode (44). After removing the StoreNNode (44) the MemBarAcquireNode (37) should be added to the >>> IGVN worklist to be processed again. >>> >>> == Solution == >>> The implementation of 'StoreNode::Ideal' is changed to add the users of the LoadNode to the IGVN worklist if the >>> StoreNode is removed. This allows MemBarNode::Ideal to remove the LoadNode from its precedent input if it is dead >>> (see [4]). >>> >>> I added a jtreg test 'TestMemBarAcquire.java' that triggers the optimization. However, the test does not trigger the >>> original bug because if 'PhaseChaitin::yank_if_dead_recurse' is executed on the MachConstantBaseNode highly depends on >>> the execution of the register allocator. The graphs [1-3] correspond to an execution of the test without the fix. >>> Graph [4] >>> >>> == Testing == >>> - Failing test (Weblogic + medrec) >>> - JPRT >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/secure/attachment/21801/graph_after_parsing.png >>> [2] https://bugs.openjdk.java.net/secure/attachment/21799/graph_after_IGVN.png >>> [3] https://bugs.openjdk.java.net/secure/attachment/21802/graph_before_reg_alloc.png >>> [4] https://bugs.openjdk.java.net/secure/attachment/21800/graph_after_IGVN_fixed.png > From igor.veresov at oracle.com Tue Aug 19 01:56:43 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 18 Aug 2014 18:56:43 -0700 Subject: [9] RFR(S): 8048879: "unexpected yanked node" opto/postaloc.cpp:139 In-Reply-To: <53F1D5FB.5020207@oracle.com> References: <53F19818.3030205@oracle.com> <53F1AEF6.8000201@oracle.com> <53F1D5FB.5020207@oracle.com> Message-ID: Looks good. igor On Aug 18, 2014, at 3:31 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > >> set_req_X() places dead store on _worklist. Look on remove_globally_dead_node() at lines 1246-1248. You can add new check into has_special_unique_user() to place membar on worklist. > > Right, that's a better solution. I added a new check for a LoadNode uniquely used by a MemBarAcquireNode. > >> You don't need next test's flags: >> -Xbootclasspath/a:. -server >> >> -server should not be specified in jtreg tests. > > I removed the flags. > > Tested with the failing test and JPRT. > > New webrev: http://cr.openjdk.java.net/~thartmann/8048879/webrev.01/ > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >> On 8/17/14 11:07 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch that fixes JDK-8048879. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048879 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8048879/webrev.00/ >>> >>> == Problem == >>> The problem is caused by the following steps: >>> 1) A volatile field access adds a LoadNNode (35) to the graph that is connected to a MemBarAcquireNode (37) to prevent >>> following loads from floating up past. The result of the load is used by a StoreNNode (44) (see [1]). >>> 2) During optimization the StoreNNode (44) is removed because a following StoreNNode (55) writes to the same memory >>> location. The LoadNNode (35) is now useless but still connected to the MemBarAcquireNode (see [2]). >>> 3) During matching a loadConP_load (9) is added together with a MachConstantBaseNode (10) to compute the address for the >>> LoadNNode (see [3]). >>> 4) During register allocation the assert in 'PhaseChaitin::yank_if_dead_recurse' is hit because a dead >>> MachConstantBaseNode is not expected at this point. >>> >>> The unused LoadNNode (35) should have been removed during IGVN. However, the corresponding optimization in >>> 'MemBarNode::Ideal()' (see line 2954 of memnode.cpp) does not apply because at this point the LoadNNode (35) is still >>> connected to the StoreNNode (44). After removing the StoreNNode (44) the MemBarAcquireNode (37) should be added to the >>> IGVN worklist to be processed again. >>> >>> == Solution == >>> The implementation of 'StoreNode::Ideal' is changed to add the users of the LoadNode to the IGVN worklist if the >>> StoreNode is removed. This allows MemBarNode::Ideal to remove the LoadNode from its precedent input if it is dead (see [4]). >>> >>> I added a jtreg test 'TestMemBarAcquire.java' that triggers the optimization. However, the test does not trigger the >>> original bug because if 'PhaseChaitin::yank_if_dead_recurse' is executed on the MachConstantBaseNode highly depends on >>> the execution of the register allocator. The graphs [1-3] correspond to an execution of the test without the fix. Graph [4] >>> >>> == Testing == >>> - Failing test (Weblogic + medrec) >>> - JPRT >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/secure/attachment/21801/graph_after_parsing.png >>> [2] https://bugs.openjdk.java.net/secure/attachment/21799/graph_after_IGVN.png >>> [3] https://bugs.openjdk.java.net/secure/attachment/21802/graph_before_reg_alloc.png >>> [4] https://bugs.openjdk.java.net/secure/attachment/21800/graph_after_IGVN_fixed.png > From tobias.hartmann at oracle.com Tue Aug 19 05:24:05 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 19 Aug 2014 07:24:05 +0200 Subject: [9] RFR(S): 8048879: "unexpected yanked node" opto/postaloc.cpp:139 In-Reply-To: References: <53F19818.3030205@oracle.com> <53F1AEF6.8000201@oracle.com> <53F1D5FB.5020207@oracle.com> Message-ID: <53F2DF75.9080703@oracle.com> Vladimir, Igor, thanks for the reviews. Best, Tobias On 19.08.2014 03:56, Igor Veresov wrote: > Looks good. > > igor > > On Aug 18, 2014, at 3:31 AM, Tobias Hartmann wrote: > >> Hi Vladimir, >> >> thanks for the review. >> >>> set_req_X() places dead store on _worklist. Look on remove_globally_dead_node() at lines 1246-1248. You can add new check into has_special_unique_user() to place membar on worklist. >> Right, that's a better solution. I added a new check for a LoadNode uniquely used by a MemBarAcquireNode. >> >>> You don't need next test's flags: >>> -Xbootclasspath/a:. -server >>> >>> -server should not be specified in jtreg tests. >> I removed the flags. >> >> Tested with the failing test and JPRT. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8048879/webrev.01/ >> >> Thanks, >> Tobias >> >>> Thanks, >>> Vladimir >>> >>> On 8/17/14 11:07 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch that fixes JDK-8048879. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048879 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8048879/webrev.00/ >>>> >>>> == Problem == >>>> The problem is caused by the following steps: >>>> 1) A volatile field access adds a LoadNNode (35) to the graph that is connected to a MemBarAcquireNode (37) to prevent >>>> following loads from floating up past. The result of the load is used by a StoreNNode (44) (see [1]). >>>> 2) During optimization the StoreNNode (44) is removed because a following StoreNNode (55) writes to the same memory >>>> location. The LoadNNode (35) is now useless but still connected to the MemBarAcquireNode (see [2]). >>>> 3) During matching a loadConP_load (9) is added together with a MachConstantBaseNode (10) to compute the address for the >>>> LoadNNode (see [3]). >>>> 4) During register allocation the assert in 'PhaseChaitin::yank_if_dead_recurse' is hit because a dead >>>> MachConstantBaseNode is not expected at this point. >>>> >>>> The unused LoadNNode (35) should have been removed during IGVN. However, the corresponding optimization in >>>> 'MemBarNode::Ideal()' (see line 2954 of memnode.cpp) does not apply because at this point the LoadNNode (35) is still >>>> connected to the StoreNNode (44). After removing the StoreNNode (44) the MemBarAcquireNode (37) should be added to the >>>> IGVN worklist to be processed again. >>>> >>>> == Solution == >>>> The implementation of 'StoreNode::Ideal' is changed to add the users of the LoadNode to the IGVN worklist if the >>>> StoreNode is removed. This allows MemBarNode::Ideal to remove the LoadNode from its precedent input if it is dead (see [4]). >>>> >>>> I added a jtreg test 'TestMemBarAcquire.java' that triggers the optimization. However, the test does not trigger the >>>> original bug because if 'PhaseChaitin::yank_if_dead_recurse' is executed on the MachConstantBaseNode highly depends on >>>> the execution of the register allocator. The graphs [1-3] correspond to an execution of the test without the fix. Graph [4] >>>> >>>> == Testing == >>>> - Failing test (Weblogic + medrec) >>>> - JPRT >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/secure/attachment/21801/graph_after_parsing.png >>>> [2] https://bugs.openjdk.java.net/secure/attachment/21799/graph_after_IGVN.png >>>> [3] https://bugs.openjdk.java.net/secure/attachment/21802/graph_before_reg_alloc.png >>>> [4] https://bugs.openjdk.java.net/secure/attachment/21800/graph_after_IGVN_fixed.png From aleksey.shipilev at oracle.com Tue Aug 19 10:30:38 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 19 Aug 2014 14:30:38 +0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53E9441D.8060209@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> <53E87C66.7000702@oracle.com> <53E93A82.4060101@oracle.com> <53E9441D.8060209@oracle.com> Message-ID: <53F3274E.4050204@oracle.com> Thanks, Vladimir. Coming back to this... On 08/12/2014 02:30 AM, Vladimir Kozlov wrote: > You may need to modify Compile::bang_size_in_bytes() and > LIR_Assembler::bang_size_in_bytes() to bang correct number of pages. Try > to test with small stacks and see > test/compiler/uncommontrap/StackOverflowGuardPagesOff.java. > > Related problems fixed recently: > https://bugs.openjdk.java.net/browse/JDK-8026775 > https://bugs.openjdk.java.net/browse/JDK-8032410 Ugh, what a mess. I think I understand the essence for those two issues. The test you mention there passes on current and patched builds, but that tells me nothing. To fix this properly, I need some guidance. If we are shooting for "lock addl (%esp, -OFFSET)" for a StoreLoad barrier, does it mean we should bang for (frame_size + OFFSET) bytes? If so, is this the addition we are shooting for? diff -r 184aac46be1f src/share/vm/c1/c1_LIRAssembler.cpp --- a/src/share/vm/c1/c1_LIRAssembler.cpp Sun Aug 10 19:38:53 2014 -0700 +++ b/src/share/vm/c1/c1_LIRAssembler.cpp Tue Aug 19 14:18:12 2014 +0400 @@ -169,7 +169,7 @@ // removes the need to bang the stack in the deoptimization blob which // in turn simplifies stack overflow handling. int LIR_Assembler::bang_size_in_bytes() const { - return MAX2(initial_frame_size_in_bytes(), _compilation->interpreter_frame_size()); + return MAX2(initial_frame_size_in_bytes() + VM_Version::L1_line_size(), _compilation->interpreter_frame_size()); } void LIR_Assembler::emit_exception_entries(ExceptionInfoList* info_list) { diff -r 184aac46be1f src/share/vm/opto/compile.cpp --- a/src/share/vm/opto/compile.cpp Sun Aug 10 19:38:53 2014 -0700 +++ b/src/share/vm/opto/compile.cpp Tue Aug 19 14:18:12 2014 +0400 @@ -430,7 +430,7 @@ // removes the need to bang the stack in the deoptimization blob which // in turn simplifies stack overflow handling. int Compile::bang_size_in_bytes() const { - return MAX2(_interpreter_frame_size, frame_size_in_bytes()); + return MAX2(_interpreter_frame_size, frame_size_in_bytes() + VM_Version::L1_line_size()); } This makes me uneasy for two reasons: a) We only need to do this for x86. ifdef'ing the generic LIR_Assembler/Compile code seems odd. Can we pro-actively bang for an additional cache line for all platforms? b) The cache line size here does seem like a magic number, and I would like to move the StoreLoad SP offset calculation somewhere -- but where to? VM_Version seems to be too generic to handle the x86-specific case. Putting it in assembler(_x86) seems to introduce the artificial dependency between the machine-neutral and machine-dependent parts of the compiler. Thanks, -Aleksey. From aleksey.shipilev at oracle.com Tue Aug 19 11:45:04 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 19 Aug 2014 15:45:04 +0400 Subject: popcnt false data dependency on recent intel In-Reply-To: References: Message-ID: <53F338C0.3070502@oracle.com> On 08/18/2014 07:20 PM, Vitaly Davidovich wrote: > Came across this SO thread recently: > http://stackoverflow.com/questions/25078285/replacing-a-32-bit-loop-count-variable-with-64-bit-introduces-crazy-performance > > I know hotspot has intrinsic that emits popcnt so thought I'd share in > case similar adjustment needs to be made to hotspot compilers. Thanks, submitted: https://bugs.openjdk.java.net/browse/JDK-8055394 Let me see if I can munge Hotspot codegen into reproducing and fixing the issue, if it's real. -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From vitalyd at gmail.com Tue Aug 19 12:24:40 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 19 Aug 2014 08:24:40 -0400 Subject: popcnt false data dependency on recent intel In-Reply-To: <53F338C0.3070502@oracle.com> References: <53F338C0.3070502@oracle.com> Message-ID: Awesome, thanks Aleksey. Interesting to know what you discover. Sent from my phone On Aug 19, 2014 7:45 AM, "Aleksey Shipilev" wrote: > On 08/18/2014 07:20 PM, Vitaly Davidovich wrote: > > Came across this SO thread recently: > > > http://stackoverflow.com/questions/25078285/replacing-a-32-bit-loop-count-variable-with-64-bit-introduces-crazy-performance > > > > I know hotspot has intrinsic that emits popcnt so thought I'd share in > > case similar adjustment needs to be made to hotspot compilers. > > Thanks, submitted: > https://bugs.openjdk.java.net/browse/JDK-8055394 > > Let me see if I can munge Hotspot codegen into reproducing and fixing > the issue, if it's real. > > -Aleksey. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Tue Aug 19 15:41:33 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Aug 2014 17:41:33 +0200 Subject: RFR(S): 8055153: nsk/stress/jck60/jck60014 crashes on sparc Message-ID: During macro expansion the control of LoadRange nodes is not set (same problem exists for LoadKlass nodes) allowing LoadRange nodes to float above a null check. The code in arraycopy macro expansion used to be executed at parse time where it was ok to not set the LoadRange control because the dependency on the null check is expressed there through a CastPP. Because macro expansion happens after CCP, CastPP nodes no longer exist in the IR when the LoadRange nodes are created, now. To fix this, I created the LoadRange (and LoadKlass) nodes when the ArrayCopyNode is created, during parsing. This way, there?s no need to set the control for the nodes (CCP will do it) and the compiler has a chance to use a previous LoadRange (or LoadKlass) and optimize it out. I found a problem in PhaseMacroExpand::copy_call_debug_info() when testing this change, where the JVMState can be shared between macro nodes and we can end up adjusting it several times. http://cr.openjdk.java.net/~roland/8055153/webrev.00/ Roland. From vladimir.kozlov at oracle.com Tue Aug 19 16:56:23 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Aug 2014 09:56:23 -0700 Subject: RFR(S): 8055153: nsk/stress/jck60/jck60014 crashes on sparc In-Reply-To: References: Message-ID: <53F381B7.9010308@oracle.com> It is good. Thanks, Vladimir On 8/19/14 8:41 AM, Roland Westrelin wrote: > During macro expansion the control of LoadRange nodes is not set (same problem exists for LoadKlass nodes) allowing LoadRange nodes to float above a null check. The code in arraycopy macro expansion used to be executed at parse time where it was ok to not set the LoadRange control because the dependency on the null check is expressed there through a CastPP. Because macro expansion happens after CCP, CastPP nodes no longer exist in the IR when the LoadRange nodes are created, now. To fix this, I created the LoadRange (and LoadKlass) nodes when the ArrayCopyNode is created, during parsing. This way, there?s no need to set the control for the nodes (CCP will do it) and the compiler has a chance to use a previous LoadRange (or LoadKlass) and optimize it out. I found a problem in PhaseMacroExpand::copy_call_debug_info() when testing this change, where the JVMState can be shared between macro nodes and we can end up adjusting it several times. > > http://cr.openjdk.java.net/~roland/8055153/webrev.00/ > > Roland. > From igor.veresov at oracle.com Tue Aug 19 17:47:26 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 19 Aug 2014 10:47:26 -0700 Subject: RFR(S): 8055153: nsk/stress/jck60/jck60014 crashes on sparc In-Reply-To: References: Message-ID: <4FD437D3-EDEA-49EB-A6F7-6C09236171F1@oracle.com> Looks good. igor On Aug 19, 2014, at 8:41 AM, Roland Westrelin wrote: > During macro expansion the control of LoadRange nodes is not set (same problem exists for LoadKlass nodes) allowing LoadRange nodes to float above a null check. The code in arraycopy macro expansion used to be executed at parse time where it was ok to not set the LoadRange control because the dependency on the null check is expressed there through a CastPP. Because macro expansion happens after CCP, CastPP nodes no longer exist in the IR when the LoadRange nodes are created, now. To fix this, I created the LoadRange (and LoadKlass) nodes when the ArrayCopyNode is created, during parsing. This way, there?s no need to set the control for the nodes (CCP will do it) and the compiler has a chance to use a previous LoadRange (or LoadKlass) and optimize it out. I found a problem in PhaseMacroExpand::copy_call_debug_info() when testing this change, where the JVMState can be shared between macro nodes and we can end up adjusting it several times. > > http://cr.openjdk.java.net/~roland/8055153/webrev.00/ > > Roland. From roland.westrelin at oracle.com Tue Aug 19 18:00:16 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Aug 2014 20:00:16 +0200 Subject: RFR(S): 8055153: nsk/stress/jck60/jck60014 crashes on sparc In-Reply-To: <4FD437D3-EDEA-49EB-A6F7-6C09236171F1@oracle.com> References: <4FD437D3-EDEA-49EB-A6F7-6C09236171F1@oracle.com> Message-ID: <51C10C7C-1765-462B-B486-16B476BC5D03@oracle.com> Thanks for the review, Vladimir & Igor. Roland. On Aug 19, 2014, at 7:47 PM, Igor Veresov wrote: > Looks good. > > igor > > On Aug 19, 2014, at 8:41 AM, Roland Westrelin wrote: > >> During macro expansion the control of LoadRange nodes is not set (same problem exists for LoadKlass nodes) allowing LoadRange nodes to float above a null check. The code in arraycopy macro expansion used to be executed at parse time where it was ok to not set the LoadRange control because the dependency on the null check is expressed there through a CastPP. Because macro expansion happens after CCP, CastPP nodes no longer exist in the IR when the LoadRange nodes are created, now. To fix this, I created the LoadRange (and LoadKlass) nodes when the ArrayCopyNode is created, during parsing. This way, there?s no need to set the control for the nodes (CCP will do it) and the compiler has a chance to use a previous LoadRange (or LoadKlass) and optimize it out. I found a problem in PhaseMacroExpand::copy_call_debug_info() when testing this change, where the JVMState can be shared between macro nodes and we can end up adjusting it several times. >> >> http://cr.openjdk.java.net/~roland/8055153/webrev.00/ >> >> Roland. > From vladimir.kozlov at oracle.com Tue Aug 19 21:17:17 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Aug 2014 14:17:17 -0700 Subject: RFR (S) 8055503: Rollback 8054164 changeset Message-ID: <53F3BEDD.2060808@oracle.com> Please, review http://cr.openjdk.java.net/~kvn/8055503/webrev/ https://bugs.openjdk.java.net/browse/JDK-8055503 Undo changes I pushed by mistake: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ae92f23ff97a Thanks, Vladimir From mikael.vidstedt at oracle.com Tue Aug 19 21:21:27 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 19 Aug 2014 14:21:27 -0700 Subject: RFR (S) 8055503: Rollback 8054164 changeset In-Reply-To: <53F3BEDD.2060808@oracle.com> References: <53F3BEDD.2060808@oracle.com> Message-ID: <53F3BFD7.9000703@oracle.com> Looks good. Cheers, Mikael On 2014-08-19 14:17, Vladimir Kozlov wrote: > Please, review > > http://cr.openjdk.java.net/~kvn/8055503/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8055503 > > Undo changes I pushed by mistake: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ae92f23ff97a > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Aug 19 21:30:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Aug 2014 14:30:00 -0700 Subject: RFR (S) 8055503: Rollback 8054164 changeset In-Reply-To: <53F3BFD7.9000703@oracle.com> References: <53F3BEDD.2060808@oracle.com> <53F3BFD7.9000703@oracle.com> Message-ID: <53F3C1D8.6000500@oracle.com> Thank you, Mikael Vladimir On 8/19/14 2:21 PM, Mikael Vidstedt wrote: > > Looks good. > > Cheers, > Mikael > > On 2014-08-19 14:17, Vladimir Kozlov wrote: >> Please, review >> >> http://cr.openjdk.java.net/~kvn/8055503/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8055503 >> >> Undo changes I pushed by mistake: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ae92f23ff97a >> >> Thanks, >> Vladimir > From igor.veresov at oracle.com Tue Aug 19 23:17:54 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 19 Aug 2014 16:17:54 -0700 Subject: RFR (S) 8055503: Rollback 8054164 changeset In-Reply-To: <53F3BEDD.2060808@oracle.com> References: <53F3BEDD.2060808@oracle.com> Message-ID: <07B24D53-115A-4FF6-A1B2-CF85989D3D56@oracle.com> Good. igor On Aug 19, 2014, at 2:17 PM, Vladimir Kozlov wrote: > Please, review > > http://cr.openjdk.java.net/~kvn/8055503/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8055503 > > Undo changes I pushed by mistake: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ae92f23ff97a > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Aug 19 23:19:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Aug 2014 16:19:42 -0700 Subject: RFR (S) 8055503: Rollback 8054164 changeset In-Reply-To: <07B24D53-115A-4FF6-A1B2-CF85989D3D56@oracle.com> References: <53F3BEDD.2060808@oracle.com> <07B24D53-115A-4FF6-A1B2-CF85989D3D56@oracle.com> Message-ID: <53F3DB8E.3000808@oracle.com> Thank you, Igor Vladimir On 8/19/14 4:17 PM, Igor Veresov wrote: > Good. > > igor > > On Aug 19, 2014, at 2:17 PM, Vladimir Kozlov wrote: > >> Please, review >> >> http://cr.openjdk.java.net/~kvn/8055503/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8055503 >> >> Undo changes I pushed by mistake: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ae92f23ff97a >> >> Thanks, >> Vladimir > From tobias.hartmann at oracle.com Thu Aug 21 07:15:46 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 21 Aug 2014 09:15:46 +0200 Subject: [9] RFR(XS): 8055657: Test compiler/classUnloading/methodUnloading/TestMethodUnloading.java does not work with non-default GC Message-ID: <53F59CA2.20508@oracle.com> Hi, please review the following patch that removes the '-XX:+UseParallelGC' parameter from the test because it is conflicting with other GC settings. Because parallel GC is the default, it will be used if no other GC is specified. Bug: https://bugs.openjdk.java.net/browse/JDK-8055657 Webrev: http://cr.openjdk.java.net/~thartmann/8055657/webrev.00/ Thanks, Tobias From tobias.hartmann at oracle.com Thu Aug 21 13:07:54 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 21 Aug 2014 15:07:54 +0200 Subject: [9] RFR(XS): 8055751: TestAnonymousClassUnloading.java needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot Message-ID: <53F5EF2A.9090402@oracle.com> Hi, please review the following patch: JDK-8011397 now requires tests using the Whitebox API to also copy the 'sun.hotspot.WhiteBox$WhiteBoxPermission' class file to the working directory. The test 'compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java' added for JDK-8054402 has to be adapted accordingly. Bug: https://bugs.openjdk.java.net/browse/JDK-8055751 Webrev: http://cr.openjdk.java.net/~thartmann/8055751/webrev.00/ Thanks, Tobias From vladimir.kozlov at oracle.com Thu Aug 21 17:24:12 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Aug 2014 10:24:12 -0700 Subject: [9] RFR(XS): 8055657: Test compiler/classUnloading/methodUnloading/TestMethodUnloading.java does not work with non-default GC In-Reply-To: <53F59CA2.20508@oracle.com> References: <53F59CA2.20508@oracle.com> Message-ID: <53F62B3C.2080404@oracle.com> Good. Thanks, Vladimir On 8/21/14 12:15 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that removes the '-XX:+UseParallelGC' parameter from the test because it is > conflicting with other GC settings. Because parallel GC is the default, it will be used if no other GC is specified. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055657 > Webrev: http://cr.openjdk.java.net/~thartmann/8055657/webrev.00/ > > Thanks, > Tobias From vladimir.kozlov at oracle.com Thu Aug 21 17:25:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Aug 2014 10:25:11 -0700 Subject: [9] RFR(XS): 8055751: TestAnonymousClassUnloading.java needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <53F5EF2A.9090402@oracle.com> References: <53F5EF2A.9090402@oracle.com> Message-ID: <53F62B77.9080700@oracle.com> Looks good. Thanks, Vladimir On 8/21/14 6:07 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > JDK-8011397 now requires tests using the Whitebox API to also copy the 'sun.hotspot.WhiteBox$WhiteBoxPermission' class > file to the working directory. The test 'compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java' added > for JDK-8054402 has to be adapted accordingly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055751 > Webrev: http://cr.openjdk.java.net/~thartmann/8055751/webrev.00/ > > Thanks, > Tobias From vladimir.kozlov at oracle.com Thu Aug 21 22:09:08 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Aug 2014 15:09:08 -0700 Subject: [9] RFR (S) 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected Message-ID: <53F66E04.7030701@oracle.com> http://cr.openjdk.java.net/~kvn/8055069/webrev/ https://bugs.openjdk.java.net/browse/JDK-8055069 Problem: "Errata HSW136. Software Using Intel? TSX May Result in Unpredictable System Behavior." Changes: Require to specify UnlockExperimentalVMOptions flag together with UseRTMLocking flag on un-patched systems where CPUID allows it but is unsupported otherwise. This would be for experiments and research and not for production applications as the name suggests. Give a warning on un-patched system when RTM is used. I have to adjust several jtreg RTM tests. Note, by default UseRTMLocking is off. I ran compiler jtreg tests on un-patched system and on machine without RTM. Thanks, Vladimir From igor.veresov at oracle.com Thu Aug 21 22:59:54 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 21 Aug 2014 15:59:54 -0700 Subject: [9] RFR (S) 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected In-Reply-To: <53F66E04.7030701@oracle.com> References: <53F66E04.7030701@oracle.com> Message-ID: Looks good. igor On Aug 21, 2014, at 3:09 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8055069/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8055069 > > Problem: > "Errata HSW136. Software Using Intel? TSX May Result in Unpredictable System Behavior." > > Changes: > Require to specify UnlockExperimentalVMOptions flag together with UseRTMLocking flag on un-patched systems where CPUID allows it but is unsupported otherwise. This would be for experiments and research and not for production applications as the name suggests. > Give a warning on un-patched system when RTM is used. > I have to adjust several jtreg RTM tests. > > Note, by default UseRTMLocking is off. > > I ran compiler jtreg tests on un-patched system and on machine without RTM. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Aug 21 23:07:19 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Aug 2014 16:07:19 -0700 Subject: [9] RFR (S) 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected In-Reply-To: References: <53F66E04.7030701@oracle.com> Message-ID: <53F67BA7.8060206@oracle.com> Thanks you, Igor Vladimir On 8/21/14 3:59 PM, Igor Veresov wrote: > Looks good. > > igor > > On Aug 21, 2014, at 3:09 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8055069/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8055069 >> >> Problem: >> "Errata HSW136. Software Using Intel? TSX May Result in Unpredictable System Behavior." >> >> Changes: >> Require to specify UnlockExperimentalVMOptions flag together with UseRTMLocking flag on un-patched systems where CPUID allows it but is unsupported otherwise. This would be for experiments and research and not for production applications as the name suggests. >> Give a warning on un-patched system when RTM is used. >> I have to adjust several jtreg RTM tests. >> >> Note, by default UseRTMLocking is off. >> >> I ran compiler jtreg tests on un-patched system and on machine without RTM. >> >> Thanks, >> Vladimir > From filipp.zhinkin at oracle.com Fri Aug 22 07:52:29 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 22 Aug 2014 11:52:29 +0400 Subject: [9] RFR (S) 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected In-Reply-To: <53F66E04.7030701@oracle.com> References: <53F66E04.7030701@oracle.com> Message-ID: <53F6F6BD.3070307@oracle.com> Hi Vladimir, the change looks good. Thanks, Filipp. On 08/22/2014 02:09 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8055069/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8055069 > > Problem: > "Errata HSW136. Software Using Intel? TSX May Result in Unpredictable > System Behavior." > > Changes: > Require to specify UnlockExperimentalVMOptions flag together with > UseRTMLocking flag on un-patched systems where CPUID allows it but is > unsupported otherwise. This would be for experiments and research and > not for production applications as the name suggests. > Give a warning on un-patched system when RTM is used. > I have to adjust several jtreg RTM tests. > > Note, by default UseRTMLocking is off. > > I ran compiler jtreg tests on un-patched system and on machine without > RTM. > > Thanks, > Vladimir From tobias.hartmann at oracle.com Fri Aug 22 08:52:21 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 22 Aug 2014 10:52:21 +0200 Subject: [9] RFR(XS): 8055751: TestAnonymousClassUnloading.java needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <53F62B77.9080700@oracle.com> References: <53F5EF2A.9090402@oracle.com> <53F62B77.9080700@oracle.com> Message-ID: <53F704C5.9000706@oracle.com> Vladimir, thanks for the review. Best, Tobias On 21.08.2014 19:25, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 8/21/14 6:07 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> JDK-8011397 now requires tests using the Whitebox API to also copy >> the 'sun.hotspot.WhiteBox$WhiteBoxPermission' class >> file to the working directory. The test >> 'compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java' >> added >> for JDK-8054402 has to be adapted accordingly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055751 >> Webrev: http://cr.openjdk.java.net/~thartmann/8055751/webrev.00/ >> >> Thanks, >> Tobias From tobias.hartmann at oracle.com Fri Aug 22 08:52:53 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 22 Aug 2014 10:52:53 +0200 Subject: [9] RFR(XS): 8055657: Test compiler/classUnloading/methodUnloading/TestMethodUnloading.java does not work with non-default GC In-Reply-To: <53F62B3C.2080404@oracle.com> References: <53F59CA2.20508@oracle.com> <53F62B3C.2080404@oracle.com> Message-ID: <53F704E5.1060806@oracle.com> Vladimir, thanks for the review. Best, Tobias On 21.08.2014 19:24, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 8/21/14 12:15 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch that removes the >> '-XX:+UseParallelGC' parameter from the test because it is >> conflicting with other GC settings. Because parallel GC is the >> default, it will be used if no other GC is specified. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055657 >> Webrev: http://cr.openjdk.java.net/~thartmann/8055657/webrev.00/ >> >> Thanks, >> Tobias From zoltan.majo at oracle.com Fri Aug 22 09:12:04 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 22 Aug 2014 11:12:04 +0200 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters Message-ID: <53F70964.4060408@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8055286 Problem: Currently, CompileCommand=option handles only flags of type bool. CompileCommand=option should be extended to handle numeric types as well. Solution: This patch adds support for processing flags of type intx and uintx (in addition flags of type bool). Support for flags of type ccstr and ccstrlist is not added by this patch; we can add support for those types when it is needed. Webrev: http://cr.openjdk.java.net/~zmajo/8055286/ Testing: JPRT, manual testing Thank you and best regards, Zoltan From zoltan.majo at oracle.com Fri Aug 22 14:07:39 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 22 Aug 2014 16:07:39 +0200 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: <53F70964.4060408@oracle.com> References: <53F70964.4060408@oracle.com> Message-ID: <53F74EAB.907@oracle.com> Hi, I've sent out an incorrect webrev URL before, here is the correct one: http://cr.openjdk.java.net/~zmajo/8055286/webrev.00/ Sorry for the mistake. Best regards, Zoltan On 08/22/2014 11:12 AM, Zolt?n Maj? wrote: > Hi, > > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055286 > > Problem: Currently, CompileCommand=option handles only flags of type > bool. CompileCommand=option should be extended to handle numeric types > as well. > > Solution: This patch adds support for processing flags of type intx > and uintx (in addition flags of type bool). Support for flags of type > ccstr and ccstrlist is not added by this patch; we can add support for > those types when it is needed. > > Webrev: http://cr.openjdk.java.net/~zmajo/8055286/ > > Testing: JPRT, manual testing > > Thank you and best regards, > > > Zoltan > From vladimir.kozlov at oracle.com Fri Aug 22 16:01:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Aug 2014 09:01:16 -0700 Subject: [9] RFR (S) 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected In-Reply-To: <53F6F6BD.3070307@oracle.com> References: <53F66E04.7030701@oracle.com> <53F6F6BD.3070307@oracle.com> Message-ID: <53F7694C.3080104@oracle.com> Thank you, Filipp Vladimir On 8/22/14 12:52 AM, Filipp Zhinkin wrote: > Hi Vladimir, > > the change looks good. > > Thanks, > Filipp. > > On 08/22/2014 02:09 AM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8055069/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8055069 >> >> Problem: >> "Errata HSW136. Software Using Intel? TSX May Result in Unpredictable System Behavior." >> >> Changes: >> Require to specify UnlockExperimentalVMOptions flag together with UseRTMLocking flag on un-patched systems where CPUID >> allows it but is unsupported otherwise. This would be for experiments and research and not for production applications >> as the name suggests. >> Give a warning on un-patched system when RTM is used. >> I have to adjust several jtreg RTM tests. >> >> Note, by default UseRTMLocking is off. >> >> I ran compiler jtreg tests on un-patched system and on machine without RTM. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Fri Aug 22 17:11:18 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Aug 2014 10:11:18 -0700 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: <53F70964.4060408@oracle.com> References: <53F70964.4060408@oracle.com> Message-ID: <53F779B6.8060607@oracle.com> Hi Zoltan, Sometimes we specify flag which is not declared as global flag in globals.hpp, for example NoRTMLockEliding. Please, don't remove such ability: + Flag *declared_flag = Flag::find_flag(flag, strlen(flag)); Flags specified in 'option' command do not affect global flags. We use the same name only for convenience. Could you move new option code from parse_from_line() method to separate method()? Also parts of that code also could be factored out, like codes which process 'intx' and 'uintx' values - they are very similar. Use 'Klass' in second line too: + // (1) CompileCommand=option,Klass::method,flag + // (2) CompileCommand=option,KLASS::method,type,flag,value Thanks, Vladimir On 8/22/14 2:12 AM, Zolt?n Maj? wrote: > Hi, > > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055286 > > Problem: Currently, CompileCommand=option handles only flags of type bool. CompileCommand=option should be extended to > handle numeric types as well. > > Solution: This patch adds support for processing flags of type intx and uintx (in addition flags of type bool). Support > for flags of type ccstr and ccstrlist is not added by this patch; we can add support for those types when it is needed. > > Webrev: http://cr.openjdk.java.net/~zmajo/8055286/ > > Testing: JPRT, manual testing > > Thank you and best regards, > > > Zoltan > From lois.foltan at oracle.com Fri Aug 22 18:35:05 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 22 Aug 2014 14:35:05 -0400 Subject: RFR (XS) JDK-8054355: ENFORCE_CC_COMPILER_REV needs to be updated to Solaris C++ 12u3 for JDK 9 Message-ID: <53F78D59.60604@oracle.com> Hi Everyone, Please review the following fix: Webrev: http://cr.openjdk.java.net/~lfoltan/bug_jdk8054355/ Bug: ENFORCE_CC_COMPILER_REV needs to be updated to Solaris C++ 12u3 for JDK 9 https://bugs.openjdk.java.net/browse/JDK-8054355 Summary of fix: Update of C++ validation check for JDK 9 on Solaris. Testing: Built various variants with Solaris C++ 12u3 to confirm that the warning concerning C++ version is no longer generated. Also built with versions other than 12u3 to further confirm that the warning is generated in those situations. Other testing in progress - jprt build to confirm builds are successful, quick run of Hotspot jtreg test/runtime in progress From vladimir.kozlov at oracle.com Fri Aug 22 19:01:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Aug 2014 12:01:53 -0700 Subject: RFR (XS) JDK-8054355: ENFORCE_CC_COMPILER_REV needs to be updated to Solaris C++ 12u3 for JDK 9 In-Reply-To: <53F78D59.60604@oracle.com> References: <53F78D59.60604@oracle.com> Message-ID: <53F793A1.6080902@oracle.com> Good. Thanks, Vladimir On 8/22/14 11:35 AM, Lois Foltan wrote: > Hi Everyone, > > Please review the following fix: > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8054355/ > > Bug: ENFORCE_CC_COMPILER_REV needs to be updated to Solaris C++ 12u3 for > JDK 9 > https://bugs.openjdk.java.net/browse/JDK-8054355 > > Summary of fix: > Update of C++ validation check for JDK 9 on Solaris. > > Testing: > Built various variants with Solaris C++ 12u3 to confirm that the warning > concerning C++ version is no longer generated. Also built with versions > other than 12u3 to further confirm that the warning is generated in > those situations. > > Other testing in progress - jprt build to confirm builds are successful, > quick run of Hotspot jtreg test/runtime in progress > > From lois.foltan at oracle.com Fri Aug 22 19:17:19 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 22 Aug 2014 15:17:19 -0400 Subject: RFR (XS) JDK-8054355: ENFORCE_CC_COMPILER_REV needs to be updated to Solaris C++ 12u3 for JDK 9 In-Reply-To: <53F793A1.6080902@oracle.com> References: <53F78D59.60604@oracle.com> <53F793A1.6080902@oracle.com> Message-ID: <53F7973F.6070401@oracle.com> Thanks Vladimir! Lois On 8/22/2014 3:01 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 8/22/14 11:35 AM, Lois Foltan wrote: >> Hi Everyone, >> >> Please review the following fix: >> >> Webrev: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8054355/ >> >> Bug: ENFORCE_CC_COMPILER_REV needs to be updated to Solaris C++ 12u3 for >> JDK 9 >> https://bugs.openjdk.java.net/browse/JDK-8054355 >> >> Summary of fix: >> Update of C++ validation check for JDK 9 on Solaris. >> >> Testing: >> Built various variants with Solaris C++ 12u3 to confirm that the warning >> concerning C++ version is no longer generated. Also built with versions >> other than 12u3 to further confirm that the warning is generated in >> those situations. >> >> Other testing in progress - jprt build to confirm builds are successful, >> quick run of Hotspot jtreg test/runtime in progress >> >> From david.r.chase at oracle.com Fri Aug 22 21:24:30 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 22 Aug 2014 17:24:30 -0400 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds Message-ID: webrev: http://cr.openjdk.java.net/~drchase/8054292/webrev-for-leak-checks.09/ bug: (confidential) https://bugs.openjdk.java.net/browse/JDK-8054292 description: CodeBuffers and BufferBlobs leak code comment strings in fastdebug. This can be seen with the KitchenSink internal test or with CompileTheWorld: w/ CodeBuffer strings freed, BufferBlobs flushed to free strings and oopmaps: Total: reserved=5,908,975KB, committed=713,911KB - Code (reserved=251,478KB, committed=22,442KB) (malloc=3,798KB #82,818) (mmap: reserved=247,680KB, committed=18,644KB) no leak plugging: Total: reserved=6,031,728KB, committed=836,404KB - Code (reserved=340,883KB, committed=111,587KB) (malloc=93,203KB #221,6790) (mmap: reserved=247,680KB, committed=18,384KB) With these leaks fixed (this includes a possible oopmap leak) KitchenSink still leaks about about 6MB/hour on a not-too-old 6MB/hour Linux box, but this leak appears to be plugged. (KitchenSink is running over the weekend with NMT detail turned on to identify the next leak. The old code leaked at least 25MB/hour on this box.) Fix: Free memory in appropriate places. Insert asserts to guard against reuse of freed memory. Testing: JPRT, jtreg, CompileTheWorld, KitchenSink, quicktest jtreg included testing with -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly to help guard against the case of prematurely freed pointers. Other testing involved freeing more aggressively at the use sites, and then asserting whenever the destructor was run w/o memory having been freed. One client of CodeBuffers allocates them without running their constructor, which interfered with enabling the full set of assertions that we might like. -------------- 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 Aug 22 22:47:38 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Aug 2014 15:47:38 -0700 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds In-Reply-To: References: Message-ID: <53F7C88A.8060706@oracle.com> There is some missmatch of use #ifdef ASSERT and #ifndef PRODUCT. Please, build 'optimized' JVM in addition to 'product' and 'debug'. Seems _defunct field should be DEBUG only since it is checked only in assert. It could be NOT_PRODUCT bu in that case set_null_and_invalidate() should clean both fields under #ifndef PRODUCT. isNull() will return 'true' in NOT_PRODUCT (optimized VM) when assign() may set _strings. An other thing I don't like in current code is the same name of _strings fields in both CodeStrings and CodeBuffer. It is difficult to follow which one is accessed in a code. > One client of CodeBuffers allocates them without running their constructor, > which interfered with enabling the full set of assertions that we might like. It would be nice to fix it - call constructor in that place. Where it is? You can try to do what we do in growableArray: new(&_strings) CodeStrings(). Thanks, Vladimir On 8/22/14 2:24 PM, David Chase wrote: > > webrev: http://cr.openjdk.java.net/~drchase/8054292/webrev-for-leak-checks.09/ > bug: (confidential) https://bugs.openjdk.java.net/browse/JDK-8054292 > > description: CodeBuffers and BufferBlobs leak code comment strings in fastdebug. > This can be seen with the KitchenSink internal test or with CompileTheWorld: > > w/ CodeBuffer strings freed, BufferBlobs flushed to free strings and oopmaps: > Total: reserved=5,908,975KB, committed=713,911KB > - Code (reserved=251,478KB, committed=22,442KB) > (malloc=3,798KB #82,818) > (mmap: reserved=247,680KB, committed=18,644KB) > > no leak plugging: > Total: reserved=6,031,728KB, committed=836,404KB > - Code (reserved=340,883KB, committed=111,587KB) > (malloc=93,203KB #221,6790) > (mmap: reserved=247,680KB, committed=18,384KB) > > With these leaks fixed (this includes a possible oopmap leak) > KitchenSink still leaks about about 6MB/hour on a not-too-old > 6MB/hour Linux box, but this leak appears to be plugged. > (KitchenSink is running over the weekend with NMT detail > turned on to identify the next leak. The old code leaked > at least 25MB/hour on this box.) > > Fix: > Free memory in appropriate places. > Insert asserts to guard against reuse of freed memory. > > Testing: > JPRT, jtreg, CompileTheWorld, KitchenSink, quicktest > > jtreg included testing with -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly > to help guard against the case of prematurely freed pointers. > > Other testing involved freeing more aggressively at the use sites, > and then asserting whenever the destructor was run w/o memory > having been freed. > > One client of CodeBuffers allocates them without running their constructor, > which interfered with enabling the full set of assertions that we might like. > From david.r.chase at oracle.com Sat Aug 23 00:43:55 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 22 Aug 2014 20:43:55 -0400 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds In-Reply-To: <53F7C88A.8060706@oracle.com> References: <53F7C88A.8060706@oracle.com> Message-ID: <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> On 2014-08-22, at 6:47 PM, Vladimir Kozlov wrote: > There is some missmatch of use #ifdef ASSERT and #ifndef PRODUCT. > Please, build 'optimized' JVM in addition to 'product' and 'debug?. Optimized VM is running my matrix-multiplication experiments happily, will also do jtreg, didn?t JPRT also do that for me? I can certainly do jtreg with the optimized build. > Seems _defunct field should be DEBUG only since it is checked only in assert. It could be NOT_PRODUCT bu in that case set_null_and_invalidate() should clean both fields under #ifndef PRODUCT. > isNull() will return 'true' in NOT_PRODUCT (optimized VM) when assign() may set _strings. John also wants it to be spelled is_null, and I just overlooked it and use JavaConventions. I was planning to have all the probe methods do as little as possible in PRODUCT. I agree, _defunct should also be DEBUG (is that the same as ASSERT?) only. > An other thing I don't like in current code is the same name of _strings fields in both CodeStrings and CodeBuffer. It is difficult to follow which one is accessed in a code. Do you recommend that I fix that, then? I also did not like this, but thought it was house style. I propose to call the CodeStrings-typed field of CodeBuffer ?_codestrings?. > > One client of CodeBuffers allocates them without running their constructor, > > which interfered with enabling the full set of assertions that we might like. > > It would be nice to fix it - call constructor in that place. Where it is? You can try to do what we do in growableArray: > new(&_strings) CodeStrings(). I?m trying to recreate that failure; it may be Linux-specific (it failed on Linux, but did not fail for me on Mac just now, this seems peculiar and even more unsettling). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Sat Aug 23 01:08:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Aug 2014 18:08:10 -0700 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds In-Reply-To: <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> References: <53F7C88A.8060706@oracle.com> <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> Message-ID: <53F7E97A.9090006@oracle.com> On 8/22/14 5:43 PM, David Chase wrote: > > On 2014-08-22, at 6:47 PM, Vladimir Kozlov wrote: > >> There is some missmatch of use #ifdef ASSERT and #ifndef PRODUCT. >> Please, build 'optimized' JVM in addition to 'product' and 'debug?. > > Optimized VM is running my matrix-multiplication experiments happily, will also do jtreg, didn?t JPRT also do that for me? > I can certainly do jtreg with the optimized build. Okay. > >> Seems _defunct field should be DEBUG only since it is checked only in assert. It could be NOT_PRODUCT bu in that case set_null_and_invalidate() should clean both fields under #ifndef PRODUCT. >> isNull() will return 'true' in NOT_PRODUCT (optimized VM) when assign() may set _strings. > > John also wants it to be spelled is_null, and I just overlooked it and use JavaConventions. > I was planning to have all the probe methods do as little as possible in PRODUCT. > I agree, _defunct should also be DEBUG (is that the same as ASSERT?) only. Yes: #ifdef ASSERT #define DEBUG_ONLY(code) code > >> An other thing I don't like in current code is the same name of _strings fields in both CodeStrings and CodeBuffer. It is difficult to follow which one is accessed in a code. > > Do you recommend that I fix that, then? I also did not like this, but thought it was house style. It is not "house style". > I propose to call the CodeStrings-typed field of CodeBuffer ?_codestrings?. Agree. >>> One client of CodeBuffers allocates them without running their constructor, >>> which interfered with enabling the full set of assertions that we might like. >> >> It would be nice to fix it - call constructor in that place. Where it is? You can try to do what we do in growableArray: >> new(&_strings) CodeStrings(). > > I?m trying to recreate that failure; it may be Linux-specific (it failed on Linux, but did not fail for me on Mac just now, this seems peculiar and even more unsettling). > Thanks, Vladimir From john.r.rose at oracle.com Sat Aug 23 01:08:58 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 22 Aug 2014 18:08:58 -0700 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds In-Reply-To: <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> References: <53F7C88A.8060706@oracle.com> <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> Message-ID: <2464B743-9814-431D-88CB-2545E90BAA9A@oracle.com> > On Aug 22, 2014, at 5:43 PM, David Chase wrote: > > house style. > I propose to call the CodeStrings-typed field of CodeBuffer ?_codestrings?. Good; that irritated me too. House style for CamelCase name rendered as method or field would be camel_case, i.e., _code_strings. From zoltan.majo at oracle.com Mon Aug 25 15:33:35 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 25 Aug 2014 17:33:35 +0200 Subject: [9] RFR(S): 8051415: TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory Message-ID: <53FB574F.1030306@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8051415 Problem: The methods TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory for field_array. Both methods allocate memory explicitly for TypeFunc::Parms; the fields() method they use for allocation allocates memory for TypeFunc::Parms as well. Solution: Change memory allocation in TypeTuple::make_domain() and TypeTuple::make_range() to not allocate memory for TypeFunc::Parms. Webrev: http://cr.openjdk.java.net/~zmajo/8051415/webrev.00/ Testing: - JPRT - JTREG - CompileTheWorld rt.jar Thank you and best regards, Zoltan From vladimir.kozlov at oracle.com Mon Aug 25 16:56:13 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Aug 2014 09:56:13 -0700 Subject: [9] RFR(S): 8051415: TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory In-Reply-To: <53FB574F.1030306@oracle.com> References: <53FB574F.1030306@oracle.com> Message-ID: <53FB6AAD.8030605@oracle.com> Please, fix copyright year in type.hpp. May be rename total_fields to arg_cnt since it is not 'total' now. Thanks, Vladimir On 8/25/14 8:33 AM, Zolt?n Maj? wrote: > Hi, > > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8051415 > > Problem: The methods TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory for field_array. Both > methods allocate memory explicitly for TypeFunc::Parms; the fields() method they use for allocation allocates memory for > TypeFunc::Parms as well. > > Solution: Change memory allocation in TypeTuple::make_domain() and TypeTuple::make_range() to not allocate memory for > TypeFunc::Parms. > > Webrev: http://cr.openjdk.java.net/~zmajo/8051415/webrev.00/ > > Testing: > > - JPRT > - JTREG > - CompileTheWorld rt.jar > > Thank you and best regards, > > > Zoltan > From zoltan.majo at oracle.com Mon Aug 25 17:56:33 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 25 Aug 2014 19:56:33 +0200 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: <53F779B6.8060607@oracle.com> References: <53F70964.4060408@oracle.com> <53F779B6.8060607@oracle.com> Message-ID: <53FB78D1.5020508@oracle.com> Hi Vladimir, thank you for the feedback. On 08/22/2014 07:11 PM, Vladimir Kozlov wrote: > Sometimes we specify flag which is not declared as global flag in > globals.hpp, for example NoRTMLockEliding. Please, don't remove such > ability: I did not know that, thanks for pointing it out. > > + Flag *declared_flag = Flag::find_flag(flag, strlen(flag)); > > Flags specified in 'option' command do not affect global flags. We use > the same name only for convenience. I removed checking if a flag is declared in globals.hpp. But I think it is important that the type of a flag specified by the user matches the type expected by the compiler (otherwise the compiler could read random values at runtime). The type of a flag is therefore recorded in TypedMethodOptionMatcher and it is checked at runtime (line 381). If the two types do not match for a method m(), the default value of the flag is used for that method. > Could you move new option code from parse_from_line() method to > separate method()? Yes, I did that. Please see the scan_flag_and_value() function. > Also parts of that code also could be factored out, like codes which > process 'intx' and 'uintx' values - they are very similar. I tried that, but it is not straightforward, as on some platforms sscanf() does not support format strings created at runtime. Without a common sscanf() call, the two branches are too little similar, but I might be wrong on that. So I decided to leave the code processing intx and uintx values unchanged. I hope that factoring out functionality into the scan_flag_and_value() function made the code already more readable. > Use 'Klass' in second line too: > + // (1) CompileCommand=option,Klass::method,flag > + // (2) CompileCommand=option,KLASS::method,type,flag,value Changed that as well. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8055286/webrev.01/ I ran the JPRT tests again, all pass. Thank you and best regards Zoltan > Thanks, > Vladimir > > On 8/22/14 2:12 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055286 >> >> Problem: Currently, CompileCommand=option handles only flags of type >> bool. CompileCommand=option should be extended to >> handle numeric types as well. >> >> Solution: This patch adds support for processing flags of type intx >> and uintx (in addition flags of type bool). Support >> for flags of type ccstr and ccstrlist is not added by this patch; we >> can add support for those types when it is needed. >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8055286/ >> >> Testing: JPRT, manual testing >> >> Thank you and best regards, >> >> >> Zoltan >> From vladimir.kozlov at oracle.com Mon Aug 25 18:50:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Aug 2014 11:50:49 -0700 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: <53FB78D1.5020508@oracle.com> References: <53F70964.4060408@oracle.com> <53F779B6.8060607@oracle.com> <53FB78D1.5020508@oracle.com> Message-ID: <53FB8589.6070700@oracle.com> You don't need changes in globals.* files now. New access methods should return boolean, this way it will be easier to use: static bool has_option_value(methodHandle method, const char* option, intx& value); Why you dup flag: strdup(flag)? TypedMethodOptionMatcher() does it already: os::strdup_check_oom(opt). Don't assign option(opt) which is replaced immediately: MethodMatcher(class_name, class_mode, method_name, method_mode, signature, next), option(opt), _type(BoolType), _value(value) { option = os::strdup_check_oom(opt); Please, use underscore for '_option' field's name too, even if it was not before. From what I see the only reason you have TypedMethodOptionMatcher constructor specialization is _type(UnknownType) setting. But why you are not using your new functions: get_type_for()? You have type check before already: strcmp(options, "intx") etc, so only known types are used. Why you need specialization for CompilerOracle::option_value()? scan_flag_and_value() should return 'match' value as add_option_string() to be consistent. The success could be checked by (match != NULL) as in other cases. On 8/25/14 10:56 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for the feedback. > > On 08/22/2014 07:11 PM, Vladimir Kozlov wrote: >> Sometimes we specify flag which is not declared as global flag in globals.hpp, for example NoRTMLockEliding. Please, >> don't remove such ability: > > I did not know that, thanks for pointing it out. > >> >> + Flag *declared_flag = Flag::find_flag(flag, strlen(flag)); >> >> Flags specified in 'option' command do not affect global flags. We use the same name only for convenience. > > I removed checking if a flag is declared in globals.hpp. > > But I think it is important that the type of a flag specified by the user matches the type expected by the compiler > (otherwise the compiler could read random values at runtime). The type of a flag is therefore recorded in > TypedMethodOptionMatcher and it is checked at runtime (line 381). If the two types do not match for a method m(), the > default value of the flag is used for that method. There is check, strcmp(options, "intx") etc, which guarantees the type consistency. > >> Could you move new option code from parse_from_line() method to separate method()? > > Yes, I did that. Please see the scan_flag_and_value() function. Good. > >> Also parts of that code also could be factored out, like codes which process 'intx' and 'uintx' values - they are very >> similar. > > I tried that, but it is not straightforward, as on some platforms sscanf() does not support format strings created at > runtime. Without a common sscanf() call, the two branches are too little similar, but I might be wrong on that. > > So I decided to leave the code processing intx and uintx values unchanged. I hope that factoring out functionality into > the scan_flag_and_value() function made the code already more readable. Looks good. > >> Use 'Klass' in second line too: >> + // (1) CompileCommand=option,Klass::method,flag >> + // (2) CompileCommand=option,KLASS::method,type,flag,value > > Changed that as well. > > Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8055286/webrev.01/ > > I ran the JPRT tests again, all pass. Thanks, Vladimir > > Thank you and best regards > > > Zoltan > >> Thanks, >> Vladimir >> >> On 8/22/14 2:12 AM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055286 >>> >>> Problem: Currently, CompileCommand=option handles only flags of type bool. CompileCommand=option should be extended to >>> handle numeric types as well. >>> >>> Solution: This patch adds support for processing flags of type intx and uintx (in addition flags of type bool). Support >>> for flags of type ccstr and ccstrlist is not added by this patch; we can add support for those types when it is needed. >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8055286/ >>> >>> Testing: JPRT, manual testing >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > From staffan.larsen at oracle.com Tue Aug 26 09:47:36 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Aug 2014 11:47:36 +0200 Subject: RFR: 8055838 Hotspot does not compile with clang 6.0 (OS X Yosemite) Message-ID: There is a check in the makefiles to lower the optimization level for some files on some versions of clang . This check needs to take clang 6.0 into account (which is the default compiler on OS X Yosemite). The straightforward fix is below. I have verified this by running the hotspot/compiler tests. With the higher optimization level, a couple of tests fail in compiler/5091921. With the lower optimization level these tests pass. So it seems the fix is still needed for clang 6.0. bug: https://bugs.openjdk.java.net/browse/JDK-8055838 Thanks, /Staffan diff -r 8e575cec7af9 make/bsd/makefiles/gcc.make --- a/make/bsd/makefiles/gcc.make Tue Aug 19 11:17:44 2014 -0700 +++ b/make/bsd/makefiles/gcc.make Fri Aug 22 19:06:41 2014 +0200 @@ -325,6 +325,10 @@ else ifeq ($(shell expr $(CC_VER_MAJOR) = 5 \& $(CC_VER_MINOR) = 1), 1) OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) OPT_CFLAGS/unsafe.o += -O1 + # Clang 6.0 + else ifeq ($(shell expr $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) = 0), 1) + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) + OPT_CFLAGS/unsafe.o += -O1 else $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") endif From lois.foltan at oracle.com Tue Aug 26 12:11:53 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 26 Aug 2014 08:11:53 -0400 Subject: RFR: 8055838 Hotspot does not compile with clang 6.0 (OS X Yosemite) In-Reply-To: References: Message-ID: <53FC7988.5030403@oracle.com> Hi Staffan, I think this looks good. I added the knock down of unsafe.o for clang 4.6.2. See https://bugs.openjdk.java.net/browse/JDK-8022407 for the original test causing the issue. Lois On 8/26/2014 5:47 AM, Staffan Larsen wrote: > There is a check in the makefiles to lower the optimization level for some files on some versions of clang . This check needs to take clang 6.0 into account (which is the default compiler on OS X Yosemite). The straightforward fix is below. I have verified this by running the hotspot/compiler tests. With the higher optimization level, a couple of tests fail in compiler/5091921. With the lower optimization level these tests pass. So it seems the fix is still needed for clang 6.0. > > bug: https://bugs.openjdk.java.net/browse/JDK-8055838 > > Thanks, > /Staffan > > > diff -r 8e575cec7af9 make/bsd/makefiles/gcc.make > --- a/make/bsd/makefiles/gcc.make Tue Aug 19 11:17:44 2014 -0700 > +++ b/make/bsd/makefiles/gcc.make Fri Aug 22 19:06:41 2014 +0200 > @@ -325,6 +325,10 @@ > else ifeq ($(shell expr $(CC_VER_MAJOR) = 5 \& $(CC_VER_MINOR) = 1), 1) > OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) > OPT_CFLAGS/unsafe.o += -O1 > + # Clang 6.0 > + else ifeq ($(shell expr $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) = 0), 1) > + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) > + OPT_CFLAGS/unsafe.o += -O1 > else > $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") > endif From igor.ignatyev at oracle.com Tue Aug 26 14:35:03 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 26 Aug 2014 18:35:03 +0400 Subject: RFR(S) : 8056072 : add jprt_optimized targets Message-ID: <53FC9B17.2060102@oracle.com> http://cr.openjdk.java.net/~iignatyev/8056072/webrev.00/ 27 lines changed: 23 ins; 0 del; 4 mod; Hi all, Please review the patch which adds jprt_build_optimized* targets and removes mentions of optimized builds from 'jprt.properties'. jbs: https://bugs.openjdk.java.net/browse/JDK-8056072 PS the platforms to build w/ optimized flavor will be selected and added into jprt.properties as the fix for JDK-8013869 after corresponding changes in JPRT. -- Igor From zoltan.majo at oracle.com Tue Aug 26 15:14:17 2014 From: zoltan.majo at oracle.com (Zoltan Majo) Date: Tue, 26 Aug 2014 17:14:17 +0200 Subject: [9] RFR(S): 8051415: TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory In-Reply-To: <53FB6AAD.8030605@oracle.com> References: <53FB574F.1030306@oracle.com> <53FB6AAD.8030605@oracle.com> Message-ID: <53FCA449.2010409@oracle.com> Hi Vladimir, thank you for the comments. On 08/25/2014 06:56 PM, Vladimir Kozlov wrote: > Please, fix copyright year in type.hpp. > May be rename total_fields to arg_cnt since it is not 'total' now. I did that, here is the new webrev: http://cr.openjdk.java.net/~zmajo/8051415/webrev.01/ I ran JPRT and CompileTheWorld with rt.jar again, just to be sure. Thanks and best regards, Zoltan > Thanks, > Vladimir > > On 8/25/14 8:33 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8051415 >> >> Problem: The methods TypeTuple::make_domain() and >> TypeTuple::make_range() allocate too much memory for field_array. Both >> methods allocate memory explicitly for TypeFunc::Parms; the fields() >> method they use for allocation allocates memory for >> TypeFunc::Parms as well. >> >> Solution: Change memory allocation in TypeTuple::make_domain() and >> TypeTuple::make_range() to not allocate memory for >> TypeFunc::Parms. >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8051415/webrev.00/ >> >> Testing: >> >> - JPRT >> - JTREG >> - CompileTheWorld rt.jar >> >> Thank you and best regards, >> >> >> Zoltan >> From vladimir.kozlov at oracle.com Tue Aug 26 15:30:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Aug 2014 08:30:42 -0700 Subject: RFR: 8055838 Hotspot does not compile with clang 6.0 (OS X Yosemite) In-Reply-To: References: Message-ID: <53FCA822.4000406@oracle.com> Looks good. I hope they will fix it soon otherwise we may better use expression with >= to cover future clang version. Thanks, Vladimir On 8/26/14 2:47 AM, Staffan Larsen wrote: > There is a check in the makefiles to lower the optimization level for some files on some versions of clang . This check needs to take clang 6.0 into account (which is the default compiler on OS X Yosemite). The straightforward fix is below. I have verified this by running the hotspot/compiler tests. With the higher optimization level, a couple of tests fail in compiler/5091921. With the lower optimization level these tests pass. So it seems the fix is still needed for clang 6.0. > > bug: https://bugs.openjdk.java.net/browse/JDK-8055838 > > Thanks, > /Staffan > > > diff -r 8e575cec7af9 make/bsd/makefiles/gcc.make > --- a/make/bsd/makefiles/gcc.make Tue Aug 19 11:17:44 2014 -0700 > +++ b/make/bsd/makefiles/gcc.make Fri Aug 22 19:06:41 2014 +0200 > @@ -325,6 +325,10 @@ > else ifeq ($(shell expr $(CC_VER_MAJOR) = 5 \& $(CC_VER_MINOR) = 1), 1) > OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) > OPT_CFLAGS/unsafe.o += -O1 > + # Clang 6.0 > + else ifeq ($(shell expr $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) = 0), 1) > + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) > + OPT_CFLAGS/unsafe.o += -O1 > else > $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") > endif > From vladimir.kozlov at oracle.com Tue Aug 26 16:05:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Aug 2014 09:05:16 -0700 Subject: [9] RFR(S): 8051415: TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory In-Reply-To: <53FCA449.2010409@oracle.com> References: <53FB574F.1030306@oracle.com> <53FB6AAD.8030605@oracle.com> <53FCA449.2010409@oracle.com> Message-ID: <53FCB03C.1010701@oracle.com> Good. Thanks, Vladimir On 8/26/14 8:14 AM, Zoltan Majo wrote: > Hi Vladimir, > > > thank you for the comments. > > On 08/25/2014 06:56 PM, Vladimir Kozlov wrote: >> Please, fix copyright year in type.hpp. >> May be rename total_fields to arg_cnt since it is not 'total' now. > > I did that, here is the new webrev: > > http://cr.openjdk.java.net/~zmajo/8051415/webrev.01/ > > I ran JPRT and CompileTheWorld with rt.jar again, just to be sure. > > Thanks and best regards, > > > Zoltan > > >> Thanks, >> Vladimir >> >> On 8/25/14 8:33 AM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8051415 >>> >>> Problem: The methods TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory for field_array. Both >>> methods allocate memory explicitly for TypeFunc::Parms; the fields() method they use for allocation allocates memory for >>> TypeFunc::Parms as well. >>> >>> Solution: Change memory allocation in TypeTuple::make_domain() and TypeTuple::make_range() to not allocate memory for >>> TypeFunc::Parms. >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8051415/webrev.00/ >>> >>> Testing: >>> >>> - JPRT >>> - JTREG >>> - CompileTheWorld rt.jar >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > From vladimir.kozlov at oracle.com Tue Aug 26 17:25:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Aug 2014 10:25:16 -0700 Subject: RFR(S) : 8056072 : add jprt_optimized targets In-Reply-To: <53FC9B17.2060102@oracle.com> References: <53FC9B17.2060102@oracle.com> Message-ID: <53FCC2FC.8040901@oracle.com> Looks good. Thanks, Vladimir On 8/26/14 7:35 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8056072/webrev.00/ > 27 lines changed: 23 ins; 0 del; 4 mod; > > Hi all, > > Please review the patch which adds jprt_build_optimized* targets and > removes mentions of optimized builds from 'jprt.properties'. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8056072 > > PS the platforms to build w/ optimized flavor will be selected and added > into jprt.properties as the fix for JDK-8013869 after corresponding > changes in JPRT. From zoltan.majo at oracle.com Wed Aug 27 07:27:36 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 27 Aug 2014 09:27:36 +0200 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: <53FB8589.6070700@oracle.com> References: <53F70964.4060408@oracle.com> <53F779B6.8060607@oracle.com> <53FB78D1.5020508@oracle.com> <53FB8589.6070700@oracle.com> Message-ID: <53FD8868.3060105@oracle.com> Hi Vladimir, thank you for the feedback. On 08/25/2014 08:50 PM, Vladimir Kozlov wrote: > You don't need changes in globals.* files now. I forgot about those files, sorry. I reverted them now. > New access methods should return boolean, this way it will be easier > to use: > > static bool has_option_value(methodHandle method, const char* option, > intx& value); OK, I changed the methods. > Why you dup flag: strdup(flag)? > TypedMethodOptionMatcher() does it already: os::strdup_check_oom(opt). You're right, it's unnecessary and I've removed it. > Don't assign option(opt) which is replaced immediately: > > MethodMatcher(class_name, class_mode, method_name, method_mode, > signature, next), > option(opt), _type(BoolType), _value(value) { > option = os::strdup_check_oom(opt); You're right, but I removed that code as you suggested not to specialize that constructor (please see below). > Please, use underscore for '_option' field's name too, even if it was > not before. OK. > From what I see the only reason you have TypedMethodOptionMatcher > constructor specialization is _type(UnknownType) setting. But why you > are not using your new functions: get_type_for()? You have type > check before already: strcmp(options, "intx") etc, so only known types > are used. You're right. I removed all specializations of that constructor. > Why you need specialization for CompilerOracle::option_value()? I changed has_option_value() to a template method and so we have only one declaration in compilerOracle.hpp. But we need to explicitly instantiate the method for all OptionTypes supported, because the method relies on some data/functionality that is available only from within CompilerOracle and thus it is not possible to instantiate it in other compilation units. The explicit instantiations are in compilerOracle.cpp. > scan_flag_and_value() should return 'match' value as > add_option_string() to be consistent. The success could be checked by > (match != NULL) as in other cases. I changed it. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8055286/webrev.02/ I ran JPRT again. Thank you and best regards, Zoltan > On 8/25/14 10:56 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> thank you for the feedback. >> >> On 08/22/2014 07:11 PM, Vladimir Kozlov wrote: >>> Sometimes we specify flag which is not declared as global flag in >>> globals.hpp, for example NoRTMLockEliding. Please, >>> don't remove such ability: >> >> I did not know that, thanks for pointing it out. >> >>> >>> + Flag *declared_flag = Flag::find_flag(flag, strlen(flag)); >>> >>> Flags specified in 'option' command do not affect global flags. We >>> use the same name only for convenience. >> >> I removed checking if a flag is declared in globals.hpp. >> >> But I think it is important that the type of a flag specified by the >> user matches the type expected by the compiler >> (otherwise the compiler could read random values at runtime). The >> type of a flag is therefore recorded in >> TypedMethodOptionMatcher and it is checked at runtime (line 381). If >> the two types do not match for a method m(), the >> default value of the flag is used for that method. > > There is check, strcmp(options, "intx") etc, which guarantees the type > consistency. > >> >>> Could you move new option code from parse_from_line() method to >>> separate method()? >> >> Yes, I did that. Please see the scan_flag_and_value() function. > > Good. > >> >>> Also parts of that code also could be factored out, like codes which >>> process 'intx' and 'uintx' values - they are very >>> similar. >> >> I tried that, but it is not straightforward, as on some platforms >> sscanf() does not support format strings created at >> runtime. Without a common sscanf() call, the two branches are too >> little similar, but I might be wrong on that. >> >> So I decided to leave the code processing intx and uintx values >> unchanged. I hope that factoring out functionality into >> the scan_flag_and_value() function made the code already more readable. > > Looks good. > >> >>> Use 'Klass' in second line too: >>> + // (1) CompileCommand=option,Klass::method,flag >>> + // (2) CompileCommand=option,KLASS::method,type,flag,value >> >> Changed that as well. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8055286/webrev.01/ >> >> I ran the JPRT tests again, all pass. > > Thanks, > Vladimir > >> >> Thank you and best regards >> >> >> Zoltan >> >>> Thanks, >>> Vladimir >>> >>> On 8/22/14 2:12 AM, Zolt?n Maj? wrote: >>>> Hi, >>>> >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055286 >>>> >>>> Problem: Currently, CompileCommand=option handles only flags of >>>> type bool. CompileCommand=option should be extended to >>>> handle numeric types as well. >>>> >>>> Solution: This patch adds support for processing flags of type intx >>>> and uintx (in addition flags of type bool). Support >>>> for flags of type ccstr and ccstrlist is not added by this patch; >>>> we can add support for those types when it is needed. >>>> >>>> Webrev: http://cr.openjdk.java.net/~zmajo/8055286/ >>>> >>>> Testing: JPRT, manual testing >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >> From roland.westrelin at oracle.com Wed Aug 27 07:30:50 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 27 Aug 2014 09:30:50 +0200 Subject: RFR(S) : 8056072 : add jprt_optimized targets In-Reply-To: <53FC9B17.2060102@oracle.com> References: <53FC9B17.2060102@oracle.com> Message-ID: <25C0AC54-276A-49F0-85AA-BC5FA9012A4D@oracle.com> > http://cr.openjdk.java.net/~iignatyev/8056072/webrev.00/ That looks good to me. Roland. From roland.westrelin at oracle.com Wed Aug 27 07:34:05 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 27 Aug 2014 09:34:05 +0200 Subject: [9] RFR(S): 8051415: TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory In-Reply-To: <53FCA449.2010409@oracle.com> References: <53FB574F.1030306@oracle.com> <53FB6AAD.8030605@oracle.com> <53FCA449.2010409@oracle.com> Message-ID: > http://cr.openjdk.java.net/~zmajo/8051415/webrev.01/ It looks good to me. Roland. From zoltan.majo at oracle.com Wed Aug 27 08:07:28 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Wed, 27 Aug 2014 10:07:28 +0200 Subject: [9] RFR(S): 8051415: TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory In-Reply-To: References: <53FB574F.1030306@oracle.com> <53FB6AAD.8030605@oracle.com> <53FCA449.2010409@oracle.com> Message-ID: <53FD91C0.50709@oracle.com> Thank you, Vladimir and Roland, for the review! Best regards, Zoltan On 08/27/2014 09:34 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~zmajo/8051415/webrev.01/ > It looks good to me. > > Roland. From aleksey.shipilev at oracle.com Wed Aug 27 11:05:32 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 27 Aug 2014 15:05:32 +0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53F3274E.4050204@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> <53E87C66.7000702@oracle.com> <53E93A82.4060101@oracle.com> <53E9441D.8060209@oracle.com> <53F3274E.4050204@oracle.com> Message-ID: <53FDBB7C.90109@oracle.com> On 08/19/2014 02:30 PM, Aleksey Shipilev wrote: > On 08/12/2014 02:30 AM, Vladimir Kozlov wrote: >> You may need to modify Compile::bang_size_in_bytes() and >> LIR_Assembler::bang_size_in_bytes() to bang correct number of pages. Try >> to test with small stacks and see >> test/compiler/uncommontrap/StackOverflowGuardPagesOff.java. >> >> Related problems fixed recently: >> https://bugs.openjdk.java.net/browse/JDK-8026775 >> https://bugs.openjdk.java.net/browse/JDK-8032410 > > Ugh, what a mess. I think I understand the essence for those two issues. > The test you mention there passes on current and patched builds, but > that tells me nothing. > > To fix this properly, I need some guidance. If we are shooting for "lock > addl (%esp, -OFFSET)" for a StoreLoad barrier, does it mean we should > bang for (frame_size + OFFSET) bytes? If so, is this the addition we are > shooting for? > > diff -r 184aac46be1f src/share/vm/c1/c1_LIRAssembler.cpp > --- a/src/share/vm/c1/c1_LIRAssembler.cpp Sun Aug 10 19:38:53 2014 -0700 > +++ b/src/share/vm/c1/c1_LIRAssembler.cpp Tue Aug 19 14:18:12 2014 +0400 > @@ -169,7 +169,7 @@ > // removes the need to bang the stack in the deoptimization blob which > // in turn simplifies stack overflow handling. > int LIR_Assembler::bang_size_in_bytes() const { > - return MAX2(initial_frame_size_in_bytes(), > _compilation->interpreter_frame_size()); > + return MAX2(initial_frame_size_in_bytes() + > VM_Version::L1_line_size(), _compilation->interpreter_frame_size()); > } > > void LIR_Assembler::emit_exception_entries(ExceptionInfoList* info_list) { > diff -r 184aac46be1f src/share/vm/opto/compile.cpp > --- a/src/share/vm/opto/compile.cpp Sun Aug 10 19:38:53 2014 -0700 > +++ b/src/share/vm/opto/compile.cpp Tue Aug 19 14:18:12 2014 +0400 > @@ -430,7 +430,7 @@ > // removes the need to bang the stack in the deoptimization blob which > // in turn simplifies stack overflow handling. > int Compile::bang_size_in_bytes() const { > - return MAX2(_interpreter_frame_size, frame_size_in_bytes()); > + return MAX2(_interpreter_frame_size, frame_size_in_bytes() + > VM_Version::L1_line_size()); > } > > This makes me uneasy for two reasons: > > a) We only need to do this for x86. ifdef'ing the generic > LIR_Assembler/Compile code seems odd. Can we pro-actively bang for an > additional cache line for all platforms? > > b) The cache line size here does seem like a magic number, and I would > like to move the StoreLoad SP offset calculation somewhere -- but where > to? VM_Version seems to be too generic to handle the x86-specific case. > Putting it in assembler(_x86) seems to introduce the artificial > dependency between the machine-neutral and machine-dependent parts of > the compiler. Anyone? -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From igor.ignatyev at oracle.com Wed Aug 27 14:18:52 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 27 Aug 2014 18:18:52 +0400 Subject: RFR(S) : 8056072 : add jprt_optimized targets In-Reply-To: <25C0AC54-276A-49F0-85AA-BC5FA9012A4D@oracle.com> References: <53FC9B17.2060102@oracle.com> <25C0AC54-276A-49F0-85AA-BC5FA9012A4D@oracle.com> Message-ID: <53FDE8CC.5080402@oracle.com> Vladimir/Roland, thank you for review. Igor On 08/27/2014 11:30 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~iignatyev/8056072/webrev.00/ > > That looks good to me. > > Roland. > On 08/26/2014 09:25 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > From vladimir.kozlov at oracle.com Wed Aug 27 17:14:04 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Aug 2014 10:14:04 -0700 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: <53FD8868.3060105@oracle.com> References: <53F70964.4060408@oracle.com> <53F779B6.8060607@oracle.com> <53FB78D1.5020508@oracle.com> <53FB8589.6070700@oracle.com> <53FD8868.3060105@oracle.com> Message-ID: <53FE11DC.5050403@oracle.com> Hi, Zoltan We usually try to avoid assignments in 'if' statements (to avoid confusion between '=' and '==' which bug prone). Please, separate it: + if ((match = scan_flag_and_value(option, line, bytes_read, Otherwise it looks good. Thanks, Vladimir On 8/27/14 12:27 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for the feedback. > > On 08/25/2014 08:50 PM, Vladimir Kozlov wrote: >> You don't need changes in globals.* files now. > > I forgot about those files, sorry. I reverted them now. > >> New access methods should return boolean, this way it will be easier >> to use: >> >> static bool has_option_value(methodHandle method, const char* option, >> intx& value); > > OK, I changed the methods. > >> Why you dup flag: strdup(flag)? >> TypedMethodOptionMatcher() does it already: os::strdup_check_oom(opt). > > You're right, it's unnecessary and I've removed it. > >> Don't assign option(opt) which is replaced immediately: >> >> MethodMatcher(class_name, class_mode, method_name, method_mode, >> signature, next), >> option(opt), _type(BoolType), _value(value) { >> option = os::strdup_check_oom(opt); > > You're right, but I removed that code as you suggested not to specialize > that constructor (please see below). > >> Please, use underscore for '_option' field's name too, even if it was >> not before. > > OK. > >> From what I see the only reason you have TypedMethodOptionMatcher >> constructor specialization is _type(UnknownType) setting. But why you >> are not using your new functions: get_type_for()? You have type >> check before already: strcmp(options, "intx") etc, so only known types >> are used. > > You're right. I removed all specializations of that constructor. > >> Why you need specialization for CompilerOracle::option_value()? > > I changed has_option_value() to a template method and so we have only > one declaration in compilerOracle.hpp. > > But we need to explicitly instantiate the method for all OptionTypes > supported, because the method relies on some data/functionality that is > available only from within CompilerOracle and thus it is not possible > to instantiate it in other compilation units. The explicit > instantiations are in compilerOracle.cpp. > >> scan_flag_and_value() should return 'match' value as >> add_option_string() to be consistent. The success could be checked by >> (match != NULL) as in other cases. > > I changed it. > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8055286/webrev.02/ > > I ran JPRT again. > > Thank you and best regards, > > > Zoltan > >> On 8/25/14 10:56 AM, Zolt?n Maj? wrote: >>> Hi Vladimir, >>> >>> >>> thank you for the feedback. >>> >>> On 08/22/2014 07:11 PM, Vladimir Kozlov wrote: >>>> Sometimes we specify flag which is not declared as global flag in >>>> globals.hpp, for example NoRTMLockEliding. Please, >>>> don't remove such ability: >>> >>> I did not know that, thanks for pointing it out. >>> >>>> >>>> + Flag *declared_flag = Flag::find_flag(flag, strlen(flag)); >>>> >>>> Flags specified in 'option' command do not affect global flags. We >>>> use the same name only for convenience. >>> >>> I removed checking if a flag is declared in globals.hpp. >>> >>> But I think it is important that the type of a flag specified by the >>> user matches the type expected by the compiler >>> (otherwise the compiler could read random values at runtime). The >>> type of a flag is therefore recorded in >>> TypedMethodOptionMatcher and it is checked at runtime (line 381). If >>> the two types do not match for a method m(), the >>> default value of the flag is used for that method. >> >> There is check, strcmp(options, "intx") etc, which guarantees the type >> consistency. >> >>> >>>> Could you move new option code from parse_from_line() method to >>>> separate method()? >>> >>> Yes, I did that. Please see the scan_flag_and_value() function. >> >> Good. >> >>> >>>> Also parts of that code also could be factored out, like codes which >>>> process 'intx' and 'uintx' values - they are very >>>> similar. >>> >>> I tried that, but it is not straightforward, as on some platforms >>> sscanf() does not support format strings created at >>> runtime. Without a common sscanf() call, the two branches are too >>> little similar, but I might be wrong on that. >>> >>> So I decided to leave the code processing intx and uintx values >>> unchanged. I hope that factoring out functionality into >>> the scan_flag_and_value() function made the code already more readable. >> >> Looks good. >> >>> >>>> Use 'Klass' in second line too: >>>> + // (1) CompileCommand=option,Klass::method,flag >>>> + // (2) CompileCommand=option,KLASS::method,type,flag,value >>> >>> Changed that as well. >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~zmajo/8055286/webrev.01/ >>> >>> I ran the JPRT tests again, all pass. >> >> Thanks, >> Vladimir >> >>> >>> Thank you and best regards >>> >>> >>> Zoltan >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/22/14 2:12 AM, Zolt?n Maj? wrote: >>>>> Hi, >>>>> >>>>> >>>>> please review the following patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055286 >>>>> >>>>> Problem: Currently, CompileCommand=option handles only flags of >>>>> type bool. CompileCommand=option should be extended to >>>>> handle numeric types as well. >>>>> >>>>> Solution: This patch adds support for processing flags of type intx >>>>> and uintx (in addition flags of type bool). Support >>>>> for flags of type ccstr and ccstrlist is not added by this patch; >>>>> we can add support for those types when it is needed. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8055286/ >>>>> >>>>> Testing: JPRT, manual testing >>>>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>> > From zoltan.majo at oracle.com Thu Aug 28 08:31:17 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 28 Aug 2014 10:31:17 +0200 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: <53FE11DC.5050403@oracle.com> References: <53F70964.4060408@oracle.com> <53F779B6.8060607@oracle.com> <53FB78D1.5020508@oracle.com> <53FB8589.6070700@oracle.com> <53FD8868.3060105@oracle.com> <53FE11DC.5050403@oracle.com> Message-ID: <53FEE8D5.8020407@oracle.com> Hi Vladimir, On 08/27/2014 07:14 PM, Vladimir Kozlov wrote: > We usually try to avoid assignments in 'if' statements (to avoid > confusion between '=' and '==' which bug prone). Please, separate it: > > + if ((match = scan_flag_and_value(option, line, bytes_read, I changed it. Here is the new webrev: http://cr.openjdk.java.net/~zmajo/8055286/webrev.03/ JPRT runs fine. Thank you! Best regards, Zoltan > > Otherwise it looks good. > > Thanks, > Vladimir > > On 8/27/14 12:27 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> thank you for the feedback. >> >> On 08/25/2014 08:50 PM, Vladimir Kozlov wrote: >>> You don't need changes in globals.* files now. >> >> I forgot about those files, sorry. I reverted them now. >> >>> New access methods should return boolean, this way it will be easier >>> to use: >>> >>> static bool has_option_value(methodHandle method, const char* option, >>> intx& value); >> >> OK, I changed the methods. >> >>> Why you dup flag: strdup(flag)? >>> TypedMethodOptionMatcher() does it already: os::strdup_check_oom(opt). >> >> You're right, it's unnecessary and I've removed it. >> >>> Don't assign option(opt) which is replaced immediately: >>> >>> MethodMatcher(class_name, class_mode, method_name, method_mode, >>> signature, next), >>> option(opt), _type(BoolType), _value(value) { >>> option = os::strdup_check_oom(opt); >> >> You're right, but I removed that code as you suggested not to specialize >> that constructor (please see below). >> >>> Please, use underscore for '_option' field's name too, even if it was >>> not before. >> >> OK. >> >>> From what I see the only reason you have TypedMethodOptionMatcher >>> constructor specialization is _type(UnknownType) setting. But why you >>> are not using your new functions: get_type_for()? You have type >>> check before already: strcmp(options, "intx") etc, so only known types >>> are used. >> >> You're right. I removed all specializations of that constructor. >> >>> Why you need specialization for CompilerOracle::option_value()? >> >> I changed has_option_value() to a template method and so we have only >> one declaration in compilerOracle.hpp. >> >> But we need to explicitly instantiate the method for all OptionTypes >> supported, because the method relies on some data/functionality that is >> available only from within CompilerOracle and thus it is not possible >> to instantiate it in other compilation units. The explicit >> instantiations are in compilerOracle.cpp. >> >>> scan_flag_and_value() should return 'match' value as >>> add_option_string() to be consistent. The success could be checked by >>> (match != NULL) as in other cases. >> >> I changed it. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8055286/webrev.02/ >> >> I ran JPRT again. >> >> Thank you and best regards, >> >> >> Zoltan >> >>> On 8/25/14 10:56 AM, Zolt?n Maj? wrote: >>>> Hi Vladimir, >>>> >>>> >>>> thank you for the feedback. >>>> >>>> On 08/22/2014 07:11 PM, Vladimir Kozlov wrote: >>>>> Sometimes we specify flag which is not declared as global flag in >>>>> globals.hpp, for example NoRTMLockEliding. Please, >>>>> don't remove such ability: >>>> >>>> I did not know that, thanks for pointing it out. >>>> >>>>> >>>>> + Flag *declared_flag = Flag::find_flag(flag, >>>>> strlen(flag)); >>>>> >>>>> Flags specified in 'option' command do not affect global flags. We >>>>> use the same name only for convenience. >>>> >>>> I removed checking if a flag is declared in globals.hpp. >>>> >>>> But I think it is important that the type of a flag specified by the >>>> user matches the type expected by the compiler >>>> (otherwise the compiler could read random values at runtime). The >>>> type of a flag is therefore recorded in >>>> TypedMethodOptionMatcher and it is checked at runtime (line 381). If >>>> the two types do not match for a method m(), the >>>> default value of the flag is used for that method. >>> >>> There is check, strcmp(options, "intx") etc, which guarantees the type >>> consistency. >>> >>>> >>>>> Could you move new option code from parse_from_line() method to >>>>> separate method()? >>>> >>>> Yes, I did that. Please see the scan_flag_and_value() function. >>> >>> Good. >>> >>>> >>>>> Also parts of that code also could be factored out, like codes which >>>>> process 'intx' and 'uintx' values - they are very >>>>> similar. >>>> >>>> I tried that, but it is not straightforward, as on some platforms >>>> sscanf() does not support format strings created at >>>> runtime. Without a common sscanf() call, the two branches are too >>>> little similar, but I might be wrong on that. >>>> >>>> So I decided to leave the code processing intx and uintx values >>>> unchanged. I hope that factoring out functionality into >>>> the scan_flag_and_value() function made the code already more >>>> readable. >>> >>> Looks good. >>> >>>> >>>>> Use 'Klass' in second line too: >>>>> + // (1) CompileCommand=option,Klass::method,flag >>>>> + // (2) CompileCommand=option,KLASS::method,type,flag,value >>>> >>>> Changed that as well. >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8055286/webrev.01/ >>>> >>>> I ran the JPRT tests again, all pass. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thank you and best regards >>>> >>>> >>>> Zoltan >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/22/14 2:12 AM, Zolt?n Maj? wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> please review the following patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055286 >>>>>> >>>>>> Problem: Currently, CompileCommand=option handles only flags of >>>>>> type bool. CompileCommand=option should be extended to >>>>>> handle numeric types as well. >>>>>> >>>>>> Solution: This patch adds support for processing flags of type intx >>>>>> and uintx (in addition flags of type bool). Support >>>>>> for flags of type ccstr and ccstrlist is not added by this patch; >>>>>> we can add support for those types when it is needed. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8055286/ >>>>>> >>>>>> Testing: JPRT, manual testing >>>>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>> >> From igor.ignatyev at oracle.com Thu Aug 28 12:22:03 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 28 Aug 2014 16:22:03 +0400 Subject: RFR(XXS) : 8056223 : typo in export_optimized_jdk Message-ID: <53FF1EEB.4090008@oracle.com> http://cr.openjdk.java.net/~iignatyev/8056223/webrev.00/ 1 line changed: 0 ins; 0 del; 1 mod; Hi all, Please review the patch: Problem: 'export_optimized_jdk' target specifies ALT_EXPORT_PATH as JDK_IMAGE_DIR, as result it exports hotspot to directory for product build instead of optimized one. jbs: https://bugs.openjdk.java.net/browse/JDK-8056223 testing: jprt w/ support of optimized build -- Igor From tobias.hartmann at oracle.com Thu Aug 28 12:24:41 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Aug 2014 14:24:41 +0200 Subject: [9] RFR(S): 8056067: NodeHash debug variables are available in product build Message-ID: <53FF1F89.4070301@oracle.com> Hi, please review the following patch that fixes JDK-8056067. Bug: https://bugs.openjdk.java.net/browse/JDK-8056067 Webrev: http://cr.openjdk.java.net/~thartmann/8056067/webrev.00/ Problem: Some members of NodeHash are only needed in debug/optimized builds but are also available in product. For example, '_grows' is incremented in 'NodeHash::grow' but only accessed for debugging in NodeHash::dump(). Other members like '_look_probes' are only maintained in debug and therefore contain no information in product and optimized (see [1]). Solution: Make variables only available in debug/optimized. Testing: - Checked output of 'java -XX:+PrintCompilation -XX:+PrintOptoStatistics -XX:+Verbose' with fastdebug, optimized and product build - JPRT Thanks, Tobias [1] Output of java -XX:+PrintCompilation -XX:+PrintOptoStatistics -XX:+Verbose fastdebug build: GVN Hash stats: 0 grows to 512 max_size 28/512 ( 5.5% full) 30p/(0h+36m) ( 0.83 probes/lookup) 0p/28i ( 0.00 probes/insert) optimized build: GVN Hash stats: 0 grows to 512 max_size 28/512 ( 5.5% full) 0p/(0h+0m) ( -nan probes/lookup) 0p/28i ( 0.00 probes/insert) The third line of the output shows wrong values with the optimized build. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.r.chase at oracle.com Thu Aug 28 13:28:02 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 28 Aug 2014 09:28:02 -0400 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds In-Reply-To: <53F7E97A.9090006@oracle.com> References: <53F7C88A.8060706@oracle.com> <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> <53F7E97A.9090006@oracle.com> Message-ID: Revised changes: http://cr.openjdk.java.net/~drchase/8054292/webrev-for-leak-checks.12/ Consistent ifdefs around _defunct _code_strings, not _strings isNull now is_null Added extra assert to assign. Added placement-new-constructor call in InterpreterCodelet (to allow that extra assert). Tested fastdebug and not-debug (calls itself ?release?) builds w/ jtreg, fastdebug with PrintAsm enabled. Did 64-hour leak check with KitchenSink; any leaks seem to be below the what?s-currently-compiled noise threshold. Sanity check: is ?optimized build? the default if I just run configure? On 2014-08-22, at 9:08 PM, Vladimir Kozlov wrote: > On 8/22/14 5:43 PM, David Chase wrote: >> >> On 2014-08-22, at 6:47 PM, Vladimir Kozlov wrote: >> >>> There is some missmatch of use #ifdef ASSERT and #ifndef PRODUCT. >>> Please, build 'optimized' JVM in addition to 'product' and 'debug?. >> >> Optimized VM is running my matrix-multiplication experiments happily, will also do jtreg, didn?t JPRT also do that for me? >> I can certainly do jtreg with the optimized build. > > Okay. > >> >>> Seems _defunct field should be DEBUG only since it is checked only in assert. It could be NOT_PRODUCT bu in that case set_null_and_invalidate() should clean both fields under #ifndef PRODUCT. >>> isNull() will return 'true' in NOT_PRODUCT (optimized VM) when assign() may set _strings. >> >> John also wants it to be spelled is_null, and I just overlooked it and use JavaConventions. >> I was planning to have all the probe methods do as little as possible in PRODUCT. >> I agree, _defunct should also be DEBUG (is that the same as ASSERT?) only. > > Yes: > > #ifdef ASSERT > #define DEBUG_ONLY(code) code > >> >>> An other thing I don't like in current code is the same name of _strings fields in both CodeStrings and CodeBuffer. It is difficult to follow which one is accessed in a code. >> >> Do you recommend that I fix that, then? I also did not like this, but thought it was house style. > > It is not "house style". > >> I propose to call the CodeStrings-typed field of CodeBuffer ?_codestrings?. > > Agree. > >>>> One client of CodeBuffers allocates them without running their constructor, >>>> which interfered with enabling the full set of assertions that we might like. >>> >>> It would be nice to fix it - call constructor in that place. Where it is? You can try to do what we do in growableArray: >>> new(&_strings) CodeStrings(). >> >> I?m trying to recreate that failure; it may be Linux-specific (it failed on Linux, but did not fail for me on Mac just now, this seems peculiar and even more unsettling). >> > > Thanks, > Vladimir From roland.westrelin at oracle.com Thu Aug 28 15:37:25 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 28 Aug 2014 17:37:25 +0200 Subject: RFR(XS): 8055946: assert(result == NULL || result->is_oop()) failed: must be oop Message-ID: <39EB809B-AF0D-418C-8AEE-75261D354954@oracle.com> When a frame is popped by JVMTI, we deoptimize the top 2 frames: the top one to pop it, the caller frame so that we can re-execute the invoke. When the caller frame is deoptimized, even if the top frame is expected to return a value, there?s no return value available because execution of the top frame did not complete. http://cr.openjdk.java.net/~roland/8055946/webrev.00/ Roland. From vladimir.kozlov at oracle.com Thu Aug 28 15:45:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Aug 2014 08:45:36 -0700 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: <53FEE8D5.8020407@oracle.com> References: <53F70964.4060408@oracle.com> <53F779B6.8060607@oracle.com> <53FB78D1.5020508@oracle.com> <53FB8589.6070700@oracle.com> <53FD8868.3060105@oracle.com> <53FE11DC.5050403@oracle.com> <53FEE8D5.8020407@oracle.com> Message-ID: <53FF4EA0.5050308@oracle.com> Looks good. Please, ask an other reviewer to look on it to get 2 reviews - changes are not small. Thanks, Vladimir On 8/28/14 1:31 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > On 08/27/2014 07:14 PM, Vladimir Kozlov wrote: >> We usually try to avoid assignments in 'if' statements (to avoid confusion between '=' and '==' which bug prone). >> Please, separate it: >> >> + if ((match = scan_flag_and_value(option, line, bytes_read, > > I changed it. Here is the new webrev: > > http://cr.openjdk.java.net/~zmajo/8055286/webrev.03/ > > JPRT runs fine. > > Thank you! > > Best regards, > > > Zoltan > >> >> Otherwise it looks good. >> >> Thanks, >> Vladimir >> >> On 8/27/14 12:27 AM, Zolt?n Maj? wrote: >>> Hi Vladimir, >>> >>> >>> thank you for the feedback. >>> >>> On 08/25/2014 08:50 PM, Vladimir Kozlov wrote: >>>> You don't need changes in globals.* files now. >>> >>> I forgot about those files, sorry. I reverted them now. >>> >>>> New access methods should return boolean, this way it will be easier >>>> to use: >>>> >>>> static bool has_option_value(methodHandle method, const char* option, >>>> intx& value); >>> >>> OK, I changed the methods. >>> >>>> Why you dup flag: strdup(flag)? >>>> TypedMethodOptionMatcher() does it already: os::strdup_check_oom(opt). >>> >>> You're right, it's unnecessary and I've removed it. >>> >>>> Don't assign option(opt) which is replaced immediately: >>>> >>>> MethodMatcher(class_name, class_mode, method_name, method_mode, >>>> signature, next), >>>> option(opt), _type(BoolType), _value(value) { >>>> option = os::strdup_check_oom(opt); >>> >>> You're right, but I removed that code as you suggested not to specialize >>> that constructor (please see below). >>> >>>> Please, use underscore for '_option' field's name too, even if it was >>>> not before. >>> >>> OK. >>> >>>> From what I see the only reason you have TypedMethodOptionMatcher >>>> constructor specialization is _type(UnknownType) setting. But why you >>>> are not using your new functions: get_type_for()? You have type >>>> check before already: strcmp(options, "intx") etc, so only known types >>>> are used. >>> >>> You're right. I removed all specializations of that constructor. >>> >>>> Why you need specialization for CompilerOracle::option_value()? >>> >>> I changed has_option_value() to a template method and so we have only >>> one declaration in compilerOracle.hpp. >>> >>> But we need to explicitly instantiate the method for all OptionTypes >>> supported, because the method relies on some data/functionality that is >>> available only from within CompilerOracle and thus it is not possible >>> to instantiate it in other compilation units. The explicit >>> instantiations are in compilerOracle.cpp. >>> >>>> scan_flag_and_value() should return 'match' value as >>>> add_option_string() to be consistent. The success could be checked by >>>> (match != NULL) as in other cases. >>> >>> I changed it. >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~zmajo/8055286/webrev.02/ >>> >>> I ran JPRT again. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> On 8/25/14 10:56 AM, Zolt?n Maj? wrote: >>>>> Hi Vladimir, >>>>> >>>>> >>>>> thank you for the feedback. >>>>> >>>>> On 08/22/2014 07:11 PM, Vladimir Kozlov wrote: >>>>>> Sometimes we specify flag which is not declared as global flag in >>>>>> globals.hpp, for example NoRTMLockEliding. Please, >>>>>> don't remove such ability: >>>>> >>>>> I did not know that, thanks for pointing it out. >>>>> >>>>>> >>>>>> + Flag *declared_flag = Flag::find_flag(flag, strlen(flag)); >>>>>> >>>>>> Flags specified in 'option' command do not affect global flags. We >>>>>> use the same name only for convenience. >>>>> >>>>> I removed checking if a flag is declared in globals.hpp. >>>>> >>>>> But I think it is important that the type of a flag specified by the >>>>> user matches the type expected by the compiler >>>>> (otherwise the compiler could read random values at runtime). The >>>>> type of a flag is therefore recorded in >>>>> TypedMethodOptionMatcher and it is checked at runtime (line 381). If >>>>> the two types do not match for a method m(), the >>>>> default value of the flag is used for that method. >>>> >>>> There is check, strcmp(options, "intx") etc, which guarantees the type >>>> consistency. >>>> >>>>> >>>>>> Could you move new option code from parse_from_line() method to >>>>>> separate method()? >>>>> >>>>> Yes, I did that. Please see the scan_flag_and_value() function. >>>> >>>> Good. >>>> >>>>> >>>>>> Also parts of that code also could be factored out, like codes which >>>>>> process 'intx' and 'uintx' values - they are very >>>>>> similar. >>>>> >>>>> I tried that, but it is not straightforward, as on some platforms >>>>> sscanf() does not support format strings created at >>>>> runtime. Without a common sscanf() call, the two branches are too >>>>> little similar, but I might be wrong on that. >>>>> >>>>> So I decided to leave the code processing intx and uintx values >>>>> unchanged. I hope that factoring out functionality into >>>>> the scan_flag_and_value() function made the code already more readable. >>>> >>>> Looks good. >>>> >>>>> >>>>>> Use 'Klass' in second line too: >>>>>> + // (1) CompileCommand=option,Klass::method,flag >>>>>> + // (2) CompileCommand=option,KLASS::method,type,flag,value >>>>> >>>>> Changed that as well. >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8055286/webrev.01/ >>>>> >>>>> I ran the JPRT tests again, all pass. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thank you and best regards >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 8/22/14 2:12 AM, Zolt?n Maj? wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> please review the following patch. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055286 >>>>>>> >>>>>>> Problem: Currently, CompileCommand=option handles only flags of >>>>>>> type bool. CompileCommand=option should be extended to >>>>>>> handle numeric types as well. >>>>>>> >>>>>>> Solution: This patch adds support for processing flags of type intx >>>>>>> and uintx (in addition flags of type bool). Support >>>>>>> for flags of type ccstr and ccstrlist is not added by this patch; >>>>>>> we can add support for those types when it is needed. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8055286/ >>>>>>> >>>>>>> Testing: JPRT, manual testing >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Thu Aug 28 15:49:17 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Aug 2014 08:49:17 -0700 Subject: RFR(XXS) : 8056223 : typo in export_optimized_jdk In-Reply-To: <53FF1EEB.4090008@oracle.com> References: <53FF1EEB.4090008@oracle.com> Message-ID: <53FF4F7D.6050802@oracle.com> Good. Vladimir On 8/28/14 5:22 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8056223/webrev.00/ > 1 line changed: 0 ins; 0 del; 1 mod; > > Hi all, > > Please review the patch: > > Problem: > 'export_optimized_jdk' target specifies ALT_EXPORT_PATH as JDK_IMAGE_DIR, as result it exports hotspot to directory for > product build instead of optimized one. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8056223 > testing: jprt w/ support of optimized build From vladimir.kozlov at oracle.com Thu Aug 28 15:59:22 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Aug 2014 08:59:22 -0700 Subject: RFR(XS): 8055946: assert(result == NULL || result->is_oop()) failed: must be oop In-Reply-To: <39EB809B-AF0D-418C-8AEE-75261D354954@oracle.com> References: <39EB809B-AF0D-418C-8AEE-75261D354954@oracle.com> Message-ID: <53FF51DA.1020304@oracle.com> Looks reasonable. Thanks, Vladimir On 8/28/14 8:37 AM, Roland Westrelin wrote: > When a frame is popped by JVMTI, we deoptimize the top 2 frames: the top one to pop it, the caller frame so that we can re-execute the invoke. When the caller frame is deoptimized, even if the top frame is expected to return a value, there?s no return value available because execution of the top frame did not complete. > > http://cr.openjdk.java.net/~roland/8055946/webrev.00/ > > Roland. > From vladimir.kozlov at oracle.com Thu Aug 28 16:06:57 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Aug 2014 09:06:57 -0700 Subject: [9] RFR(S): 8056067: NodeHash debug variables are available in product build In-Reply-To: <53FF1F89.4070301@oracle.com> References: <53FF1F89.4070301@oracle.com> Message-ID: <53FF53A1.5040503@oracle.com> Changes are good. Thanks, Vladimir On 8/28/14 5:24 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that fixes JDK-8056067. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8056067 > Webrev: http://cr.openjdk.java.net/~thartmann/8056067/webrev.00/ > > Problem: > Some members of NodeHash are only needed in debug/optimized builds but are also available in product. For example, > '_grows' is incremented in 'NodeHash::grow' but only accessed for debugging in NodeHash::dump(). Other members like > '_look_probes' are only maintained in debug and therefore contain no information in product and optimized (see [1]). > > Solution: > Make variables only available in debug/optimized. > > Testing: > - Checked output of 'java -XX:+PrintCompilation -XX:+PrintOptoStatistics -XX:+Verbose' with fastdebug, optimized and > product build > - JPRT > > Thanks, > Tobias > > > [1] > Output of java -XX:+PrintCompilation -XX:+PrintOptoStatistics -XX:+Verbose > > fastdebug build: > GVN Hash stats: 0 grows to 512 max_size > 28/512 ( 5.5% full) > 30p/(0h+36m) ( 0.83 probes/lookup) > 0p/28i ( 0.00 probes/insert) > > optimized build: > GVN Hash stats: 0 grows to 512 max_size > 28/512 ( 5.5% full) > 0p/(0h+0m) ( -nan probes/lookup) > 0p/28i ( 0.00 probes/insert) > > The third line of the output shows wrong values with the optimized build. > From zoltan.majo at oracle.com Thu Aug 28 16:11:27 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 28 Aug 2014 18:11:27 +0200 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: <53FF4EA0.5050308@oracle.com> References: <53F70964.4060408@oracle.com> <53F779B6.8060607@oracle.com> <53FB78D1.5020508@oracle.com> <53FB8589.6070700@oracle.com> <53FD8868.3060105@oracle.com> <53FE11DC.5050403@oracle.com> <53FEE8D5.8020407@oracle.com> <53FF4EA0.5050308@oracle.com> Message-ID: <53FF54AF.3080609@oracle.com> Thank you, Vladimir! I'll ask an other reviewer then. Best regards, Zoltan On 08/28/2014 05:45 PM, Vladimir Kozlov wrote: > Looks good. Please, ask an other reviewer to look on it to get 2 > reviews - changes are not small. > > Thanks, > Vladimir > > > On 8/28/14 1:31 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> On 08/27/2014 07:14 PM, Vladimir Kozlov wrote: >>> We usually try to avoid assignments in 'if' statements (to avoid >>> confusion between '=' and '==' which bug prone). >>> Please, separate it: >>> >>> + if ((match = scan_flag_and_value(option, line, bytes_read, >> >> I changed it. Here is the new webrev: >> >> http://cr.openjdk.java.net/~zmajo/8055286/webrev.03/ >> >> JPRT runs fine. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> Otherwise it looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 8/27/14 12:27 AM, Zolt?n Maj? wrote: >>>> Hi Vladimir, >>>> >>>> >>>> thank you for the feedback. >>>> >>>> On 08/25/2014 08:50 PM, Vladimir Kozlov wrote: >>>>> You don't need changes in globals.* files now. >>>> >>>> I forgot about those files, sorry. I reverted them now. >>>> >>>>> New access methods should return boolean, this way it will be easier >>>>> to use: >>>>> >>>>> static bool has_option_value(methodHandle method, const char* option, >>>>> intx& value); >>>> >>>> OK, I changed the methods. >>>> >>>>> Why you dup flag: strdup(flag)? >>>>> TypedMethodOptionMatcher() does it already: >>>>> os::strdup_check_oom(opt). >>>> >>>> You're right, it's unnecessary and I've removed it. >>>> >>>>> Don't assign option(opt) which is replaced immediately: >>>>> >>>>> MethodMatcher(class_name, class_mode, method_name, method_mode, >>>>> signature, next), >>>>> option(opt), _type(BoolType), _value(value) { >>>>> option = os::strdup_check_oom(opt); >>>> >>>> You're right, but I removed that code as you suggested not to >>>> specialize >>>> that constructor (please see below). >>>> >>>>> Please, use underscore for '_option' field's name too, even if it was >>>>> not before. >>>> >>>> OK. >>>> >>>>> From what I see the only reason you have TypedMethodOptionMatcher >>>>> constructor specialization is _type(UnknownType) setting. But why you >>>>> are not using your new functions: get_type_for()? You have type >>>>> check before already: strcmp(options, "intx") etc, so only known >>>>> types >>>>> are used. >>>> >>>> You're right. I removed all specializations of that constructor. >>>> >>>>> Why you need specialization for CompilerOracle::option_value()? >>>> >>>> I changed has_option_value() to a template method and so we have only >>>> one declaration in compilerOracle.hpp. >>>> >>>> But we need to explicitly instantiate the method for all OptionTypes >>>> supported, because the method relies on some data/functionality >>>> that is >>>> available only from within CompilerOracle and thus it is not possible >>>> to instantiate it in other compilation units. The explicit >>>> instantiations are in compilerOracle.cpp. >>>> >>>>> scan_flag_and_value() should return 'match' value as >>>>> add_option_string() to be consistent. The success could be checked by >>>>> (match != NULL) as in other cases. >>>> >>>> I changed it. >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8055286/webrev.02/ >>>> >>>> I ran JPRT again. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> On 8/25/14 10:56 AM, Zolt?n Maj? wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> >>>>>> thank you for the feedback. >>>>>> >>>>>> On 08/22/2014 07:11 PM, Vladimir Kozlov wrote: >>>>>>> Sometimes we specify flag which is not declared as global flag in >>>>>>> globals.hpp, for example NoRTMLockEliding. Please, >>>>>>> don't remove such ability: >>>>>> >>>>>> I did not know that, thanks for pointing it out. >>>>>> >>>>>>> >>>>>>> + Flag *declared_flag = Flag::find_flag(flag, >>>>>>> strlen(flag)); >>>>>>> >>>>>>> Flags specified in 'option' command do not affect global flags. We >>>>>>> use the same name only for convenience. >>>>>> >>>>>> I removed checking if a flag is declared in globals.hpp. >>>>>> >>>>>> But I think it is important that the type of a flag specified by the >>>>>> user matches the type expected by the compiler >>>>>> (otherwise the compiler could read random values at runtime). The >>>>>> type of a flag is therefore recorded in >>>>>> TypedMethodOptionMatcher and it is checked at runtime (line 381). If >>>>>> the two types do not match for a method m(), the >>>>>> default value of the flag is used for that method. >>>>> >>>>> There is check, strcmp(options, "intx") etc, which guarantees the >>>>> type >>>>> consistency. >>>>> >>>>>> >>>>>>> Could you move new option code from parse_from_line() method to >>>>>>> separate method()? >>>>>> >>>>>> Yes, I did that. Please see the scan_flag_and_value() function. >>>>> >>>>> Good. >>>>> >>>>>> >>>>>>> Also parts of that code also could be factored out, like codes >>>>>>> which >>>>>>> process 'intx' and 'uintx' values - they are very >>>>>>> similar. >>>>>> >>>>>> I tried that, but it is not straightforward, as on some platforms >>>>>> sscanf() does not support format strings created at >>>>>> runtime. Without a common sscanf() call, the two branches are too >>>>>> little similar, but I might be wrong on that. >>>>>> >>>>>> So I decided to leave the code processing intx and uintx values >>>>>> unchanged. I hope that factoring out functionality into >>>>>> the scan_flag_and_value() function made the code already more >>>>>> readable. >>>>> >>>>> Looks good. >>>>> >>>>>> >>>>>>> Use 'Klass' in second line too: >>>>>>> + // (1) CompileCommand=option,Klass::method,flag >>>>>>> + // (2) CompileCommand=option,KLASS::method,type,flag,value >>>>>> >>>>>> Changed that as well. >>>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8055286/webrev.01/ >>>>>> >>>>>> I ran the JPRT tests again, all pass. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Thank you and best regards >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 8/22/14 2:12 AM, Zolt?n Maj? wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> please review the following patch. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055286 >>>>>>>> >>>>>>>> Problem: Currently, CompileCommand=option handles only flags of >>>>>>>> type bool. CompileCommand=option should be extended to >>>>>>>> handle numeric types as well. >>>>>>>> >>>>>>>> Solution: This patch adds support for processing flags of type >>>>>>>> intx >>>>>>>> and uintx (in addition flags of type bool). Support >>>>>>>> for flags of type ccstr and ccstrlist is not added by this patch; >>>>>>>> we can add support for those types when it is needed. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8055286/ >>>>>>>> >>>>>>>> Testing: JPRT, manual testing >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> >>>>>>>> >>>>>>>> Zoltan >>>>>>>> >>>>>> >>>> >> From vladimir.kozlov at oracle.com Thu Aug 28 17:51:04 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Aug 2014 10:51:04 -0700 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds In-Reply-To: References: <53F7C88A.8060706@oracle.com> <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> <53F7E97A.9090006@oracle.com> Message-ID: <53FF6C08.4020007@oracle.com> On 8/28/14 6:28 AM, David Chase wrote: > > Revised changes: http://cr.openjdk.java.net/~drchase/8054292/webrev-for-leak-checks.12/ > > Consistent ifdefs around _defunct > _code_strings, not _strings > isNull now is_null > Added extra assert to assign. The above changes look good. > Added placement-new-constructor call in InterpreterCodelet (to allow that extra assert). This one I am not sure. It could hide potential memory leak when constructor overwrite previously stored _strings values. But I agree that it is the simplest change to enable the assert. And based on what I see in current code it should not cause a leak because we assign default NULL to _strings several times until the final store in ~CodeletMark(). In short, I accept current change but, please, file RFE (starter task) to clean this code. As I said before strings recording for InterpreterCodelet could be done differently (do not do it generally for Stub class). > > Tested fastdebug and not-debug (calls itself ?release?) builds w/ jtreg, fastdebug with PrintAsm enabled. > Did 64-hour leak check with KitchenSink; any leaks seem to be below the what?s-currently-compiled noise threshold. > > Sanity check: is ?optimized build? the default if I just run configure? No, the default is 'product' Hotspot build. I would suggest to build 'optimized' VM separately (it looks like 'optimized' target for whole forest does not work) and test it for leaks. Thanks, Vladimir > > > On 2014-08-22, at 9:08 PM, Vladimir Kozlov wrote: > >> On 8/22/14 5:43 PM, David Chase wrote: >>> >>> On 2014-08-22, at 6:47 PM, Vladimir Kozlov wrote: >>> >>>> There is some missmatch of use #ifdef ASSERT and #ifndef PRODUCT. >>>> Please, build 'optimized' JVM in addition to 'product' and 'debug?. >>> >>> Optimized VM is running my matrix-multiplication experiments happily, will also do jtreg, didn?t JPRT also do that for me? >>> I can certainly do jtreg with the optimized build. >> >> Okay. >> >>> >>>> Seems _defunct field should be DEBUG only since it is checked only in assert. It could be NOT_PRODUCT bu in that case set_null_and_invalidate() should clean both fields under #ifndef PRODUCT. >>>> isNull() will return 'true' in NOT_PRODUCT (optimized VM) when assign() may set _strings. >>> >>> John also wants it to be spelled is_null, and I just overlooked it and use JavaConventions. >>> I was planning to have all the probe methods do as little as possible in PRODUCT. >>> I agree, _defunct should also be DEBUG (is that the same as ASSERT?) only. >> >> Yes: >> >> #ifdef ASSERT >> #define DEBUG_ONLY(code) code >> >>> >>>> An other thing I don't like in current code is the same name of _strings fields in both CodeStrings and CodeBuffer. It is difficult to follow which one is accessed in a code. >>> >>> Do you recommend that I fix that, then? I also did not like this, but thought it was house style. >> >> It is not "house style". >> >>> I propose to call the CodeStrings-typed field of CodeBuffer ?_codestrings?. >> >> Agree. >> >>>>> One client of CodeBuffers allocates them without running their constructor, >>>>> which interfered with enabling the full set of assertions that we might like. >>>> >>>> It would be nice to fix it - call constructor in that place. Where it is? You can try to do what we do in growableArray: >>>> new(&_strings) CodeStrings(). >>> >>> I?m trying to recreate that failure; it may be Linux-specific (it failed on Linux, but did not fail for me on Mac just now, this seems peculiar and even more unsettling). >>> >> >> Thanks, >> Vladimir > From zoltan.majo at oracle.com Thu Aug 28 18:02:34 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 28 Aug 2014 20:02:34 +0200 Subject: [9] RFR(S): 8050407: Add jtreg compiler tests to Hotspot JPRT jobs Message-ID: <53FF6EBA.8070200@oracle.com> Hi, please review the following patch. Bug: Add jtreg compiler tests to Hotspot JPRT jobs Problem: The test/TEST.groups file lists JTREG compiler tests executed in JPRT (target name: 'hotspot_compiler'). We need to determine the list of tests from test/compiler that should be executed in JPRT. The total time of execution should be less than 10 minutes on slowest platform. Solution: The slowest platform in JPRT is currently solaris_sparcv9. I executed all open JTREG tests from test/compiler on solaris_sparcv9 and measured the "work time" of each test. Then, tests were sorted in ascending order of their work time. To construct the subset, I first added the test with the lowest work time to the subset and then continued adding tests until a time limit L is reached. Limit L is set to 80% of the original time budget (10 minutes). L is set conservatively to account also for JPRT "cleanup", "init", and "finishing" time, as well as for the variation of tests' "work time". (The profiling measurements contain only "work time".) The subset contains 77 tests. The longest executing test in the subset takes 6.9 seconds. Webrev: http://cr.openjdk.java.net/~zmajo/8050407/webrev.00/ Testing: Ran subset on all platforms in both west and stockholm JPRT. Execution times of tests are as follows: West: linux_i586-fastdebug-c1-hotspot_compiler success(03m 01s) linux_i586-fastdebug-c2-hotspot_compiler success(03m 39s) linux_x64-fastdebug-c2-hotspot_compiler success(03m 32s) macosx_x64-fastdebug-c2-hotspot_compiler success(03m 48s) solaris_sparcv9-fastdebug-c2-hotspot_compiler success(08m 41s) solaris_x64-fastdebug-c2-hotspot_compiler success(03m 00s) windows_i586-fastdebug-c1-hotspot_compiler success(03m 39s) windows_i586-fastdebug-c2-hotspot_compiler success(03m 54s) windows_x64-fastdebug-c2-hotspot_compiler success(04m 51s) Stockholm: linux_i586-fastdebug-c1-hotspot_compiler success(02m 31s) linux_i586-fastdebug-c2-hotspot_compiler success(02m 39s) linux_x64-fastdebug-c2-hotspot_compiler success(02m 53s) macosx_x64-fastdebug-c2-hotspot_compiler success(04m 10s) solaris_sparcv9-fastdebug-c2-hotspot_compiler success(05m 55s) solaris_x64-fastdebug-c2-hotspot_compiler success(03m 06s) windows_i586-fastdebug-c1-hotspot_compiler success(02m 34s) windows_i586-fastdebug-c2-hotspot_compiler success(03m 07s) windows_x64-fastdebug-c2-hotspot_compiler success(04m 33s) We get close to the 10 minute budget (87% usage on West for solaris_sparcv9). Thank you and best regards, Zoltan From christian.thalinger at oracle.com Thu Aug 28 18:06:34 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 28 Aug 2014 11:06:34 -0700 Subject: RFR(XS): 8055946: assert(result == NULL || result->is_oop()) failed: must be oop In-Reply-To: <39EB809B-AF0D-418C-8AEE-75261D354954@oracle.com> References: <39EB809B-AF0D-418C-8AEE-75261D354954@oracle.com> Message-ID: The comment is awkward: + // If we the previous was popped, we don't have a result On Aug 28, 2014, at 8:37 AM, Roland Westrelin wrote: > When a frame is popped by JVMTI, we deoptimize the top 2 frames: the top one to pop it, the caller frame so that we can re-execute the invoke. When the caller frame is deoptimized, even if the top frame is expected to return a value, there?s no return value available because execution of the top frame did not complete. > > http://cr.openjdk.java.net/~roland/8055946/webrev.00/ > > Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Thu Aug 28 18:43:13 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 28 Aug 2014 20:43:13 +0200 Subject: RFR(XS): 8055946: assert(result == NULL || result->is_oop()) failed: must be oop In-Reply-To: References: <39EB809B-AF0D-418C-8AEE-75261D354954@oracle.com> Message-ID: > The comment is awkward: > > + // If we the previous was popped, we don't have a result Thanks for spotting that. I?ll fix the comment. Can I consider this as a review? Roland. From david.r.chase at oracle.com Thu Aug 28 18:46:19 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 28 Aug 2014 14:46:19 -0400 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds In-Reply-To: <53FF6C08.4020007@oracle.com> References: <53F7C88A.8060706@oracle.com> <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> <53F7E97A.9090006@oracle.com> <53FF6C08.4020007@oracle.com> Message-ID: <3B65E069-6D39-4952-8A3F-8261250B470E@oracle.com> On 2014-08-28, at 1:51 PM, Vladimir Kozlov wrote: >> >> Sanity check: is ?optimized build? the default if I just run configure? > > No, the default is 'product' Hotspot build. I would suggest to build 'optimized' VM separately (it looks like 'optimized' target for whole forest does not work) and test it for leaks. What?s the incantation for optimized build that is not whole-forest? I?ve been doing new-build so long I?ve forgotten the incantations for hotspot-only. Or is this in the Wiki? (I?m WFH today, the better to torture my children.) David From vladimir.kozlov at oracle.com Thu Aug 28 18:55:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Aug 2014 11:55:20 -0700 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds In-Reply-To: <3B65E069-6D39-4952-8A3F-8261250B470E@oracle.com> References: <53F7C88A.8060706@oracle.com> <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> <53F7E97A.9090006@oracle.com> <53FF6C08.4020007@oracle.com> <3B65E069-6D39-4952-8A3F-8261250B470E@oracle.com> Message-ID: <53FF7B18.3020101@oracle.com> In hotspot/make directory: make optimized LP64=1 Vladimir On 8/28/14 11:46 AM, David Chase wrote: > > On 2014-08-28, at 1:51 PM, Vladimir Kozlov wrote: >>> >>> Sanity check: is ?optimized build? the default if I just run configure? >> >> No, the default is 'product' Hotspot build. I would suggest to build 'optimized' VM separately (it looks like 'optimized' target for whole forest does not work) and test it for leaks. > > What?s the incantation for optimized build that is not whole-forest? I?ve been doing new-build so long I?ve forgotten the incantations for hotspot-only. Or is this in the Wiki? (I?m WFH today, the better to torture my children.) > > David > From igor.ignatyev at oracle.com Thu Aug 28 19:29:38 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 28 Aug 2014 23:29:38 +0400 Subject: RFR(XXS) : 8056223 : typo in export_optimized_jdk In-Reply-To: <53FF4F7D.6050802@oracle.com> References: <53FF1EEB.4090008@oracle.com> <53FF4F7D.6050802@oracle.com> Message-ID: <53FF8322.6050009@oracle.com> Vladimir, thanks for review. Igor On 08/28/2014 07:49 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 8/28/14 5:22 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8056223/webrev.00/ >> 1 line changed: 0 ins; 0 del; 1 mod; >> >> Hi all, >> >> Please review the patch: >> >> Problem: >> 'export_optimized_jdk' target specifies ALT_EXPORT_PATH as >> JDK_IMAGE_DIR, as result it exports hotspot to directory for >> product build instead of optimized one. >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8056223 >> testing: jprt w/ support of optimized build From john.r.rose at oracle.com Thu Aug 28 21:41:12 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 28 Aug 2014 14:41:12 -0700 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53F3274E.4050204@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> <53E87C66.7000702@oracle.com> <53E93A82.4060101@oracle.com> <53E9441D.8060209@oracle.com> <53F3274E.4050204@oracle.com> Message-ID: <773795D4-A960-4313-A01D-079D8C967050@oracle.com> On Aug 19, 2014, at 3:30 AM, Aleksey Shipilev wrote: > Thanks, Vladimir. > > Coming back to this... > > On 08/12/2014 02:30 AM, Vladimir Kozlov wrote: >> You may need to modify Compile::bang_size_in_bytes() and >> LIR_Assembler::bang_size_in_bytes() to bang correct number of pages. Try >> to test with small stacks and see >> test/compiler/uncommontrap/StackOverflowGuardPagesOff.java. >> >> Related problems fixed recently: >> https://bugs.openjdk.java.net/browse/JDK-8026775 >> https://bugs.openjdk.java.net/browse/JDK-8032410 > > Ugh, what a mess. I think I understand the essence for those two issues. > The test you mention there passes on current and patched builds, but > that tells me nothing. > > To fix this properly, I need some guidance. If we are shooting for "lock > addl (%esp, -OFFSET)" for a StoreLoad barrier, does it mean we should > bang for (frame_size + OFFSET) bytes? If so, is this the addition we are > shooting for? > > diff -r 184aac46be1f src/share/vm/c1/c1_LIRAssembler.cpp > --- a/src/share/vm/c1/c1_LIRAssembler.cpp Sun Aug 10 19:38:53 2014 -0700 > +++ b/src/share/vm/c1/c1_LIRAssembler.cpp Tue Aug 19 14:18:12 2014 +0400 > @@ -169,7 +169,7 @@ > // removes the need to bang the stack in the deoptimization blob which > // in turn simplifies stack overflow handling. > int LIR_Assembler::bang_size_in_bytes() const { > - return MAX2(initial_frame_size_in_bytes(), > _compilation->interpreter_frame_size()); > + return MAX2(initial_frame_size_in_bytes() + > VM_Version::L1_line_size(), _compilation->interpreter_frame_size()); > } > > void LIR_Assembler::emit_exception_entries(ExceptionInfoList* info_list) { > diff -r 184aac46be1f src/share/vm/opto/compile.cpp > --- a/src/share/vm/opto/compile.cpp Sun Aug 10 19:38:53 2014 -0700 > +++ b/src/share/vm/opto/compile.cpp Tue Aug 19 14:18:12 2014 +0400 > @@ -430,7 +430,7 @@ > // removes the need to bang the stack in the deoptimization blob which > // in turn simplifies stack overflow handling. > int Compile::bang_size_in_bytes() const { > - return MAX2(_interpreter_frame_size, frame_size_in_bytes()); > + return MAX2(_interpreter_frame_size, frame_size_in_bytes() + > VM_Version::L1_line_size()); > } > > This makes me uneasy for two reasons: > > a) We only need to do this for x86. ifdef'ing the generic > LIR_Assembler/Compile code seems odd. Can we pro-actively bang for an > additional cache line for all platforms? I do think we could do this, although there are ways it could bite us later. It would need a comment saying that it matters for x86, and is thought to be harmless for other chips. That way if someone wants to change it later on they will know the constraints. But, to be more verbose but also more future-proof, let's add another function to these files: hotspot/src/os_cpu/*/vm/os_*.hpp /* amount beyond the callee frame size that we bang the stack; see JDK-@@ */ static int extra_bang_size_in_bytes() { return VM_Version::L1_line_size(); } > b) The cache line size here does seem like a magic number, and I would > like to move the StoreLoad SP offset calculation somewhere -- but where > to? VM_Version seems to be too generic to handle the x86-specific case. > Putting it in assembler(_x86) seems to introduce the artificial > dependency between the machine-neutral and machine-dependent parts of > the compiler. The function above could easily couple to x86-specific logic. ? John From aleksey.shipilev at oracle.com Thu Aug 28 21:49:02 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 29 Aug 2014 01:49:02 +0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <773795D4-A960-4313-A01D-079D8C967050@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> <53E87C66.7000702@oracle.com> <53E93A82.4060101@oracle.com> <53E9441D.8060209@oracle.com> <53F3274E.4050204@oracle.com> <773795D4-A960-4313-A01D-079D8C967050@oracle.com> Message-ID: <53FFA3CE.4040401@oracle.com> On 08/29/2014 01:41 AM, John Rose wrote: >> This makes me uneasy for two reasons: >> >> a) We only need to do this for x86. ifdef'ing the generic >> LIR_Assembler/Compile code seems odd. Can we pro-actively bang for an >> additional cache line for all platforms? > > I do think we could do this, although there are ways it could bite us later. > > It would need a comment saying that it matters for x86, and is thought to be harmless for other chips. That way if someone wants to change it later on they will know the constraints. > > But, to be more verbose but also more future-proof, let's add another function to these files: > hotspot/src/os_cpu/*/vm/os_*.hpp > > /* amount beyond the callee frame size that we bang the stack; see JDK-@@ */ > static int extra_bang_size_in_bytes() { return VM_Version::L1_line_size(); } > >> b) The cache line size here does seem like a magic number, and I would >> like to move the StoreLoad SP offset calculation somewhere -- but where >> to? VM_Version seems to be too generic to handle the x86-specific case. >> Putting it in assembler(_x86) seems to introduce the artificial >> dependency between the machine-neutral and machine-dependent parts of >> the compiler. > > The function above could easily couple to x86-specific logic. That's a nice suggestion! Let me try that. Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Fri Aug 29 08:01:15 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Aug 2014 10:01:15 +0200 Subject: [9] RFR(S): 8056067: NodeHash debug variables are available in product build In-Reply-To: <53FF53A1.5040503@oracle.com> References: <53FF1F89.4070301@oracle.com> <53FF53A1.5040503@oracle.com> Message-ID: <5400334B.3030805@oracle.com> Thank you, Vladimir. Best, Tobias On 28.08.2014 18:06, Vladimir Kozlov wrote: > Changes are good. > > Thanks, > Vladimir > > On 8/28/14 5:24 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch that fixes JDK-8056067. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8056067 >> Webrev: http://cr.openjdk.java.net/~thartmann/8056067/webrev.00/ >> >> Problem: >> Some members of NodeHash are only needed in debug/optimized builds >> but are also available in product. For example, >> '_grows' is incremented in 'NodeHash::grow' but only accessed for >> debugging in NodeHash::dump(). Other members like >> '_look_probes' are only maintained in debug and therefore contain no >> information in product and optimized (see [1]). >> >> Solution: >> Make variables only available in debug/optimized. >> >> Testing: >> - Checked output of 'java -XX:+PrintCompilation >> -XX:+PrintOptoStatistics -XX:+Verbose' with fastdebug, optimized and >> product build >> - JPRT >> >> Thanks, >> Tobias >> >> >> [1] >> Output of java -XX:+PrintCompilation -XX:+PrintOptoStatistics >> -XX:+Verbose >> >> fastdebug build: >> GVN Hash stats: 0 grows to 512 max_size >> 28/512 ( 5.5% full) >> 30p/(0h+36m) ( 0.83 probes/lookup) >> 0p/28i ( 0.00 probes/insert) >> >> optimized build: >> GVN Hash stats: 0 grows to 512 max_size >> 28/512 ( 5.5% full) >> 0p/(0h+0m) ( -nan probes/lookup) >> 0p/28i ( 0.00 probes/insert) >> >> The third line of the output shows wrong values with the optimized >> build. >> From staffan.larsen at oracle.com Fri Aug 29 11:27:56 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 29 Aug 2014 13:27:56 +0200 Subject: RFR: 8055838 Hotspot does not compile with clang 6.0 (OS X Yosemite) In-Reply-To: <53FC7988.5030403@oracle.com> References: <53FC7988.5030403@oracle.com> Message-ID: <0FF23942-F831-4F0F-B8DA-BD68EA817F37@oracle.com> Thanks for the pointer, Lois. I have verified that the knockdown of unsafe.cpp is still necessary using the jdk/test/sun/misc/CopyMemory.java test from that bug report. /Staffan On 26 aug 2014, at 14:11, Lois Foltan wrote: > Hi Staffan, > I think this looks good. I added the knock down of unsafe.o for clang 4.6.2. See https://bugs.openjdk.java.net/browse/JDK-8022407 for the original test causing the issue. > Lois > > On 8/26/2014 5:47 AM, Staffan Larsen wrote: >> There is a check in the makefiles to lower the optimization level for some files on some versions of clang . This check needs to take clang 6.0 into account (which is the default compiler on OS X Yosemite). The straightforward fix is below. I have verified this by running the hotspot/compiler tests. With the higher optimization level, a couple of tests fail in compiler/5091921. With the lower optimization level these tests pass. So it seems the fix is still needed for clang 6.0. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8055838 >> >> Thanks, >> /Staffan >> >> >> diff -r 8e575cec7af9 make/bsd/makefiles/gcc.make >> --- a/make/bsd/makefiles/gcc.make Tue Aug 19 11:17:44 2014 -0700 >> +++ b/make/bsd/makefiles/gcc.make Fri Aug 22 19:06:41 2014 +0200 >> @@ -325,6 +325,10 @@ >> else ifeq ($(shell expr $(CC_VER_MAJOR) = 5 \& $(CC_VER_MINOR) = 1), 1) >> OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >> OPT_CFLAGS/unsafe.o += -O1 >> + # Clang 6.0 >> + else ifeq ($(shell expr $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) = 0), 1) >> + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >> + OPT_CFLAGS/unsafe.o += -O1 >> else >> $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") >> endif > From roland.westrelin at oracle.com Fri Aug 29 12:02:00 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 29 Aug 2014 14:02:00 +0200 Subject: [9] RFR(S): 8056067: NodeHash debug variables are available in product build In-Reply-To: <53FF1F89.4070301@oracle.com> References: <53FF1F89.4070301@oracle.com> Message-ID: > Webrev: http://cr.openjdk.java.net/~thartmann/8056067/webrev.00/ That looks good to me. Roland. From tobias.hartmann at oracle.com Fri Aug 29 12:02:44 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Aug 2014 14:02:44 +0200 Subject: [9] RFR(S): 8056067: NodeHash debug variables are available in product build In-Reply-To: References: <53FF1F89.4070301@oracle.com> Message-ID: <54006BE4.6080703@oracle.com> Thanks, Roland. Best, Tobias On 29.08.2014 14:02, Roland Westrelin wrote: >> Webrev: http://cr.openjdk.java.net/~thartmann/8056067/webrev.00/ > That looks good to me. > > Roland. From roland.westrelin at oracle.com Fri Aug 29 12:58:41 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 29 Aug 2014 14:58:41 +0200 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: <53FEE8D5.8020407@oracle.com> References: <53F70964.4060408@oracle.com> <53F779B6.8060607@oracle.com> <53FB78D1.5020508@oracle.com> <53FB8589.6070700@oracle.com> <53FD8868.3060105@oracle.com> <53FE11DC.5050403@oracle.com> <53FEE8D5.8020407@oracle.com> Message-ID: > http://cr.openjdk.java.net/~zmajo/8055286/webrev.03/ 182 static OptionType get_type_for(void) { 186 template<> OptionType get_type_for(void) { ?void? is not needed here I assume. Can you remove it? No need for an updated webrev. That looks good to me. Roland. From zoltan.majo at oracle.com Fri Aug 29 13:21:24 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Fri, 29 Aug 2014 15:21:24 +0200 Subject: [9] RFR(S): 8055286: Extend CompileCommand=option to handle numeric parameters In-Reply-To: References: <53F70964.4060408@oracle.com> <53F779B6.8060607@oracle.com> <53FB78D1.5020508@oracle.com> <53FB8589.6070700@oracle.com> <53FD8868.3060105@oracle.com> <53FE11DC.5050403@oracle.com> <53FEE8D5.8020407@oracle.com> Message-ID: <54007E54.4030702@oracle.com> Hi Roland, thank you for providing the second review. On 08/29/2014 02:58 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~zmajo/8055286/webrev.03/ > 182 static OptionType get_type_for(void) { > 186 template<> OptionType get_type_for(void) { > > ?void? is not needed here I assume. Can you remove it? No need for an updated webrev. You are right. I removed "void" at both places. Best regards, Zoltan From filipp.zhinkin at oracle.com Fri Aug 29 14:37:03 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 29 Aug 2014 18:37:03 +0400 Subject: [9] RFR (S): JDK-8056091: Move compiler/intrinsics/mathexact/sanity/Verifier to compiler/testlibrary and extend its functionality Message-ID: <5400900F.6010301@oracle.com> Hi all, please review the fix for JDK-8056091. The intent of this change is to extend Verifier used by mathexact sanity tests so it will be possible to verify not only exact count of emitted intrinsics, but alsojust a fact that an intrinsic was emitted. All tests that use Verifier were updated as well. This change is required for sanity tests on SHA intrinsics. Bug id: https://bugs.openjdk.java.net/browse/JDK-8056091 Webrev:http://cr.openjdk.java.net/~fzhinkin/8056091/webrev.00/ Testing: manual, automated using compiler/intrinsics/mathexact/sanity tests. Thanks, Filipp. From filipp.zhinkin at oracle.com Fri Aug 29 14:45:48 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 29 Aug 2014 18:45:48 +0400 Subject: [9] RFR (L): JDK-8055903: Develop sanity tests on SPARC's SHA instructions support Message-ID: <5400921C.3050001@oracle.com> Hi all, please review sanity tests on SHA intrinsics support. Tests verify that appropriate intrinsic is emitted whencorresponding option is enabled and not emitted ifsuch option is disabled. In case when CPU does not support required instructions or JVM configuration does not allow to use an intrinsic, the test will expect that intrinsic will not be emitted. Bug id: https://bugs.openjdk.java.net/browse/JDK-8055903 Webrev: http://cr.openjdk.java.net/~fzhinkin/8055903/webrev.00/ Testing: manual, automated. Thanks, Filipp. From filipp.zhinkin at oracle.com Fri Aug 29 15:10:22 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 29 Aug 2014 19:10:22 +0400 Subject: [9] RFR (L): JDK-8055903: Develop sanity tests on SPARC's SHA instructions support In-Reply-To: <5400921C.3050001@oracle.com> References: <5400921C.3050001@oracle.com> Message-ID: <540097DE.7040707@oracle.com> Small note: This change is depend on the fix for JDK-8056091 [1]. RFR for JDK-8056091 [2] was sent just before this one. Regards, Filipp. [1] https://bugs.openjdk.java.net/browse/JDK-8056091 [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-August/015336.html On 29.08.2014 18:45, Filipp Zhinkin wrote: > Hi all, > > please review sanity tests on SHA intrinsics support. > > Tests verify that appropriate intrinsic is emitted whencorresponding > option is enabled and not emitted ifsuch option is disabled. > > In case when CPU does not support required instructions or > JVM configuration does not allow to use an intrinsic, > the test will expect that intrinsic will not be emitted. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8055903 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8055903/webrev.00/ > Testing: manual, automated. > > Thanks, > Filipp. From aleksey.shipilev at oracle.com Fri Aug 29 15:45:46 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 29 Aug 2014 19:45:46 +0400 Subject: RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages In-Reply-To: <53FFA3CE.4040401@oracle.com> References: <53CED9BB.4000007@oracle.com> <53D0013B.4090603@oracle.com> <5124BD42-1077-4079-B910-4CBDB69A1AC7@oracle.com> <53E3FC46.3000008@oracle.com> <8564E61B-4A61-4B9B-9C82-8EA95BECE6BC@oracle.com> <53E4BBFE.20705@oracle.com> <3AA1A6B1-4B5A-420B-A149-CAF49622E5B4@oracle.com> <53E87C66.7000702@oracle.com> <53E93A82.4060101@oracle.com> <53E9441D.8060209@oracle.com> <53F3274E.4050204@oracle.com> <773795D4-A960-4313-A01D-079D8C967050@oracle.com> <53FFA3CE.4040401@oracle.com> Message-ID: <5400A02A.6060102@oracle.com> On 08/29/2014 01:49 AM, Aleksey Shipilev wrote: > On 08/29/2014 01:41 AM, John Rose wrote: >>> This makes me uneasy for two reasons: >>> >>> a) We only need to do this for x86. ifdef'ing the generic >>> LIR_Assembler/Compile code seems odd. Can we pro-actively bang for an >>> additional cache line for all platforms? >> >> I do think we could do this, although there are ways it could bite us later. >> >> It would need a comment saying that it matters for x86, and is thought to be harmless for other chips. That way if someone wants to change it later on they will know the constraints. >> >> But, to be more verbose but also more future-proof, let's add another function to these files: >> hotspot/src/os_cpu/*/vm/os_*.hpp >> >> /* amount beyond the callee frame size that we bang the stack; see JDK-@@ */ >> static int extra_bang_size_in_bytes() { return VM_Version::L1_line_size(); } >> >>> b) The cache line size here does seem like a magic number, and I would >>> like to move the StoreLoad SP offset calculation somewhere -- but where >>> to? VM_Version seems to be too generic to handle the x86-specific case. >>> Putting it in assembler(_x86) seems to introduce the artificial >>> dependency between the machine-neutral and machine-dependent parts of >>> the compiler. >> >> The function above could easily couple to x86-specific logic. > > That's a nice suggestion! Let me try that. There you go, please review: http://cr.openjdk.java.net/~shade/8050147/webrev.05/ This webrev passes the full JPRT smoke tests on all platforms (trivial changes in closed code are required), and the performance improvement on microbenchmarks is still there. Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From vladimir.kozlov at oracle.com Fri Aug 29 16:16:34 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Aug 2014 09:16:34 -0700 Subject: [9] RFR (S): JDK-8056091: Move compiler/intrinsics/mathexact/sanity/Verifier to compiler/testlibrary and extend its functionality In-Reply-To: <5400900F.6010301@oracle.com> References: <5400900F.6010301@oracle.com> Message-ID: <5400A762.9080602@oracle.com> Seems fine. Thanks, Vladimir On 8/29/14 7:37 AM, Filipp Zhinkin wrote: > Hi all, > > please review the fix for JDK-8056091. > > The intent of this change is to extend Verifier used by mathexact sanity tests > so it will be possible to verify not only exact count of emitted intrinsics, > but alsojust a fact that an intrinsic was emitted. > > All tests that use Verifier were updated as well. > > This change is required for sanity tests on SHA intrinsics. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8056091 > Webrev:http://cr.openjdk.java.net/~fzhinkin/8056091/webrev.00/ > Testing: manual, automated using compiler/intrinsics/mathexact/sanity tests. > > Thanks, > Filipp. From filipp.zhinkin at oracle.com Fri Aug 29 16:26:45 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 29 Aug 2014 20:26:45 +0400 Subject: [9] RFR (S): JDK-8056091: Move compiler/intrinsics/mathexact/sanity/Verifier to compiler/testlibrary and extend its functionality In-Reply-To: <5400A762.9080602@oracle.com> References: <5400900F.6010301@oracle.com> <5400A762.9080602@oracle.com> Message-ID: <5400A9C5.2030003@oracle.com> Vladimir, thank you for the review. Filipp. On 29.08.2014 20:16, Vladimir Kozlov wrote: > Seems fine. > > Thanks, > Vladimir > > On 8/29/14 7:37 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review the fix for JDK-8056091. >> >> The intent of this change is to extend Verifier used by mathexact >> sanity tests >> so it will be possible to verify not only exact count of emitted >> intrinsics, >> but alsojust a fact that an intrinsic was emitted. >> >> All tests that use Verifier were updated as well. >> >> This change is required for sanity tests on SHA intrinsics. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8056091 >> Webrev:http://cr.openjdk.java.net/~fzhinkin/8056091/webrev.00/ >> Testing: manual, automated using compiler/intrinsics/mathexact/sanity >> tests. >> >> Thanks, >> Filipp. From vladimir.kozlov at oracle.com Fri Aug 29 16:32:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Aug 2014 09:32:42 -0700 Subject: [9] RFR (L): JDK-8055903: Develop sanity tests on SPARC's SHA instructions support In-Reply-To: <5400921C.3050001@oracle.com> References: <5400921C.3050001@oracle.com> Message-ID: <5400AB2A.60308@oracle.com> So it is mostly verification that intrinsic is used. The code looks fine. But what about testing that intrinsic produce correct data? Thanks, Vladimir On 8/29/14 7:45 AM, Filipp Zhinkin wrote: > Hi all, > > please review sanity tests on SHA intrinsics support. > > Tests verify that appropriate intrinsic is emitted whencorresponding > option is enabled and not emitted ifsuch option is disabled. > > In case when CPU does not support required instructions or > JVM configuration does not allow to use an intrinsic, > the test will expect that intrinsic will not be emitted. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8055903 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8055903/webrev.00/ > Testing: manual, automated. > > Thanks, > Filipp. From filipp.zhinkin at oracle.com Fri Aug 29 16:37:31 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 29 Aug 2014 20:37:31 +0400 Subject: [9] RFR (L): JDK-8055903: Develop sanity tests on SPARC's SHA instructions support In-Reply-To: <5400AB2A.60308@oracle.com> References: <5400921C.3050001@oracle.com> <5400AB2A.60308@oracle.com> Message-ID: <5400AC4B.3030100@oracle.com> Vladimir, On 29.08.2014 20:32, Vladimir Kozlov wrote: > So it is mostly verification that intrinsic is used. Right. > The code looks fine. > But what about testing that intrinsic produce correct data? It is done by compiler/intrinsics/sha/TestSHA.java test: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/3a2d373abcab/test/compiler/intrinsics/sha/TestSHA.java#l104 Thanks, Filipp. > > Thanks, > Vladimir > > On 8/29/14 7:45 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review sanity tests on SHA intrinsics support. >> >> Tests verify that appropriate intrinsic is emitted whencorresponding >> option is enabled and not emitted ifsuch option is disabled. >> >> In case when CPU does not support required instructions or >> JVM configuration does not allow to use an intrinsic, >> the test will expect that intrinsic will not be emitted. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8055903 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8055903/webrev.00/ >> Testing: manual, automated. >> >> Thanks, >> Filipp. From vladimir.kozlov at oracle.com Fri Aug 29 16:43:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Aug 2014 09:43:00 -0700 Subject: [9] RFR (L): JDK-8055903: Develop sanity tests on SPARC's SHA instructions support In-Reply-To: <5400AC4B.3030100@oracle.com> References: <5400921C.3050001@oracle.com> <5400AB2A.60308@oracle.com> <5400AC4B.3030100@oracle.com> Message-ID: <5400AD94.5010309@oracle.com> On 8/29/14 9:37 AM, Filipp Zhinkin wrote: > Vladimir, > > On 29.08.2014 20:32, Vladimir Kozlov wrote: >> So it is mostly verification that intrinsic is used. > Right. >> The code looks fine. >> But what about testing that intrinsic produce correct data? > It is done by compiler/intrinsics/sha/TestSHA.java test: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/3a2d373abcab/test/compiler/intrinsics/sha/TestSHA.java#l104 I know about this test but I though we may not cover all cases. Did you evaluate it? I am fine if you think that everything is covered. Thanks, Vladimir > > Thanks, > Filipp. >> >> Thanks, >> Vladimir >> >> On 8/29/14 7:45 AM, Filipp Zhinkin wrote: >>> Hi all, >>> >>> please review sanity tests on SHA intrinsics support. >>> >>> Tests verify that appropriate intrinsic is emitted whencorresponding >>> option is enabled and not emitted ifsuch option is disabled. >>> >>> In case when CPU does not support required instructions or >>> JVM configuration does not allow to use an intrinsic, >>> the test will expect that intrinsic will not be emitted. >>> >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8055903 >>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8055903/webrev.00/ >>> Testing: manual, automated. >>> >>> Thanks, >>> Filipp. > From filipp.zhinkin at oracle.com Fri Aug 29 18:13:36 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 29 Aug 2014 22:13:36 +0400 Subject: [9] RFR (L): JDK-8055903: Develop sanity tests on SPARC's SHA instructions support In-Reply-To: <5400AD94.5010309@oracle.com> References: <5400921C.3050001@oracle.com> <5400AB2A.60308@oracle.com> <5400AC4B.3030100@oracle.com> <5400AD94.5010309@oracle.com> Message-ID: <5400C2D0.90400@oracle.com> On 29.08.2014 20:43, Vladimir Kozlov wrote: > On 8/29/14 9:37 AM, Filipp Zhinkin wrote: >> Vladimir, >> >> On 29.08.2014 20:32, Vladimir Kozlov wrote: >>> So it is mostly verification that intrinsic is used. >> Right. >>> The code looks fine. >>> But what about testing that intrinsic produce correct data? >> It is done by compiler/intrinsics/sha/TestSHA.java test: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/3a2d373abcab/test/compiler/intrinsics/sha/TestSHA.java#l104 >> > > I know about this test but I though we may not cover all cases. > Did you evaluate it? I am fine if you think that everything is covered. Originally I was concerned by the fact that this test use messages of fixed size. However, while the multi-block intrinsic (_digestBase_implCompressMB) will be used to compute the digest for almost all blocks, a single block intrinsic (_sha*_implCompress) still will be used to compute the digest of the final block, thus if one of this intrinsics compute the digest incorrectly, then the overall result will be incorrect. Sanity tests invoke TestSHA::testSHA, so it is covered with different combinations of UseSHA & UseSHA*Intrinsics. Also, there a lot of JDK tests which verify that different security algorithms which use SHA* message digests work well. And there is sun/security/provider/MessageDigest/DigestKAT.java test, which compares message digest computed using SHA* algorithms with precomputed values. So I believe that there is no need to develop additional tests. Thanks, Filipp. > > Thanks, > Vladimir > >> >> Thanks, >> Filipp. >>> >>> Thanks, >>> Vladimir >>> >>> On 8/29/14 7:45 AM, Filipp Zhinkin wrote: >>>> Hi all, >>>> >>>> please review sanity tests on SHA intrinsics support. >>>> >>>> Tests verify that appropriate intrinsic is emitted whencorresponding >>>> option is enabled and not emitted ifsuch option is disabled. >>>> >>>> In case when CPU does not support required instructions or >>>> JVM configuration does not allow to use an intrinsic, >>>> the test will expect that intrinsic will not be emitted. >>>> >>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8055903 >>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8055903/webrev.00/ >>>> Testing: manual, automated. >>>> >>>> Thanks, >>>> Filipp. >> From vladimir.kozlov at oracle.com Fri Aug 29 18:31:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Aug 2014 11:31:20 -0700 Subject: [9] RFR (L): JDK-8055903: Develop sanity tests on SPARC's SHA instructions support In-Reply-To: <5400C2D0.90400@oracle.com> References: <5400921C.3050001@oracle.com> <5400AB2A.60308@oracle.com> <5400AC4B.3030100@oracle.com> <5400AD94.5010309@oracle.com> <5400C2D0.90400@oracle.com> Message-ID: <5400C6F8.1070706@oracle.com> On 8/29/14 11:13 AM, Filipp Zhinkin wrote: > > On 29.08.2014 20:43, Vladimir Kozlov wrote: >> On 8/29/14 9:37 AM, Filipp Zhinkin wrote: >>> Vladimir, >>> >>> On 29.08.2014 20:32, Vladimir Kozlov wrote: >>>> So it is mostly verification that intrinsic is used. >>> Right. >>>> The code looks fine. >>>> But what about testing that intrinsic produce correct data? >>> It is done by compiler/intrinsics/sha/TestSHA.java test: >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/3a2d373abcab/test/compiler/intrinsics/sha/TestSHA.java#l104 >>> >> >> I know about this test but I though we may not cover all cases. >> Did you evaluate it? I am fine if you think that everything is covered. > Originally I was concerned by the fact that this test use messages of > fixed size. > However, while the multi-block intrinsic (_digestBase_implCompressMB) > will be used > to compute the digest for almost all blocks, a single block intrinsic > (_sha*_implCompress) > still will be used to compute the digest of the final block, thus if one > of this intrinsics > compute the digest incorrectly, then the overall result will be incorrect. > > Sanity tests invoke TestSHA::testSHA, so it is covered with different > combinations > of UseSHA & UseSHA*Intrinsics. > > Also, there a lot of JDK tests which verify that different security > algorithms which use SHA* > message digests work well. > > And there is sun/security/provider/MessageDigest/DigestKAT.java test, > which compares > message digest computed using SHA* algorithms with precomputed values. > > So I believe that there is no need to develop additional tests. Okay, thanks. Again, your changes looks good. Thanks, Vladimir > > Thanks, > Filipp. >> >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> Filipp. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/29/14 7:45 AM, Filipp Zhinkin wrote: >>>>> Hi all, >>>>> >>>>> please review sanity tests on SHA intrinsics support. >>>>> >>>>> Tests verify that appropriate intrinsic is emitted whencorresponding >>>>> option is enabled and not emitted ifsuch option is disabled. >>>>> >>>>> In case when CPU does not support required instructions or >>>>> JVM configuration does not allow to use an intrinsic, >>>>> the test will expect that intrinsic will not be emitted. >>>>> >>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8055903 >>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8055903/webrev.00/ >>>>> Testing: manual, automated. >>>>> >>>>> Thanks, >>>>> Filipp. >>> > From filipp.zhinkin at oracle.com Fri Aug 29 18:31:47 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 29 Aug 2014 22:31:47 +0400 Subject: [9] RFR (L): JDK-8055903: Develop sanity tests on SPARC's SHA instructions support In-Reply-To: <5400C6F8.1070706@oracle.com> References: <5400921C.3050001@oracle.com> <5400AB2A.60308@oracle.com> <5400AC4B.3030100@oracle.com> <5400AD94.5010309@oracle.com> <5400C2D0.90400@oracle.com> <5400C6F8.1070706@oracle.com> Message-ID: <5400C713.4070700@oracle.com> Thank you, Vladimir. Regards, Filipp. On 29.08.2014 22:31, Vladimir Kozlov wrote: > On 8/29/14 11:13 AM, Filipp Zhinkin wrote: >> >> On 29.08.2014 20:43, Vladimir Kozlov wrote: >>> On 8/29/14 9:37 AM, Filipp Zhinkin wrote: >>>> Vladimir, >>>> >>>> On 29.08.2014 20:32, Vladimir Kozlov wrote: >>>>> So it is mostly verification that intrinsic is used. >>>> Right. >>>>> The code looks fine. >>>>> But what about testing that intrinsic produce correct data? >>>> It is done by compiler/intrinsics/sha/TestSHA.java test: >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/3a2d373abcab/test/compiler/intrinsics/sha/TestSHA.java#l104 >>>> >>>> >>> >>> I know about this test but I though we may not cover all cases. >>> Did you evaluate it? I am fine if you think that everything is covered. >> Originally I was concerned by the fact that this test use messages of >> fixed size. >> However, while the multi-block intrinsic (_digestBase_implCompressMB) >> will be used >> to compute the digest for almost all blocks, a single block intrinsic >> (_sha*_implCompress) >> still will be used to compute the digest of the final block, thus if one >> of this intrinsics >> compute the digest incorrectly, then the overall result will be >> incorrect. >> >> Sanity tests invoke TestSHA::testSHA, so it is covered with different >> combinations >> of UseSHA & UseSHA*Intrinsics. >> >> Also, there a lot of JDK tests which verify that different security >> algorithms which use SHA* >> message digests work well. >> >> And there is sun/security/provider/MessageDigest/DigestKAT.java test, >> which compares >> message digest computed using SHA* algorithms with precomputed values. >> >> So I believe that there is no need to develop additional tests. > > Okay, thanks. Again, your changes looks good. > > Thanks, > Vladimir > >> >> Thanks, >> Filipp. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> Filipp. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/29/14 7:45 AM, Filipp Zhinkin wrote: >>>>>> Hi all, >>>>>> >>>>>> please review sanity tests on SHA intrinsics support. >>>>>> >>>>>> Tests verify that appropriate intrinsic is emitted whencorresponding >>>>>> option is enabled and not emitted ifsuch option is disabled. >>>>>> >>>>>> In case when CPU does not support required instructions or >>>>>> JVM configuration does not allow to use an intrinsic, >>>>>> the test will expect that intrinsic will not be emitted. >>>>>> >>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8055903 >>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8055903/webrev.00/ >>>>>> Testing: manual, automated. >>>>>> >>>>>> Thanks, >>>>>> Filipp. >>>> >> From filipp.zhinkin at oracle.com Fri Aug 29 18:49:12 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 29 Aug 2014 22:49:12 +0400 Subject: [9] RFR (L): JDK-8055904: Develop tests on newly added command line options related to SHA intrinsics Message-ID: <5400CB28.2070407@oracle.com> Hi all, please review tests on processing of SHA-related command line options. Tests verify: - startup warnings; - default values; - ability to enable/disable options on supported CPUs; - that options are always disabled on unsupported CPUs; - relations between UseSHA and UseSHA*Intrinsics options. Each particular test constructed from several generalized testcases, each of which verifies that several assertions hold in specific environment, like availability of all SPARC's sha* instruction, availability of only several of then or execution on X86 CPU. Each test case will be executed only if all its preconditions have been met. Otherwise, the test case will be skipped from execution. Bug id: https://bugs.openjdk.java.net/browse/JDK-8055904 Webrev: http://cr.openjdk.java.net/~fzhinkin/8055904/webrev.00/ Testing: manual, automated. Note that this change depends on the fix for JDK-8055903 [1]. RFR for JDK-8055903 [2] was published earlier today. Thanks, Filipp. [1] https://bugs.openjdk.java.net/browse/JDK-8055903 [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-August/015337.html From david.r.chase at oracle.com Fri Aug 29 19:16:05 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 29 Aug 2014 15:16:05 -0400 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds In-Reply-To: <53FF6C08.4020007@oracle.com> References: <53F7C88A.8060706@oracle.com> <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> <53F7E97A.9090006@oracle.com> <53FF6C08.4020007@oracle.com> Message-ID: <6A9A5D47-1658-4B8F-A7CE-AEB9A83BD39A@oracle.com> On 2014-08-28, at 1:51 PM, Vladimir Kozlov wrote: > On 8/28/14 6:28 AM, David Chase wrote: >> >> Revised changes: http://cr.openjdk.java.net/~drchase/8054292/webrev-for-leak-checks.12/ >> Added placement-new-constructor call in InterpreterCodelet (to allow that extra assert). > > This one I am not sure. It could hide potential memory leak when constructor overwrite previously stored _strings values. But I agree that it is the simplest change to enable the assert. And based on what I see in current code it should not cause a leak because we assign default NULL to _strings several times until the final store in ~CodeletMark(). > > In short, I accept current change but, please, file RFE (starter task) to clean this code. As I said before strings recording for InterpreterCodelet could be done differently (do not do it generally for Stub class). Chris seemed to think that though this could leak, it was bounded because we only generate the interpreter once. But I?ll file that bug once this one is pushed. >> Tested fastdebug and not-debug (calls itself ?release?) builds w/ jtreg, fastdebug with PrintAsm enabled. >> Did 64-hour leak check with KitchenSink; any leaks seem to be below the what?s-currently-compiled noise threshold. >> >> Sanity check: is ?optimized build? the default if I just run configure? > > No, the default is 'product' Hotspot build. I would suggest to build 'optimized' VM separately (it looks like 'optimized' target for whole forest does not work) and test it for leaks. Done, and there appeared to be no leaks in CTW (not in ?code?, which is where they showed up before). Good to go? David From james.cheng at oracle.com Fri Aug 29 19:51:22 2014 From: james.cheng at oracle.com (james cheng) Date: Fri, 29 Aug 2014 12:51:22 -0700 Subject: [9] RFR (L): JDK-8055904: Develop tests on newly added command line options related to SHA intrinsics In-Reply-To: <5400CB28.2070407@oracle.com> References: <5400CB28.2070407@oracle.com> Message-ID: <5400D9BA.5040809@oracle.com> Hi Filipp, I saw some glitches: http://cr.openjdk.java.net/~fzhinkin/8055904/webrev.00/test/compiler/intrinsics/sha/cli/SHAOptionsBase.java.html 50 = "SHA256 instruction.*is not available on this CPU."; 52 = "SHA512 instruction.*is not available on this CPU."; ^^ http://cr.openjdk.java.net/~fzhinkin/8055904/webrev.00/test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedSparcCPU.java.html 49 // all UseSHA*Intrinsics options were turned on. ^^ http://cr.openjdk.java.net/~fzhinkin/8055904/webrev.00/test/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java.html 42 SHAOptionsBase.USE_SHA512_INTRINSICS_OPTION), ^^^ http://cr.openjdk.java.net/~fzhinkin/8055904/webrev.00/test/compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java.html 42 SHAOptionsBase.USE_SHA512_INTRINSICS_OPTION), ^^^ Thanks, -James On 8/29/2014 11:49 AM, Filipp Zhinkin wrote: > Hi all, > > please review tests on processing of SHA-related command line options. > > Tests verify: > - startup warnings; > - default values; > - ability to enable/disable options on supported CPUs; > - that options are always disabled on unsupported CPUs; > - relations between UseSHA and UseSHA*Intrinsics options. > > Each particular test constructed from several generalized testcases, > each of which verifies that several assertions hold in specific environment, > like availability of all SPARC's sha* instruction, availability of only several > of then or execution on X86 CPU. > > Each test case will be executed only if all its preconditions have been met. > Otherwise, the test case will be skipped from execution. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8055904 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8055904/webrev.00/ > Testing: manual, automated. > > Note that this change depends on the fix for JDK-8055903 [1]. > RFR for JDK-8055903 [2] was published earlier today. > > Thanks, > Filipp. > > [1] https://bugs.openjdk.java.net/browse/JDK-8055903 > [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-August/015337.html From vladimir.kozlov at oracle.com Fri Aug 29 21:05:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Aug 2014 14:05:36 -0700 Subject: [9] RFR (L): JDK-8055904: Develop tests on newly added command line options related to SHA intrinsics In-Reply-To: <5400CB28.2070407@oracle.com> References: <5400CB28.2070407@oracle.com> Message-ID: <5400EB20.8090003@oracle.com> Looks fine. Thanks, Vladimir On 8/29/14 11:49 AM, Filipp Zhinkin wrote: > Hi all, > > please review tests on processing of SHA-related command line options. > > Tests verify: > - startup warnings; > - default values; > - ability to enable/disable options on supported CPUs; > - that options are always disabled on unsupported CPUs; > - relations between UseSHA and UseSHA*Intrinsics options. > > Each particular test constructed from several generalized testcases, > each of which verifies that several assertions hold in specific > environment, > like availability of all SPARC's sha* instruction, availability of only > several > of then or execution on X86 CPU. > > Each test case will be executed only if all its preconditions have been > met. > Otherwise, the test case will be skipped from execution. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8055904 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8055904/webrev.00/ > Testing: manual, automated. > > Note that this change depends on the fix for JDK-8055903 [1]. > RFR for JDK-8055903 [2] was published earlier today. > > Thanks, > Filipp. > > [1] https://bugs.openjdk.java.net/browse/JDK-8055903 > [2] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-August/015337.html > From vladimir.kozlov at oracle.com Fri Aug 29 21:10:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Aug 2014 14:10:00 -0700 Subject: [9] RFR(M): 8054292 : code comments leak in fastdebug builds In-Reply-To: <6A9A5D47-1658-4B8F-A7CE-AEB9A83BD39A@oracle.com> References: <53F7C88A.8060706@oracle.com> <93DB8F54-2308-4578-8921-6ED5CB0CB72E@oracle.com> <53F7E97A.9090006@oracle.com> <53FF6C08.4020007@oracle.com> <6A9A5D47-1658-4B8F-A7CE-AEB9A83BD39A@oracle.com> Message-ID: <5400EC28.7080107@oracle.com> On 8/29/14 12:16 PM, David Chase wrote: > > On 2014-08-28, at 1:51 PM, Vladimir Kozlov wrote: >> On 8/28/14 6:28 AM, David Chase wrote: >>> >>> Revised changes: http://cr.openjdk.java.net/~drchase/8054292/webrev-for-leak-checks.12/ > >>> Added placement-new-constructor call in InterpreterCodelet (to allow that extra assert). >> >> This one I am not sure. It could hide potential memory leak when constructor overwrite previously stored _strings values. But I agree that it is the simplest change to enable the assert. And based on what I see in current code it should not cause a leak because we assign default NULL to _strings several times until the final store in ~CodeletMark(). >> >> In short, I accept current change but, please, file RFE (starter task) to clean this code. As I said before strings recording for InterpreterCodelet could be done differently (do not do it generally for Stub class). > > Chris seemed to think that though this could leak, it was bounded because we only generate the interpreter once. > But I?ll file that bug once this one is pushed. I mostly want to clean that code for easy understanding and already then for leak avoidance. > >>> Tested fastdebug and not-debug (calls itself ?release?) builds w/ jtreg, fastdebug with PrintAsm enabled. >>> Did 64-hour leak check with KitchenSink; any leaks seem to be below the what?s-currently-compiled noise threshold. >>> >>> Sanity check: is ?optimized build? the default if I just run configure? >> >> No, the default is 'product' Hotspot build. I would suggest to build 'optimized' VM separately (it looks like 'optimized' target for whole forest does not work) and test it for leaks. > > Done, and there appeared to be no leaks in CTW (not in ?code?, which is where they showed up before). > > Good to go? Yes, thumbs up from me. Thanks, Vladimir > > David > From vladimir.kozlov at oracle.com Sat Aug 30 02:32:17 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Aug 2014 19:32:17 -0700 Subject: RFR(M) 8056964: JDK-8055286 changes are incomplete. Message-ID: <540137B1.8070706@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8056964 http://cr.openjdk.java.net/~kvn/8056964/webrev/ I want to use compilerOracle 'option' ccstr type for 8055494 testing: -XX:CompileCommand=option,java.math.BigInteger::multiply,ccstr,DisableIntrinsic,_multiplyToLen So it is blocker for 8055494. I added ccstr and ccstrlist types to compilerOracle 'option' command. Internally ccstr and ccstrlist are the same: const char*. As result templates are declared only for ccstr. Fixed 'bool' option to accept 'false' value. Modified the output for options (added type). Added missing accessor methods in Compile and ciMethod classes. The output: java -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 -XX:CompileCommand=option,Test::test,MyFlag -version CompilerOracle: option Test.test const char* MyListOption = '_foo _bar' CompilerOracle: option Test.test const char* MyStrOption = '_foo' CompilerOracle: option Test.test bool MyBoolOption = false CompilerOracle: option Test.test intx MyIntxOption = -1 CompilerOracle: option Test.test uintx MyUintxOption = 1 CompilerOracle: option Test.test bool MyFlag = true java version "1.9.0-ea-fastdebug" Thanks, Vladimir From vladimir.kozlov at oracle.com Sat Aug 30 03:02:17 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Aug 2014 20:02:17 -0700 Subject: RFR(L) 8055494: Add C2 x86 intrinsic for BigInteger::multiplyToLen() method Message-ID: <54013EB9.2050906@oracle.com> http://cr.openjdk.java.net/~kvn/8055494/webrev/ https://bugs.openjdk.java.net/browse/JDK-8055494 Add new C2 intrinsic for BigInteger::multiplyToLen() on x86 in 64-bit VM. Use unsigned multiply instruction which produces 128 bit result in registers pair. It doubles performance in microbenchmark and gives about 4-5% improvement in jvm2008.crypto. It has code which will run on old cpus and additional specialized code which use BMI2 instructions (allow to reduce number of instructions). Also it has a special code for next processor to use new ADX instructions. BMI instructions require VEX encoding which we generate only with AVX so I added additional check for UseBMI1Instructions and UseBMI2Instructions flags settings in vm_version_x86.cpp. Added regression test with flags which requires 8056964 and 8055286 changes. Flags disable the intrinsic in base_multiply() method and enable in new_multiply() to verify correctness. Tested jtreg, JPRT. Thanks, Vladimir From sandro.sansone at gmail.com Tue Aug 5 22:23:46 2014 From: sandro.sansone at gmail.com (Sandro Sansone) Date: Tue, 05 Aug 2014 22:23:46 -0000 Subject: Concern about JDK-8051955 Message-ID: Hi guys, I need 1 minute of yours. I am concerned about the management of this issue and I would like to give you my point of view on this. Few days back I have opened the following bug on jre7: https://bugs.openjdk.java.net/browse/JDK-8051955 Now I can see it will be resolved in jre8. My question is: why? This serious bug was introduced in jre7, while in jre6 was working fine and it is an issue that potentially can come out to anybody else who migrate to jre7. Why you don't want to fix it in jre7? One additional note: in the real world, in production, at least finance field, people are now migrating to java 7 considering it the stable and mature version, while java 8 is still quite far. Their requirement is performance, while this issue causes degradation of performances. Doing so you are potentially affecting thousand of people migrating to java7 (the luck is that they will probably never discover it is a java issue thinking it was due to their application bug). I hope you understand my point, which purpose is the best for the java community ;) Thanks in advance Sandro -------------- next part -------------- An HTML attachment was scrubbed... URL: