From Christian.Thalinger at Sun.COM Mon Feb 1 08:33:02 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 01 Feb 2010 17:33:02 +0100 Subject: Request for reviews (XS): 6921799: JSR 292 call sites should not be fixed-up Message-ID: <4B67023E.9050801@Sun.COM> http://cr.openjdk.java.net/~twisti/6921799/webrev.01/ From Vladimir.Kozlov at Sun.COM Mon Feb 1 09:30:52 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 01 Feb 2010 09:30:52 -0800 Subject: Request for reviews (XS): 6921799: JSR 292 call sites should not be fixed-up In-Reply-To: <4B67023E.9050801@Sun.COM> References: <4B67023E.9050801@Sun.COM> Message-ID: <4B670FCC.7070308@sun.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6921799/webrev.01/ From yamauchi at google.com Mon Feb 1 10:18:07 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Mon, 1 Feb 2010 10:18:07 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: <4B62AFFB.10707@Sun.COM> References: <4B62AFFB.10707@Sun.COM> Message-ID: Hi Christian, > I think that's a good change. ?I have two comments: personally I prefer to > use assembler instructions directly in the ins_encode than writing > very-hard-to-read enc_class methods and the predicates are kind of ugly, but > I don't know if that could be done any better. I'll see if I can do it better that way. > Maybe, given that we probably support more 32-bit architectures in the > future, we could model such instructions in ideal (e.g. in a pass that's > only used on 32-bit). I agree that it'd be easier and probably more effective to apply the same optimization at the ideal graph level. Thanks, Hiroshi From Thomas.Rodriguez at Sun.COM Mon Feb 1 11:07:28 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 01 Feb 2010 11:07:28 -0800 Subject: Request for reviews (XS): 6921799: JSR 292 call sites should not be fixed-up In-Reply-To: <4B67023E.9050801@Sun.COM> References: <4B67023E.9050801@Sun.COM> Message-ID: <6539A859-0DF9-4074-B6BA-08851AA0F46D@sun.com> Looks good. tom On Feb 1, 2010, at 8:33 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6921799/webrev.01/ From Christian.Thalinger at Sun.COM Mon Feb 1 12:29:55 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 01 Feb 2010 20:29:55 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6921352: JSR 292 needs its own deopt handler Message-ID: <20100201203001.BF6D3419CD@hg.openjdk.java.net> Changeset: 18a389214829 Author: twisti Date: 2010-02-01 19:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/18a389214829 6921352: JSR 292 needs its own deopt handler Summary: We need to introduce a new MH deopt handler so we can easily determine if the deopt happened at a MH call site or not. Reviewed-by: never, jrose ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/sharedRuntime.cpp From Thomas.Rodriguez at Sun.COM Mon Feb 1 14:01:51 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 01 Feb 2010 14:01:51 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: References: <4B62AFFB.10707@Sun.COM> Message-ID: <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> On Feb 1, 2010, at 10:18 AM, Hiroshi Yamauchi wrote: > Hi Christian, > >> I think that's a good change. I have two comments: personally I prefer to >> use assembler instructions directly in the ins_encode than writing >> very-hard-to-read enc_class methods and the predicates are kind of ugly, but >> I don't know if that could be done any better. The predicates are ugly but we don't currently have a better mechanism. The cleaner way this could be expressed would be: predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); but the Matcher doesn't capture the type table from the last phase of GVN. The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. It returns the worst case type TypeLong::LONG. Only the type table captures the improved type that we computed though iter GVN. If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. I think in most interesting cases the predicate will work correctly though. It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. Anyway, I think the predicates are fine for this purpose. > > I'll see if I can do it better that way. > >> Maybe, given that we probably support more 32-bit architectures in the >> future, we could model such instructions in ideal (e.g. in a pass that's >> only used on 32-bit). > > I agree that it'd be easier and probably more effective to apply the > same optimization at the ideal graph level. I agree that it would be nice if these optimizations kind of fell out more automatically but I'm leery of adding yet more one off ideal nodes to describe machine dependent operations. Maybe there is a reasonable set that could be used for decomposing 64-bit operations into a clean set of 32 bit operations, though I think that might have ramifications for the register allocator since we represent longs as pairs. We're definitely emitting less than optimal sequences for 64 bit operations in 32 mode. tom > > Thanks, > Hiroshi From rasbold at google.com Mon Feb 1 14:39:51 2010 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 1 Feb 2010 14:39:51 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> Message-ID: <4149a0431002011439r7fecd9b9q20aa2a44b9460829@mail.gmail.com> Could someone on the inside (I can't bring myself to say the O-word yet) open a bug this one? Thanks. -- Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100201/ae74ff5d/attachment.html From Thomas.Rodriguez at Sun.COM Mon Feb 1 15:15:17 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 01 Feb 2010 15:15:17 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: <4149a0431002011439r7fecd9b9q20aa2a44b9460829@mail.gmail.com> References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> <4149a0431002011439r7fecd9b9q20aa2a44b9460829@mail.gmail.com> Message-ID: <5AB63F68-6CA3-47BE-935F-26A677B74F7C@sun.com> I filed 6921969 for this. tom On Feb 1, 2010, at 2:39 PM, Chuck Rasbold wrote: > Could someone on the inside (I can't bring myself to say the O-word yet) open a bug this one? > > Thanks. > > -- Chuck > > From yamauchi at google.com Mon Feb 1 15:34:12 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Mon, 1 Feb 2010 15:34:12 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> Message-ID: I think it's a little more readable this way: http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ Hiroshi On Mon, Feb 1, 2010 at 2:01 PM, Tom Rodriguez wrote: > > On Feb 1, 2010, at 10:18 AM, Hiroshi Yamauchi wrote: > >> Hi Christian, >> >>> I think that's a good change. ?I have two comments: personally I prefer to >>> use assembler instructions directly in the ins_encode than writing >>> very-hard-to-read enc_class methods and the predicates are kind of ugly, but >>> I don't know if that could be done any better. > > The predicates are ugly but we don't currently have a better mechanism. ?The cleaner way this could be expressed would be: > > predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); > > but the Matcher doesn't capture the type table from the last phase of GVN. ?The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. ?It returns the worst case type TypeLong::LONG. ?Only the type table captures the improved type that we computed though iter GVN. ?If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. ?Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. ?I think in most interesting cases the predicate will work correctly though. ?It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. ?Anyway, I think the predicates are fine for this purpose. > >> >> I'll see if I can do it better that way. >> >>> Maybe, given that we probably support more 32-bit architectures in the >>> future, we could model such instructions in ideal (e.g. in a pass that's >>> only used on 32-bit). >> >> I agree that it'd be easier and probably more effective to apply the >> same optimization at the ideal graph level. > > I agree that it would be nice if these optimizations kind of fell out more automatically but I'm leery of adding yet more one off ideal nodes to describe machine dependent operations. ?Maybe there is a reasonable set that could be used for decomposing 64-bit operations into a clean set of 32 bit operations, though I think that might have ramifications for the register allocator since we represent longs as pairs. ?We're definitely emitting less than optimal sequences for 64 bit operations in 32 mode. > > tom > >> >> Thanks, >> Hiroshi > > From Thomas.Rodriguez at Sun.COM Mon Feb 1 16:18:00 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 01 Feb 2010 16:18:00 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> Message-ID: The assembler changes look good but I'd rather have the predicate stuff in the ad file instead of over in MulLNode. The normal way make ad helper functions is to put it into the ad file itself in the source block. There's a section of the ad file which begins with "source %{" and it's included verbatim in the main generated ad file. So just add is_operand_hi32_zero as a static function in the source block. tom On Feb 1, 2010, at 3:34 PM, Hiroshi Yamauchi wrote: > I think it's a little more readable this way: > > http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ > > Hiroshi > > On Mon, Feb 1, 2010 at 2:01 PM, Tom Rodriguez wrote: >> >> On Feb 1, 2010, at 10:18 AM, Hiroshi Yamauchi wrote: >> >>> Hi Christian, >>> >>>> I think that's a good change. I have two comments: personally I prefer to >>>> use assembler instructions directly in the ins_encode than writing >>>> very-hard-to-read enc_class methods and the predicates are kind of ugly, but >>>> I don't know if that could be done any better. >> >> The predicates are ugly but we don't currently have a better mechanism. The cleaner way this could be expressed would be: >> >> predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); >> >> but the Matcher doesn't capture the type table from the last phase of GVN. The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. It returns the worst case type TypeLong::LONG. Only the type table captures the improved type that we computed though iter GVN. If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. I think in most interesting cases the predicate will work correctly though. It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. Anyway, I think the predicates are fine for this purpose. >> >>> >>> I'll see if I can do it better that way. >>> >>>> Maybe, given that we probably support more 32-bit architectures in the >>>> future, we could model such instructions in ideal (e.g. in a pass that's >>>> only used on 32-bit). >>> >>> I agree that it'd be easier and probably more effective to apply the >>> same optimization at the ideal graph level. >> >> I agree that it would be nice if these optimizations kind of fell out more automatically but I'm leery of adding yet more one off ideal nodes to describe machine dependent operations. Maybe there is a reasonable set that could be used for decomposing 64-bit operations into a clean set of 32 bit operations, though I think that might have ramifications for the register allocator since we represent longs as pairs. We're definitely emitting less than optimal sequences for 64 bit operations in 32 mode. >> >> tom >> >>> >>> Thanks, >>> Hiroshi >> >> From Christian.Thalinger at Sun.COM Mon Feb 1 16:19:23 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 02 Feb 2010 00:19:23 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6921799: JSR 292 call sites should not be fixed-up Message-ID: <20100202001927.2C30541A0D@hg.openjdk.java.net> Changeset: 5fcfaa1ad96f Author: twisti Date: 2010-02-01 23:18 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5fcfaa1ad96f 6921799: JSR 292 call sites should not be fixed-up Summary: MethodHandle invoke call sites should not be fixed-up by SharedRuntime::fixup_callers_callsite as c2i/i2c adapters are used to implement MethodHandle actions. Reviewed-by: kvn, never ! src/share/vm/runtime/sharedRuntime.cpp From Vladimir.Kozlov at Sun.COM Mon Feb 1 16:42:16 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 01 Feb 2010 16:42:16 -0800 Subject: Request for reviews (M): 6614597: Performance variability in jvm2008 xml.validation In-Reply-To: References: <4B58F33D.8080602@sun.com> <8C52D571-00AD-4E97-A171-76E0E5741B70@sun.com> <4B593493.4030306@sun.com> <5762ED9E-DDDE-49FA-8579-003B68E01FAB@sun.com> <230C3E82-284F-49A7-B9CC-20DF94ACAE68@Sun.COM> <4B5A3285.4090001@sun.com> <4B08BEA3-D244-441A-A38D-2F8D395D96C0@Sun.COM> <4B5A77EB.5050602@sun.com> <4B5A8246.4070605@sun.com> <4B5A91CD.5010601@sun.com> <05018CEF-AE12-408F-8C79-FA71660F396B@sun.com> <4B5DE1C9.7040801@sun.com> <4B5DEE1C.1050901@sun.com> <4B60FA3C.5080306@sun.com> <220C8936-DE40-4F25-97F8-5305C2BADEB8@sun.com> <4B61EBAC.30100@sun.com> <978FA0A8-087E-4238-9A95-0EEAC1DF0BD1@Sun.COM> <4B632AE1.1010903@sun.com> Message-ID: <4B6774E8.50609@sun.com> I was paranoid about having too_many_traps check for monomorphic case since as described in the original big comment we may miss the transition from monomorphic to bimorphic if counters was not updated before compilation. So I added the compilation assert for such case and everything passed (JPRT) except xml.transform in specjvm2008 which has method with a lot of calls to the same small methods which are inlined. One such method has 4 class_check traps (it was recompiled once). As result of this method inlining accumulative (per method) class_check trap count reaches 100: and too_many_traps() returns 'true' even if an other call site does not have trap: It seems to me, it is overkill. I know why we do this - to avoid a lot of deoptimizations. But may be we should apply such restriction only for traps not recorded per bytecode? Or keep track of which trap count is used for accumulative count and avoid this case? Anyway it is edge case and we may look on it later. For now I am pushing my changes with too_many_traps(). Thanks, Vladimir Tom Rodriguez wrote: > I would be happy with your current change but just adding in the per bci too many traps check for the appropriate Reason_class_check or Reason_bimorphic. I think its clearer and will work slightly better. > > tom > > On Jan 29, 2010, at 10:37 AM, Vladimir Kozlov wrote: > >> Actually I am also not sure what would be the best. >> Refworkload shows no difference for any case. >> >> Yes, I don't need Reason_bimorphic but it could help to avoid possible >> one deoptimization (transition bimorphich to polimorphic). >> Also we can separate uncommon traps in logs. >> >> I can remove it and use its place for Reason_predicate (which should be per bytecode trap). >> >> The check too_many_traps() also not needed BUT, as you pointed, >> if we have Reason_bimorphic we should use it to avoid >> ONE additional deoptimization and recompilation. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> I'm a little confused. I thought you'd only need either Reason_bimorphic or to adjust the way counters are handled, not both? I'm not against having both since it rationalizes the counters but then why aren't you checking too_many_traps any more? You've got the counter so why ignore it? Otherwise you're exposed to the race that's mentioned in the big comment you deleted where the mdo trap count is updated but not the call site counts. >>> tom >>> On Jan 28, 2010, at 11:55 AM, Vladimir Kozlov wrote: >>>> Here is new webrev >>>> >>>> http://cr.openjdk.java.net/~kvn/6614597/webrev.07 >>>> >>>> Tom, you are right. I just need to remove too_many_traps() check >>>> and rely only on counters. We may get an additional deoptimization >>>> and recompilation in the next rare case but I think it is fine. >>>> >>>> There is time interval between the method deoptimization and >>>> when interpreter continue execution of the method and increment >>>> total counter for the call bytecode indicating polimorphic case. >>>> During this interval an other thread can trigger compilation and >>>> compiler thread will load MDO which has not updated total counter. >>>> The parser will still see bimorphic case and generate bimorphic code. >>>> >>>> And I will use Reason_bimorphic to separate traps. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> I assumed you intended to use the state of the counters to distinguish mono from bi, i.e. if the total count is greater than rec1 + rec2 then bimorphic can't work otherwise give it a try. I agree is might be more clear if Reason_bimorphic were used. Your changes to make it per bci look fine. >>>>> tom >>>>> On Jan 27, 2010, at 6:45 PM, Vladimir Kozlov wrote: >>>>>> ....!!! I need Reason_bimorphic even with my changes for call counters. >>>>>> >>>>>> Otherwise uncommon trap will not be generated for bimorphic case >>>>>> if the first compilation was with monomorphic case after which >>>>>> we hit class_check trap and recorded it in MDO for this bytecode. >>>>>> >>>>>> I forgot about it and found again during testing of latest changes. >>>>>> >>>>>> And I want to have too_many_traps() check per bytecode instead of current per method. >>>>>> So I am going to place Reason_bimorphic before Reason_unloaded to record it >>>>>> per bytecode. I think the next changes should be enough. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> @@ -33,12 +33,15 @@ class Deoptimization : AllStatic { >>>>>> enum DeoptReason { >>>>>> Reason_many = -1, // indicates presence of several reasons >>>>>> Reason_none = 0, // indicates absence of a relevant deopt. >>>>>> + // Next 7 reasons are recorded per bytecode in DataLayout::trap_bits >>>>>> Reason_null_check, // saw unexpected null or zero divisor (@bci) >>>>>> Reason_null_assert, // saw unexpected non-null or non-zero (@bci) >>>>>> Reason_range_check, // saw unexpected array index (@bci) >>>>>> Reason_class_check, // saw unexpected object class (@bci) >>>>>> Reason_array_check, // saw unexpected array class (aastore @bci) >>>>>> Reason_intrinsic, // saw unexpected operand to intrinsic (@bci) >>>>>> + Reason_bimorphic, // saw unexpected object class in bimorphic inlining (@bci) >>>>>> + >>>>>> Reason_unloaded, // unloaded class or constant pool entry >>>>>> Reason_uninitialized, // bad class state (uninitialized) >>>>>> Reason_unreached, // code is not reached, compiler >>>>>> @@ -49,7 +52,7 @@ class Deoptimization : AllStatic { >>>>>> Reason_predicate, // compiler generated predicate failed >>>>>> Reason_LIMIT, >>>>>> // Note: Keep this enum in sync. with _trap_reason_name. >>>>>> - Reason_RECORDED_LIMIT = Reason_unloaded // some are not recorded per bc >>>>>> + Reason_RECORDED_LIMIT = Reason_bimorphic // some are not recorded per bc >>>>>> // Note: Reason_RECORDED_LIMIT should be < 8 to fit into 3 bits of >>>>>> // DataLayout::trap_bits. This dependency is enforced indirectly >>>>>> // via asserts, to avoid excessive direct header-to-header dependencies. >>>>>> @@ -279,7 +282,7 @@ class Deoptimization : AllStatic { >>>>>> int trap_state); >>>>>> >>>>>> static bool reason_is_recorded_per_bytecode(DeoptReason reason) { >>>>>> - return reason > Reason_none && reason < Reason_RECORDED_LIMIT; >>>>>> + return reason > Reason_none && reason <= Reason_RECORDED_LIMIT; >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> Vladimir Kozlov wrote: >>>>>>> Thank you, Tom >>>>>>> Then I will go ahead to implement it. >>>>>>> Vladimir >>>>>>> Tom Rodriguez wrote: >>>>>>>> I think you're right that part of the problem is that even though we maintain 3 counters, the total is supposed to be related to the other two but since they aren't updated atomically they can actually be out of sync by an almost arbitrary amount. So I think you're suggesting that instead of maintaining rec1, rec2 and total, we should maintain rec1, rec2 and other. The site count will be the sum of rec1, rec2 and other. Another nice thing about this would be that we'd only be updating a single counter for the call site instead of normally doing two. The other way to handle this would be to set TypeProfileWidth to 3. Either way, if the profile itself could reliably indicate more than 2 receiver types we wouldn't need to have a new Reason. I like the idea of a solution like this. >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>> On Jan 25, 2010, at 10:24 AM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> Reason_bimorphic will not cover the case when total counter >>>>>>>>> is larger then sum of 2 receivers in real bimorphic case. >>>>>>>>> >>>>>>>>> What I am saying is currently the only reliable information >>>>>>>>> these counters can give us is monomorphic case. We can not >>>>>>>>> relay on them (in current implementation) to distinguish >>>>>>>>> bimorphic case from polimorphic case. This is why Reason_bimorphic >>>>>>>>> helps. If we use counters differently we don't need Reason_bimorphic. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> John Rose wrote: >>>>>>>>>> On Jan 22, 2010, at 10:06 PM, Vladimir Kozlov wrote: >>>>>>>>>>> The third solution (sorry they are still popping up) will be using >>>>>>>>>>> the total counter in MDO only for missing (third receiver) cases. >>>>>>>>>>> It will allow to keep current type profile width and distinguish >>>>>>>>>>> bimorphic case from polimorphic. >>>>>>>>>> I like Tom's idea of mapping Reason_bimorphic to an unrelated reason, such as Reason_range_check. >>>>>>>>>> -- John > From John.Rose at Sun.COM Mon Feb 1 17:00:26 2010 From: John.Rose at Sun.COM (John Rose) Date: Mon, 01 Feb 2010 17:00:26 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> Message-ID: <88B629FD-EF4C-447E-AA52-90C26AF39B0E@sun.com> On Feb 1, 2010, at 2:01 PM, Tom Rodriguez wrote: > The predicates are ugly but we don't currently have a better mechanism. The cleaner way this could be expressed would be: > > predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); > > but the Matcher doesn't capture the type table from the last phase of GVN. The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. It returns the worst case type TypeLong::LONG. Only the type table captures the improved type that we computed though iter GVN. If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. I think in most interesting cases the predicate will work correctly though. It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. Anyway, I think the predicates are fine for this purpose. My first thought also was "why don't we use types for such predicates?" It would be much more robust that way. Your explanation of why not is correct. There's a marginally better way: Use a type predicate on the RHS of the AndL node: predicate(n->in(1)->in(2)->bottom_type()->higher_equals(TypeLong::UINT)); That way we get the optimization for (x & 0xFFFFFFFFl) and also (x & 0xFF) and similar variants. -- John From Thomas.Rodriguez at Sun.COM Mon Feb 1 17:04:59 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 01 Feb 2010 17:04:59 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: <88B629FD-EF4C-447E-AA52-90C26AF39B0E@sun.com> References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> <88B629FD-EF4C-447E-AA52-90C26AF39B0E@sun.com> Message-ID: On Feb 1, 2010, at 5:00 PM, John Rose wrote: > On Feb 1, 2010, at 2:01 PM, Tom Rodriguez wrote: > >> The predicates are ugly but we don't currently have a better mechanism. The cleaner way this could be expressed would be: >> >> predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); >> >> but the Matcher doesn't capture the type table from the last phase of GVN. The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. It returns the worst case type TypeLong::LONG. Only the type table captures the improved type that we computed though iter GVN. If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. I think in most interesting cases the predicate will work correctly though. It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. Anyway, I think the predicates are fine for this purpose. > > > My first thought also was "why don't we use types for such predicates?" It would be much more robust that way. Your explanation of why not is correct. > > There's a marginally better way: Use a type predicate on the RHS of the AndL node: > predicate(n->in(1)->in(2)->bottom_type()->higher_equals(TypeLong::UINT)); > > That way we get the optimization for (x & 0xFFFFFFFFl) and also (x & 0xFF) and similar variants. It will already get those since 0xff & 0xFFFFFFFF00000000LL == 0. tom > > -- John From John.Rose at Sun.COM Mon Feb 1 17:14:16 2010 From: John.Rose at Sun.COM (John Rose) Date: Mon, 01 Feb 2010 17:14:16 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> <88B629FD-EF4C-447E-AA52-90C26AF39B0E@sun.com> Message-ID: <510AC596-9287-46ED-850A-0CC8BD0E4764@Sun.COM> On Feb 1, 2010, at 5:04 PM, Tom Rodriguez wrote: > It will already get those since 0xff & 0xFFFFFFFF00000000LL == 0. Right... Oops, misread the code. Somehow I imagined a literal constant node in the pattern. -- John From vladimir.kozlov at sun.com Mon Feb 1 18:53:24 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 02 Feb 2010 02:53:24 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6614597: Performance variability in jvm2008 xml.validation Message-ID: <20100202025328.030C141A38@hg.openjdk.java.net> Changeset: 87684f1a88b5 Author: kvn Date: 2010-02-01 16:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87684f1a88b5 6614597: Performance variability in jvm2008 xml.validation Summary: Fix incorrect marking of methods as not compilable. Reviewed-by: never ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/globals.hpp From rasbold at google.com Tue Feb 2 11:53:06 2010 From: rasbold at google.com (Chuck Rasbold) Date: Tue, 2 Feb 2010 11:53:06 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: <510AC596-9287-46ED-850A-0CC8BD0E4764@Sun.COM> References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> <88B629FD-EF4C-447E-AA52-90C26AF39B0E@sun.com> <510AC596-9287-46ED-850A-0CC8BD0E4764@Sun.COM> Message-ID: <4149a0431002021153m72c0f549v2461e726c1d1c8eb@mail.gmail.com> With the proper bug id, an updated webrev is here http://cr.openjdk.java.net/~rasbold/6921969/webrev.01/ Aside from the bugId, this webrev is otherwise identical to the last link posted on this thread -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100202/5bc6d5f6/attachment.html From yamauchi at google.com Tue Feb 2 13:15:15 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 2 Feb 2010 13:15:15 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> Message-ID: I will work on this. Hiroshi On Mon, Feb 1, 2010 at 4:18 PM, Tom Rodriguez wrote: > The assembler changes look good but I'd rather have the predicate stuff in the ad file instead of over in MulLNode. ?The normal way make ad helper functions is to put it into the ad file itself in the source block. ?There's a section of the ad file which begins with "source %{" and it's included verbatim in the main generated ad file. ?So just add is_operand_hi32_zero as a static function in the source block. > > tom > > On Feb 1, 2010, at 3:34 PM, Hiroshi Yamauchi wrote: > >> I think it's a little more readable this way: >> >> http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ >> >> Hiroshi >> >> On Mon, Feb 1, 2010 at 2:01 PM, Tom Rodriguez wrote: >>> >>> On Feb 1, 2010, at 10:18 AM, Hiroshi Yamauchi wrote: >>> >>>> Hi Christian, >>>> >>>>> I think that's a good change. ?I have two comments: personally I prefer to >>>>> use assembler instructions directly in the ins_encode than writing >>>>> very-hard-to-read enc_class methods and the predicates are kind of ugly, but >>>>> I don't know if that could be done any better. >>> >>> The predicates are ugly but we don't currently have a better mechanism. ?The cleaner way this could be expressed would be: >>> >>> predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); >>> >>> but the Matcher doesn't capture the type table from the last phase of GVN. ?The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. ?It returns the worst case type TypeLong::LONG. ?Only the type table captures the improved type that we computed though iter GVN. ?If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. ?Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. ?I think in most interesting cases the predicate will work correctly though. ?It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. ?Anyway, I think the predicates are fine for this purpose. >>> >>>> >>>> I'll see if I can do it better that way. >>>> >>>>> Maybe, given that we probably support more 32-bit architectures in the >>>>> future, we could model such instructions in ideal (e.g. in a pass that's >>>>> only used on 32-bit). >>>> >>>> I agree that it'd be easier and probably more effective to apply the >>>> same optimization at the ideal graph level. >>> >>> I agree that it would be nice if these optimizations kind of fell out more automatically but I'm leery of adding yet more one off ideal nodes to describe machine dependent operations. ?Maybe there is a reasonable set that could be used for decomposing 64-bit operations into a clean set of 32 bit operations, though I think that might have ramifications for the register allocator since we represent longs as pairs. ?We're definitely emitting less than optimal sequences for 64 bit operations in 32 mode. >>> >>> tom >>> >>>> >>>> Thanks, >>>> Hiroshi >>> >>> > > From Thomas.Rodriguez at Sun.COM Tue Feb 2 14:15:09 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 02 Feb 2010 14:15:09 -0800 Subject: review (S) for 6921922: fix for 6911204 breaks tagged stack interpreter Message-ID: http://cr.openjdk.java.net/~never/6921922 From Vladimir.Kozlov at Sun.COM Tue Feb 2 14:59:35 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 02 Feb 2010 14:59:35 -0800 Subject: review (S) for 6921922: fix for 6911204 breaks tagged stack interpreter In-Reply-To: References: Message-ID: <4B68AE57.30302@sun.com> Looks very good. sharedRuntime.hpp + // Captures code and signature used to generate this sdapter when ^ Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6921922 From Thomas.Rodriguez at Sun.COM Tue Feb 2 15:55:27 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 02 Feb 2010 15:55:27 -0800 Subject: review (S) for 6921922: fix for 6911204 breaks tagged stack interpreter In-Reply-To: <4B68AE57.30302@sun.com> References: <4B68AE57.30302@sun.com> Message-ID: <5C1D4F15-B664-47A0-924C-5F63962CDAAA@Sun.COM> Fixed. Thanks! tom On Feb 2, 2010, at 2:59 PM, Vladimir Kozlov wrote: > Looks very good. > > sharedRuntime.hpp > > + // Captures code and signature used to generate this sdapter when > ^ > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6921922 From yamauchi at google.com Wed Feb 3 11:52:46 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 3 Feb 2010 11:52:46 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> Message-ID: OK. I moved is_operand_hi32_zero to the ad file. http://cr.openjdk.java.net/~rasbold/6921969/webrev.02/ On Tue, Feb 2, 2010 at 1:15 PM, Hiroshi Yamauchi wrote: > I will work on this. > > Hiroshi > > On Mon, Feb 1, 2010 at 4:18 PM, Tom Rodriguez wrote: >> The assembler changes look good but I'd rather have the predicate stuff in the ad file instead of over in MulLNode. ?The normal way make ad helper functions is to put it into the ad file itself in the source block. ?There's a section of the ad file which begins with "source %{" and it's included verbatim in the main generated ad file. ?So just add is_operand_hi32_zero as a static function in the source block. >> >> tom >> >> On Feb 1, 2010, at 3:34 PM, Hiroshi Yamauchi wrote: >> >>> I think it's a little more readable this way: >>> >>> http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ >>> >>> Hiroshi >>> >>> On Mon, Feb 1, 2010 at 2:01 PM, Tom Rodriguez wrote: >>>> >>>> On Feb 1, 2010, at 10:18 AM, Hiroshi Yamauchi wrote: >>>> >>>>> Hi Christian, >>>>> >>>>>> I think that's a good change. ?I have two comments: personally I prefer to >>>>>> use assembler instructions directly in the ins_encode than writing >>>>>> very-hard-to-read enc_class methods and the predicates are kind of ugly, but >>>>>> I don't know if that could be done any better. >>>> >>>> The predicates are ugly but we don't currently have a better mechanism. ?The cleaner way this could be expressed would be: >>>> >>>> predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); >>>> >>>> but the Matcher doesn't capture the type table from the last phase of GVN. ?The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. ?It returns the worst case type TypeLong::LONG. ?Only the type table captures the improved type that we computed though iter GVN. ?If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. ?Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. ?I think in most interesting cases the predicate will work correctly though. ?It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. ?Anyway, I think the predicates are fine for this purpose. >>>> >>>>> >>>>> I'll see if I can do it better that way. >>>>> >>>>>> Maybe, given that we probably support more 32-bit architectures in the >>>>>> future, we could model such instructions in ideal (e.g. in a pass that's >>>>>> only used on 32-bit). >>>>> >>>>> I agree that it'd be easier and probably more effective to apply the >>>>> same optimization at the ideal graph level. >>>> >>>> I agree that it would be nice if these optimizations kind of fell out more automatically but I'm leery of adding yet more one off ideal nodes to describe machine dependent operations. ?Maybe there is a reasonable set that could be used for decomposing 64-bit operations into a clean set of 32 bit operations, though I think that might have ramifications for the register allocator since we represent longs as pairs. ?We're definitely emitting less than optimal sequences for 64 bit operations in 32 mode. >>>> >>>> tom >>>> >>>>> >>>>> Thanks, >>>>> Hiroshi >>>> >>>> >> >> > From Thomas.Rodriguez at Sun.COM Wed Feb 3 12:07:39 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 03 Feb 2010 12:07:39 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> Message-ID: <184A76C0-5EF4-40A1-95D5-C7508A773CDF@Sun.COM> The cast is unneeded and I don't like the use of a bool for input selection. Would you mind if it were like this: +source_hpp %{ +// Must be visible to the DFA in dfa_x86_32.cpp +extern bool is_operand_hi32_zero(Node* n); +%} + +// Returns true if the high 32 bits of the value is known to be zero. +bool is_operand_hi32_zero(Node* n) { + int opc = n->Opcode(); + if (opc == Op_LoadUI2L) { + return true; + } + if (opc == Op_AndL) { + Node* o2 = n->in(2); + if (o2->is_Con() && (o2->get_long() & 0xFFFFFFFF00000000LL) == 0LL) { + return true; + } + } + return false; +} + + predicate(is_operand_hi32_zero(n->in(1))); + predicate(is_operand_hi32_zero(n->in(2))); + predicate(is_operand_hi32_zero(n->in(1)) && is_operand_hi32_zero(n->in(2))); tom On Feb 3, 2010, at 11:52 AM, Hiroshi Yamauchi wrote: > OK. I moved is_operand_hi32_zero to the ad file. > > http://cr.openjdk.java.net/~rasbold/6921969/webrev.02/ > > On Tue, Feb 2, 2010 at 1:15 PM, Hiroshi Yamauchi wrote: >> I will work on this. >> >> Hiroshi >> >> On Mon, Feb 1, 2010 at 4:18 PM, Tom Rodriguez wrote: >>> The assembler changes look good but I'd rather have the predicate stuff in the ad file instead of over in MulLNode. The normal way make ad helper functions is to put it into the ad file itself in the source block. There's a section of the ad file which begins with "source %{" and it's included verbatim in the main generated ad file. So just add is_operand_hi32_zero as a static function in the source block. >>> >>> tom >>> >>> On Feb 1, 2010, at 3:34 PM, Hiroshi Yamauchi wrote: >>> >>>> I think it's a little more readable this way: >>>> >>>> http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ >>>> >>>> Hiroshi >>>> >>>> On Mon, Feb 1, 2010 at 2:01 PM, Tom Rodriguez wrote: >>>>> >>>>> On Feb 1, 2010, at 10:18 AM, Hiroshi Yamauchi wrote: >>>>> >>>>>> Hi Christian, >>>>>> >>>>>>> I think that's a good change. I have two comments: personally I prefer to >>>>>>> use assembler instructions directly in the ins_encode than writing >>>>>>> very-hard-to-read enc_class methods and the predicates are kind of ugly, but >>>>>>> I don't know if that could be done any better. >>>>> >>>>> The predicates are ugly but we don't currently have a better mechanism. The cleaner way this could be expressed would be: >>>>> >>>>> predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); >>>>> >>>>> but the Matcher doesn't capture the type table from the last phase of GVN. The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. It returns the worst case type TypeLong::LONG. Only the type table captures the improved type that we computed though iter GVN. If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. I think in most interesting cases the predicate will work correctly though. It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. Anyway, I think the predicates are fine for this purpose. >>>>> >>>>>> >>>>>> I'll see if I can do it better that way. >>>>>> >>>>>>> Maybe, given that we probably support more 32-bit architectures in the >>>>>>> future, we could model such instructions in ideal (e.g. in a pass that's >>>>>>> only used on 32-bit). >>>>>> >>>>>> I agree that it'd be easier and probably more effective to apply the >>>>>> same optimization at the ideal graph level. >>>>> >>>>> I agree that it would be nice if these optimizations kind of fell out more automatically but I'm leery of adding yet more one off ideal nodes to describe machine dependent operations. Maybe there is a reasonable set that could be used for decomposing 64-bit operations into a clean set of 32 bit operations, though I think that might have ramifications for the register allocator since we represent longs as pairs. We're definitely emitting less than optimal sequences for 64 bit operations in 32 mode. >>>>> >>>>> tom >>>>> >>>>>> >>>>>> Thanks, >>>>>> Hiroshi >>>>> >>>>> >>> >>> >> From Vladimir.Kozlov at Sun.COM Wed Feb 3 12:41:48 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 03 Feb 2010 12:41:48 -0800 Subject: Request for reviews (S): 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly Message-ID: <4B69DF8C.4000008@sun.com> http://cr.openjdk.java.net/~kvn/6923043/webrev Fixed 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly The intention of changes in 6614597 was to print "made not compilable" line for methods for which compilation was disabled due to frequent deoptimizations. But it prints such line also for methods for which compilation was disabled due to CompilerOracle options (Exclude, CompileOnly, CIStart, CIStop). The fix is to path flag to methodOopDesc::set_not_compilable() to print the line only for deoptimizations. Reviewed by: Fix verified (y/n): y, failed test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Wed Feb 3 13:03:40 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 03 Feb 2010 13:03:40 -0800 Subject: Request for reviews (S): 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly In-Reply-To: <4B69DF8C.4000008@sun.com> References: <4B69DF8C.4000008@sun.com> Message-ID: <9696D58D-63BE-48F9-8253-811D0D1E4212@sun.com> Which test did this cause to fail? I think it would be better for the default to be reporting, particularly since I think you missed a couple in compilerBroker that should be reported. Maybe we should add set_not_compilable_quietly for use by the various oracle routines that supplies the correct arguments. tom On Feb 3, 2010, at 12:41 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6923043/webrev > > Fixed 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly > > The intention of changes in 6614597 was to print "made not compilable" line > for methods for which compilation was disabled due to frequent deoptimizations. > But it prints such line also for methods for which compilation was disabled > due to CompilerOracle options (Exclude, CompileOnly, CIStart, CIStop). > > The fix is to path flag to methodOopDesc::set_not_compilable() to print > the line only for deoptimizations. > > Reviewed by: > > Fix verified (y/n): y, failed test > > Other testing: > JPRT > From Thomas.Rodriguez at Sun.COM Wed Feb 3 13:39:22 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 03 Feb 2010 13:39:22 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: <184A76C0-5EF4-40A1-95D5-C7508A773CDF@Sun.COM> References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> <184A76C0-5EF4-40A1-95D5-C7508A773CDF@Sun.COM> Message-ID: <5BFB037B-A181-4B9A-8CFD-0E6A37F87B28@sun.com> Is http://cr.openjdk.java.net/~never/6921969 ok? I made the changes I proposed and also adjusted the copyright on the test to include the GPL language and removed your email address from it. I believe that's the correct format but someone correct me if it isn't. If it's ok then I will push it. tom On Feb 3, 2010, at 12:07 PM, Tom Rodriguez wrote: > The cast is unneeded and I don't like the use of a bool for input selection. Would you mind if it were like this: > > +source_hpp %{ > +// Must be visible to the DFA in dfa_x86_32.cpp > +extern bool is_operand_hi32_zero(Node* n); > +%} > + > > +// Returns true if the high 32 bits of the value is known to be zero. > +bool is_operand_hi32_zero(Node* n) { > + int opc = n->Opcode(); > + if (opc == Op_LoadUI2L) { > + return true; > + } > + if (opc == Op_AndL) { > + Node* o2 = n->in(2); > + if (o2->is_Con() && (o2->get_long() & 0xFFFFFFFF00000000LL) == 0LL) { > + return true; > + } > + } > + return false; > +} > + > > + predicate(is_operand_hi32_zero(n->in(1))); > > + predicate(is_operand_hi32_zero(n->in(2))); > > + predicate(is_operand_hi32_zero(n->in(1)) && is_operand_hi32_zero(n->in(2))); > > tom > > On Feb 3, 2010, at 11:52 AM, Hiroshi Yamauchi wrote: > >> OK. I moved is_operand_hi32_zero to the ad file. >> >> http://cr.openjdk.java.net/~rasbold/6921969/webrev.02/ >> >> On Tue, Feb 2, 2010 at 1:15 PM, Hiroshi Yamauchi wrote: >>> I will work on this. >>> >>> Hiroshi >>> >>> On Mon, Feb 1, 2010 at 4:18 PM, Tom Rodriguez wrote: >>>> The assembler changes look good but I'd rather have the predicate stuff in the ad file instead of over in MulLNode. The normal way make ad helper functions is to put it into the ad file itself in the source block. There's a section of the ad file which begins with "source %{" and it's included verbatim in the main generated ad file. So just add is_operand_hi32_zero as a static function in the source block. >>>> >>>> tom >>>> >>>> On Feb 1, 2010, at 3:34 PM, Hiroshi Yamauchi wrote: >>>> >>>>> I think it's a little more readable this way: >>>>> >>>>> http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ >>>>> >>>>> Hiroshi >>>>> >>>>> On Mon, Feb 1, 2010 at 2:01 PM, Tom Rodriguez wrote: >>>>>> >>>>>> On Feb 1, 2010, at 10:18 AM, Hiroshi Yamauchi wrote: >>>>>> >>>>>>> Hi Christian, >>>>>>> >>>>>>>> I think that's a good change. I have two comments: personally I prefer to >>>>>>>> use assembler instructions directly in the ins_encode than writing >>>>>>>> very-hard-to-read enc_class methods and the predicates are kind of ugly, but >>>>>>>> I don't know if that could be done any better. >>>>>> >>>>>> The predicates are ugly but we don't currently have a better mechanism. The cleaner way this could be expressed would be: >>>>>> >>>>>> predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); >>>>>> >>>>>> but the Matcher doesn't capture the type table from the last phase of GVN. The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. It returns the worst case type TypeLong::LONG. Only the type table captures the improved type that we computed though iter GVN. If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. I think in most interesting cases the predicate will work correctly though. It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. Anyway, I think the predicates are fine for this purpose. >>>>>> >>>>>>> >>>>>>> I'll see if I can do it better that way. >>>>>>> >>>>>>>> Maybe, given that we probably support more 32-bit architectures in the >>>>>>>> future, we could model such instructions in ideal (e.g. in a pass that's >>>>>>>> only used on 32-bit). >>>>>>> >>>>>>> I agree that it'd be easier and probably more effective to apply the >>>>>>> same optimization at the ideal graph level. >>>>>> >>>>>> I agree that it would be nice if these optimizations kind of fell out more automatically but I'm leery of adding yet more one off ideal nodes to describe machine dependent operations. Maybe there is a reasonable set that could be used for decomposing 64-bit operations into a clean set of 32 bit operations, though I think that might have ramifications for the register allocator since we represent longs as pairs. We're definitely emitting less than optimal sequences for 64 bit operations in 32 mode. >>>>>> >>>>>> tom >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Hiroshi >>>>>> >>>>>> >>>> >>>> >>> > From Thomas.Rodriguez at Sun.COM Wed Feb 3 13:41:17 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 03 Feb 2010 13:41:17 -0800 Subject: review (S) for 6920293: OptimizeStringConcat causing core dumps Message-ID: <754E1F6D-320C-43B2-986F-19AB80AC2CE1@sun.com> http://cr.openjdk.java.net/~never/6920293 6920293: OptimizeStringConcat causing core dumps Reviewed-by: The code for the idiom a == null ? "null" : a) in OptimizeStringConcat was putting an explicit NOTNULL on the result Phi which allowed the optimizer to move some loads above the null check which caused a crash. The fix is to use the same idiom the parser uses which is to cast the resulting value to be notnull and leave the phi type alone. Tested with failing test from report. I also made some changes to error reporting to make the crash output more useful. Currently if we don't find an implicit exception handler we die inside the VM and don't print out much useful information. Instead we should simply return null and let the VMError machinery produce a normal crash dump. I also fixed the formatting for the register in 64 bit mode on solaris to match the linux formatting. src/share/vm/opto/stringopts.cpp src/share/vm/runtime/sharedRuntime.cpp src/share/vm/code/nmethod.cpp src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp From Vladimir.Kozlov at Sun.COM Wed Feb 3 14:08:37 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 03 Feb 2010 14:08:37 -0800 Subject: Request for reviews (S): 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly In-Reply-To: <9696D58D-63BE-48F9-8253-811D0D1E4212@sun.com> References: <4B69DF8C.4000008@sun.com> <9696D58D-63BE-48F9-8253-811D0D1E4212@sun.com> Message-ID: <4B69F3E5.6090402@sun.com> Tom Rodriguez wrote: > Which test did this cause to fail? I think it would be better for the default to be reporting, particularly since I think you missed a couple in compilerBroker that should be reported. Maybe we should add set_not_compilable_quietly for use by the various oracle routines that supplies the correct arguments. You are right, I missed few cases. I set the default to report. http://cr.openjdk.java.net/~kvn/6923043/webrev.01 I don't think we should add global set_not_compilable_quietly since the methods which are still compilable could be deoptimized and we want report the case. Test failed because it greps output for Exception: test/closed/compiler/4903383/Test4903383.sh made not compilable java.lang.Thread:: (49 bytes) made not compilable java.lang.System::getProperty (25 bytes) ... made not compilable java.lang.Exception:: (7 bytes) ------------------------------------ grep "java.lang.Exception" test.out if [ $? = 0 ] then echo "Test Failed" exit 1 else echo "Test Passed" exit 0 fi ----------------------------------- Thanks, Vladimir > > tom > > On Feb 3, 2010, at 12:41 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6923043/webrev >> >> Fixed 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly >> >> The intention of changes in 6614597 was to print "made not compilable" line >> for methods for which compilation was disabled due to frequent deoptimizations. >> But it prints such line also for methods for which compilation was disabled >> due to CompilerOracle options (Exclude, CompileOnly, CIStart, CIStop). >> >> The fix is to path flag to methodOopDesc::set_not_compilable() to print >> the line only for deoptimizations. >> >> Reviewed by: >> >> Fix verified (y/n): y, failed test >> >> Other testing: >> JPRT >> > From Vladimir.Kozlov at Sun.COM Wed Feb 3 14:16:04 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 03 Feb 2010 14:16:04 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: <5BFB037B-A181-4B9A-8CFD-0E6A37F87B28@sun.com> References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> <184A76C0-5EF4-40A1-95D5-C7508A773CDF@Sun.COM> <5BFB037B-A181-4B9A-8CFD-0E6A37F87B28@sun.com> Message-ID: <4B69F5A4.5010801@sun.com> Looks good. Vladimir Tom Rodriguez wrote: > Is http://cr.openjdk.java.net/~never/6921969 ok? I made the changes I proposed and also adjusted the copyright on the test to include the GPL language and removed your email address from it. I believe that's the correct format but someone correct me if it isn't. If it's ok then I will push it. > > tom > > On Feb 3, 2010, at 12:07 PM, Tom Rodriguez wrote: > >> The cast is unneeded and I don't like the use of a bool for input selection. Would you mind if it were like this: >> >> +source_hpp %{ >> +// Must be visible to the DFA in dfa_x86_32.cpp >> +extern bool is_operand_hi32_zero(Node* n); >> +%} >> + >> >> +// Returns true if the high 32 bits of the value is known to be zero. >> +bool is_operand_hi32_zero(Node* n) { >> + int opc = n->Opcode(); >> + if (opc == Op_LoadUI2L) { >> + return true; >> + } >> + if (opc == Op_AndL) { >> + Node* o2 = n->in(2); >> + if (o2->is_Con() && (o2->get_long() & 0xFFFFFFFF00000000LL) == 0LL) { >> + return true; >> + } >> + } >> + return false; >> +} >> + >> >> + predicate(is_operand_hi32_zero(n->in(1))); >> >> + predicate(is_operand_hi32_zero(n->in(2))); >> >> + predicate(is_operand_hi32_zero(n->in(1)) && is_operand_hi32_zero(n->in(2))); >> >> tom >> >> On Feb 3, 2010, at 11:52 AM, Hiroshi Yamauchi wrote: >> >>> OK. I moved is_operand_hi32_zero to the ad file. >>> >>> http://cr.openjdk.java.net/~rasbold/6921969/webrev.02/ >>> >>> On Tue, Feb 2, 2010 at 1:15 PM, Hiroshi Yamauchi wrote: >>>> I will work on this. >>>> >>>> Hiroshi >>>> >>>> On Mon, Feb 1, 2010 at 4:18 PM, Tom Rodriguez wrote: >>>>> The assembler changes look good but I'd rather have the predicate stuff in the ad file instead of over in MulLNode. The normal way make ad helper functions is to put it into the ad file itself in the source block. There's a section of the ad file which begins with "source %{" and it's included verbatim in the main generated ad file. So just add is_operand_hi32_zero as a static function in the source block. >>>>> >>>>> tom >>>>> >>>>> On Feb 1, 2010, at 3:34 PM, Hiroshi Yamauchi wrote: >>>>> >>>>>> I think it's a little more readable this way: >>>>>> >>>>>> http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ >>>>>> >>>>>> Hiroshi >>>>>> >>>>>> On Mon, Feb 1, 2010 at 2:01 PM, Tom Rodriguez wrote: >>>>>>> On Feb 1, 2010, at 10:18 AM, Hiroshi Yamauchi wrote: >>>>>>> >>>>>>>> Hi Christian, >>>>>>>> >>>>>>>>> I think that's a good change. I have two comments: personally I prefer to >>>>>>>>> use assembler instructions directly in the ins_encode than writing >>>>>>>>> very-hard-to-read enc_class methods and the predicates are kind of ugly, but >>>>>>>>> I don't know if that could be done any better. >>>>>>> The predicates are ugly but we don't currently have a better mechanism. The cleaner way this could be expressed would be: >>>>>>> >>>>>>> predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); >>>>>>> >>>>>>> but the Matcher doesn't capture the type table from the last phase of GVN. The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. It returns the worst case type TypeLong::LONG. Only the type table captures the improved type that we computed though iter GVN. If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. I think in most interesting cases the predicate will work correctly though. It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. Anyway, I think the predicates are fine for this purpose. >>>>>>> >>>>>>>> I'll see if I can do it better that way. >>>>>>>> >>>>>>>>> Maybe, given that we probably support more 32-bit architectures in the >>>>>>>>> future, we could model such instructions in ideal (e.g. in a pass that's >>>>>>>>> only used on 32-bit). >>>>>>>> I agree that it'd be easier and probably more effective to apply the >>>>>>>> same optimization at the ideal graph level. >>>>>>> I agree that it would be nice if these optimizations kind of fell out more automatically but I'm leery of adding yet more one off ideal nodes to describe machine dependent operations. Maybe there is a reasonable set that could be used for decomposing 64-bit operations into a clean set of 32 bit operations, though I think that might have ramifications for the register allocator since we represent longs as pairs. We're definitely emitting less than optimal sequences for 64 bit operations in 32 mode. >>>>>>> >>>>>>> tom >>>>>>> >>>>>>>> Thanks, >>>>>>>> Hiroshi >>>>>>> >>>>> > From thomas.rodriguez at sun.com Wed Feb 3 14:22:34 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 03 Feb 2010 22:22:34 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6921922: fix for 6911204 breaks tagged stack interpreter Message-ID: <20100203222237.807CA41CCB@hg.openjdk.java.net> Changeset: 74c848d437ab Author: never Date: 2010-02-03 12:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/74c848d437ab 6921922: fix for 6911204 breaks tagged stack interpreter Reviewed-by: kvn ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp From Thomas.Rodriguez at Sun.COM Wed Feb 3 14:28:30 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 03 Feb 2010 14:28:30 -0800 Subject: Request for reviews (S): 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly In-Reply-To: <4B69F3E5.6090402@sun.com> References: <4B69DF8C.4000008@sun.com> <9696D58D-63BE-48F9-8253-811D0D1E4212@sun.com> <4B69F3E5.6090402@sun.com> Message-ID: <3F02FC6A-9BC8-41FE-83E2-2F03A2C39F64@Sun.COM> On Feb 3, 2010, at 2:08 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> Which test did this cause to fail? I think it would be better for the default to be reporting, particularly since I think you missed a couple in compilerBroker that should be reported. Maybe we should add set_not_compilable_quietly for use by the various oracle routines that supplies the correct arguments. > > You are right, I missed few cases. I set the default to report. > > http://cr.openjdk.java.net/~kvn/6923043/webrev.01 > > I don't think we should add global set_not_compilable_quietly since the methods > which are still compilable could be deoptimized and we want report the case. I meant that we should add: void set_not_compilable_quietly(int comp_level = CompLevel_highest_tier) { set_not_compilable(comp_level, false); } so you don't have to guess what false means. tom > > > Test failed because it greps output for Exception: > > test/closed/compiler/4903383/Test4903383.sh > > made not compilable java.lang.Thread:: (49 bytes) > made not compilable java.lang.System::getProperty (25 bytes) > ... > made not compilable java.lang.Exception:: (7 bytes) > ------------------------------------ > grep "java.lang.Exception" test.out > > if [ $? = 0 ] > then > echo "Test Failed" > exit 1 > else > echo "Test Passed" > exit 0 > fi > ----------------------------------- > > Thanks, > Vladimir > >> tom >> On Feb 3, 2010, at 12:41 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6923043/webrev >>> >>> Fixed 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly >>> >>> The intention of changes in 6614597 was to print "made not compilable" line >>> for methods for which compilation was disabled due to frequent deoptimizations. >>> But it prints such line also for methods for which compilation was disabled >>> due to CompilerOracle options (Exclude, CompileOnly, CIStart, CIStop). >>> >>> The fix is to path flag to methodOopDesc::set_not_compilable() to print >>> the line only for deoptimizations. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, failed test >>> >>> Other testing: >>> JPRT >>> From Vladimir.Kozlov at Sun.COM Wed Feb 3 14:28:55 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 03 Feb 2010 14:28:55 -0800 Subject: review (S) for 6920293: OptimizeStringConcat causing core dumps In-Reply-To: <754E1F6D-320C-43B2-986F-19AB80AC2CE1@sun.com> References: <754E1F6D-320C-43B2-986F-19AB80AC2CE1@sun.com> Message-ID: <4B69F8A7.5040506@sun.com> The changes seem correct. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6920293 > > 6920293: OptimizeStringConcat causing core dumps > Reviewed-by: > > The code for the idiom a == null ? "null" : a) in OptimizeStringConcat > was putting an explicit NOTNULL on the result Phi which allowed the > optimizer to move some loads above the null check which caused a > crash. The fix is to use the same idiom the parser uses which is to > cast the resulting value to be notnull and leave the phi type alone. > Tested with failing test from report. I also made some changes to > error reporting to make the crash output more useful. Currently if we > don't find an implicit exception handler we die inside the VM and > don't print out much useful information. Instead we should simply > return null and let the VMError machinery produce a normal crash dump. > I also fixed the formatting for the register in 64 bit mode on solaris > to match the linux formatting. > > src/share/vm/opto/stringopts.cpp > src/share/vm/runtime/sharedRuntime.cpp > src/share/vm/code/nmethod.cpp > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp From Vladimir.Kozlov at Sun.COM Wed Feb 3 14:45:40 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 03 Feb 2010 14:45:40 -0800 Subject: Request for reviews (S): 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly In-Reply-To: <3F02FC6A-9BC8-41FE-83E2-2F03A2C39F64@Sun.COM> References: <4B69DF8C.4000008@sun.com> <9696D58D-63BE-48F9-8253-811D0D1E4212@sun.com> <4B69F3E5.6090402@sun.com> <3F02FC6A-9BC8-41FE-83E2-2F03A2C39F64@Sun.COM> Message-ID: <4B69FC94.9010601@sun.com> Tom Rodriguez wrote: >> >> I don't think we should add global set_not_compilable_quietly since the methods >> which are still compilable could be deoptimized and we want report the case. > > I meant that we should add: > > void set_not_compilable_quietly(int comp_level = CompLevel_highest_tier) { > set_not_compilable(comp_level, false); > } > > so you don't have to guess what false means. http://cr.openjdk.java.net/~kvn/6923043/webrev.02 Done. Sorry, I misunderstood you. Vladimir From Thomas.Rodriguez at Sun.COM Wed Feb 3 14:57:39 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 03 Feb 2010 14:57:39 -0800 Subject: Request for reviews (S): 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly In-Reply-To: <4B69FC94.9010601@sun.com> References: <4B69DF8C.4000008@sun.com> <9696D58D-63BE-48F9-8253-811D0D1E4212@sun.com> <4B69F3E5.6090402@sun.com> <3F02FC6A-9BC8-41FE-83E2-2F03A2C39F64@Sun.COM> <4B69FC94.9010601@sun.com> Message-ID: I was a little cryptic. Anyway, this looks good. tom On Feb 3, 2010, at 2:45 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >>> >>> I don't think we should add global set_not_compilable_quietly since the methods >>> which are still compilable could be deoptimized and we want report the case. >> I meant that we should add: >> void set_not_compilable_quietly(int comp_level = CompLevel_highest_tier) { >> set_not_compilable(comp_level, false); >> } >> so you don't have to guess what false means. > > http://cr.openjdk.java.net/~kvn/6923043/webrev.02 > > Done. Sorry, I misunderstood you. > > Vladimir > From Vladimir.Kozlov at Sun.COM Wed Feb 3 15:02:48 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 03 Feb 2010 15:02:48 -0800 Subject: Request for reviews (S): 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly In-Reply-To: References: <4B69DF8C.4000008@sun.com> <9696D58D-63BE-48F9-8253-811D0D1E4212@sun.com> <4B69F3E5.6090402@sun.com> <3F02FC6A-9BC8-41FE-83E2-2F03A2C39F64@Sun.COM> <4B69FC94.9010601@sun.com> Message-ID: <4B6A0098.3020506@sun.com> Thanks Vladimir Tom Rodriguez wrote: > I was a little cryptic. Anyway, this looks good. > > tom > > On Feb 3, 2010, at 2:45 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>>> I don't think we should add global set_not_compilable_quietly since the methods >>>> which are still compilable could be deoptimized and we want report the case. >>> I meant that we should add: >>> void set_not_compilable_quietly(int comp_level = CompLevel_highest_tier) { >>> set_not_compilable(comp_level, false); >>> } >>> so you don't have to guess what false means. >> http://cr.openjdk.java.net/~kvn/6923043/webrev.02 >> >> Done. Sorry, I misunderstood you. >> >> Vladimir >> > From yamauchi at google.com Wed Feb 3 15:32:40 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 3 Feb 2010 15:32:40 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: <5BFB037B-A181-4B9A-8CFD-0E6A37F87B28@sun.com> References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> <184A76C0-5EF4-40A1-95D5-C7508A773CDF@Sun.COM> <5BFB037B-A181-4B9A-8CFD-0E6A37F87B28@sun.com> Message-ID: Tom, Yes, it looks good to me. Thanks for applying the changes. I reran the test and verified the speedup in a benchmark with that. I'm not sure about the copyright, but if that follows a previous test file that Chuck created before, then it's probably fine. Thanks. Hiroshi On Wed, Feb 3, 2010 at 1:39 PM, Tom Rodriguez wrote: > Is http://cr.openjdk.java.net/~never/6921969 ok? ?I made the changes I proposed and also adjusted the copyright on the test to include the GPL language and removed your email address from it. ?I believe that's the correct format but someone correct me if it isn't. ?If it's ok then I will push it. > > tom > > On Feb 3, 2010, at 12:07 PM, Tom Rodriguez wrote: > >> The cast is unneeded and I don't like the use of a bool for input selection. ?Would you mind if it were like this: >> >> +source_hpp %{ >> +// Must be visible to the DFA in dfa_x86_32.cpp >> +extern bool is_operand_hi32_zero(Node* n); >> +%} >> + >> >> +// Returns true if the high 32 bits of the value is known to be zero. >> +bool is_operand_hi32_zero(Node* n) { >> + ?int opc = n->Opcode(); >> + ?if (opc == Op_LoadUI2L) { >> + ? ?return true; >> + ?} >> + ?if (opc == Op_AndL) { >> + ? ?Node* o2 = n->in(2); >> + ? ?if (o2->is_Con() && (o2->get_long() & 0xFFFFFFFF00000000LL) == 0LL) { >> + ? ? ?return true; >> + ? ?} >> + ?} >> + ?return false; >> +} >> + >> >> + ?predicate(is_operand_hi32_zero(n->in(1))); >> >> + ?predicate(is_operand_hi32_zero(n->in(2))); >> >> + ?predicate(is_operand_hi32_zero(n->in(1)) && is_operand_hi32_zero(n->in(2))); >> >> tom >> >> On Feb 3, 2010, at 11:52 AM, Hiroshi Yamauchi wrote: >> >>> OK. I moved is_operand_hi32_zero to the ad file. >>> >>> http://cr.openjdk.java.net/~rasbold/6921969/webrev.02/ >>> >>> On Tue, Feb 2, 2010 at 1:15 PM, Hiroshi Yamauchi wrote: >>>> I will work on this. >>>> >>>> Hiroshi >>>> >>>> On Mon, Feb 1, 2010 at 4:18 PM, Tom Rodriguez wrote: >>>>> The assembler changes look good but I'd rather have the predicate stuff in the ad file instead of over in MulLNode. ?The normal way make ad helper functions is to put it into the ad file itself in the source block. ?There's a section of the ad file which begins with "source %{" and it's included verbatim in the main generated ad file. ?So just add is_operand_hi32_zero as a static function in the source block. >>>>> >>>>> tom >>>>> >>>>> On Feb 1, 2010, at 3:34 PM, Hiroshi Yamauchi wrote: >>>>> >>>>>> I think it's a little more readable this way: >>>>>> >>>>>> http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ >>>>>> >>>>>> Hiroshi >>>>>> >>>>>> On Mon, Feb 1, 2010 at 2:01 PM, Tom Rodriguez wrote: >>>>>>> >>>>>>> On Feb 1, 2010, at 10:18 AM, Hiroshi Yamauchi wrote: >>>>>>> >>>>>>>> Hi Christian, >>>>>>>> >>>>>>>>> I think that's a good change. ?I have two comments: personally I prefer to >>>>>>>>> use assembler instructions directly in the ins_encode than writing >>>>>>>>> very-hard-to-read enc_class methods and the predicates are kind of ugly, but >>>>>>>>> I don't know if that could be done any better. >>>>>>> >>>>>>> The predicates are ugly but we don't currently have a better mechanism. ?The cleaner way this could be expressed would be: >>>>>>> >>>>>>> predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); >>>>>>> >>>>>>> but the Matcher doesn't capture the type table from the last phase of GVN. ?The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. ?It returns the worst case type TypeLong::LONG. ?Only the type table captures the improved type that we computed though iter GVN. ?If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. ?Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. ?I think in most interesting cases the predicate will work correctly though. ?It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. ?Anyway, I think the predicates are fine for this purpose. >>>>>>> >>>>>>>> >>>>>>>> I'll see if I can do it better that way. >>>>>>>> >>>>>>>>> Maybe, given that we probably support more 32-bit architectures in the >>>>>>>>> future, we could model such instructions in ideal (e.g. in a pass that's >>>>>>>>> only used on 32-bit). >>>>>>>> >>>>>>>> I agree that it'd be easier and probably more effective to apply the >>>>>>>> same optimization at the ideal graph level. >>>>>>> >>>>>>> I agree that it would be nice if these optimizations kind of fell out more automatically but I'm leery of adding yet more one off ideal nodes to describe machine dependent operations. ?Maybe there is a reasonable set that could be used for decomposing 64-bit operations into a clean set of 32 bit operations, though I think that might have ramifications for the register allocator since we represent longs as pairs. ?We're definitely emitting less than optimal sequences for 64 bit operations in 32 mode. >>>>>>> >>>>>>> tom >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Hiroshi >>>>>>> >>>>>>> >>>>> >>>>> >>>> >> > > From Thomas.Rodriguez at Sun.COM Wed Feb 3 15:56:42 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 03 Feb 2010 15:56:42 -0800 Subject: Long multiplication and BigInteger.mulAdd on x86_32 In-Reply-To: References: <4B62AFFB.10707@Sun.COM> <12419880-3C7D-4CB0-A549-ECAB756C3394@Sun.COM> <184A76C0-5EF4-40A1-95D5-C7508A773CDF@Sun.COM> <5BFB037B-A181-4B9A-8CFD-0E6A37F87B28@sun.com> Message-ID: <3A5DADD1-719B-405C-9C74-DB8B895FF671@Sun.COM> On Feb 3, 2010, at 3:32 PM, Hiroshi Yamauchi wrote: > Tom, > > Yes, it looks good to me. Thanks for applying the changes. I reran the > test and verified the speedup in a benchmark with that. > > I'm not sure about the copyright, but if that follows a previous test > file that Chuck created before, then it's probably fine. Yes, I copied it from the two others already in the repo. I'll push in now. Thanks for providing this fix and making the suggested changes. tom > > Thanks. > > Hiroshi > > On Wed, Feb 3, 2010 at 1:39 PM, Tom Rodriguez wrote: >> Is http://cr.openjdk.java.net/~never/6921969 ok? I made the changes I proposed and also adjusted the copyright on the test to include the GPL language and removed your email address from it. I believe that's the correct format but someone correct me if it isn't. If it's ok then I will push it. >> >> tom >> >> On Feb 3, 2010, at 12:07 PM, Tom Rodriguez wrote: >> >>> The cast is unneeded and I don't like the use of a bool for input selection. Would you mind if it were like this: >>> >>> +source_hpp %{ >>> +// Must be visible to the DFA in dfa_x86_32.cpp >>> +extern bool is_operand_hi32_zero(Node* n); >>> +%} >>> + >>> >>> +// Returns true if the high 32 bits of the value is known to be zero. >>> +bool is_operand_hi32_zero(Node* n) { >>> + int opc = n->Opcode(); >>> + if (opc == Op_LoadUI2L) { >>> + return true; >>> + } >>> + if (opc == Op_AndL) { >>> + Node* o2 = n->in(2); >>> + if (o2->is_Con() && (o2->get_long() & 0xFFFFFFFF00000000LL) == 0LL) { >>> + return true; >>> + } >>> + } >>> + return false; >>> +} >>> + >>> >>> + predicate(is_operand_hi32_zero(n->in(1))); >>> >>> + predicate(is_operand_hi32_zero(n->in(2))); >>> >>> + predicate(is_operand_hi32_zero(n->in(1)) && is_operand_hi32_zero(n->in(2))); >>> >>> tom >>> >>> On Feb 3, 2010, at 11:52 AM, Hiroshi Yamauchi wrote: >>> >>>> OK. I moved is_operand_hi32_zero to the ad file. >>>> >>>> http://cr.openjdk.java.net/~rasbold/6921969/webrev.02/ >>>> >>>> On Tue, Feb 2, 2010 at 1:15 PM, Hiroshi Yamauchi wrote: >>>>> I will work on this. >>>>> >>>>> Hiroshi >>>>> >>>>> On Mon, Feb 1, 2010 at 4:18 PM, Tom Rodriguez wrote: >>>>>> The assembler changes look good but I'd rather have the predicate stuff in the ad file instead of over in MulLNode. The normal way make ad helper functions is to put it into the ad file itself in the source block. There's a section of the ad file which begins with "source %{" and it's included verbatim in the main generated ad file. So just add is_operand_hi32_zero as a static function in the source block. >>>>>> >>>>>> tom >>>>>> >>>>>> On Feb 1, 2010, at 3:34 PM, Hiroshi Yamauchi wrote: >>>>>> >>>>>>> I think it's a little more readable this way: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ >>>>>>> >>>>>>> Hiroshi >>>>>>> >>>>>>> On Mon, Feb 1, 2010 at 2:01 PM, Tom Rodriguez wrote: >>>>>>>> >>>>>>>> On Feb 1, 2010, at 10:18 AM, Hiroshi Yamauchi wrote: >>>>>>>> >>>>>>>>> Hi Christian, >>>>>>>>> >>>>>>>>>> I think that's a good change. I have two comments: personally I prefer to >>>>>>>>>> use assembler instructions directly in the ins_encode than writing >>>>>>>>>> very-hard-to-read enc_class methods and the predicates are kind of ugly, but >>>>>>>>>> I don't know if that could be done any better. >>>>>>>> >>>>>>>> The predicates are ugly but we don't currently have a better mechanism. The cleaner way this could be expressed would be: >>>>>>>> >>>>>>>> predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT)); >>>>>>>> >>>>>>>> but the Matcher doesn't capture the type table from the last phase of GVN. The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant. It returns the worst case type TypeLong::LONG. Only the type table captures the improved type that we computed though iter GVN. If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach. Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for. I think in most interesting cases the predicate will work correctly though. It's only if there are multiple users of in(1) or in(2) that it might fail to trigger. Anyway, I think the predicates are fine for this purpose. >>>>>>>> >>>>>>>>> >>>>>>>>> I'll see if I can do it better that way. >>>>>>>>> >>>>>>>>>> Maybe, given that we probably support more 32-bit architectures in the >>>>>>>>>> future, we could model such instructions in ideal (e.g. in a pass that's >>>>>>>>>> only used on 32-bit). >>>>>>>>> >>>>>>>>> I agree that it'd be easier and probably more effective to apply the >>>>>>>>> same optimization at the ideal graph level. >>>>>>>> >>>>>>>> I agree that it would be nice if these optimizations kind of fell out more automatically but I'm leery of adding yet more one off ideal nodes to describe machine dependent operations. Maybe there is a reasonable set that could be used for decomposing 64-bit operations into a clean set of 32 bit operations, though I think that might have ramifications for the register allocator since we represent longs as pairs. We're definitely emitting less than optimal sequences for 64 bit operations in 32 mode. >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Hiroshi >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>> >> >> From vladimir.kozlov at sun.com Wed Feb 3 18:31:08 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 04 Feb 2010 02:31:08 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly Message-ID: <20100204023112.6D61241D0A@hg.openjdk.java.net> Changeset: cef333a48af6 Author: kvn Date: 2010-02-03 15:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cef333a48af6 6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly Summary: Print "made not compilable" line only for deoptimizations. Reviewed-by: never ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp From thomas.rodriguez at sun.com Wed Feb 3 21:31:49 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 04 Feb 2010 05:31:49 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20100204053156.3FF1741D3F@hg.openjdk.java.net> Changeset: e8443c7be117 Author: never Date: 2010-02-03 15:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e8443c7be117 6921969: optimize 64 long multiply for case with high bits zero Reviewed-by: never, twisti, kvn, rasbold Contributed-by: Hiroshi Yamauchi ! src/cpu/x86/vm/x86_32.ad + test/compiler/6921969/TestMultiplyLongHiZero.java Changeset: 0fce83e8dc0e Author: never Date: 2010-02-03 18:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0fce83e8dc0e Merge From Christian.Thalinger at Sun.COM Thu Feb 4 02:39:28 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 04 Feb 2010 11:39:28 +0100 Subject: review (S) for 6920293: OptimizeStringConcat causing core dumps In-Reply-To: <754E1F6D-320C-43B2-986F-19AB80AC2CE1@sun.com> References: <754E1F6D-320C-43B2-986F-19AB80AC2CE1@sun.com> Message-ID: <4B6AA3E0.5010803@Sun.COM> On 02/ 3/10 10:41 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6920293 > > 6920293: OptimizeStringConcat causing core dumps > Reviewed-by: > > The code for the idiom a == null ? "null" : a) in OptimizeStringConcat > was putting an explicit NOTNULL on the result Phi which allowed the > optimizer to move some loads above the null check which caused a > crash. The fix is to use the same idiom the parser uses which is to > cast the resulting value to be notnull and leave the phi type alone. > Tested with failing test from report. I also made some changes to > error reporting to make the crash output more useful. Currently if we > don't find an implicit exception handler we die inside the VM and > don't print out much useful information. Instead we should simply > return null and let the VMError machinery produce a normal crash dump. > I also fixed the formatting for the register in 64 bit mode on solaris > to match the linux formatting. > > src/share/vm/opto/stringopts.cpp > src/share/vm/runtime/sharedRuntime.cpp > src/share/vm/code/nmethod.cpp > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp Looks good. -- Christian From Christian.Thalinger at Sun.COM Thu Feb 4 08:36:23 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 04 Feb 2010 16:36:23 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 8 new changesets Message-ID: <20100204163657.4258D41DDF@hg.openjdk.java.net> Changeset: 4788266644c1 Author: jmasa Date: 2010-01-21 11:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4788266644c1 6895236: CMS: cmsOopClosures.inline.hpp:43 assert(..., "Should remember klasses in this context") Summary: Adjust assertion checking for ExplicitGCInvokesConcurrentAndUnloadsClasses as a reason for class unloading Reviewed-by: ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: fed17682aea5 Author: ysr Date: 2010-01-21 14:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fed17682aea5 Merge Changeset: 776fb94f33cc Author: apetrusenko Date: 2010-01-21 18:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/776fb94f33cc 6918006: G1: spill space must be reserved on the stack for barrier calls on Windows x64 Summary: Stub code generated to call G1 barriers does not allocate spill space on the stack as required by Windows x64 ABI. The fix is to use more ABI-friendly call_VM_leaf(). Reviewed-by: iveresov, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: c81fa70144aa Author: tonyp Date: 2010-01-25 18:03 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c81fa70144aa 6919980: G1: remove +UseG1GC from under experimental options (second attempt) Summary: Trying this again, as the original change was lost. Reviewed-by: ysr, jmasa ! src/share/vm/runtime/globals.hpp Changeset: 34fb2662f6c2 Author: ysr Date: 2010-01-26 16:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/34fb2662f6c2 6920090: G1: Disable ReduceInitialCardMarks at least until 6920109 is fixed Summary: G1 now answers "no" to the query can_elide_initializing_store_barrier() in the product build. A debug flag allows alternate behaviour in debug builds. Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 291c9b3b64fc Author: ysr Date: 2010-01-26 23:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/291c9b3b64fc Merge Changeset: f3345b7b01b4 Author: ysr Date: 2010-01-27 22:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f3345b7b01b4 Merge ! src/share/vm/runtime/globals.hpp Changeset: c1f1137b3575 Author: twisti Date: 2010-02-04 03:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c1f1137b3575 Merge ! src/share/vm/runtime/globals.hpp From Vladimir.Kozlov at Sun.COM Thu Feb 4 09:43:31 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 04 Feb 2010 09:43:31 -0800 Subject: Request for reviews (S): 6923002: assert(false,"this call site should not be polymorphic") Message-ID: <4B6B0743.5010906@sun.com> http://cr.openjdk.java.net/~kvn/6923002/webrev Fixed 6923002: assert(false,"this call site should not be polymorphic") Problem: After the 6614597 changes C2 expects that the MDO total count at the virtual call site indicates only polimorphic case and the assert was added for that. But ReceiverTypeData::follow_weak_refs() may clear a receiver information in MDO leaving the data at strange state and causing assert. Solution: Clear also the total count when a receiver information is cleared. An additional receiver, if it exists, will be recorded in the cleaned row during next execution of the call site. Also add method name for the assert output and record in logs a second receiver even for polimorphic case. Reviewed by: Fix verified (y/n): y, test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Thu Feb 4 10:30:14 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 04 Feb 2010 10:30:14 -0800 Subject: review (XS) for 6921992: failure in verify scheduling after 6792161 Message-ID: <8B3D7837-3F37-445C-8DC9-810D6BD1830B@Sun.COM> http://cr.openjdk.java.net/~never/6921992 6921992: failure in verify scheduling after 6792161 Reviewed-by: The fix for 6792161 created problems with the scheduler verification logic so until I find a better for 6792161 I'm backing it out. This is just an anti-delta for the original fix. src/share/vm/opto/ifg.cpp The previous changeset was http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0e14bd797dad From Vladimir.Kozlov at Sun.COM Thu Feb 4 10:48:49 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 04 Feb 2010 10:48:49 -0800 Subject: review (XS) for 6921992: failure in verify scheduling after 6792161 In-Reply-To: <8B3D7837-3F37-445C-8DC9-810D6BD1830B@Sun.COM> References: <8B3D7837-3F37-445C-8DC9-810D6BD1830B@Sun.COM> Message-ID: <4B6B1691.8080102@sun.com> Changes look good. Tom, was 679216 case rare? Can we live without the fix? Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6921992 > > 6921992: failure in verify scheduling after 6792161 > Reviewed-by: > > The fix for 6792161 created problems with the scheduler verification > logic so until I find a better for 6792161 I'm backing it out. This > is just an anti-delta for the original fix. > > src/share/vm/opto/ifg.cpp > > The previous changeset was http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0e14bd797dad From Thomas.Rodriguez at Sun.COM Thu Feb 4 11:15:06 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 04 Feb 2010 11:15:06 -0800 Subject: review (XS) for 6921992: failure in verify scheduling after 6792161 In-Reply-To: <4B6B1691.8080102@sun.com> References: <8B3D7837-3F37-445C-8DC9-810D6BD1830B@Sun.COM> <4B6B1691.8080102@sun.com> Message-ID: <0D2D1C5A-80DF-4F95-8405-496BAD0390B7@Sun.COM> Yes we can live without the fix though I think we need to fix it at some point. I'm going to push this to hotspot/hotspot first since these changes just were pushed up and I'd prefer the failure not to propagate out further. tom On Feb 4, 2010, at 10:48 AM, Vladimir Kozlov wrote: > Changes look good. > > Tom, was 679216 case rare? Can we live without the fix? > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6921992 >> 6921992: failure in verify scheduling after 6792161 >> Reviewed-by: >> The fix for 6792161 created problems with the scheduler verification >> logic so until I find a better for 6792161 I'm backing it out. This >> is just an anti-delta for the original fix. >> src/share/vm/opto/ifg.cpp >> The previous changeset was http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0e14bd797dad From Vladimir.Kozlov at Sun.COM Thu Feb 4 11:13:33 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 04 Feb 2010 11:13:33 -0800 Subject: review (XS) for 6921992: failure in verify scheduling after 6792161 In-Reply-To: <0D2D1C5A-80DF-4F95-8405-496BAD0390B7@Sun.COM> References: <8B3D7837-3F37-445C-8DC9-810D6BD1830B@Sun.COM> <4B6B1691.8080102@sun.com> <0D2D1C5A-80DF-4F95-8405-496BAD0390B7@Sun.COM> Message-ID: <4B6B1C5D.8050008@sun.com> Agree. Vladimir Tom Rodriguez wrote: > Yes we can live without the fix though I think we need to fix it at some point. I'm going to push this to hotspot/hotspot first since these changes just were pushed up and I'd prefer the failure not to propagate out further. > > tom > > On Feb 4, 2010, at 10:48 AM, Vladimir Kozlov wrote: > >> Changes look good. >> >> Tom, was 679216 case rare? Can we live without the fix? >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6921992 >>> 6921992: failure in verify scheduling after 6792161 >>> Reviewed-by: >>> The fix for 6792161 created problems with the scheduler verification >>> logic so until I find a better for 6792161 I'm backing it out. This >>> is just an anti-delta for the original fix. >>> src/share/vm/opto/ifg.cpp >>> The previous changeset was http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0e14bd797dad > From John.Rose at Sun.COM Thu Feb 4 11:51:05 2010 From: John.Rose at Sun.COM (John Rose) Date: Thu, 04 Feb 2010 11:51:05 -0800 Subject: Request for reviews (S): 6923002: assert(false,"this call site should not be polymorphic") In-Reply-To: <4B6B0743.5010906@sun.com> References: <4B6B0743.5010906@sun.com> Message-ID: <18762FDC-F980-40A7-9D7F-2B13565F4A25@sun.com> Two comments: Typo: s/polimorphic/polymorphic/ The count field of a call site is inclusive of the counts on the rows. Therefore, I think you should decrement the main count by the row count, rather than zero it out. Correlated profile numbers is not good design however. We should (not in this bug) change InterpreterMacroAssembler::profile_virtual_call to increment the main count only if a row count is not incremented. That way, the total count of the call site will be the sum of all counts (which then are disjoint). And the main count becomes a "default" or "misc" count. Does this make sense to you? -- John On Feb 4, 2010, at 9:43 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6923002/webrev > > Fixed 6923002: assert(false,"this call site should not be polymorphic") > > Problem: > After the 6614597 changes C2 expects that the MDO total count at the virtual > call site indicates only polimorphic case and the assert was added for that. > But ReceiverTypeData::follow_weak_refs() may clear a receiver information > in MDO leaving the data at strange state and causing assert. > > Solution: > Clear also the total count when a receiver information is cleared. > An additional receiver, if it exists, will be recorded in the cleaned row > during next execution of the call site. > Also add method name for the assert output and record in logs a second > receiver even for polimorphic case. > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Thu Feb 4 12:01:51 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 04 Feb 2010 12:01:51 -0800 Subject: Request for reviews (S): 6923002: assert(false,"this call site should not be polymorphic") In-Reply-To: <18762FDC-F980-40A7-9D7F-2B13565F4A25@sun.com> References: <4B6B0743.5010906@sun.com> <18762FDC-F980-40A7-9D7F-2B13565F4A25@sun.com> Message-ID: <4B6B27AF.3050708@sun.com> Thank you, John John Rose wrote: > Two comments: > > Typo: s/polimorphic/polymorphic/ Fixed. > > The count field of a call site is inclusive of the counts on the rows. Therefore, I think you should decrement the main count by the row count, rather than zero it out. > > Correlated profile numbers is not good design however. We should (not in this bug) change InterpreterMacroAssembler::profile_virtual_call to increment the main count only if a row count is not incremented. That way, the total count of the call site will be the sum of all counts (which then are disjoint). And the main count becomes a "default" or "misc" count. Does this make sense to you? It seems, you missed my changes for 6614597 :) The count field is not inclusive any more. http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87684f1a88b5 Vladimir > > -- John > > On Feb 4, 2010, at 9:43 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6923002/webrev >> >> Fixed 6923002: assert(false,"this call site should not be polymorphic") >> >> Problem: >> After the 6614597 changes C2 expects that the MDO total count at the virtual >> call site indicates only polimorphic case and the assert was added for that. >> But ReceiverTypeData::follow_weak_refs() may clear a receiver information >> in MDO leaving the data at strange state and causing assert. >> >> Solution: >> Clear also the total count when a receiver information is cleared. >> An additional receiver, if it exists, will be recorded in the cleaned row >> during next execution of the call site. >> Also add method name for the assert output and record in logs a second >> receiver even for polimorphic case. >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > From Thomas.Rodriguez at Sun.COM Thu Feb 4 12:14:12 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 04 Feb 2010 12:14:12 -0800 Subject: Request for reviews (S): 6923002: assert(false,"this call site should not be polymorphic") In-Reply-To: <4B6B0743.5010906@sun.com> References: <4B6B0743.5010906@sun.com> Message-ID: <7CFACEC6-88FA-4AA2-A8CC-43A2D32E3BB8@sun.com> Why is clearing the count the right solution? I understand that it makes the code work but it's clearing actual history too so that the call site doesn't reflect what was actually invoked. A call site could suddenly look monomorphic when in fact it isn't. I guess I would have expected that the count of the cleared row would be added to the count. Also I think the logic that clears the slots should repack the entries so that none of the earlier slots are empty. tom On Feb 4, 2010, at 9:43 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6923002/webrev > > Fixed 6923002: assert(false,"this call site should not be polymorphic") > > Problem: > After the 6614597 changes C2 expects that the MDO total count at the virtual > call site indicates only polimorphic case and the assert was added for that. > But ReceiverTypeData::follow_weak_refs() may clear a receiver information > in MDO leaving the data at strange state and causing assert. > > Solution: > Clear also the total count when a receiver information is cleared. > An additional receiver, if it exists, will be recorded in the cleaned row > during next execution of the call site. > Also add method name for the assert output and record in logs a second > receiver even for polimorphic case. > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > From John.Rose at Sun.COM Thu Feb 4 12:19:28 2010 From: John.Rose at Sun.COM (John Rose) Date: Thu, 04 Feb 2010 12:19:28 -0800 Subject: Request for reviews (S): 6923002: assert(false,"this call site should not be polymorphic") In-Reply-To: <4B6B27AF.3050708@sun.com> References: <4B6B0743.5010906@sun.com> <18762FDC-F980-40A7-9D7F-2B13565F4A25@sun.com> <4B6B27AF.3050708@sun.com> Message-ID: <8A53CCA5-EF19-42C4-81FA-A27599CD9F83@Sun.COM> On Feb 4, 2010, at 12:01 PM, Vladimir Kozlov wrote: > It seems, you missed my changes for 6614597 :) The count field is not inclusive any more. > > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87684f1a88b5 D'oh. I guess I had it filed in the wrong hemisphere. -- John From Thomas.Rodriguez at Sun.COM Thu Feb 4 13:46:11 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 04 Feb 2010 13:46:11 -0800 Subject: review (S) for 6920293: OptimizeStringConcat causing core dumps In-Reply-To: <4B6AA3E0.5010803@Sun.COM> References: <754E1F6D-320C-43B2-986F-19AB80AC2CE1@sun.com> <4B6AA3E0.5010803@Sun.COM> Message-ID: I had to change this a little bit since I was putting the cast in the wrong place. The old change was casting the Phi to NotNull when it should have been casting the null checked value before it was merged into the phi. It's acceptable to put it where I did but it's more correct to put it on the value instead of the phi. The fix operates the same otherwise. Could I get a rereview? tom On Feb 4, 2010, at 2:39 AM, Christian Thalinger wrote: > On 02/ 3/10 10:41 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6920293 >> >> 6920293: OptimizeStringConcat causing core dumps >> Reviewed-by: >> >> The code for the idiom a == null ? "null" : a) in OptimizeStringConcat >> was putting an explicit NOTNULL on the result Phi which allowed the >> optimizer to move some loads above the null check which caused a >> crash. The fix is to use the same idiom the parser uses which is to >> cast the resulting value to be notnull and leave the phi type alone. >> Tested with failing test from report. I also made some changes to >> error reporting to make the crash output more useful. Currently if we >> don't find an implicit exception handler we die inside the VM and >> don't print out much useful information. Instead we should simply >> return null and let the VMError machinery produce a normal crash dump. >> I also fixed the formatting for the register in 64 bit mode on solaris >> to match the linux formatting. >> >> src/share/vm/opto/stringopts.cpp >> src/share/vm/runtime/sharedRuntime.cpp >> src/share/vm/code/nmethod.cpp >> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > > Looks good. -- Christian From thomas.rodriguez at sun.com Thu Feb 4 15:15:03 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 04 Feb 2010 23:15:03 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6921992: failure in verify scheduling after 6792161 Message-ID: <20100204231508.40BC241E3D@hg.openjdk.java.net> Changeset: c028504fdaa6 Author: never Date: 2010-02-04 11:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c028504fdaa6 6921992: failure in verify scheduling after 6792161 Reviewed-by: kvn ! src/share/vm/opto/ifg.cpp From Vladimir.Kozlov at Sun.COM Thu Feb 4 15:49:43 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 04 Feb 2010 15:49:43 -0800 Subject: review (S) for 6920293: OptimizeStringConcat causing core dumps In-Reply-To: References: <754E1F6D-320C-43B2-986F-19AB80AC2CE1@sun.com> <4B6AA3E0.5010803@Sun.COM> Message-ID: <4B6B5D17.7030704@sun.com> Good. Vladimir Tom Rodriguez wrote: > I had to change this a little bit since I was putting the cast in the wrong place. The old change was casting the Phi to NotNull when it should have been casting the null checked value before it was merged into the phi. It's acceptable to put it where I did but it's more correct to put it on the value instead of the phi. The fix operates the same otherwise. Could I get a rereview? > > tom > > On Feb 4, 2010, at 2:39 AM, Christian Thalinger wrote: > >> On 02/ 3/10 10:41 PM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6920293 >>> >>> 6920293: OptimizeStringConcat causing core dumps >>> Reviewed-by: >>> >>> The code for the idiom a == null ? "null" : a) in OptimizeStringConcat >>> was putting an explicit NOTNULL on the result Phi which allowed the >>> optimizer to move some loads above the null check which caused a >>> crash. The fix is to use the same idiom the parser uses which is to >>> cast the resulting value to be notnull and leave the phi type alone. >>> Tested with failing test from report. I also made some changes to >>> error reporting to make the crash output more useful. Currently if we >>> don't find an implicit exception handler we die inside the VM and >>> don't print out much useful information. Instead we should simply >>> return null and let the VMError machinery produce a normal crash dump. >>> I also fixed the formatting for the register in 64 bit mode on solaris >>> to match the linux formatting. >>> >>> src/share/vm/opto/stringopts.cpp >>> src/share/vm/runtime/sharedRuntime.cpp >>> src/share/vm/code/nmethod.cpp >>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >> Looks good. -- Christian > From Vladimir.Kozlov at Sun.COM Thu Feb 4 16:07:40 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 04 Feb 2010 16:07:40 -0800 Subject: Request for reviews (S): 6923002: assert(false,"this call site should not be polymorphic") In-Reply-To: <7CFACEC6-88FA-4AA2-A8CC-43A2D32E3BB8@sun.com> References: <4B6B0743.5010906@sun.com> <7CFACEC6-88FA-4AA2-A8CC-43A2D32E3BB8@sun.com> Message-ID: <4B6B614C.8010006@sun.com> First, all our profiling logic works with empty rows in any slot. I verified it since I also thought about repacking but it is not necessary. We do sorting when building profiling info (ciCallProfile) for compilation. Also I intentionally want to make it monomorphic since it allow to have more accurate profiling information because there was execution phase change (klasses were unloaded). And if the site still polymorphic MDO will be updated to reflect it. But it could be the case that the site becomes only bimorphic. Then keeping total count not 0 will be wrong. Even if we use monomorphic (when it is not) for compilation we will only have trap, deoptimization and recompile again with updated MDO (after executing method in Interpreter). Thanks, Vladimir Tom Rodriguez wrote: > Why is clearing the count the right solution? I understand that it makes the code work but it's clearing actual history too so that the call site doesn't reflect what was actually invoked. A call site could suddenly look monomorphic when in fact it isn't. I guess I would have expected that the count of the cleared row would be added to the count. Also I think the logic that clears the slots should repack the entries so that none of the earlier slots are empty. > > tom > > On Feb 4, 2010, at 9:43 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6923002/webrev >> >> Fixed 6923002: assert(false,"this call site should not be polymorphic") >> >> Problem: >> After the 6614597 changes C2 expects that the MDO total count at the virtual >> call site indicates only polimorphic case and the assert was added for that. >> But ReceiverTypeData::follow_weak_refs() may clear a receiver information >> in MDO leaving the data at strange state and causing assert. >> >> Solution: >> Clear also the total count when a receiver information is cleared. >> An additional receiver, if it exists, will be recorded in the cleaned row >> during next execution of the call site. >> Also add method name for the assert output and record in logs a second >> receiver even for polimorphic case. >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > From Thomas.Rodriguez at Sun.COM Thu Feb 4 16:15:12 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 04 Feb 2010 16:15:12 -0800 Subject: Request for reviews (S): 6923002: assert(false,"this call site should not be polymorphic") In-Reply-To: <4B6B614C.8010006@sun.com> References: <4B6B0743.5010906@sun.com> <7CFACEC6-88FA-4AA2-A8CC-43A2D32E3BB8@sun.com> <4B6B614C.8010006@sun.com> Message-ID: On Feb 4, 2010, at 4:07 PM, Vladimir Kozlov wrote: > First, all our profiling logic works with empty rows in any slot. > I verified it since I also thought about repacking but it is not necessary. > We do sorting when building profiling info (ciCallProfile) for compilation. You're right. The code will all deal with this correctly. > > Also I intentionally want to make it monomorphic since it allow to have > more accurate profiling information because there was execution phase change > (klasses were unloaded). And if the site still polymorphic MDO will be updated > to reflect it. But it could be the case that the site becomes only bimorphic. > Then keeping total count not 0 will be wrong. > Even if we use monomorphic (when it is not) for compilation we will only have > trap, deoptimization and recompile again with updated MDO (after executing method > in Interpreter). Agreed. I'm ok with the changes then. One more typo s/Cleare/Clear/. tom > > Thanks, > Vladimir > > > Tom Rodriguez wrote: >> Why is clearing the count the right solution? I understand that it makes the code work but it's clearing actual history too so that the call site doesn't reflect what was actually invoked. A call site could suddenly look monomorphic when in fact it isn't. I guess I would have expected that the count of the cleared row would be added to the count. Also I think the logic that clears the slots should repack the entries so that none of the earlier slots are empty. >> tom >> On Feb 4, 2010, at 9:43 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6923002/webrev >>> >>> Fixed 6923002: assert(false,"this call site should not be polymorphic") >>> >>> Problem: >>> After the 6614597 changes C2 expects that the MDO total count at the virtual >>> call site indicates only polimorphic case and the assert was added for that. >>> But ReceiverTypeData::follow_weak_refs() may clear a receiver information >>> in MDO leaving the data at strange state and causing assert. >>> >>> Solution: >>> Clear also the total count when a receiver information is cleared. >>> An additional receiver, if it exists, will be recorded in the cleaned row >>> during next execution of the call site. >>> Also add method name for the assert output and record in logs a second >>> receiver even for polimorphic case. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, test >>> >>> Other testing: >>> JPRT >>> From Vladimir.Kozlov at Sun.COM Thu Feb 4 16:40:06 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 04 Feb 2010 16:40:06 -0800 Subject: Request for reviews (S): 6923002: assert(false,"this call site should not be polymorphic") In-Reply-To: References: <4B6B0743.5010906@sun.com> <7CFACEC6-88FA-4AA2-A8CC-43A2D32E3BB8@sun.com> <4B6B614C.8010006@sun.com> Message-ID: <4B6B68E6.9090605@sun.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > On Feb 4, 2010, at 4:07 PM, Vladimir Kozlov wrote: > >> First, all our profiling logic works with empty rows in any slot. >> I verified it since I also thought about repacking but it is not necessary. >> We do sorting when building profiling info (ciCallProfile) for compilation. > > You're right. The code will all deal with this correctly. > >> Also I intentionally want to make it monomorphic since it allow to have >> more accurate profiling information because there was execution phase change >> (klasses were unloaded). And if the site still polymorphic MDO will be updated >> to reflect it. But it could be the case that the site becomes only bimorphic. >> Then keeping total count not 0 will be wrong. >> Even if we use monomorphic (when it is not) for compilation we will only have >> trap, deoptimization and recompile again with updated MDO (after executing method >> in Interpreter). > > Agreed. I'm ok with the changes then. One more typo s/Cleare/Clear/. > > tom > >> Thanks, >> Vladimir >> >> >> Tom Rodriguez wrote: >>> Why is clearing the count the right solution? I understand that it makes the code work but it's clearing actual history too so that the call site doesn't reflect what was actually invoked. A call site could suddenly look monomorphic when in fact it isn't. I guess I would have expected that the count of the cleared row would be added to the count. Also I think the logic that clears the slots should repack the entries so that none of the earlier slots are empty. >>> tom >>> On Feb 4, 2010, at 9:43 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/6923002/webrev >>>> >>>> Fixed 6923002: assert(false,"this call site should not be polymorphic") >>>> >>>> Problem: >>>> After the 6614597 changes C2 expects that the MDO total count at the virtual >>>> call site indicates only polimorphic case and the assert was added for that. >>>> But ReceiverTypeData::follow_weak_refs() may clear a receiver information >>>> in MDO leaving the data at strange state and causing assert. >>>> >>>> Solution: >>>> Clear also the total count when a receiver information is cleared. >>>> An additional receiver, if it exists, will be recorded in the cleaned row >>>> during next execution of the call site. >>>> Also add method name for the assert output and record in logs a second >>>> receiver even for polimorphic case. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y, test >>>> >>>> Other testing: >>>> JPRT >>>> > From thomas.rodriguez at sun.com Fri Feb 5 13:38:26 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 05 Feb 2010 21:38:26 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6920293: OptimizeStringConcat causing core dumps Message-ID: <20100205213829.6655141F80@hg.openjdk.java.net> Changeset: 3f5b7efb9642 Author: never Date: 2010-02-05 11:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3f5b7efb9642 6920293: OptimizeStringConcat causing core dumps Reviewed-by: kvn, twisti ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/sharedRuntime.cpp From john.coomes at sun.com Fri Feb 5 18:21:14 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 06 Feb 2010 02:21:14 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b82 for changeset e1176f86805f Message-ID: <20100206022114.5B00441FD7@hg.openjdk.java.net> Changeset: 6880a3af9add Author: mikejwre Date: 2010-02-04 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/6880a3af9add Added tag jdk7-b82 for changeset e1176f86805f ! .hgtags From john.coomes at sun.com Fri Feb 5 18:21:19 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 06 Feb 2010 02:21:19 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b82 for changeset 1e8c1bfad1ab Message-ID: <20100206022123.3418E41FD8@hg.openjdk.java.net> Changeset: fde0df7a2384 Author: mikejwre Date: 2010-02-04 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/fde0df7a2384 Added tag jdk7-b82 for changeset 1e8c1bfad1ab ! .hgtags From john.coomes at sun.com Fri Feb 5 18:24:37 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 06 Feb 2010 02:24:37 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b82 for changeset c876ad22e4bf Message-ID: <20100206022437.D70D641FD9@hg.openjdk.java.net> Changeset: 309a0a7fc6ce Author: mikejwre Date: 2010-02-04 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/309a0a7fc6ce Added tag jdk7-b82 for changeset c876ad22e4bf ! .hgtags From john.coomes at sun.com Fri Feb 5 18:24:44 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 06 Feb 2010 02:24:44 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b82 for changeset 31573ae8eed1 Message-ID: <20100206022444.860E841FDA@hg.openjdk.java.net> Changeset: 371e3ded591d Author: mikejwre Date: 2010-02-04 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/371e3ded591d Added tag jdk7-b82 for changeset 31573ae8eed1 ! .hgtags From john.coomes at sun.com Fri Feb 5 18:24:55 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 06 Feb 2010 02:24:55 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 4 new changesets Message-ID: <20100206022636.1689E41FDC@hg.openjdk.java.net> Changeset: b250e6c5a9e5 Author: andrew Date: 2010-01-28 21:01 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b250e6c5a9e5 6921068: Remove javadoc builds warnings from specdefault tag Summary: Ignore specdefault tag to avoid javadoc warnings Reviewed-by: darcy, ohair ! make/docs/Makefile Changeset: b3b10d45778a Author: andrew Date: 2010-01-29 02:38 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b3b10d45778a 6917466: Should set bootclasspath for javadoc in jdk build Summary: javadoc needs to reference the newly built classes so as not to hit APIs which differ between the boot JDK and the source files of the JDK being built. Reviewed-by: ohair ! make/common/shared/Defs-java.gmk ! make/javax/swing/beaninfo/SwingBeans.gmk Changeset: 69ef657320ad Author: ohair Date: 2010-01-29 09:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/69ef657320ad Merge Changeset: 9027c6b9d7e2 Author: mikejwre Date: 2010-02-04 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9027c6b9d7e2 Added tag jdk7-b82 for changeset 69ef657320ad ! .hgtags From john.coomes at sun.com Fri Feb 5 18:29:38 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 06 Feb 2010 02:29:38 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b82 for changeset 47003a3622f6 Message-ID: <20100206022945.4E92F41FDE@hg.openjdk.java.net> Changeset: c9f4ae1f1480 Author: mikejwre Date: 2010-02-04 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c9f4ae1f1480 Added tag jdk7-b82 for changeset 47003a3622f6 ! .hgtags From Vladimir.Kozlov at Sun.COM Fri Feb 5 18:59:30 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 05 Feb 2010 18:59:30 -0800 Subject: Request for reviews (S): 6910605: C2: NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used Message-ID: <4B6CDB12.9050409@sun.com> http://cr.openjdk.java.net/~kvn/6910605/webrev.00 Fixed 6910605: C2: NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used Problem: Regression after 6603492: multianewarray should generate same code as anewarray for 1-d arrays. After deoptimization interpreter will continue execution after _multianewarray even if compiled code did not allocate all needed arrays. Solution: Set the reexecute bit for the interpreter to reexecute the _multianewarray bytecode if deoptimization happens. Do it unconditionally even for one dimension array. Added regression test copied from nsk/coverage/runtime/runtime007 Reviewed by: Fix verified (y/n): y, tests Other testing: JPRT From Vladimir.Kozlov at Sun.COM Sat Feb 6 14:43:04 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Sat, 06 Feb 2010 14:43:04 -0800 Subject: Request for reviews (S): 6910605: C2:NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used In-Reply-To: <4B6CDB12.9050409@sun.com> References: <4B6CDB12.9050409@sun.com> Message-ID: <4B6DF078.1000001@sun.com> http://cr.openjdk.java.net/~kvn/6910605/webrev.01 The first implementation was not correct for the case when runtime call is used for multianewarray allocation. Because of that interpreter should not have _multianewarray marked as reexecutable (stack is not reset for such case). Also setting reexecute bit in do_multianewarray() was not propagated to the AllocateArray node so I have to set it in graphKit. I replaced "expand_count == 1" check with "ndimensions == 1" otherwise with MultiArrayExpandLimit=0 we hit ShouldNotReachHere() in case of one dimension multianewarray because the method expand_multianewarray() will not be called. And I removed annoying "reexecute=false" from PcDesc output. Thanks, Vladimir Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6910605/webrev.00 > > Fixed 6910605: C2: NullPointerException/ClassCaseException is thrown > when C2 with DeoptimizeALot is used > > Problem: > Regression after 6603492: multianewarray should generate same code as > anewarray for 1-d arrays. > After deoptimization interpreter will continue execution after > _multianewarray > even if compiled code did not allocate all needed arrays. > > Solution: > Set the reexecute bit for the interpreter to reexecute the > _multianewarray bytecode > if deoptimization happens. Do it unconditionally even for one dimension > array. > > Added regression test copied from nsk/coverage/runtime/runtime007 > > Reviewed by: > > Fix verified (y/n): y, tests > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Sun Feb 7 12:18:02 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Sun, 07 Feb 2010 12:18:02 -0800 Subject: Request for reviews (XXS): 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") Message-ID: <4B6F1FFA.8050203@sun.com> http://cr.openjdk.java.net/~kvn/6924097/webrev Fixed 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") Problem: PhaseIdealLoop::split_thru_phi() does not set adr_type when creates new memory Phi node. Solution: PhiNode::make_blank(r, n) method to construct the phi. Reviewed by: Fix verified (y/n): y, test Other testing: JPRT From vladimir.kozlov at sun.com Sun Feb 7 14:29:43 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Sun, 07 Feb 2010 22:29:43 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6923002: assert(false, "this call site should not be polymorphic") Message-ID: <20100207222948.8864641630@hg.openjdk.java.net> Changeset: 576e77447e3c Author: kvn Date: 2010-02-07 12:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/576e77447e3c 6923002: assert(false,"this call site should not be polymorphic") Summary: Clear the total count when a receiver information is cleared. Reviewed-by: never, jrose ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp From Vladimir.Kozlov at Sun.COM Mon Feb 8 11:12:03 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 08 Feb 2010 11:12:03 -0800 Subject: Request for reviews (M): 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") Message-ID: <4B706203.5020104@sun.com> http://cr.openjdk.java.net/~kvn/6910618/webrev.00 Fixed 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") Problem: If deoptimization happened on the return from a call which which returns oop, the oop will be not updated during GC which is triggered by scalar replaced objects reallocation. Solution: Mark in PcDesc call sites which return oop (this is main part of changes) and save the result oop across objects reallocation during deoptimization. Reviewed by: Fix verified (y/n): y, test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Mon Feb 8 11:43:04 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 08 Feb 2010 11:43:04 -0800 Subject: Request for reviews (M): 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") In-Reply-To: <4B706203.5020104@sun.com> References: <4B706203.5020104@sun.com> Message-ID: Why do you need to record this in the PcDesc? Why can't you just do: chunk->at(0)->scope()->method()->return_type() == T_OBJECT tom On Feb 8, 2010, at 11:12 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6910618/webrev.00 > > Fixed 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") > > Problem: > If deoptimization happened on the return from a call which > which returns oop, the oop will be not updated during GC which > is triggered by scalar replaced objects reallocation. > > Solution: > Mark in PcDesc call sites which return oop (this is main part of changes) > and save the result oop across objects reallocation during deoptimization. > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > From Thomas.Rodriguez at Sun.COM Mon Feb 8 11:45:01 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 08 Feb 2010 11:45:01 -0800 Subject: Request for reviews (XXS): 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") In-Reply-To: <4B6F1FFA.8050203@sun.com> References: <4B6F1FFA.8050203@sun.com> Message-ID: Looks good. tom On Feb 7, 2010, at 12:18 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6924097/webrev > > Fixed 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") > > Problem: > PhaseIdealLoop::split_thru_phi() does not set adr_type when creates new memory Phi node. > > Solution: > PhiNode::make_blank(r, n) method to construct the phi. > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > From Thomas.Rodriguez at Sun.COM Mon Feb 8 11:48:49 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 08 Feb 2010 11:48:49 -0800 Subject: Request for reviews (S): 6910605: C2:NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used In-Reply-To: <4B6DF078.1000001@sun.com> References: <4B6CDB12.9050409@sun.com> <4B6DF078.1000001@sun.com> Message-ID: <1E49AD90-1D0B-4CF2-952B-FFCC612EBC17@sun.com> I think that looks good. Thanks for removing reexecute output. tom On Feb 6, 2010, at 2:43 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6910605/webrev.01 > > The first implementation was not correct for the case when > runtime call is used for multianewarray allocation. > Because of that interpreter should not have _multianewarray > marked as reexecutable (stack is not reset for such case). > > Also setting reexecute bit in do_multianewarray() was not > propagated to the AllocateArray node so I have to set it in graphKit. > > I replaced "expand_count == 1" check with "ndimensions == 1" > otherwise with MultiArrayExpandLimit=0 we hit ShouldNotReachHere() > in case of one dimension multianewarray because the method > expand_multianewarray() will not be called. > > And I removed annoying "reexecute=false" from PcDesc output. > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6910605/webrev.00 >> Fixed 6910605: C2: NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used >> Problem: >> Regression after 6603492: multianewarray should generate same code as anewarray for 1-d arrays. >> After deoptimization interpreter will continue execution after _multianewarray >> even if compiled code did not allocate all needed arrays. >> Solution: >> Set the reexecute bit for the interpreter to reexecute the _multianewarray bytecode >> if deoptimization happens. Do it unconditionally even for one dimension array. >> Added regression test copied from nsk/coverage/runtime/runtime007 >> Reviewed by: >> Fix verified (y/n): y, tests >> Other testing: >> JPRT From Vladimir.Kozlov at Sun.COM Mon Feb 8 11:48:29 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 08 Feb 2010 11:48:29 -0800 Subject: Request for reviews (XXS): 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") In-Reply-To: References: <4B6F1FFA.8050203@sun.com> Message-ID: <4B706A8D.1070907@sun.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Feb 7, 2010, at 12:18 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6924097/webrev >> >> Fixed 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") >> >> Problem: >> PhaseIdealLoop::split_thru_phi() does not set adr_type when creates new memory Phi node. >> >> Solution: >> PhiNode::make_blank(r, n) method to construct the phi. >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > From Vladimir.Kozlov at Sun.COM Mon Feb 8 11:50:05 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 08 Feb 2010 11:50:05 -0800 Subject: Request for reviews (M): 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") In-Reply-To: References: <4B706203.5020104@sun.com> Message-ID: <4B706AED.50004@sun.com> Because it will return deoptee (caller method) and not the method from which we returned already (no frame on stack). Vladimir Tom Rodriguez wrote: > Why do you need to record this in the PcDesc? Why can't you just do: > > chunk->at(0)->scope()->method()->return_type() == T_OBJECT > > tom > > On Feb 8, 2010, at 11:12 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6910618/webrev.00 >> >> Fixed 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") >> >> Problem: >> If deoptimization happened on the return from a call which >> which returns oop, the oop will be not updated during GC which >> is triggered by scalar replaced objects reallocation. >> >> Solution: >> Mark in PcDesc call sites which return oop (this is main part of changes) >> and save the result oop across objects reallocation during deoptimization. >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > From Vladimir.Kozlov at Sun.COM Mon Feb 8 11:51:44 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 08 Feb 2010 11:51:44 -0800 Subject: Request for reviews (S): 6910605: C2:NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used In-Reply-To: <1E49AD90-1D0B-4CF2-952B-FFCC612EBC17@sun.com> References: <4B6CDB12.9050409@sun.com> <4B6DF078.1000001@sun.com> <1E49AD90-1D0B-4CF2-952B-FFCC612EBC17@sun.com> Message-ID: <4B706B50.9070303@sun.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > I think that looks good. Thanks for removing reexecute output. > > tom > > On Feb 6, 2010, at 2:43 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6910605/webrev.01 >> >> The first implementation was not correct for the case when >> runtime call is used for multianewarray allocation. >> Because of that interpreter should not have _multianewarray >> marked as reexecutable (stack is not reset for such case). >> >> Also setting reexecute bit in do_multianewarray() was not >> propagated to the AllocateArray node so I have to set it in graphKit. >> >> I replaced "expand_count == 1" check with "ndimensions == 1" >> otherwise with MultiArrayExpandLimit=0 we hit ShouldNotReachHere() >> in case of one dimension multianewarray because the method >> expand_multianewarray() will not be called. >> >> And I removed annoying "reexecute=false" from PcDesc output. >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6910605/webrev.00 >>> Fixed 6910605: C2: NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used >>> Problem: >>> Regression after 6603492: multianewarray should generate same code as anewarray for 1-d arrays. >>> After deoptimization interpreter will continue execution after _multianewarray >>> even if compiled code did not allocate all needed arrays. >>> Solution: >>> Set the reexecute bit for the interpreter to reexecute the _multianewarray bytecode >>> if deoptimization happens. Do it unconditionally even for one dimension array. >>> Added regression test copied from nsk/coverage/runtime/runtime007 >>> Reviewed by: >>> Fix verified (y/n): y, tests >>> Other testing: >>> JPRT > From Thomas.Rodriguez at Sun.COM Mon Feb 8 12:44:35 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 08 Feb 2010 12:44:35 -0800 Subject: Request for reviews (M): 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") In-Reply-To: <4B706AED.50004@sun.com> References: <4B706203.5020104@sun.com> <4B706AED.50004@sun.com> Message-ID: <6BE2537D-F489-48F4-94E1-A8045C1BFAF7@Sun.COM> Oh, right, wrong end of the stack. So then why can't you get it from the bytecodes of the call site of the last scope? ScopeDesc* scope = chunk->at(chunk->length() - 1)->scope(); Bytecode_invoke* invoke = Bytecode_invoke_at_check(scope->method(), scope->bci()); if (invoke != NULL) { save_oop_result = invoke->result_type() == T_OBJECT; } I guess it's possible that the site is being handled in some different way such that we don't actually have a real call there, particularly if reexecute were true. So your fix seems more right. What do you think about dropping the =true on the printing output since it seems redundant? tom On Feb 8, 2010, at 11:50 AM, Vladimir Kozlov wrote: > Because it will return deoptee (caller method) and not the method > from which we returned already (no frame on stack). > > Vladimir > > Tom Rodriguez wrote: >> Why do you need to record this in the PcDesc? Why can't you just do: >> chunk->at(0)->scope()->method()->return_type() == T_OBJECT >> tom >> On Feb 8, 2010, at 11:12 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6910618/webrev.00 >>> >>> Fixed 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") >>> >>> Problem: >>> If deoptimization happened on the return from a call which >>> which returns oop, the oop will be not updated during GC which >>> is triggered by scalar replaced objects reallocation. >>> >>> Solution: >>> Mark in PcDesc call sites which return oop (this is main part of changes) >>> and save the result oop across objects reallocation during deoptimization. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, test >>> >>> Other testing: >>> JPRT >>> From Vladimir.Kozlov at Sun.COM Mon Feb 8 13:44:39 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 08 Feb 2010 13:44:39 -0800 Subject: Request for reviews (M): 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") In-Reply-To: <6BE2537D-F489-48F4-94E1-A8045C1BFAF7@Sun.COM> References: <4B706203.5020104@sun.com> <4B706AED.50004@sun.com> <6BE2537D-F489-48F4-94E1-A8045C1BFAF7@Sun.COM> Message-ID: <4B7085C7.6000403@sun.com> Thank you, Tom Bytecode_invoke_at_check() does not check for allocation bytecodes and the bug case is deoptimization on the return from the call to OptoRuntime::new_array_C(). So I am nervous about checking only bytecode since I may miss something. I will remove printing. Thanks, Vladimir Tom Rodriguez wrote: > Oh, right, wrong end of the stack. So then why can't you get it from the bytecodes of the call site of the last scope? > > ScopeDesc* scope = chunk->at(chunk->length() - 1)->scope(); > Bytecode_invoke* invoke = Bytecode_invoke_at_check(scope->method(), scope->bci()); > if (invoke != NULL) { > save_oop_result = invoke->result_type() == T_OBJECT; > } > > I guess it's possible that the site is being handled in some different way such that we don't actually have a real call there, particularly if reexecute were true. So your fix seems more right. What do you think about dropping the =true on the printing output since it seems redundant? > > tom > > On Feb 8, 2010, at 11:50 AM, Vladimir Kozlov wrote: > >> Because it will return deoptee (caller method) and not the method >> from which we returned already (no frame on stack). >> >> Vladimir >> >> Tom Rodriguez wrote: >>> Why do you need to record this in the PcDesc? Why can't you just do: >>> chunk->at(0)->scope()->method()->return_type() == T_OBJECT >>> tom >>> On Feb 8, 2010, at 11:12 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/6910618/webrev.00 >>>> >>>> Fixed 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") >>>> >>>> Problem: >>>> If deoptimization happened on the return from a call which >>>> which returns oop, the oop will be not updated during GC which >>>> is triggered by scalar replaced objects reallocation. >>>> >>>> Solution: >>>> Mark in PcDesc call sites which return oop (this is main part of changes) >>>> and save the result oop across objects reallocation during deoptimization. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y, test >>>> >>>> Other testing: >>>> JPRT >>>> > From Thomas.Rodriguez at Sun.COM Mon Feb 8 13:59:06 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 08 Feb 2010 13:59:06 -0800 Subject: Request for reviews (M): 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") In-Reply-To: <4B7085C7.6000403@sun.com> References: <4B706203.5020104@sun.com> <4B706AED.50004@sun.com> <6BE2537D-F489-48F4-94E1-A8045C1BFAF7@Sun.COM> <4B7085C7.6000403@sun.com> Message-ID: <390DCB70-B5B2-451A-B898-539557CF4EE0@Sun.COM> On Feb 8, 2010, at 1:44 PM, Vladimir Kozlov wrote: > Thank you, Tom > > Bytecode_invoke_at_check() does not check for allocation bytecodes > and the bug case is deoptimization on the return from the call to > OptoRuntime::new_array_C(). So I am nervous about checking only > bytecode since I may miss something. I hadn't even considered that case but your fix definitely seems right. You might put a larger comment on return_oop indicating under what conditions it's used any what it can't be divined from the bytecodes themselves. tom > > I will remove printing. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> Oh, right, wrong end of the stack. So then why can't you get it from the bytecodes of the call site of the last scope? >> ScopeDesc* scope = chunk->at(chunk->length() - 1)->scope(); >> Bytecode_invoke* invoke = Bytecode_invoke_at_check(scope->method(), scope->bci()); >> if (invoke != NULL) { >> save_oop_result = invoke->result_type() == T_OBJECT; >> } >> I guess it's possible that the site is being handled in some different way such that we don't actually have a real call there, particularly if reexecute were true. So your fix seems more right. What do you think about dropping the =true on the printing output since it seems redundant? >> tom >> On Feb 8, 2010, at 11:50 AM, Vladimir Kozlov wrote: >>> Because it will return deoptee (caller method) and not the method >>> from which we returned already (no frame on stack). >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> Why do you need to record this in the PcDesc? Why can't you just do: >>>> chunk->at(0)->scope()->method()->return_type() == T_OBJECT >>>> tom >>>> On Feb 8, 2010, at 11:12 AM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/6910618/webrev.00 >>>>> >>>>> Fixed 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") >>>>> >>>>> Problem: >>>>> If deoptimization happened on the return from a call which >>>>> which returns oop, the oop will be not updated during GC which >>>>> is triggered by scalar replaced objects reallocation. >>>>> >>>>> Solution: >>>>> Mark in PcDesc call sites which return oop (this is main part of changes) >>>>> and save the result oop across objects reallocation during deoptimization. >>>>> >>>>> Reviewed by: >>>>> >>>>> Fix verified (y/n): y, test >>>>> >>>>> Other testing: >>>>> JPRT >>>>> From Vladimir.Kozlov at Sun.COM Mon Feb 8 16:28:17 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 08 Feb 2010 16:28:17 -0800 Subject: Request for reviews (M): 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") In-Reply-To: <390DCB70-B5B2-451A-B898-539557CF4EE0@Sun.COM> References: <4B706203.5020104@sun.com> <4B706AED.50004@sun.com> <6BE2537D-F489-48F4-94E1-A8045C1BFAF7@Sun.COM> <4B7085C7.6000403@sun.com> <390DCB70-B5B2-451A-B898-539557CF4EE0@Sun.COM> Message-ID: <4B70AC21.3020809@sun.com> http://cr.openjdk.java.net/~kvn/6910618/webrev.01 I added comment about return_oop in deoptimization.cpp. And I added the regression test case. I finally made it fail with current VM (have to force inlining StringBuilder::append). Thanks, Vladimir Tom Rodriguez wrote: > On Feb 8, 2010, at 1:44 PM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Bytecode_invoke_at_check() does not check for allocation bytecodes >> and the bug case is deoptimization on the return from the call to >> OptoRuntime::new_array_C(). So I am nervous about checking only >> bytecode since I may miss something. > > I hadn't even considered that case but your fix definitely seems right. You might put a larger comment on return_oop indicating under what conditions it's used any what it can't be divined from the bytecodes themselves. > > tom > >> I will remove printing. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> Oh, right, wrong end of the stack. So then why can't you get it from the bytecodes of the call site of the last scope? >>> ScopeDesc* scope = chunk->at(chunk->length() - 1)->scope(); >>> Bytecode_invoke* invoke = Bytecode_invoke_at_check(scope->method(), scope->bci()); >>> if (invoke != NULL) { >>> save_oop_result = invoke->result_type() == T_OBJECT; >>> } >>> I guess it's possible that the site is being handled in some different way such that we don't actually have a real call there, particularly if reexecute were true. So your fix seems more right. What do you think about dropping the =true on the printing output since it seems redundant? >>> tom >>> On Feb 8, 2010, at 11:50 AM, Vladimir Kozlov wrote: >>>> Because it will return deoptee (caller method) and not the method >>>> from which we returned already (no frame on stack). >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> Why do you need to record this in the PcDesc? Why can't you just do: >>>>> chunk->at(0)->scope()->method()->return_type() == T_OBJECT >>>>> tom >>>>> On Feb 8, 2010, at 11:12 AM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/6910618/webrev.00 >>>>>> >>>>>> Fixed 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") >>>>>> >>>>>> Problem: >>>>>> If deoptimization happened on the return from a call which >>>>>> which returns oop, the oop will be not updated during GC which >>>>>> is triggered by scalar replaced objects reallocation. >>>>>> >>>>>> Solution: >>>>>> Mark in PcDesc call sites which return oop (this is main part of changes) >>>>>> and save the result oop across objects reallocation during deoptimization. >>>>>> >>>>>> Reviewed by: >>>>>> >>>>>> Fix verified (y/n): y, test >>>>>> >>>>>> Other testing: >>>>>> JPRT >>>>>> > From Thomas.Rodriguez at Sun.COM Mon Feb 8 19:10:42 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 08 Feb 2010 19:10:42 -0800 Subject: Request for reviews (M): 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") In-Reply-To: <4B70AC21.3020809@sun.com> References: <4B706203.5020104@sun.com> <4B706AED.50004@sun.com> <6BE2537D-F489-48F4-94E1-A8045C1BFAF7@Sun.COM> <4B7085C7.6000403@sun.com> <390DCB70-B5B2-451A-B898-539557CF4EE0@Sun.COM> <4B70AC21.3020809@sun.com> Message-ID: <3A2B6200-955B-46BE-B6A8-FF3B20CCFF57@Sun.COM> s/guaranty/guaranteed/ otherwise that looks good. tom On Feb 8, 2010, at 4:28 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6910618/webrev.01 > > I added comment about return_oop in deoptimization.cpp. > And I added the regression test case. I finally made it fail > with current VM (have to force inlining StringBuilder::append). > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Feb 8, 2010, at 1:44 PM, Vladimir Kozlov wrote: >>> Thank you, Tom >>> >>> Bytecode_invoke_at_check() does not check for allocation bytecodes >>> and the bug case is deoptimization on the return from the call to >>> OptoRuntime::new_array_C(). So I am nervous about checking only >>> bytecode since I may miss something. >> I hadn't even considered that case but your fix definitely seems right. You might put a larger comment on return_oop indicating under what conditions it's used any what it can't be divined from the bytecodes themselves. >> tom >>> I will remove printing. >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> Oh, right, wrong end of the stack. So then why can't you get it from the bytecodes of the call site of the last scope? >>>> ScopeDesc* scope = chunk->at(chunk->length() - 1)->scope(); >>>> Bytecode_invoke* invoke = Bytecode_invoke_at_check(scope->method(), scope->bci()); >>>> if (invoke != NULL) { >>>> save_oop_result = invoke->result_type() == T_OBJECT; >>>> } >>>> I guess it's possible that the site is being handled in some different way such that we don't actually have a real call there, particularly if reexecute were true. So your fix seems more right. What do you think about dropping the =true on the printing output since it seems redundant? >>>> tom >>>> On Feb 8, 2010, at 11:50 AM, Vladimir Kozlov wrote: >>>>> Because it will return deoptee (caller method) and not the method >>>>> from which we returned already (no frame on stack). >>>>> >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> Why do you need to record this in the PcDesc? Why can't you just do: >>>>>> chunk->at(0)->scope()->method()->return_type() == T_OBJECT >>>>>> tom >>>>>> On Feb 8, 2010, at 11:12 AM, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/6910618/webrev.00 >>>>>>> >>>>>>> Fixed 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") >>>>>>> >>>>>>> Problem: >>>>>>> If deoptimization happened on the return from a call which >>>>>>> which returns oop, the oop will be not updated during GC which >>>>>>> is triggered by scalar replaced objects reallocation. >>>>>>> >>>>>>> Solution: >>>>>>> Mark in PcDesc call sites which return oop (this is main part of changes) >>>>>>> and save the result oop across objects reallocation during deoptimization. >>>>>>> >>>>>>> Reviewed by: >>>>>>> >>>>>>> Fix verified (y/n): y, test >>>>>>> >>>>>>> Other testing: >>>>>>> JPRT >>>>>>> From Vladimir.Kozlov at Sun.COM Mon Feb 8 19:11:40 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 08 Feb 2010 19:11:40 -0800 Subject: Request for reviews (M): 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") In-Reply-To: <3A2B6200-955B-46BE-B6A8-FF3B20CCFF57@Sun.COM> References: <4B706203.5020104@sun.com> <4B706AED.50004@sun.com> <6BE2537D-F489-48F4-94E1-A8045C1BFAF7@Sun.COM> <4B7085C7.6000403@sun.com> <390DCB70-B5B2-451A-B898-539557CF4EE0@Sun.COM> <4B70AC21.3020809@sun.com> <3A2B6200-955B-46BE-B6A8-FF3B20CCFF57@Sun.COM> Message-ID: <4B70D26C.9070506@sun.com> Thank you, Tom Tom Rodriguez wrote: > s/guaranty/guaranteed/ otherwise that looks good. Fixed. Vladimir > > tom > > On Feb 8, 2010, at 4:28 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6910618/webrev.01 >> >> I added comment about return_oop in deoptimization.cpp. >> And I added the regression test case. I finally made it fail >> with current VM (have to force inlining StringBuilder::append). >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> On Feb 8, 2010, at 1:44 PM, Vladimir Kozlov wrote: >>>> Thank you, Tom >>>> >>>> Bytecode_invoke_at_check() does not check for allocation bytecodes >>>> and the bug case is deoptimization on the return from the call to >>>> OptoRuntime::new_array_C(). So I am nervous about checking only >>>> bytecode since I may miss something. >>> I hadn't even considered that case but your fix definitely seems right. You might put a larger comment on return_oop indicating under what conditions it's used any what it can't be divined from the bytecodes themselves. >>> tom >>>> I will remove printing. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> Oh, right, wrong end of the stack. So then why can't you get it from the bytecodes of the call site of the last scope? >>>>> ScopeDesc* scope = chunk->at(chunk->length() - 1)->scope(); >>>>> Bytecode_invoke* invoke = Bytecode_invoke_at_check(scope->method(), scope->bci()); >>>>> if (invoke != NULL) { >>>>> save_oop_result = invoke->result_type() == T_OBJECT; >>>>> } >>>>> I guess it's possible that the site is being handled in some different way such that we don't actually have a real call there, particularly if reexecute were true. So your fix seems more right. What do you think about dropping the =true on the printing output since it seems redundant? >>>>> tom >>>>> On Feb 8, 2010, at 11:50 AM, Vladimir Kozlov wrote: >>>>>> Because it will return deoptee (caller method) and not the method >>>>>> from which we returned already (no frame on stack). >>>>>> >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> Why do you need to record this in the PcDesc? Why can't you just do: >>>>>>> chunk->at(0)->scope()->method()->return_type() == T_OBJECT >>>>>>> tom >>>>>>> On Feb 8, 2010, at 11:12 AM, Vladimir Kozlov wrote: >>>>>>>> http://cr.openjdk.java.net/~kvn/6910618/webrev.00 >>>>>>>> >>>>>>>> Fixed 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") >>>>>>>> >>>>>>>> Problem: >>>>>>>> If deoptimization happened on the return from a call which >>>>>>>> which returns oop, the oop will be not updated during GC which >>>>>>>> is triggered by scalar replaced objects reallocation. >>>>>>>> >>>>>>>> Solution: >>>>>>>> Mark in PcDesc call sites which return oop (this is main part of changes) >>>>>>>> and save the result oop across objects reallocation during deoptimization. >>>>>>>> >>>>>>>> Reviewed by: >>>>>>>> >>>>>>>> Fix verified (y/n): y, test >>>>>>>> >>>>>>>> Other testing: >>>>>>>> JPRT >>>>>>>> > From vladimir.kozlov at sun.com Mon Feb 8 21:42:22 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 09 Feb 2010 05:42:22 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6910605: C2: NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used Message-ID: <20100209054226.70ECA417FE@hg.openjdk.java.net> Changeset: f516d5d7a019 Author: kvn Date: 2010-02-08 12:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f516d5d7a019 6910605: C2: NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used Summary: Set the reexecute bit for runtime calls _new_array_Java when they used for _multianewarray bytecode. Reviewed-by: never ! src/share/vm/code/pcDesc.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/6910605/Test.java From Christian.Thalinger at Sun.COM Tue Feb 9 03:04:24 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 09 Feb 2010 12:04:24 +0100 Subject: Request for reviews (M): 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") In-Reply-To: <4B70AC21.3020809@sun.com> References: <4B706203.5020104@sun.com> <4B706AED.50004@sun.com> <6BE2537D-F489-48F4-94E1-A8045C1BFAF7@Sun.COM> <4B7085C7.6000403@sun.com> <390DCB70-B5B2-451A-B898-539557CF4EE0@Sun.COM> <4B70AC21.3020809@sun.com> Message-ID: <4B714138.9070903@Sun.COM> On 02/ 9/10 01:28 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6910618/webrev.01 > > I added comment about return_oop in deoptimization.cpp. > And I added the regression test case. I finally made it fail > with current VM (have to force inlining StringBuilder::append). Looks good. -- Christian From vladimir.kozlov at sun.com Tue Feb 9 07:29:00 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 09 Feb 2010 15:29:00 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6910618: C2: Error: assert(d->is_oop(), "JVM_ArrayCopy: dst not an oop") Message-ID: <20100209152916.4A1084188A@hg.openjdk.java.net> Changeset: f70b0d9ab095 Author: kvn Date: 2010-02-09 01:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f70b0d9ab095 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") Summary: Mark in PcDesc call sites which return oop and save the result oop across objects reallocation during deoptimization. Reviewed-by: never ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/includeDB_core ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/deoptimization.cpp + test/compiler/6910618/Test.java From volker.hollich at sap.com Tue Feb 9 08:12:30 2010 From: volker.hollich at sap.com (Hollich, Volker) Date: Tue, 9 Feb 2010 17:12:30 +0100 Subject: Crash due to stack overflow situation if new frame is interpreted and previous is compiled Message-ID: Hello everyone, I observed that the current hotspot (both client/server) fails if a stack overflow situation occurs while generating an interpreted frame on top of a compiled frame. The small example program enclosed fills the stack with compiled frames and makes sure the interpreted frame does not fit onto the stack. In order to provoke this situation, I created a method with extraordinary many locals but this is no prerequisite for the crash situation per se. I see the test crashing hotspots on sparc, x86_32, and x86_64. Given the -Xint option, the test passes easily. The enclosed jar file is runnable and contains the java source code as well. Regards, Volker Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. -------------- next part -------------- A non-text attachment was scrubbed... Name: stackoverflow.jar Type: application/java-archive Size: 206507 bytes Desc: stackoverflow.jar Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100209/08853d68/attachment-0001.bin From Christian.Thalinger at Sun.COM Tue Feb 9 12:32:22 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 09 Feb 2010 21:32:22 +0100 Subject: Crash due to stack overflow situation if new frame is interpreted and previous is compiled In-Reply-To: References: Message-ID: <4B71C656.8070405@Sun.COM> On 02/ 9/10 05:12 PM, Hollich, Volker wrote: > Hello everyone, > > I observed that the current hotspot (both client/server) fails if a > stack overflow situation occurs while generating an interpreted frame > on top of a compiled frame. The small example program enclosed fills > the stack with compiled frames and makes sure the interpreted frame > does not fit onto the stack. In order to provoke this situation, I > created a method with extraordinary many locals but this is no > prerequisite for the crash situation per se. I see the test crashing > hotspots on sparc, x86_32, and x86_64. Given the -Xint option, the > test passes easily. The enclosed jar file is runnable and contains > the java source code as well. I filed: 6924814: Crash due to stack overflow situation if new frame is interpreted and previous is compiled -- Christian From vladimir.kozlov at sun.com Tue Feb 9 13:25:55 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 09 Feb 2010 21:25:55 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0), "adr_type for memory phis only") Message-ID: <20100209212608.00636418E2@hg.openjdk.java.net> Changeset: 4ee1c645110e Author: kvn Date: 2010-02-09 10:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4ee1c645110e 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") Summary: Use PhiNode::make_blank(r, n) method to construct the phi. Reviewed-by: never ! src/share/vm/opto/loopopts.cpp From Vladimir.Kozlov at Sun.COM Tue Feb 9 15:32:31 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 09 Feb 2010 15:32:31 -0800 Subject: Crash due to stack overflow situation if new frame is interpreted and previous is compiled In-Reply-To: <4B71C656.8070405@Sun.COM> References: <4B71C656.8070405@Sun.COM> Message-ID: <4B71F08F.6060202@sun.com> It could be another incarnation of next bug (in Fix Failed state): 6474998: nsk/regression/b4688375 test crashes hotspot Vladimir Christian Thalinger wrote: > On 02/ 9/10 05:12 PM, Hollich, Volker wrote: >> Hello everyone, >> >> I observed that the current hotspot (both client/server) fails if a >> stack overflow situation occurs while generating an interpreted frame >> on top of a compiled frame. The small example program enclosed fills >> the stack with compiled frames and makes sure the interpreted frame >> does not fit onto the stack. In order to provoke this situation, I >> created a method with extraordinary many locals but this is no >> prerequisite for the crash situation per se. I see the test crashing >> hotspots on sparc, x86_32, and x86_64. Given the -Xint option, the >> test passes easily. The enclosed jar file is runnable and contains >> the java source code as well. > > I filed: > > 6924814: Crash due to stack overflow situation if new frame is > interpreted and previous is compiled > > -- Christian From Coleen.Phillimore at Sun.COM Tue Feb 9 16:43:39 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Tue, 09 Feb 2010 19:43:39 -0500 Subject: Crash due to stack overflow situation if new frame is interpreted and previous is compiled In-Reply-To: <4B71F08F.6060202@sun.com> References: <4B71C656.8070405@Sun.COM> <4B71F08F.6060202@sun.com> Message-ID: <4B72013B.9060406@sun.com> I remember that bug. The idea was to stack bang Shadow Pages before we put the interpreter frames back on the stack but it didn't work, or probably wasn't coded carefully enough. The calculations of how much stack to check was probably wrong. Coleen On 02/09/10 18:32, Vladimir Kozlov wrote: > It could be another incarnation of next bug (in Fix Failed state): > > 6474998: nsk/regression/b4688375 test crashes hotspot > > Vladimir > > Christian Thalinger wrote: >> On 02/ 9/10 05:12 PM, Hollich, Volker wrote: >>> Hello everyone, >>> >>> I observed that the current hotspot (both client/server) fails if a >>> stack overflow situation occurs while generating an interpreted frame >>> on top of a compiled frame. The small example program enclosed fills >>> the stack with compiled frames and makes sure the interpreted frame >>> does not fit onto the stack. In order to provoke this situation, I >>> created a method with extraordinary many locals but this is no >>> prerequisite for the crash situation per se. I see the test crashing >>> hotspots on sparc, x86_32, and x86_64. Given the -Xint option, the >>> test passes easily. The enclosed jar file is runnable and contains >>> the java source code as well. >> >> I filed: >> >> 6924814: Crash due to stack overflow situation if new frame is >> interpreted and previous is compiled >> >> -- Christian From Vladimir.Kozlov at Sun.COM Thu Feb 11 12:32:46 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 11 Feb 2010 12:32:46 -0800 Subject: Request for reviews (S): 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") Message-ID: <4B74696E.1040207@sun.com> http://cr.openjdk.java.net/~kvn/6925249/webrev Fixed 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") Problem: Assert triggered when printing debug information for top deoptimized frame. Such frame has last_sp == interpreter_frame_monitor_end if there is no expressions and interpreter_frame_monitor_end == interpreter_frame_monitor_begin if there are no monitors. Solution: Fix assert. There is also misleading printing for stack expressions for middle deoptimized frames since it prints value of passed arguments to callee frame which is not initialized at the time of printing. But I decided don't touch any structures and values in vframe and iframe since they work and the problem only with printing. Also did some cleanup and removed printing create_vframeArray since values are still not initialized. Reviewed by: Fix verified (y/n): y, test Other testing: JPRT From Christian.Thalinger at Sun.COM Fri Feb 12 02:37:58 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 12 Feb 2010 11:37:58 +0100 Subject: Request for reviews (S): 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") In-Reply-To: <4B74696E.1040207@sun.com> References: <4B74696E.1040207@sun.com> Message-ID: <4B752F86.5020502@Sun.COM> On 02/11/10 09:32 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6925249/webrev > > Fixed 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") > > Problem: > Assert triggered when printing debug information for top deoptimized frame. > Such frame has last_sp == interpreter_frame_monitor_end if there is no > expressions and interpreter_frame_monitor_end == interpreter_frame_monitor_begin > if there are no monitors. > > Solution: > Fix assert. There is also misleading printing for stack expressions for middle > deoptimized frames since it prints value of passed arguments to callee frame > which is not initialized at the time of printing. But I decided don't touch > any structures and values in vframe and iframe since they work and the problem > only with printing. > Also did some cleanup and removed printing create_vframeArray since values are > still not initialized. > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > Looks good. -- Christian From gbenson at redhat.com Fri Feb 12 03:21:23 2010 From: gbenson at redhat.com (Gary Benson) Date: Fri, 12 Feb 2010 11:21:23 +0000 Subject: Review Request: Zero speedup Message-ID: <20100212112123.GB724@redhat.com> Hi all, Zero's normal and native method entries both call methodOopDesc::result_type when a method returns without an exception. I didn't realise, but this parses the method's signature, so is pretty slow. This webrev makes Zero figure out result types in a similar way to the x86 and sparc C++ interpreter implementations. http://cr.openjdk.java.net/~gbenson/zero-speedup-01/ Some quick and dirty SPECjvm98 numbers (not produced in compliance with the SPECjvm98 run rules and therefore not comparable with SPECjvm98 metrics): Old New Speedup compress 151.38 136.34 9.9% jess 38.81 28.64 26.2% db 73.22 59.11 19.3% javac 43.10 34.84 19.2% mpegaudio 108.47 100.61 7.2% mtrt 38.66 29.30 24.2% jack 27.68 22.40 19.1% I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From Vladimir.Kozlov at Sun.COM Fri Feb 12 07:34:02 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 12 Feb 2010 07:34:02 -0800 Subject: Request for reviews (S): 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") In-Reply-To: <4B752F86.5020502@Sun.COM> References: <4B74696E.1040207@sun.com> <4B752F86.5020502@Sun.COM> Message-ID: <4B7574EA.8040202@sun.com> Thank you, Christian Vladimir On 2/12/10 2:37 AM, Christian Thalinger wrote: > On 02/11/10 09:32 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6925249/webrev >> >> Fixed 6925249: assert(last_sp< (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") >> >> Problem: >> Assert triggered when printing debug information for top deoptimized frame. >> Such frame has last_sp == interpreter_frame_monitor_end if there is no >> expressions and interpreter_frame_monitor_end == interpreter_frame_monitor_begin >> if there are no monitors. >> >> Solution: >> Fix assert. There is also misleading printing for stack expressions for middle >> deoptimized frames since it prints value of passed arguments to callee frame >> which is not initialized at the time of printing. But I decided don't touch >> any structures and values in vframe and iframe since they work and the problem >> only with printing. >> Also did some cleanup and removed printing create_vframeArray since values are >> still not initialized. >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > > Looks good. -- Christian From Vladimir.Kozlov at Sun.COM Fri Feb 12 10:17:16 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 12 Feb 2010 10:17:16 -0800 Subject: Review Request: Zero speedup In-Reply-To: <20100212112123.GB724@redhat.com> References: <20100212112123.GB724@redhat.com> Message-ID: <4B759B2C.9010505@sun.com> Gary, I created bug 6926048: Improve Zero performance Changes are good so I will push them. Thanks, Vladimir Gary Benson wrote: > Hi all, > > Zero's normal and native method entries both call > methodOopDesc::result_type when a method returns without an exception. > I didn't realise, but this parses the method's signature, so is pretty > slow. This webrev makes Zero figure out result types in a similar way > to the x86 and sparc C++ interpreter implementations. > > http://cr.openjdk.java.net/~gbenson/zero-speedup-01/ > > Some quick and dirty SPECjvm98 numbers (not produced in compliance > with the SPECjvm98 run rules and therefore not comparable with > SPECjvm98 metrics): > > Old New Speedup > compress 151.38 136.34 9.9% > jess 38.81 28.64 26.2% > db 73.22 59.11 19.3% > javac 43.10 34.84 19.2% > mpegaudio 108.47 100.61 7.2% > mtrt 38.66 29.30 24.2% > jack 27.68 22.40 19.1% > > I don't have a bug id for this. > > Cheers, > Gary > From vladimir.kozlov at sun.com Fri Feb 12 11:06:31 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 12 Feb 2010 19:06:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(), "bad tos") Message-ID: <20100212190635.36C3E41D4F@hg.openjdk.java.net> Changeset: e3a4305c6bc3 Author: kvn Date: 2010-02-12 08:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e3a4305c6bc3 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") Summary: Fix assert since top deoptimized frame has last_sp == interpreter_frame_monitor_begin if there are no expressions. Reviewed-by: twisti ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/vframeArray.cpp From Thomas.Rodriguez at Sun.COM Fri Feb 12 12:46:33 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 12 Feb 2010 12:46:33 -0800 Subject: uncommon trap for athrow In-Reply-To: References: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> <72599AF7-126F-413A-A7C9-3E76F40BCE3E@sun.com> <91677D2A-FF8C-4E76-B680-2C66588F53B9@Sun.COM> Message-ID: <241B8ACD-ED45-4222-839F-343817012546@Sun.COM> I've been looking this again because there's a push for a fix and I've decided that removing athrow from can_rerun_bytecodes isn't really the right fix. It looks to me like the uncommon trap path is used for 2 reasons: if the klass mentioned in the handler is unloaded or if the klass has subklasses. There's a note there that now that subtype checks are fast we should emit a full subtype check instead of uncommon trapping. Fixing the code to do subtype check makes this test case work without deopt. It doesn't seem to me that the primary purpose of this uncommon trap is really to prune out exception paths but to deal with cases we don't handle. In practice it appears to be extremely rare that we even emit a trap. Anyway, this is what I'm thinking: http://javaweb.sfbay.sun.com/~never/webrev/athrow/src/share/vm/opto/doCall.cpp.udiff.html Any gotchas that I should look out for with making this change? It's rare that it even emits this case with javac being the only benchmark test that really trigger its. tom On Sep 10, 2009, at 12:02 PM, John Rose wrote: > On Sep 10, 2009, at 11:30 AM, Tom Rodriguez wrote: > >> maybe the uncommon trap needs to have a proper trap count like other kinds of uncommon traps so that we could avoid it if it's hot. That might be better. > > I agree; if it gets hot we should make the extra paths. > > -- John From Thomas.Rodriguez at Sun.COM Fri Feb 12 13:04:39 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 12 Feb 2010 13:04:39 -0800 Subject: uncommon trap for athrow In-Reply-To: <241B8ACD-ED45-4222-839F-343817012546@Sun.COM> References: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> <72599AF7-126F-413A-A7C9-3E76F40BCE3E@sun.com> <91677D2A-FF8C-4E76-B680-2C66588F53B9@Sun.COM> <241B8ACD-ED45-4222-839F-343817012546@Sun.COM> Message-ID: <4FA1F7C4-CD8D-46C8-86C5-5A679045EE88@sun.com> Sorry for the SWAN URL. http://cr.openjdk.java.net/~never/6877221/src/share/vm/opto/doCall.cpp.udiff.html tom On Feb 12, 2010, at 12:46 PM, Tom Rodriguez wrote: > I've been looking this again because there's a push for a fix and I've decided that removing athrow from can_rerun_bytecodes isn't really the right fix. It looks to me like the uncommon trap path is used for 2 reasons: if the klass mentioned in the handler is unloaded or if the klass has subklasses. There's a note there that now that subtype checks are fast we should emit a full subtype check instead of uncommon trapping. Fixing the code to do subtype check makes this test case work without deopt. It doesn't seem to me that the primary purpose of this uncommon trap is really to prune out exception paths but to deal with cases we don't handle. In practice it appears to be extremely rare that we even emit a trap. > > Anyway, this is what I'm thinking: > > http://javaweb.sfbay.sun.com/~never/webrev/athrow/src/share/vm/opto/doCall.cpp.udiff.html > > Any gotchas that I should look out for with making this change? It's rare that it even emits this case with javac being the only benchmark test that really trigger its. > > tom > > On Sep 10, 2009, at 12:02 PM, John Rose wrote: > >> On Sep 10, 2009, at 11:30 AM, Tom Rodriguez wrote: >> >>> maybe the uncommon trap needs to have a proper trap count like other kinds of uncommon traps so that we could avoid it if it's hot. That might be better. >> >> I agree; if it gets hot we should make the extra paths. >> >> -- John > From vladimir.kozlov at sun.com Fri Feb 12 13:05:45 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 12 Feb 2010 21:05:45 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6926048: Improve Zero performance Message-ID: <20100212210548.A3AE341D72@hg.openjdk.java.net> Changeset: c09ee209b65c Author: kvn Date: 2010-02-12 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c09ee209b65c 6926048: Improve Zero performance Summary: Make Zero figure out result types in a similar way to C++ interpreter implementation. Reviewed-by: kvn Contributed-by: gbenson at redhat.com ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp From Vladimir.Kozlov at Sun.COM Fri Feb 12 14:29:21 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 12 Feb 2010 14:29:21 -0800 Subject: uncommon trap for athrow In-Reply-To: <4FA1F7C4-CD8D-46C8-86C5-5A679045EE88@sun.com> References: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> <72599AF7-126F-413A-A7C9-3E76F40BCE3E@sun.com> <91677D2A-FF8C-4E76-B680-2C66588F53B9@Sun.COM> <241B8ACD-ED45-4222-839F-343817012546@Sun.COM> <4FA1F7C4-CD8D-46C8-86C5-5A679045EE88@sun.com> Message-ID: <4B75D641.6010203@sun.com> Tom, I don see any issues. Only that the SSC_full_test subtype check code will be inline (not low probability) and larger then original. Also the fast path has different probability for the check (0.9 vs 0.7). Did you run jvm2008 to see how many cases there? Thanks, Vladimir Tom Rodriguez wrote: > Sorry for the SWAN URL. http://cr.openjdk.java.net/~never/6877221/src/share/vm/opto/doCall.cpp.udiff.html > > tom > > On Feb 12, 2010, at 12:46 PM, Tom Rodriguez wrote: > >> I've been looking this again because there's a push for a fix and I've decided that removing athrow from can_rerun_bytecodes isn't really the right fix. It looks to me like the uncommon trap path is used for 2 reasons: if the klass mentioned in the handler is unloaded or if the klass has subklasses. There's a note there that now that subtype checks are fast we should emit a full subtype check instead of uncommon trapping. Fixing the code to do subtype check makes this test case work without deopt. It doesn't seem to me that the primary purpose of this uncommon trap is really to prune out exception paths but to deal with cases we don't handle. In practice it appears to be extremely rare that we even emit a trap. >> >> Anyway, this is what I'm thinking: >> >> http://javaweb.sfbay.sun.com/~never/webrev/athrow/src/share/vm/opto/doCall.cpp.udiff.html >> >> Any gotchas that I should look out for with making this change? It's rare that it even emits this case with javac being the only benchmark test that really trigger its. >> >> tom >> >> On Sep 10, 2009, at 12:02 PM, John Rose wrote: >> >>> On Sep 10, 2009, at 11:30 AM, Tom Rodriguez wrote: >>> >>>> maybe the uncommon trap needs to have a proper trap count like other kinds of uncommon traps so that we could avoid it if it's hot. That might be better. >>> I agree; if it gets hot we should make the extra paths. >>> >>> -- John > From John.Rose at Sun.COM Fri Feb 12 14:37:42 2010 From: John.Rose at Sun.COM (John Rose) Date: Fri, 12 Feb 2010 14:37:42 -0800 Subject: uncommon trap for athrow In-Reply-To: <4FA1F7C4-CD8D-46C8-86C5-5A679045EE88@sun.com> References: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> <72599AF7-126F-413A-A7C9-3E76F40BCE3E@sun.com> <91677D2A-FF8C-4E76-B680-2C66588F53B9@Sun.COM> <241B8ACD-ED45-4222-839F-343817012546@Sun.COM> <4FA1F7C4-CD8D-46C8-86C5-5A679045EE88@sun.com> Message-ID: Yes, that should work. That code was always half one thing and half another (half trap and half branch). This is a good cleanup. It's possible that the trapping behavior helps (as I said earlier) by removing paths from the machine-level CFG. This would be in the case where the handler has never been executed (the common case), not when it is in active use. We could consider building some logic complementary to 'treat_throw_as_hot' in graphKit.cpp: A suitable 'treat_handler_as_hot' condition, when true, would route control flow from every call site, but the normal code shape would be a trap. [Taking a careful look at 'catch_inline_exceptions'...] I don't think the traps appear much in compiled code. As you say, they are used for unloaded classes (which we don't much care about) and for non-exact catch types. But the latter case happens only if the predicate 'remaining == 1' fails to pick off the common case of a single catch type. So maybe the traps have always been rare, in which case it's OK to eliminate all of them. -- John On Feb 12, 2010, at 1:04 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6877221/src/share/vm/opto/doCall.cpp.udiff.html From Thomas.Rodriguez at Sun.COM Fri Feb 12 14:57:04 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 12 Feb 2010 14:57:04 -0800 Subject: uncommon trap for athrow In-Reply-To: <4B75D641.6010203@sun.com> References: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> <72599AF7-126F-413A-A7C9-3E76F40BCE3E@sun.com> <91677D2A-FF8C-4E76-B680-2C66588F53B9@Sun.COM> <241B8ACD-ED45-4222-839F-343817012546@Sun.COM> <4FA1F7C4-CD8D-46C8-86C5-5A679045EE88@sun.com> <4B75D641.6010203@sun.com> Message-ID: On Feb 12, 2010, at 2:29 PM, Vladimir Kozlov wrote: > Tom, I don see any issues. Only that the SSC_full_test subtype check code will be > inline (not low probability) and larger then original. In practice the test will never be more that an extra load unless the inheritance depth is enough to trigger the subtype search logic. That doesn't seem like much extra code. > Also the fast path has different probability for the check (0.9 vs 0.7). I don't really think the probability will really play into the code generation that much since it's the exception paths. > Did you run jvm2008 to see how many cases there? It triggers in the compiler benchmarks but that's it. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> Sorry for the SWAN URL. http://cr.openjdk.java.net/~never/6877221/src/share/vm/opto/doCall.cpp.udiff.html >> tom >> On Feb 12, 2010, at 12:46 PM, Tom Rodriguez wrote: >>> I've been looking this again because there's a push for a fix and I've decided that removing athrow from can_rerun_bytecodes isn't really the right fix. It looks to me like the uncommon trap path is used for 2 reasons: if the klass mentioned in the handler is unloaded or if the klass has subklasses. There's a note there that now that subtype checks are fast we should emit a full subtype check instead of uncommon trapping. Fixing the code to do subtype check makes this test case work without deopt. It doesn't seem to me that the primary purpose of this uncommon trap is really to prune out exception paths but to deal with cases we don't handle. In practice it appears to be extremely rare that we even emit a trap. >>> >>> Anyway, this is what I'm thinking: >>> >>> http://javaweb.sfbay.sun.com/~never/webrev/athrow/src/share/vm/opto/doCall.cpp.udiff.html >>> >>> Any gotchas that I should look out for with making this change? It's rare that it even emits this case with javac being the only benchmark test that really trigger its. >>> >>> tom >>> >>> On Sep 10, 2009, at 12:02 PM, John Rose wrote: >>> >>>> On Sep 10, 2009, at 11:30 AM, Tom Rodriguez wrote: >>>> >>>>> maybe the uncommon trap needs to have a proper trap count like other kinds of uncommon traps so that we could avoid it if it's hot. That might be better. >>>> I agree; if it gets hot we should make the extra paths. >>>> >>>> -- John From Thomas.Rodriguez at Sun.COM Fri Feb 12 15:28:09 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 12 Feb 2010 15:28:09 -0800 Subject: uncommon trap for athrow In-Reply-To: References: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> <72599AF7-126F-413A-A7C9-3E76F40BCE3E@sun.com> <91677D2A-FF8C-4E76-B680-2C66588F53B9@Sun.COM> <241B8ACD-ED45-4222-839F-343817012546@Sun.COM> <4FA1F7C4-CD8D-46C8-86C5-5A679045EE88@sun.com> Message-ID: On Feb 12, 2010, at 2:37 PM, John Rose wrote: > Yes, that should work. That code was always half one thing and half another (half trap and half branch). This is a good cleanup. > > It's possible that the trapping behavior helps (as I said earlier) by removing paths from the machine-level CFG. This would be in the case where the handler has never been executed (the common case), not when it is in active use. We could consider building some logic complementary to 'treat_throw_as_hot' in graphKit.cpp: A suitable 'treat_handler_as_hot' condition, when true, would route control flow from every call site, but the normal code shape would be a trap. I don't really think this changes the number of edges in the graph. Unless we emit an uncommon trap we produce an edge for every exception handler, either as an inline test or as a CatchProj off the rethrow call. The oddity in the case that created the bug report was that the bytecode was an athrow which is rerunnable so we put in the uncommon trap. Emitting the trap in general is rare, (<< 1%) and I think that if it became hot we'd really want to recompile it instead of trapping every time. With my change the existing trap really devolves into a Reason_unloaded trap though it's using Action_none which isn't so great if the path becomes frequent. We might simply remove it since we generate an uncommon trap in catch_call_exceptions for unloaded classes, though I wouldn't want to do that as part of this change since this is likely to be backported. treat_handler_as_hot is an interesting idea. We could consider profiling exception dispatch to drive logic like that. However, I'd want some measurable improvement from such a change before we add yet another reason to throw out code and regenerate it. tom > > [Taking a careful look at 'catch_inline_exceptions'...] I don't think the traps appear much in compiled code. As you say, they are used for unloaded classes (which we don't much care about) and for non-exact catch types. But the latter case happens only if the predicate 'remaining == 1' fails to pick off the common case of a single catch type. So maybe the traps have always been rare, in which case it's OK to eliminate all of them. > > -- John > > On Feb 12, 2010, at 1:04 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/6877221/src/share/vm/opto/doCall.cpp.udiff.html > From vladimir.kozlov at sun.com Fri Feb 12 19:30:23 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Sat, 13 Feb 2010 03:30:23 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 17 new changesets Message-ID: <20100213033115.BA8BE41DDB@hg.openjdk.java.net> Changeset: 6deeaebad47a Author: dcubed Date: 2010-02-01 17:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6deeaebad47a 6902182: 4/4 Starting with jdwp agent should not incur performance penalty Summary: Rename can_post_exceptions support to can_post_on_exceptions. Add support for should_post_on_exceptions flag to permit per JavaThread optimizations. Reviewed-by: never, kvn, dcubed Contributed-by: tom.deneau at amd.com ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 0fc941df6fb7 Author: dcubed Date: 2010-02-02 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0fc941df6fb7 6918421: 1/1 in-process JVM now ignores preset Windows unhandled exception filter Summary: Add support for chaining Windows UnhandledExceptionFilter handlers Reviewed-by: kamg, dholmes, never, acorn, ikrylov ! src/os/windows/vm/os_windows.cpp Changeset: f19bf22685cc Author: dcubed Date: 2010-02-02 11:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f19bf22685cc Merge ! src/os/windows/vm/os_windows.cpp Changeset: 7f8790caccb0 Author: apangin Date: 2010-02-04 15:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7f8790caccb0 Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 359445e739ac Author: mikejwre Date: 2010-01-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/359445e739ac Added tag jdk7-b80 for changeset 3003ddd1d433 ! .hgtags Changeset: 10f901469941 Author: trims Date: 2010-01-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/10f901469941 Merge Changeset: 1f9b07674480 Author: trims Date: 2010-01-22 15:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1f9b07674480 6919437: Bump the HS17 build number to 08 Summary: Update the HS17 build number to 08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1999f5b12482 Author: mikejwre Date: 2010-01-28 11:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1999f5b12482 Added tag jdk7-b81 for changeset 1f9b07674480 ! .hgtags Changeset: dba18cabafec Author: trims Date: 2010-02-05 12:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dba18cabafec Merge Changeset: ff3232b68fbb Author: trims Date: 2010-02-05 12:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ff3232b68fbb 6921473: Bump the HS17 build number to 09 Summary: Update the HS17 build number to 09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 745c853ee57f Author: johnc Date: 2010-01-29 14:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/745c853ee57f 6885297: java -XX:RefDiscoveryPolicy=2 or -XX:TLABWasteTargetPercent=0 cause VM crash Summary: Interval checking is now being performed on the values passed in for these two flags. The current acceptable range for RefDiscoveryPolicy is [0..1], and for TLABWasteTargetPercent it is [1..100]. Reviewed-by: apetrusenko, ysr ! src/share/vm/includeDB_core ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 6484c4ee11cb Author: ysr Date: 2010-02-01 17:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6484c4ee11cb 6904516: More object array barrier fixes, following up on 6906727 Summary: Fixed missing pre-barrier calls for G1, modified C1 to call pre- and correct post-barrier interfaces, deleted obsolete interface, (temporarily) disabled redundant deferred barrier in BacktraceBuilder. Reviewed-by: coleenp, jmasa, kvn, never ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/runtime/stubRoutines.cpp Changeset: deada8912c54 Author: johnc Date: 2010-02-02 18:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/deada8912c54 6914402: G1: assert(!is_young_card(cached_ptr),"shouldn't get a card in young region") Summary: Invalid assert. Filter cards evicted from the card count cache instead. Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp Changeset: 230fac611b50 Author: johnc Date: 2010-02-08 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/230fac611b50 Merge ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/includeDB_core Changeset: 455df1b81409 Author: kamg Date: 2010-02-08 13:49 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/455df1b81409 6587322: dtrace probe object__alloc doesn't fire in some situations on amd64 Summary: Fix misplaced probe point Reviewed-by: rasbold, phh Contributed-by: neojia at gmail.com ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 95d21201c29a Author: apangin Date: 2010-02-11 10:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/95d21201c29a Merge Changeset: 7b4415a18c8a Author: kvn Date: 2010-02-12 15:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7b4415a18c8a Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/sharedRuntime.cpp From john.coomes at sun.com Sun Feb 14 11:52:05 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sun, 14 Feb 2010 19:52:05 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b83 for changeset 6880a3af9add Message-ID: <20100214195205.7A06B42075@hg.openjdk.java.net> Changeset: 2f3ea057d1ad Author: mikejwre Date: 2010-02-12 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/2f3ea057d1ad Added tag jdk7-b83 for changeset 6880a3af9add ! .hgtags From john.coomes at sun.com Sun Feb 14 11:52:11 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sun, 14 Feb 2010 19:52:11 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b83 for changeset fde0df7a2384 Message-ID: <20100214195215.AA34F42076@hg.openjdk.java.net> Changeset: 68c8961a82e4 Author: mikejwre Date: 2010-02-12 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/68c8961a82e4 Added tag jdk7-b83 for changeset fde0df7a2384 ! .hgtags From john.coomes at sun.com Sun Feb 14 11:55:30 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sun, 14 Feb 2010 19:55:30 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b83 for changeset 309a0a7fc6ce Message-ID: <20100214195531.438B242078@hg.openjdk.java.net> Changeset: c664aff74b41 Author: mikejwre Date: 2010-02-12 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/c664aff74b41 Added tag jdk7-b83 for changeset 309a0a7fc6ce ! .hgtags From john.coomes at sun.com Sun Feb 14 11:55:44 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sun, 14 Feb 2010 19:55:44 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b83 for changeset 371e3ded591d Message-ID: <20100214195546.3F06442079@hg.openjdk.java.net> Changeset: 8bc02839eee4 Author: mikejwre Date: 2010-02-12 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/8bc02839eee4 Added tag jdk7-b83 for changeset 371e3ded591d ! .hgtags From john.coomes at sun.com Sun Feb 14 11:56:05 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sun, 14 Feb 2010 19:56:05 +0000 Subject: hg: jdk7/hotspot-comp/jdk: Added tag jdk7-b83 for changeset 9027c6b9d7e2 Message-ID: <20100214195815.8178A4207A@hg.openjdk.java.net> Changeset: 9b82fa0505bc Author: mikejwre Date: 2010-02-12 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9b82fa0505bc Added tag jdk7-b83 for changeset 9027c6b9d7e2 ! .hgtags From john.coomes at sun.com Sun Feb 14 12:02:14 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sun, 14 Feb 2010 20:02:14 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b83 for changeset c9f4ae1f1480 Message-ID: <20100214200230.3AFE44207C@hg.openjdk.java.net> Changeset: 2edcb5dc642d Author: mikejwre Date: 2010-02-12 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2edcb5dc642d Added tag jdk7-b83 for changeset c9f4ae1f1480 ! .hgtags From gbenson at redhat.com Mon Feb 15 01:25:41 2010 From: gbenson at redhat.com (Gary Benson) Date: Mon, 15 Feb 2010 09:25:41 +0000 Subject: Review Request: Zero speedup In-Reply-To: <4B759B2C.9010505@sun.com> References: <20100212112123.GB724@redhat.com> <4B759B2C.9010505@sun.com> Message-ID: <20100215092541.GA3394@redhat.com> Thank you. Vladimir Kozlov wrote: > Gary, > > I created bug 6926048: Improve Zero performance > > Changes are good so I will push them. > > Thanks, > Vladimir > > Gary Benson wrote: > > Hi all, > > > > Zero's normal and native method entries both call > > methodOopDesc::result_type when a method returns without an > > exception. I didn't realise, but this parses the method's > > signature, so is pretty slow. This webrev makes Zero figure out > > result types in a similar way to the x86 and sparc C++ interpreter > > implementations. > > > > http://cr.openjdk.java.net/~gbenson/zero-speedup-01/ > > > > Some quick and dirty SPECjvm98 numbers (not produced in compliance > > with the SPECjvm98 run rules and therefore not comparable with > > SPECjvm98 metrics): > > > > Old New Speedup > > compress 151.38 136.34 9.9% > > jess 38.81 28.64 26.2% > > db 73.22 59.11 19.3% > > javac 43.10 34.84 19.2% > > mpegaudio 108.47 100.61 7.2% > > mtrt 38.66 29.30 24.2% > > jack 27.68 22.40 19.1% > > > > I don't have a bug id for this. > > > > Cheers, > > Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Mon Feb 15 10:38:13 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 15 Feb 2010 19:38:13 +0100 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 Message-ID: <4B799495.5030605@Sun.COM> http://cr.openjdk.java.net/~twisti/6919934/webrev.01/ This implements JSR 292 support for C1 x86. It also includes changes from Tom that change C1 exception unwinding to operate as C2 does it. This makes the JSR 292 implementation easier. Testing: JPRT -- Christian From Thomas.Rodriguez at Sun.COM Mon Feb 15 11:55:01 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 15 Feb 2010 11:55:01 -0800 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <4B799495.5030605@Sun.COM> References: <4B799495.5030605@Sun.COM> Message-ID: We shouldn't push this change until we fork hs18. The C1 changes are correct but I'd really like them to sit in jdk7 for a while. tom On Feb 15, 2010, at 10:38 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6919934/webrev.01/ > > This implements JSR 292 support for C1 x86. It also includes changes > from Tom that change C1 exception unwinding to operate as C2 does it. > This makes the JSR 292 implementation easier. > > Testing: JPRT > > -- Christian From Christian.Thalinger at Sun.COM Mon Feb 15 12:17:33 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 15 Feb 2010 21:17:33 +0100 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: References: <4B799495.5030605@Sun.COM> Message-ID: <4B79ABDD.8060705@Sun.COM> On 02/15/10 08:55 PM, Tom Rodriguez wrote: > We shouldn't push this change until we fork hs18. The C1 changes are > correct but I'd really like them to sit in jdk7 for a while. Sure, no problem. Just a public review to find all problems. Maybe I should also look into how I can emit the MH deopt handler only when required. -- Christian From Vladimir.Kozlov at Sun.COM Mon Feb 15 12:34:53 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 15 Feb 2010 12:34:53 -0800 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <4B799495.5030605@Sun.COM> References: <4B799495.5030605@Sun.COM> Message-ID: <4B79AFED.70301@sun.com> I did not look on C1 code changes but the rest is fine. And I agree with Tom to wait HS18. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6919934/webrev.01/ > > This implements JSR 292 support for C1 x86. It also includes changes > from Tom that change C1 exception unwinding to operate as C2 does it. > This makes the JSR 292 implementation easier. > > Testing: JPRT > > -- Christian From mlists at juma.me.uk Mon Feb 15 14:36:51 2010 From: mlists at juma.me.uk (Ismael Juma) Date: Mon, 15 Feb 2010 22:36:51 +0000 (UTC) Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 References: <4B799495.5030605@Sun.COM> Message-ID: Hi Tom, Tom Rodriguez writes: > We shouldn't push this change until we fork hs18. As a curious outsider, is there a (rough) plan for when this will happen? Thanks, Ismael From Thomas.Rodriguez at Sun.COM Mon Feb 15 17:27:11 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 15 Feb 2010 17:27:11 -0800 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: References: <4B799495.5030605@Sun.COM> Message-ID: <450792CF-FADE-483A-9C55-0893C1F423F2@sun.com> I don't know definitely but it's at least a few weeks, maybe more. tom On Feb 15, 2010, at 2:36 PM, Ismael Juma wrote: > Hi Tom, > > Tom Rodriguez writes: >> We shouldn't push this change until we fork hs18. > > As a curious outsider, is there a (rough) plan for when this will happen? > > Thanks, > Ismael > From mlists at juma.me.uk Mon Feb 15 23:34:21 2010 From: mlists at juma.me.uk (Ismael Juma) Date: Tue, 16 Feb 2010 07:34:21 +0000 (UTC) Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 References: <4B799495.5030605@Sun.COM> <450792CF-FADE-483A-9C55-0893C1F423F2@sun.com> Message-ID: Tom Rodriguez writes: > I don't know definitely but it's at least a few weeks, maybe more. Thanks. Ismael From Christian.Thalinger at Sun.COM Tue Feb 16 05:05:14 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 16 Feb 2010 14:05:14 +0100 Subject: Request for reviews (S): 6926782: CodeBuffer size too small after 6921352 Message-ID: <4B7A980A.3070607@Sun.COM> http://cr.openjdk.java.net/~twisti/6926782/webrev.01/ In the changes for 6921352 I forgot to increase the CodeBuffer size and thus we sometimes get an assert when generating code: # Internal Error (/tmp/jprt/P1/B/233753.kvn/source/src/share/vm/asm/codeBuffer.hpp:169), pid=26304, tid=3011459984 # Error: assert(allocates2(pc),"") The fix is to increase the CodeBuffer size. Additionally I changed the code to emit the deopt MH handler only when it's required. -- Christian From Thomas.Rodriguez at Sun.COM Tue Feb 16 09:10:17 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 16 Feb 2010 09:10:17 -0800 Subject: Request for reviews (S): 6926782: CodeBuffer size too small after 6921352 In-Reply-To: <4B7A980A.3070607@Sun.COM> References: <4B7A980A.3070607@Sun.COM> Message-ID: Looks good. tom On Feb 16, 2010, at 5:05 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6926782/webrev.01/ > > In the changes for 6921352 I forgot to increase the CodeBuffer size > and thus we sometimes get an assert when generating code: > > # Internal Error > (/tmp/jprt/P1/B/233753.kvn/source/src/share/vm/asm/codeBuffer.hpp:169), > pid=26304, tid=3011459984 > # Error: assert(allocates2(pc),"") > > The fix is to increase the CodeBuffer size. Additionally I changed > the code to emit the deopt MH handler only when it's required. > > -- Christian From Thomas.Rodriguez at Sun.COM Tue Feb 16 09:43:43 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 16 Feb 2010 09:43:43 -0800 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <4B799495.5030605@Sun.COM> References: <4B799495.5030605@Sun.COM> Message-ID: <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> Can you change these to just say, // Not required for sparc + void LIR_Assembler::preserve_SP() { + // XXX I'm not sure yet if these are required on SPARC. + } + + + void LIR_Assembler::restore_SP() { + // XXX I'm not sure yet if these are required on SPARC. + } + + c1_Runtime1_x86.cpp: Why does this only have a value for NOT_LP64? Isn't rsi ok for 64 bit? + const Register exception_oop_callee_saved = NOT_LP64(rsi); Otherwise this looks good. tom On Feb 15, 2010, at 10:38 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6919934/webrev.01/ > > This implements JSR 292 support for C1 x86. It also includes changes > from Tom that change C1 exception unwinding to operate as C2 does it. > This makes the JSR 292 implementation easier. > > Testing: JPRT > > -- Christian From Vladimir.Kozlov at Sun.COM Tue Feb 16 09:46:53 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Feb 2010 09:46:53 -0800 Subject: Request for reviews (S): 6926782: CodeBuffer size too small after 6921352 In-Reply-To: <4B7A980A.3070607@Sun.COM> References: <4B7A980A.3070607@Sun.COM> Message-ID: <4B7ADA0D.6060801@sun.com> Christian, I thought you will set the flag during parsing because it could be helpful to know that call site is MH during whole compilation. Is it possible? Adding size for MH should be also under MH check. Thanks, Vladimir On 2/16/10 5:05 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6926782/webrev.01/ > > In the changes for 6921352 I forgot to increase the CodeBuffer size > and thus we sometimes get an assert when generating code: > > # Internal Error > (/tmp/jprt/P1/B/233753.kvn/source/src/share/vm/asm/codeBuffer.hpp:169), > pid=26304, tid=3011459984 > # Error: assert(allocates2(pc),"") > > The fix is to increase the CodeBuffer size. Additionally I changed > the code to emit the deopt MH handler only when it's required. > > -- Christian From Vladimir.Kozlov at Sun.COM Tue Feb 16 10:50:44 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Feb 2010 10:50:44 -0800 Subject: Request for reviews (XS): 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete Message-ID: <4B7AE904.9070301@sun.com> http://cr.openjdk.java.net/~kvn/6926697/webrev Fixed 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete Problem: AdapterHandlerTableIterator is defined only in debug VM but it is used in all non product VM versions. Solution: Use AdapterHandlerTableIterator only in debug VM. Reviewed by: Fix verified (y/n): y, build Other testing: JPRT From Christian.Thalinger at Sun.COM Tue Feb 16 11:24:43 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 16 Feb 2010 20:24:43 +0100 Subject: Request for reviews (S): 6926782: CodeBuffer size too small after 6921352 In-Reply-To: <4B7ADA0D.6060801@sun.com> References: <4B7A980A.3070607@Sun.COM> <4B7ADA0D.6060801@sun.com> Message-ID: <4B7AF0FB.3070502@Sun.COM> On 02/16/10 06:46 PM, Vladimir Kozlov wrote: > Christian, > > I thought you will set the flag during parsing because > it could be helpful to know that call site is MH during whole > compilation. Is it possible? Hmm, it should be. Let me look into it. > Adding size for MH should be also under MH check. That can be done when I have the above working. -- Christian From Christian.Thalinger at Sun.COM Tue Feb 16 11:32:22 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 16 Feb 2010 20:32:22 +0100 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> Message-ID: <4B7AF2C6.70207@Sun.COM> On 02/16/10 06:43 PM, Tom Rodriguez wrote: > Can you change these to just say, // Not required for sparc > > + void LIR_Assembler::preserve_SP() { > + // XXX I'm not sure yet if these are required on SPARC. > + } > + > + > + void LIR_Assembler::restore_SP() { > + // XXX I'm not sure yet if these are required on SPARC. > + } > + > + I can change it yes, but I'm really not sure yet if we need to preserve the SP on SPARC. > > c1_Runtime1_x86.cpp: > > Why does this only have a value for NOT_LP64? Isn't rsi ok for 64 bit? > > > + const Register exception_oop_callee_saved = NOT_LP64(rsi); No, RSI is an argument register on 64 bit and I didn't know which one to use instead. I guess any callee saved might do it? -- Christian From Thomas.Rodriguez at Sun.COM Tue Feb 16 12:05:08 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 16 Feb 2010 12:05:08 -0800 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <4B7AF2C6.70207@Sun.COM> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> Message-ID: <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> On Feb 16, 2010, at 11:32 AM, Christian Thalinger wrote: > On 02/16/10 06:43 PM, Tom Rodriguez wrote: >> Can you change these to just say, // Not required for sparc >> >> + void LIR_Assembler::preserve_SP() { >> + // XXX I'm not sure yet if these are required on SPARC. >> + } >> + >> + >> + void LIR_Assembler::restore_SP() { >> + // XXX I'm not sure yet if these are required on SPARC. >> + } >> + >> + > > I can change it yes, but I'm really not sure yet if we need to preserve > the SP on SPARC. I don't think they are and I'd rather not have XXX comments lying around. If they are needed then I suspect you'll figure it out because of a new bug report, not because the comment is there. > >> >> c1_Runtime1_x86.cpp: >> >> Why does this only have a value for NOT_LP64? Isn't rsi ok for 64 bit? >> >> >> + const Register exception_oop_callee_saved = NOT_LP64(rsi); > > No, RSI is an argument register on 64 bit and I didn't know which one to > use instead. I guess any callee saved might do it? Yep. tom > > -- Christian From Thomas.Rodriguez at Sun.COM Tue Feb 16 12:07:42 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 16 Feb 2010 12:07:42 -0800 Subject: Request for reviews (XS): 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete In-Reply-To: <4B7AE904.9070301@sun.com> References: <4B7AE904.9070301@sun.com> Message-ID: <93F1CBAF-12D6-49A6-9C52-DDAD36850CA2@sun.com> I'd rather have that whole section ifdef ASSERT or make AdapterHandlerTableIterator ifdef PRODUCT. Having contains always return false just seems wrong. tom On Feb 16, 2010, at 10:50 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6926697/webrev > > Fixed 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete > > Problem: > AdapterHandlerTableIterator is defined only in debug VM > but it is used in all non product VM versions. > > Solution: > Use AdapterHandlerTableIterator only in debug VM. > > Reviewed by: > > Fix verified (y/n): y, build > > Other testing: > JPRT > From Thomas.Rodriguez at Sun.COM Tue Feb 16 12:09:42 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 16 Feb 2010 12:09:42 -0800 Subject: review (S) for 6877221: Endless deoptimizations in OSR nmethod Message-ID: http://cr.openjdk.java.net/~never/6877221 6877221: Endless deoptimizations in OSR nmethod Reviewed-by: When emitting the inline exception code if we can't handle all the exception types inline we will try to fall back to an uncommon trap for bytecodes that can be rerun to produce the exceptional condition. All bytecodes except the various invokes can be handled this way. The cases we currently can't handle inline are unloaded catch classes, which will require class loading during lookup and catch classes that have subclasses. That latter is a historical limitation from the times when type checks were more expensive. Currently athrow is handled by rerunning it which means that any exception forwarding logic that uses athrow will force us back into the interpreter for every exception dispatch through this nmethod. Since this fix will likely be backported I want to do the simple fix of removing athrow from the set of rerunnable bytecodes. A more complete fix involving rewriting catch_inline_exceptions to avoid the uncommon trap with Action_none and to perform full type checks inline will be done for hs18. I collected some stats on how catch_inline_exceptions behaves to get some sense of which paths are used. These numbers are generated every benchmark in reference_server plus specjvm2008. In 22631 calls, 16050 terminate by unwinding the frame, 3280 dispatch to a default exception handler, 3176 call the rethrow function, and 125 emit an uncommon trap. Of those uncommon traps the bytecode breakdown is this: 14 anewarray 52 athrow 52 new 7 newarray Of the athrows, 43 are from unloaded classes and the other 9 are because the catch class had subclasses. src/share/vm/opto/parse1.cpp From Vladimir.Kozlov at Sun.COM Tue Feb 16 13:39:24 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Feb 2010 13:39:24 -0800 Subject: Request for reviews (XS): 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete In-Reply-To: <93F1CBAF-12D6-49A6-9C52-DDAD36850CA2@sun.com> References: <4B7AE904.9070301@sun.com> <93F1CBAF-12D6-49A6-9C52-DDAD36850CA2@sun.com> Message-ID: <4B7B108C.1050709@sun.com> Thank you, Tom I will rework the change. Vladimir Tom Rodriguez wrote: > I'd rather have that whole section ifdef ASSERT or make AdapterHandlerTableIterator ifdef PRODUCT. Having contains always return false just seems wrong. > > tom > > On Feb 16, 2010, at 10:50 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6926697/webrev >> >> Fixed 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete >> >> Problem: >> AdapterHandlerTableIterator is defined only in debug VM >> but it is used in all non product VM versions. >> >> Solution: >> Use AdapterHandlerTableIterator only in debug VM. >> >> Reviewed by: >> >> Fix verified (y/n): y, build >> >> Other testing: >> JPRT >> > From Vladimir.Kozlov at Sun.COM Tue Feb 16 15:24:20 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Feb 2010 15:24:20 -0800 Subject: review (S) for 6877221: Endless deoptimizations in OSR nmethod In-Reply-To: References: Message-ID: <4B7B2924.8080707@sun.com> Tom, So making athrow non rerunnable will force to generate runtime call to trow instead of uncommon trap. Correct? Otherwise looks fine. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6877221 > > 6877221: Endless deoptimizations in OSR nmethod > Reviewed-by: > > When emitting the inline exception code if we can't handle all the > exception types inline we will try to fall back to an uncommon trap > for bytecodes that can be rerun to produce the exceptional condition. > All bytecodes except the various invokes can be handled this way. The > cases we currently can't handle inline are unloaded catch classes, > which will require class loading during lookup and catch classes that > have subclasses. That latter is a historical limitation from the > times when type checks were more expensive. Currently athrow is > handled by rerunning it which means that any exception forwarding > logic that uses athrow will force us back into the interpreter for > every exception dispatch through this nmethod. Since this fix will > likely be backported I want to do the simple fix of removing athrow > from the set of rerunnable bytecodes. A more complete fix involving > rewriting catch_inline_exceptions to avoid the uncommon trap with > Action_none and to perform full type checks inline will be done for > hs18. > > I collected some stats on how catch_inline_exceptions behaves to get > some sense of which paths are used. These numbers are generated every > benchmark in reference_server plus specjvm2008. In 22631 calls, 16050 > terminate by unwinding the frame, 3280 dispatch to a default exception > handler, 3176 call the rethrow function, and 125 emit an uncommon > trap. Of those uncommon traps the bytecode breakdown is this: > > 14 anewarray > 52 athrow > 52 new > 7 newarray > > Of the athrows, 43 are from unloaded classes and the other 9 are > because the catch class had subclasses. > > src/share/vm/opto/parse1.cpp From Thomas.Rodriguez at Sun.COM Tue Feb 16 15:32:12 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 16 Feb 2010 15:32:12 -0800 Subject: review (S) for 6877221: Endless deoptimizations in OSR nmethod In-Reply-To: <4B7B2924.8080707@sun.com> References: <4B7B2924.8080707@sun.com> Message-ID: On Feb 16, 2010, at 3:24 PM, Vladimir Kozlov wrote: > Tom, > > So making athrow non rerunnable will force to generate runtime call to trow > instead of uncommon trap. Correct? Yes and we'll get CatchProj's off the call to handle/describe all the exception edges. tom > > Otherwise looks fine. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6877221 >> 6877221: Endless deoptimizations in OSR nmethod >> Reviewed-by: >> When emitting the inline exception code if we can't handle all the >> exception types inline we will try to fall back to an uncommon trap >> for bytecodes that can be rerun to produce the exceptional condition. >> All bytecodes except the various invokes can be handled this way. The >> cases we currently can't handle inline are unloaded catch classes, >> which will require class loading during lookup and catch classes that >> have subclasses. That latter is a historical limitation from the >> times when type checks were more expensive. Currently athrow is >> handled by rerunning it which means that any exception forwarding >> logic that uses athrow will force us back into the interpreter for >> every exception dispatch through this nmethod. Since this fix will >> likely be backported I want to do the simple fix of removing athrow >> from the set of rerunnable bytecodes. A more complete fix involving >> rewriting catch_inline_exceptions to avoid the uncommon trap with >> Action_none and to perform full type checks inline will be done for >> hs18. >> I collected some stats on how catch_inline_exceptions behaves to get >> some sense of which paths are used. These numbers are generated every >> benchmark in reference_server plus specjvm2008. In 22631 calls, 16050 >> terminate by unwinding the frame, 3280 dispatch to a default exception >> handler, 3176 call the rethrow function, and 125 emit an uncommon >> trap. Of those uncommon traps the bytecode breakdown is this: >> 14 anewarray >> 52 athrow >> 52 new >> 7 newarray >> Of the athrows, 43 are from unloaded classes and the other 9 are >> because the catch class had subclasses. >> src/share/vm/opto/parse1.cpp From Vladimir.Kozlov at Sun.COM Tue Feb 16 15:46:16 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Feb 2010 15:46:16 -0800 Subject: Request for reviews (XS): 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete In-Reply-To: <4B7B108C.1050709@sun.com> References: <4B7AE904.9070301@sun.com> <93F1CBAF-12D6-49A6-9C52-DDAD36850CA2@sun.com> <4B7B108C.1050709@sun.com> Message-ID: <4B7B2E48.9060300@sun.com> I changed it to NOT_PRODUCT since it is used to collect statistics and I updated webrev. Vladimir Vladimir Kozlov wrote: > Thank you, Tom > > I will rework the change. > > Vladimir > > Tom Rodriguez wrote: >> I'd rather have that whole section ifdef ASSERT or make >> AdapterHandlerTableIterator ifdef PRODUCT. Having contains always >> return false just seems wrong. >> >> tom >> >> On Feb 16, 2010, at 10:50 AM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/6926697/webrev >>> >>> Fixed 6926697: "optimized" VM build failed: The type >>> "AdapterHandlerTableIterator" is incomplete >>> >>> Problem: >>> AdapterHandlerTableIterator is defined only in debug VM >>> but it is used in all non product VM versions. >>> >>> Solution: >>> Use AdapterHandlerTableIterator only in debug VM. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, build >>> >>> Other testing: >>> JPRT >>> >> From Vladimir.Kozlov at Sun.COM Tue Feb 16 15:59:18 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Feb 2010 15:59:18 -0800 Subject: review (S) for 6877221: Endless deoptimizations in OSR nmethod In-Reply-To: References: <4B7B2924.8080707@sun.com> Message-ID: <4B7B3156.4060907@sun.com> Good. Thanks, Tom. Vladimir Tom Rodriguez wrote: > On Feb 16, 2010, at 3:24 PM, Vladimir Kozlov wrote: > >> Tom, >> >> So making athrow non rerunnable will force to generate runtime call to trow >> instead of uncommon trap. Correct? > > Yes and we'll get CatchProj's off the call to handle/describe all the exception edges. > > tom > >> Otherwise looks fine. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6877221 >>> 6877221: Endless deoptimizations in OSR nmethod >>> Reviewed-by: >>> When emitting the inline exception code if we can't handle all the >>> exception types inline we will try to fall back to an uncommon trap >>> for bytecodes that can be rerun to produce the exceptional condition. >>> All bytecodes except the various invokes can be handled this way. The >>> cases we currently can't handle inline are unloaded catch classes, >>> which will require class loading during lookup and catch classes that >>> have subclasses. That latter is a historical limitation from the >>> times when type checks were more expensive. Currently athrow is >>> handled by rerunning it which means that any exception forwarding >>> logic that uses athrow will force us back into the interpreter for >>> every exception dispatch through this nmethod. Since this fix will >>> likely be backported I want to do the simple fix of removing athrow >>> from the set of rerunnable bytecodes. A more complete fix involving >>> rewriting catch_inline_exceptions to avoid the uncommon trap with >>> Action_none and to perform full type checks inline will be done for >>> hs18. >>> I collected some stats on how catch_inline_exceptions behaves to get >>> some sense of which paths are used. These numbers are generated every >>> benchmark in reference_server plus specjvm2008. In 22631 calls, 16050 >>> terminate by unwinding the frame, 3280 dispatch to a default exception >>> handler, 3176 call the rethrow function, and 125 emit an uncommon >>> trap. Of those uncommon traps the bytecode breakdown is this: >>> 14 anewarray >>> 52 athrow >>> 52 new >>> 7 newarray >>> Of the athrows, 43 are from unloaded classes and the other 9 are >>> because the catch class had subclasses. >>> src/share/vm/opto/parse1.cpp > From Thomas.Rodriguez at Sun.COM Tue Feb 16 16:06:14 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 16 Feb 2010 16:06:14 -0800 Subject: Request for reviews (XS): 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete In-Reply-To: <4B7B2E48.9060300@sun.com> References: <4B7AE904.9070301@sun.com> <93F1CBAF-12D6-49A6-9C52-DDAD36850CA2@sun.com> <4B7B108C.1050709@sun.com> <4B7B2E48.9060300@sun.com> Message-ID: <8C34C36F-B231-4AFE-8DE4-28C59E1D9F08@Sun.COM> That looks good. tom On Feb 16, 2010, at 3:46 PM, Vladimir Kozlov wrote: > I changed it to NOT_PRODUCT since it is used to collect statistics > and I updated webrev. > > Vladimir > > Vladimir Kozlov wrote: >> Thank you, Tom >> I will rework the change. >> Vladimir >> Tom Rodriguez wrote: >>> I'd rather have that whole section ifdef ASSERT or make AdapterHandlerTableIterator ifdef PRODUCT. Having contains always return false just seems wrong. >>> >>> tom >>> >>> On Feb 16, 2010, at 10:50 AM, Vladimir Kozlov wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/6926697/webrev >>>> >>>> Fixed 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete >>>> >>>> Problem: >>>> AdapterHandlerTableIterator is defined only in debug VM >>>> but it is used in all non product VM versions. >>>> >>>> Solution: >>>> Use AdapterHandlerTableIterator only in debug VM. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y, build >>>> >>>> Other testing: >>>> JPRT >>>> >>> From Vladimir.Kozlov at Sun.COM Tue Feb 16 16:12:48 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Feb 2010 16:12:48 -0800 Subject: Request for reviews (XS): 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete In-Reply-To: <8C34C36F-B231-4AFE-8DE4-28C59E1D9F08@Sun.COM> References: <4B7AE904.9070301@sun.com> <93F1CBAF-12D6-49A6-9C52-DDAD36850CA2@sun.com> <4B7B108C.1050709@sun.com> <4B7B2E48.9060300@sun.com> <8C34C36F-B231-4AFE-8DE4-28C59E1D9F08@Sun.COM> Message-ID: <4B7B3480.4070501@sun.com> Thanks, Tom Vladimir Tom Rodriguez wrote: > That looks good. > > tom > > On Feb 16, 2010, at 3:46 PM, Vladimir Kozlov wrote: > >> I changed it to NOT_PRODUCT since it is used to collect statistics >> and I updated webrev. >> >> Vladimir >> >> Vladimir Kozlov wrote: >>> Thank you, Tom >>> I will rework the change. >>> Vladimir >>> Tom Rodriguez wrote: >>>> I'd rather have that whole section ifdef ASSERT or make AdapterHandlerTableIterator ifdef PRODUCT. Having contains always return false just seems wrong. >>>> >>>> tom >>>> >>>> On Feb 16, 2010, at 10:50 AM, Vladimir Kozlov wrote: >>>> >>>>> http://cr.openjdk.java.net/~kvn/6926697/webrev >>>>> >>>>> Fixed 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete >>>>> >>>>> Problem: >>>>> AdapterHandlerTableIterator is defined only in debug VM >>>>> but it is used in all non product VM versions. >>>>> >>>>> Solution: >>>>> Use AdapterHandlerTableIterator only in debug VM. >>>>> >>>>> Reviewed by: >>>>> >>>>> Fix verified (y/n): y, build >>>>> >>>>> Other testing: >>>>> JPRT >>>>> > From vladimir.kozlov at sun.com Tue Feb 16 18:22:57 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 17 Feb 2010 02:22:57 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete Message-ID: <20100217022300.BE93442406@hg.openjdk.java.net> Changeset: e7b1cc79bd25 Author: kvn Date: 2010-02-16 16:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e7b1cc79bd25 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete Summary: Define AdapterHandlerTableIterator class as non product instead of debug. Reviewed-by: never ! src/share/vm/runtime/sharedRuntime.cpp From thomas.rodriguez at sun.com Tue Feb 16 22:06:40 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 17 Feb 2010 06:06:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6877221: Endless deoptimizations in OSR nmethod Message-ID: <20100217060643.7FEC642451@hg.openjdk.java.net> Changeset: 106f41e88c85 Author: never Date: 2010-02-16 20:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/106f41e88c85 6877221: Endless deoptimizations in OSR nmethod Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp From gbenson at redhat.com Wed Feb 17 01:04:00 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 17 Feb 2010 09:04:00 +0000 Subject: Review Request: Zero S/390 fixes Message-ID: <20100217090400.GC3365@redhat.com> Hi all, This webrev fixes two failures on 31-bit S/390: http://cr.openjdk.java.net/~gbenson/zero-s390-fixes-01/ The first is that there were not enough shadow pages for a StackOverflowError to be thrown. The second is the implementation of a 64-bit atomic copy such that long and double fields in objects are got and set atomically. I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Wed Feb 17 03:13:26 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 17 Feb 2010 12:13:26 +0100 Subject: Review Request: Zero S/390 fixes In-Reply-To: <20100217090400.GC3365@redhat.com> References: <20100217090400.GC3365@redhat.com> Message-ID: <4B7BCF56.2080807@Sun.COM> On 02/17/10 10:04 AM, Gary Benson wrote: > Hi all, > > This webrev fixes two failures on 31-bit S/390: > > http://cr.openjdk.java.net/~gbenson/zero-s390-fixes-01/ > > The first is that there were not enough shadow pages for a > StackOverflowError to be thrown. The second is the > implementation of a 64-bit atomic copy such that long and > double fields in objects are got and set atomically. > > I don't have a bug id for this. I filed: 6927165: Zero S/390 fixes The changes look good and I will push them for you. -- Christian From gbenson at redhat.com Wed Feb 17 03:21:58 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 17 Feb 2010 11:21:58 +0000 Subject: Review Request: Zero S/390 fixes In-Reply-To: <4B7BCF56.2080807@Sun.COM> References: <20100217090400.GC3365@redhat.com> <4B7BCF56.2080807@Sun.COM> Message-ID: <20100217112158.GA23727@redhat.com> Christian Thalinger wrote: > On 02/17/10 10:04 AM, Gary Benson wrote: > > This webrev fixes two failures on 31-bit S/390: > > > > http://cr.openjdk.java.net/~gbenson/zero-s390-fixes-01/ > > > > The first is that there were not enough shadow pages for a > > StackOverflowError to be thrown. The second is the > > implementation of a 64-bit atomic copy such that long and > > double fields in objects are got and set atomically. > > > > I don't have a bug id for this. > > I filed: > > 6927165: Zero S/390 fixes > > The changes look good and I will push them for you. Thank you :) Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Wed Feb 17 04:23:27 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 17 Feb 2010 13:23:27 +0100 Subject: Request for reviews (S): 6926782: CodeBuffer size too small after 6921352 In-Reply-To: <4B7AF0FB.3070502@Sun.COM> References: <4B7A980A.3070607@Sun.COM> <4B7ADA0D.6060801@sun.com> <4B7AF0FB.3070502@Sun.COM> Message-ID: <4B7BDFBF.6030705@Sun.COM> On 02/16/10 08:24 PM, Christian Thalinger wrote: > On 02/16/10 06:46 PM, Vladimir Kozlov wrote: >> Christian, >> >> I thought you will set the flag during parsing because >> it could be helpful to know that call site is MH during whole >> compilation. Is it possible? > > Hmm, it should be. Let me look into it. > >> Adding size for MH should be also under MH check. > > That can be done when I have the above working. Here is the updated webrev: http://cr.openjdk.java.net/~twisti/6926782/webrev.02/ -- Christian From Vladimir.Kozlov at Sun.COM Wed Feb 17 08:14:15 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 17 Feb 2010 08:14:15 -0800 Subject: Request for reviews (S): 6926782: CodeBuffer size too small after 6921352 In-Reply-To: <4B7BDFBF.6030705@Sun.COM> References: <4B7A980A.3070607@Sun.COM> <4B7ADA0D.6060801@sun.com> <4B7AF0FB.3070502@Sun.COM> <4B7BDFBF.6030705@Sun.COM> Message-ID: <4B7C15D7.4090602@sun.com> This looks good. Thanks, Vladimir On 2/17/10 4:23 AM, Christian Thalinger wrote: > On 02/16/10 08:24 PM, Christian Thalinger wrote: >> On 02/16/10 06:46 PM, Vladimir Kozlov wrote: >>> Christian, >>> >>> I thought you will set the flag during parsing because >>> it could be helpful to know that call site is MH during whole >>> compilation. Is it possible? >> >> Hmm, it should be. Let me look into it. >> >>> Adding size for MH should be also under MH check. >> >> That can be done when I have the above working. > > Here is the updated webrev: > > http://cr.openjdk.java.net/~twisti/6926782/webrev.02/ > > -- Christian From Thomas.Rodriguez at Sun.COM Wed Feb 17 14:30:03 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 17 Feb 2010 14:30:03 -0800 Subject: review (S) for 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp Message-ID: 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp Reviewed-by: This is another instance of the ConvI2L problem with type information being raised to a point that it's no longer true, like the bug 6659207, resulting in top being returned and some code path being mistakenly killed. The same style of fix for 6659207 won't work in this case because there's no option to bailout if the types won't work. Instead we strip the constrained type off the ConvI2L as it is pushed up. The test case was automatically generated and I couldn't simplify it any further so it's pretty horrific looking. Tested with test case and confirmed that stripping the type doesn't affect the code quality for scimark which is very sensitive to the loss of the type information on ConvI2Ls used in address expressions. src/share/vm/opto/split_if.cpp test/compiler/6663854/Test6663854.java From Thomas.Rodriguez at Sun.COM Wed Feb 17 14:51:29 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 17 Feb 2010 14:51:29 -0800 Subject: review (S) for 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp In-Reply-To: References: Message-ID: Oops. http://cr.openjdk.java.net/~never/6663854 tom On Feb 17, 2010, at 2:30 PM, Tom Rodriguez wrote: > 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp > Reviewed-by: > > This is another instance of the ConvI2L problem with type information > being raised to a point that it's no longer true, like the bug > 6659207, resulting in top being returned and some code path being > mistakenly killed. The same style of fix for 6659207 won't work in > this case because there's no option to bailout if the types won't > work. Instead we strip the constrained type off the ConvI2L as it is > pushed up. The test case was automatically generated and I couldn't > simplify it any further so it's pretty horrific looking. Tested with > test case and confirmed that stripping the type doesn't affect the > code quality for scimark which is very sensitive to the loss of the > type information on ConvI2Ls used in address expressions. > > src/share/vm/opto/split_if.cpp > test/compiler/6663854/Test6663854.java From Vladimir.Kozlov at Sun.COM Wed Feb 17 15:03:47 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 17 Feb 2010 15:03:47 -0800 Subject: review (S) for 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp In-Reply-To: References: Message-ID: <4B7C75D3.1020508@sun.com> Looks good. The main test class is called Tester - not Test6663854: public class Tester { Vladimir Tom Rodriguez wrote: > Oops. http://cr.openjdk.java.net/~never/6663854 > > tom > > On Feb 17, 2010, at 2:30 PM, Tom Rodriguez wrote: > >> 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp >> Reviewed-by: >> >> This is another instance of the ConvI2L problem with type information >> being raised to a point that it's no longer true, like the bug >> 6659207, resulting in top being returned and some code path being >> mistakenly killed. The same style of fix for 6659207 won't work in >> this case because there's no option to bailout if the types won't >> work. Instead we strip the constrained type off the ConvI2L as it is >> pushed up. The test case was automatically generated and I couldn't >> simplify it any further so it's pretty horrific looking. Tested with >> test case and confirmed that stripping the type doesn't affect the >> code quality for scimark which is very sensitive to the loss of the >> type information on ConvI2Ls used in address expressions. >> >> src/share/vm/opto/split_if.cpp >> test/compiler/6663854/Test6663854.java > From Thomas.Rodriguez at Sun.COM Wed Feb 17 15:15:25 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 17 Feb 2010 15:15:25 -0800 Subject: review (S) for 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp In-Reply-To: <4B7C75D3.1020508@sun.com> References: <4B7C75D3.1020508@sun.com> Message-ID: Thanks. I fixed the class name and ran it with jtreg to confirm that it works. tom On Feb 17, 2010, at 3:03 PM, Vladimir Kozlov wrote: > Looks good. > > The main test class is called Tester - not Test6663854: > > public class Tester { > > > Vladimir > > Tom Rodriguez wrote: >> Oops. http://cr.openjdk.java.net/~never/6663854 >> tom >> On Feb 17, 2010, at 2:30 PM, Tom Rodriguez wrote: >>> 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp >>> Reviewed-by: >>> >>> This is another instance of the ConvI2L problem with type information >>> being raised to a point that it's no longer true, like the bug >>> 6659207, resulting in top being returned and some code path being >>> mistakenly killed. The same style of fix for 6659207 won't work in >>> this case because there's no option to bailout if the types won't >>> work. Instead we strip the constrained type off the ConvI2L as it is >>> pushed up. The test case was automatically generated and I couldn't >>> simplify it any further so it's pretty horrific looking. Tested with >>> test case and confirmed that stripping the type doesn't affect the >>> code quality for scimark which is very sensitive to the loss of the >>> type information on ConvI2Ls used in address expressions. >>> >>> src/share/vm/opto/split_if.cpp >>> test/compiler/6663854/Test6663854.java From Vladimir.Kozlov at Sun.COM Wed Feb 17 15:17:48 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 17 Feb 2010 15:17:48 -0800 Subject: review (S) for 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp In-Reply-To: References: <4B7C75D3.1020508@sun.com> Message-ID: <4B7C791C.4000306@sun.com> Good. Vladimir Tom Rodriguez wrote: > Thanks. I fixed the class name and ran it with jtreg to confirm that it works. > > tom > > On Feb 17, 2010, at 3:03 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> The main test class is called Tester - not Test6663854: >> >> public class Tester { >> >> >> Vladimir >> >> Tom Rodriguez wrote: >>> Oops. http://cr.openjdk.java.net/~never/6663854 >>> tom >>> On Feb 17, 2010, at 2:30 PM, Tom Rodriguez wrote: >>>> 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp >>>> Reviewed-by: >>>> >>>> This is another instance of the ConvI2L problem with type information >>>> being raised to a point that it's no longer true, like the bug >>>> 6659207, resulting in top being returned and some code path being >>>> mistakenly killed. The same style of fix for 6659207 won't work in >>>> this case because there's no option to bailout if the types won't >>>> work. Instead we strip the constrained type off the ConvI2L as it is >>>> pushed up. The test case was automatically generated and I couldn't >>>> simplify it any further so it's pretty horrific looking. Tested with >>>> test case and confirmed that stripping the type doesn't affect the >>>> code quality for scimark which is very sensitive to the loss of the >>>> type information on ConvI2Ls used in address expressions. >>>> >>>> src/share/vm/opto/split_if.cpp >>>> test/compiler/6663854/Test6663854.java > From Christian.Thalinger at Sun.COM Thu Feb 18 02:31:07 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 18 Feb 2010 11:31:07 +0100 Subject: Review Request: Zero S/390 fixes In-Reply-To: <20100217112158.GA23727@redhat.com> References: <20100217090400.GC3365@redhat.com> <4B7BCF56.2080807@Sun.COM> <20100217112158.GA23727@redhat.com> Message-ID: <1266489068.6151.0.camel@macbook> On Wed, 2010-02-17 at 11:21 +0000, Gary Benson wrote: > Christian Thalinger wrote: > > On 02/17/10 10:04 AM, Gary Benson wrote: > > > This webrev fixes two failures on 31-bit S/390: > > > > > > http://cr.openjdk.java.net/~gbenson/zero-s390-fixes-01/ > > > > > > The first is that there were not enough shadow pages for a > > > StackOverflowError to be thrown. The second is the > > > implementation of a 64-bit atomic copy such that long and > > > double fields in objects are got and set atomically. > > > > > > I don't have a bug id for this. > > > > I filed: > > > > 6927165: Zero S/390 fixes > > > > The changes look good and I will push them for you. > > Thank you :) For the record, Gary found out that the fix is not completely correct and I killed the push job. We are waiting for the right fix. -- Christian From Christian.Thalinger at Sun.COM Thu Feb 18 04:44:33 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 18 Feb 2010 12:44:33 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6926782: CodeBuffer size too small after 6921352 Message-ID: <20100218124456.4971542658@hg.openjdk.java.net> Changeset: b4b440360f1e Author: twisti Date: 2010-02-18 11:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b4b440360f1e 6926782: CodeBuffer size too small after 6921352 Summary: After 6921352 the CodeBuffer size was too small. Reviewed-by: kvn, never ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp From gbenson at redhat.com Thu Feb 18 06:09:57 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 18 Feb 2010 14:09:57 +0000 Subject: Review Request: Zero S/390 fixes In-Reply-To: <1266489068.6151.0.camel@macbook> References: <20100217090400.GC3365@redhat.com> <4B7BCF56.2080807@Sun.COM> <20100217112158.GA23727@redhat.com> <1266489068.6151.0.camel@macbook> Message-ID: <20100218140956.GB3419@redhat.com> Christian Thalinger wrote: > On Wed, 2010-02-17 at 11:21 +0000, Gary Benson wrote: > > Christian Thalinger wrote: > > > On 02/17/10 10:04 AM, Gary Benson wrote: > > > > This webrev fixes two failures on 31-bit S/390: > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-s390-fixes-01/ > > > > > > > > The first is that there were not enough shadow pages for a > > > > StackOverflowError to be thrown. The second is the > > > > implementation of a 64-bit atomic copy such that long and > > > > double fields in objects are got and set atomically. > > > > > > > > I don't have a bug id for this. > > > > > > I filed: > > > > > > 6927165: Zero S/390 fixes > > > > > > The changes look good and I will push them for you. > > > > Thank you :) > > For the record, Gary found out that the fix is not completely > correct and I killed the push job. We are waiting for the right > fix. Yeah, my S/390 assembler isn't as hot as I thought it was... This one's better :) http://cr.openjdk.java.net/~gbenson/zero-s390-fixes-02/ Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Thu Feb 18 06:51:44 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 18 Feb 2010 15:51:44 +0100 Subject: Review Request: Zero S/390 fixes In-Reply-To: <20100218140956.GB3419@redhat.com> References: <20100217090400.GC3365@redhat.com> <4B7BCF56.2080807@Sun.COM> <20100217112158.GA23727@redhat.com> <1266489068.6151.0.camel@macbook> <20100218140956.GB3419@redhat.com> Message-ID: <4B7D5400.4030201@Sun.COM> On 02/18/10 03:09 PM, Gary Benson wrote: > Yeah, my S/390 assembler isn't as hot as I thought it was... > This one's better :) > > http://cr.openjdk.java.net/~gbenson/zero-s390-fixes-02/ Then I'll commit this one. -- Christian From gbenson at redhat.com Thu Feb 18 07:16:11 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 18 Feb 2010 15:16:11 +0000 Subject: Review Request: Zero S/390 fixes In-Reply-To: <4B7D5400.4030201@Sun.COM> References: <20100217090400.GC3365@redhat.com> <4B7BCF56.2080807@Sun.COM> <20100217112158.GA23727@redhat.com> <1266489068.6151.0.camel@macbook> <20100218140956.GB3419@redhat.com> <4B7D5400.4030201@Sun.COM> Message-ID: <20100218151611.GC3419@redhat.com> Christian Thalinger wrote: > On 02/18/10 03:09 PM, Gary Benson wrote: > > Yeah, my S/390 assembler isn't as hot as I thought it was... > > This one's better :) > > > > http://cr.openjdk.java.net/~gbenson/zero-s390-fixes-02/ > > Then I'll commit this one. -- Christian Thanks! From Christian.Thalinger at Sun.COM Thu Feb 18 08:53:36 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 18 Feb 2010 16:53:36 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6927165: Zero S/390 fixes Message-ID: <20100218165344.81C9E4269C@hg.openjdk.java.net> Changeset: 3b687c53c266 Author: twisti Date: 2010-02-18 06:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3b687c53c266 6927165: Zero S/390 fixes Summary: Fixes two failures on 31-bit S/390. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/globals_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.hpp From Christian.Thalinger at Sun.COM Thu Feb 18 14:47:44 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 18 Feb 2010 22:47:44 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6 new changesets Message-ID: <20100218224808.C297E426FD@hg.openjdk.java.net> Changeset: 38836cf1d8d2 Author: tonyp Date: 2010-02-05 11:05 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/38836cf1d8d2 6920977: G1: guarantee(k == probe->klass(),"klass should be in dictionary") fails Summary: the guarantee is too strict and the test will fail (incorrectly) if the class is not in the system dictionary but in the placeholders. Reviewed-by: acorn, phh ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/includeDB_core Changeset: 9eee977dd1a9 Author: tonyp Date: 2010-02-08 14:23 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9eee977dd1a9 6802453: G1: hr()->is_in_reserved(from),"Precondition." Summary: The operations of re-using a RSet component and expanding the same RSet component were not mutually exlusive, and this could lead to RSets getting corrupted and entries being dropped. Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: 8859772195c6 Author: johnc Date: 2010-02-09 13:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8859772195c6 6782663: Data produced by PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime is not accurate. Summary: Update and display the timers associated with these flags for all safepoints. Reviewed-by: ysr, jcoomes ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/runtimeService.cpp Changeset: 0414c1049f15 Author: iveresov Date: 2010-02-11 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0414c1049f15 6923991: G1: improve scalability of RSet scanning Summary: Implemented block-based work stealing. Moved copying during the rset scanning phase to the main copying phase. Made the size of rset table depend on the region size. Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 58add740c4ee Author: johnc Date: 2010-02-16 14:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/58add740c4ee Merge ! src/share/vm/includeDB_core Changeset: 72f1840531a4 Author: twisti Date: 2010-02-18 10:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/72f1840531a4 Merge From thomas.rodriguez at sun.com Thu Feb 18 17:07:26 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 19 Feb 2010 01:07:26 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6663854: assert(n != __null, "Bad immediate dominator info.") in C2 with -Xcomp Message-ID: <20100219010731.81FAB42723@hg.openjdk.java.net> Changeset: 877a14af58e1 Author: never Date: 2010-02-18 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/877a14af58e1 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp Reviewed-by: kvn ! src/share/vm/opto/split_if.cpp + test/compiler/6663854/Test6663854.java From Vladimir.Kozlov at Sun.COM Thu Feb 18 19:08:05 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 18 Feb 2010 19:08:05 -0800 Subject: Request for reviews (S): 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag Message-ID: <4B7E0095.1030305@sun.com> http://cr.openjdk.java.net/~kvn/6910664/webrev.02 Fixed 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag Problem: The test has several java float locals and use XMM registers in debug info. But the code which restore these values during deoptimization was not updated for XMM registers usage. It assumes that float values were converted to double on stack as it was before SSE hardware when FPU was used. Solution: Add platform specific method to get float stack value from compiled frame. Reviewed by: Fix verified (y/n): y, test with -XX:UseSSE=0|1|2 Other testing: JPRT From Christian.Thalinger at Sun.COM Fri Feb 19 01:56:53 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 19 Feb 2010 10:56:53 +0100 Subject: Request for reviews (S): 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag In-Reply-To: <4B7E0095.1030305@sun.com> References: <4B7E0095.1030305@sun.com> Message-ID: <4B7E6065.9010409@Sun.COM> On 02/19/10 04:08 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6910664/webrev.02 > > Fixed 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag > > Problem: > The test has several java float locals and use XMM registers in debug info. > But the code which restore these values during deoptimization was not > updated for XMM registers usage. It assumes that float values were converted > to double on stack as it was before SSE hardware when FPU was used. > > Solution: > Add platform specific method to get float stack value from compiled frame. > > Reviewed by: > > Fix verified (y/n): y, test with -XX:UseSSE=0|1|2 > > Other testing: > JPRT Looks good. -- Christian From Thomas.Rodriguez at Sun.COM Fri Feb 19 08:26:51 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 19 Feb 2010 08:26:51 -0800 Subject: Request for reviews (S): 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag In-Reply-To: <4B7E0095.1030305@sun.com> References: <4B7E0095.1030305@sun.com> Message-ID: <032F8710-C549-4647-97FE-FF88B8AD89D1@sun.com> I'm not sure that's the right fix. The whole point of float_in_dbl is to deal with x86 FPU registers so converting it into some platform dependent thing based on UseSSE doesn't seem right. I think Matcher::float_in_double should be false if UseSSE >= 1 in x86_32.ad and should always be false in x86_64.ad. In that case it will use Location::normal instead which will do: // Just copy all other bits straight through union { intptr_t p; jint ji;} value; value.p = (intptr_t) CONST64(0xDEADDEAFDEADDEAF); value.ji = *(jint*)value_addr; return new StackValue(value.p); which is equivalent to your new create_float_stack_value logic. How did we go for so long with this being broken? It's totally wrong on 64 bit. C1 has the same problem too. tom On Feb 18, 2010, at 7:08 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6910664/webrev.02 > > Fixed 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag > > Problem: > The test has several java float locals and use XMM registers in debug info. > But the code which restore these values during deoptimization was not > updated for XMM registers usage. It assumes that float values were converted > to double on stack as it was before SSE hardware when FPU was used. > > Solution: > Add platform specific method to get float stack value from compiled frame. > > Reviewed by: > > Fix verified (y/n): y, test with -XX:UseSSE=0|1|2 > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Fri Feb 19 08:46:49 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 19 Feb 2010 08:46:49 -0800 Subject: Request for reviews (S): 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag In-Reply-To: <032F8710-C549-4647-97FE-FF88B8AD89D1@sun.com> References: <4B7E0095.1030305@sun.com> <032F8710-C549-4647-97FE-FF88B8AD89D1@sun.com> Message-ID: <4B7EC079.90701@sun.com> Thank you, Tom Yes, you are right, I did not thought that I can use Location::normal. Then the comment in the .ad files is wrong. I can fix C1 also if you point me the place. Thanks, Vladimir Tom Rodriguez wrote: > I'm not sure that's the right fix. The whole point of float_in_dbl is to deal with x86 FPU registers so converting it into some platform dependent thing based on UseSSE doesn't seem right. I think Matcher::float_in_double should be false if UseSSE >= 1 in x86_32.ad and should always be false in x86_64.ad. In that case it will use Location::normal instead which will do: > > // Just copy all other bits straight through > union { intptr_t p; jint ji;} value; > value.p = (intptr_t) CONST64(0xDEADDEAFDEADDEAF); > value.ji = *(jint*)value_addr; > return new StackValue(value.p); > > which is equivalent to your new create_float_stack_value logic. > > How did we go for so long with this being broken? It's totally wrong on 64 bit. C1 has the same problem too. > > tom > > On Feb 18, 2010, at 7:08 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6910664/webrev.02 >> >> Fixed 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag >> >> Problem: >> The test has several java float locals and use XMM registers in debug info. >> But the code which restore these values during deoptimization was not >> updated for XMM registers usage. It assumes that float values were converted >> to double on stack as it was before SSE hardware when FPU was used. >> >> Solution: >> Add platform specific method to get float stack value from compiled frame. >> >> Reviewed by: >> >> Fix verified (y/n): y, test with -XX:UseSSE=0|1|2 >> >> Other testing: >> JPRT >> > From Thomas.Rodriguez at Sun.COM Fri Feb 19 09:11:35 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 19 Feb 2010 09:11:35 -0800 Subject: Request for reviews (S): 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag In-Reply-To: <4B7EC079.90701@sun.com> References: <4B7E0095.1030305@sun.com> <032F8710-C549-4647-97FE-FF88B8AD89D1@sun.com> <4B7EC079.90701@sun.com> Message-ID: I was wrong about C1, it already handles this correctly. It uses float_in_dbl for fpu registers and normal for xmm. tom On Feb 19, 2010, at 8:46 AM, Vladimir Kozlov wrote: > Thank you, Tom > > Yes, you are right, I did not thought that I can use Location::normal. > Then the comment in the .ad files is wrong. > > I can fix C1 also if you point me the place. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> I'm not sure that's the right fix. The whole point of float_in_dbl is to deal with x86 FPU registers so converting it into some platform dependent thing based on UseSSE doesn't seem right. I think Matcher::float_in_double should be false if UseSSE >= 1 in x86_32.ad and should always be false in x86_64.ad. In that case it will use Location::normal instead which will do: >> // Just copy all other bits straight through >> union { intptr_t p; jint ji;} value; >> value.p = (intptr_t) CONST64(0xDEADDEAFDEADDEAF); >> value.ji = *(jint*)value_addr; >> return new StackValue(value.p); >> which is equivalent to your new create_float_stack_value logic. >> How did we go for so long with this being broken? It's totally wrong on 64 bit. C1 has the same problem too. >> tom >> On Feb 18, 2010, at 7:08 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6910664/webrev.02 >>> >>> Fixed 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag >>> >>> Problem: >>> The test has several java float locals and use XMM registers in debug info. >>> But the code which restore these values during deoptimization was not >>> updated for XMM registers usage. It assumes that float values were converted >>> to double on stack as it was before SSE hardware when FPU was used. >>> >>> Solution: >>> Add platform specific method to get float stack value from compiled frame. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, test with -XX:UseSSE=0|1|2 >>> >>> Other testing: >>> JPRT >>> From Vladimir.Kozlov at Sun.COM Fri Feb 19 09:40:15 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 19 Feb 2010 09:40:15 -0800 Subject: Request for reviews (S): 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag In-Reply-To: References: <4B7E0095.1030305@sun.com> <032F8710-C549-4647-97FE-FF88B8AD89D1@sun.com> <4B7EC079.90701@sun.com> Message-ID: <4B7ECCFF.4040005@sun.com> I updated webrev: http://cr.openjdk.java.net/~kvn/6910664/webrev.03 Thanks, Vladimir Tom Rodriguez wrote: > I was wrong about C1, it already handles this correctly. It uses float_in_dbl for fpu registers and normal for xmm. > > tom > > On Feb 19, 2010, at 8:46 AM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Yes, you are right, I did not thought that I can use Location::normal. >> Then the comment in the .ad files is wrong. >> >> I can fix C1 also if you point me the place. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> I'm not sure that's the right fix. The whole point of float_in_dbl is to deal with x86 FPU registers so converting it into some platform dependent thing based on UseSSE doesn't seem right. I think Matcher::float_in_double should be false if UseSSE >= 1 in x86_32.ad and should always be false in x86_64.ad. In that case it will use Location::normal instead which will do: >>> // Just copy all other bits straight through >>> union { intptr_t p; jint ji;} value; >>> value.p = (intptr_t) CONST64(0xDEADDEAFDEADDEAF); >>> value.ji = *(jint*)value_addr; >>> return new StackValue(value.p); >>> which is equivalent to your new create_float_stack_value logic. >>> How did we go for so long with this being broken? It's totally wrong on 64 bit. C1 has the same problem too. >>> tom >>> On Feb 18, 2010, at 7:08 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/6910664/webrev.02 >>>> >>>> Fixed 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag >>>> >>>> Problem: >>>> The test has several java float locals and use XMM registers in debug info. >>>> But the code which restore these values during deoptimization was not >>>> updated for XMM registers usage. It assumes that float values were converted >>>> to double on stack as it was before SSE hardware when FPU was used. >>>> >>>> Solution: >>>> Add platform specific method to get float stack value from compiled frame. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y, test with -XX:UseSSE=0|1|2 >>>> >>>> Other testing: >>>> JPRT >>>> > From Thomas.Rodriguez at Sun.COM Fri Feb 19 10:03:22 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 19 Feb 2010 10:03:22 -0800 Subject: Request for reviews (S): 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag In-Reply-To: <4B7ECCFF.4040005@sun.com> References: <4B7E0095.1030305@sun.com> <032F8710-C549-4647-97FE-FF88B8AD89D1@sun.com> <4B7EC079.90701@sun.com> <4B7ECCFF.4040005@sun.com> Message-ID: <2D0F191F-BC8C-407B-9A6F-EF643D54FEB0@Sun.COM> s/Do floats are conerted/Are floats converted/ Looks good. tom On Feb 19, 2010, at 9:40 AM, Vladimir Kozlov wrote: > I updated webrev: > > http://cr.openjdk.java.net/~kvn/6910664/webrev.03 > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> I was wrong about C1, it already handles this correctly. It uses float_in_dbl for fpu registers and normal for xmm. >> tom >> On Feb 19, 2010, at 8:46 AM, Vladimir Kozlov wrote: >>> Thank you, Tom >>> >>> Yes, you are right, I did not thought that I can use Location::normal. >>> Then the comment in the .ad files is wrong. >>> >>> I can fix C1 also if you point me the place. >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> I'm not sure that's the right fix. The whole point of float_in_dbl is to deal with x86 FPU registers so converting it into some platform dependent thing based on UseSSE doesn't seem right. I think Matcher::float_in_double should be false if UseSSE >= 1 in x86_32.ad and should always be false in x86_64.ad. In that case it will use Location::normal instead which will do: >>>> // Just copy all other bits straight through >>>> union { intptr_t p; jint ji;} value; >>>> value.p = (intptr_t) CONST64(0xDEADDEAFDEADDEAF); >>>> value.ji = *(jint*)value_addr; >>>> return new StackValue(value.p); >>>> which is equivalent to your new create_float_stack_value logic. >>>> How did we go for so long with this being broken? It's totally wrong on 64 bit. C1 has the same problem too. >>>> tom >>>> On Feb 18, 2010, at 7:08 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/6910664/webrev.02 >>>>> >>>>> Fixed 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag >>>>> >>>>> Problem: >>>>> The test has several java float locals and use XMM registers in debug info. >>>>> But the code which restore these values during deoptimization was not >>>>> updated for XMM registers usage. It assumes that float values were converted >>>>> to double on stack as it was before SSE hardware when FPU was used. >>>>> >>>>> Solution: >>>>> Add platform specific method to get float stack value from compiled frame. >>>>> >>>>> Reviewed by: >>>>> >>>>> Fix verified (y/n): y, test with -XX:UseSSE=0|1|2 >>>>> >>>>> Other testing: >>>>> JPRT >>>>> From Vladimir.Kozlov at Sun.COM Fri Feb 19 10:02:35 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 19 Feb 2010 10:02:35 -0800 Subject: Request for reviews (S): 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag In-Reply-To: <2D0F191F-BC8C-407B-9A6F-EF643D54FEB0@Sun.COM> References: <4B7E0095.1030305@sun.com> <032F8710-C549-4647-97FE-FF88B8AD89D1@sun.com> <4B7EC079.90701@sun.com> <4B7ECCFF.4040005@sun.com> <2D0F191F-BC8C-407B-9A6F-EF643D54FEB0@Sun.COM> Message-ID: <4B7ED23B.5000402@sun.com> Thanks, Tom Vladimir Tom Rodriguez wrote: > s/Do floats are conerted/Are floats converted/ > > Looks good. > > tom > > On Feb 19, 2010, at 9:40 AM, Vladimir Kozlov wrote: > >> I updated webrev: >> >> http://cr.openjdk.java.net/~kvn/6910664/webrev.03 >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> I was wrong about C1, it already handles this correctly. It uses float_in_dbl for fpu registers and normal for xmm. >>> tom >>> On Feb 19, 2010, at 8:46 AM, Vladimir Kozlov wrote: >>>> Thank you, Tom >>>> >>>> Yes, you are right, I did not thought that I can use Location::normal. >>>> Then the comment in the .ad files is wrong. >>>> >>>> I can fix C1 also if you point me the place. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> I'm not sure that's the right fix. The whole point of float_in_dbl is to deal with x86 FPU registers so converting it into some platform dependent thing based on UseSSE doesn't seem right. I think Matcher::float_in_double should be false if UseSSE >= 1 in x86_32.ad and should always be false in x86_64.ad. In that case it will use Location::normal instead which will do: >>>>> // Just copy all other bits straight through >>>>> union { intptr_t p; jint ji;} value; >>>>> value.p = (intptr_t) CONST64(0xDEADDEAFDEADDEAF); >>>>> value.ji = *(jint*)value_addr; >>>>> return new StackValue(value.p); >>>>> which is equivalent to your new create_float_stack_value logic. >>>>> How did we go for so long with this being broken? It's totally wrong on 64 bit. C1 has the same problem too. >>>>> tom >>>>> On Feb 18, 2010, at 7:08 PM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/6910664/webrev.02 >>>>>> >>>>>> Fixed 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag >>>>>> >>>>>> Problem: >>>>>> The test has several java float locals and use XMM registers in debug info. >>>>>> But the code which restore these values during deoptimization was not >>>>>> updated for XMM registers usage. It assumes that float values were converted >>>>>> to double on stack as it was before SSE hardware when FPU was used. >>>>>> >>>>>> Solution: >>>>>> Add platform specific method to get float stack value from compiled frame. >>>>>> >>>>>> Reviewed by: >>>>>> >>>>>> Fix verified (y/n): y, test with -XX:UseSSE=0|1|2 >>>>>> >>>>>> Other testing: >>>>>> JPRT >>>>>> > From john.coomes at sun.com Fri Feb 19 11:35:48 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Feb 2010 19:35:48 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b84 for changeset 2f3ea057d1ad Message-ID: <20100219193548.6E5EA42865@hg.openjdk.java.net> Changeset: cf26288a114b Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/cf26288a114b Added tag jdk7-b84 for changeset 2f3ea057d1ad ! .hgtags From john.coomes at sun.com Fri Feb 19 11:35:54 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Feb 2010 19:35:54 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b84 for changeset 68c8961a82e4 Message-ID: <20100219193557.AE7F942866@hg.openjdk.java.net> Changeset: c67a9df7bc0c Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/c67a9df7bc0c Added tag jdk7-b84 for changeset 68c8961a82e4 ! .hgtags From john.coomes at sun.com Fri Feb 19 11:39:07 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Feb 2010 19:39:07 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 4 new changesets Message-ID: <20100219193907.EB14142867@hg.openjdk.java.net> Changeset: df2e196a5f01 Author: ohair Date: 2010-02-03 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/df2e196a5f01 6923146: Upgrade to JAXP 1.4.3 Reviewed-by: darcy ! jaxp.properties Changeset: bf7c7f2825ef Author: lana Date: 2010-02-08 23:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/bf7c7f2825ef Merge Changeset: 32c0cf01d555 Author: lana Date: 2010-02-14 23:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/32c0cf01d555 Merge Changeset: 6c0ccabb430d Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/6c0ccabb430d Added tag jdk7-b84 for changeset 32c0cf01d555 ! .hgtags From john.coomes at sun.com Fri Feb 19 11:39:14 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Feb 2010 19:39:14 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b84 for changeset 8bc02839eee4 Message-ID: <20100219193914.6F24C42868@hg.openjdk.java.net> Changeset: 8424512588ff Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/8424512588ff Added tag jdk7-b84 for changeset 8bc02839eee4 ! .hgtags From Thomas.Rodriguez at Sun.COM Fri Feb 19 11:54:15 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 19 Feb 2010 11:54:15 -0800 Subject: review (S) for 6927049: assert(is_Loop(),"invalid node class") Message-ID: <5F59DDBA-C5BF-4593-B131-4207EF2DF67E@sun.com> http://cr.openjdk.java.net/~never/6927049 6927049: assert(is_Loop(),"invalid node class") Reviewed-by: The loop predication code is missing a guard for is_Loop since it's possible that the loop might simply by a Region if there are irreducible loops in the loop tree. I also moved the other loop type guards up so they would be together before any traps count logic. Tested with failing test from report. src/share/vm/opto/loopTransform.cpp From john.coomes at sun.com Fri Feb 19 11:42:09 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Feb 2010 19:42:09 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 48 new changesets Message-ID: <20100219195809.EF3334286F@hg.openjdk.java.net> Changeset: dca3a251a001 Author: xuelei Date: 2010-01-20 21:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dca3a251a001 6862064: incorrect implementation of PKIXParameters.clone() Reviewed-by: weijun, mullan ! src/share/classes/java/security/cert/PKIXParameters.java Changeset: b19cd193245e Author: dcubed Date: 2010-01-20 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b19cd193245e 6580131: 3/4 CompiledMethodLoad events don't produce the expected extra notifications to describe inlining Summary: Add support for additional implementation specific info to the JVM/TI CompiledMethodLoad event via the compile_info parameter. Reviewed-by: never, ohair, tbell, tdeneau Contributed-by: Vasanth Venkatachalam ! make/common/shared/Sanity.gmk ! make/java/jvm/Makefile ! make/mkdemo/jvmti/Makefile ! make/mkdemo/jvmti/README.txt + make/mkdemo/jvmti/compiledMethodLoad/Makefile + src/share/demo/jvmti/compiledMethodLoad/README.txt + src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c + src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt ! src/share/demo/jvmti/index.html + src/share/javavm/export/jvmticmlr.h + test/demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java ! test/demo/jvmti/heapTracker/HeapTrackerTest.java ! test/demo/jvmti/hprof/CpuTimesDefineClassTest.java ! test/demo/jvmti/hprof/CpuTimesTest.java ! test/demo/jvmti/minst/MinstTest.java ! test/demo/jvmti/mtrace/TraceJFrame.java Changeset: 117b245b5bb9 Author: vinnie Date: 2010-01-21 23:59 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/117b245b5bb9 6763530: Cannot decode PublicKey (Proider SunPKCS11, curve prime256v1) Reviewed-by: andrew ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: c94ac5522d01 Author: vinnie Date: 2010-01-22 00:02 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c94ac5522d01 Merge Changeset: e67bf9abc6a5 Author: chegar Date: 2010-01-25 15:41 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e67bf9abc6a5 6707289: InterfaceAddress.getNetworkPrefixLength() does not conform to Javadoc Reviewed-by: michaelm ! src/windows/native/java/net/NetworkInterface_winXP.c + test/java/net/InterfaceAddress/NetworkPrefixLength.java Changeset: 558f2a424bfa Author: weijun Date: 2010-01-26 17:03 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/558f2a424bfa 6919610: KeyTabInputStream uses static field for per-instance value Reviewed-by: mullan ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java + test/sun/security/krb5/ktab/KeyTabIndex.java Changeset: f544825d0976 Author: jccollet Date: 2010-01-26 11:39 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f544825d0976 6919185: test/closed/sun/net/ftp/FtpTests fails to compile Summary: Fixed a couple of regressions in FtpClient and updated the test. Reviewed-by: chegar ! src/share/classes/sun/net/ftp/impl/FtpClient.java Changeset: 8df0ffac7f4d Author: chegar Date: 2010-01-27 16:11 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8df0ffac7f4d 6905552: libnet/nio portability issues Reviewed-by: alanb ! src/share/native/java/net/net_util.c ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h ! src/solaris/native/sun/net/spi/SdpProvider.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/SctpNet.c Changeset: 4192f6edbbf4 Author: ptisnovs Date: 2010-01-27 17:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4192f6edbbf4 6920143: test/java/awt/TestArea/UsingWithMouse.java needs realSync() Summary: Added small delay to make sure that TextArea animation have finished Reviewed-by: anthony ! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.java Changeset: 0126effcc249 Author: lana Date: 2010-01-27 14:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0126effcc249 Merge Changeset: 946b30073247 Author: sherman Date: 2010-01-27 19:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/946b30073247 6920732: opensource test/java/nio/charset Summary: move the test cases to openjdk Reviewed-by: martin + test/java/nio/charset/Charset/AvailableCharsetNames.java + test/java/nio/charset/Charset/CharsetContainmentTest.java + test/java/nio/charset/Charset/Contains.java + test/java/nio/charset/Charset/Default.java + test/java/nio/charset/Charset/EmptyCharsetName.java + test/java/nio/charset/Charset/EncDec.java + test/java/nio/charset/Charset/IllegalCharsetName.java + test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java + test/java/nio/charset/Charset/NullCharsetName.java + test/java/nio/charset/Charset/RegisteredCharsets.java + test/java/nio/charset/Charset/default.sh + test/java/nio/charset/CharsetDecoder/AverageMax.java + test/java/nio/charset/CharsetDecoder/EmptyInput.java + test/java/nio/charset/CharsetEncoder/CanEncode.java + test/java/nio/charset/CharsetEncoder/Flush.java + test/java/nio/charset/RemovingSunIO/SunioAlias.java + test/java/nio/charset/RemovingSunIO/TestCOMP.java + test/java/nio/charset/RemovingSunIO/TestUnmappableForLength.java + test/java/nio/charset/coders/BashCache.java + test/java/nio/charset/coders/BashStreams.java + test/java/nio/charset/coders/Check.java + test/java/nio/charset/coders/CheckSJISMappingProp.sh + test/java/nio/charset/coders/Errors.java + test/java/nio/charset/coders/FullRead.java + test/java/nio/charset/coders/IOCoders.java + test/java/nio/charset/coders/IsLegalReplacement.java + test/java/nio/charset/coders/ResetISO2022JP.java + test/java/nio/charset/coders/SJISPropTest.java + test/java/nio/charset/coders/StreamTimeout.java + test/java/nio/charset/coders/Surrogate.java + test/java/nio/charset/coders/Surrogates.java + test/java/nio/charset/coders/Util.java + test/java/nio/charset/coders/ref.shift_jis + test/java/nio/charset/coders/ref.windows-31j + test/java/nio/charset/spi/FooCharset.java + test/java/nio/charset/spi/FooProvider.java + test/java/nio/charset/spi/Test.java + test/java/nio/charset/spi/basic.sh + test/java/nio/charset/spi/charsetProvider.sp + test/java/nio/charset/spi/default-pol Changeset: 7dadd2951a8b Author: andrew Date: 2010-02-02 10:55 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7dadd2951a8b 6921740: Eliminate warnings from sun.io converters and allow compiling with JAVAC_MAX_WARNINGS=true Summary: Fix sun.io converters unchecked and cast warnings produced by -Xlint:all Reviewed-by: alanb, sherman ! make/java/sun_nio/Makefile ! src/share/classes/sun/io/ByteToCharUTF8.java ! src/share/classes/sun/io/CharToByteUnicode.java ! src/share/classes/sun/io/CharacterEncoding.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java Changeset: e6ab5fabaf7e Author: weijun Date: 2010-02-03 17:04 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e6ab5fabaf7e 6922482: keytool's help on -file always shows 'output file' Reviewed-by: wetmore ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/file-in-help.sh Changeset: a39e899aa5dc Author: sherman Date: 2010-02-05 00:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a39e899aa5dc 6919132: Regex \P{Lu} selects half of a surrogate pari Summary: To use StartS for complement category/block class Reviewed-by: martin, okutsu ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 7136683a33d2 Author: wetmore Date: 2010-02-05 17:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7136683a33d2 6923976: TestProviderLeak.java is using too small of an initial heap under newer Hotspot (b79+) Reviewed-by: ohair ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java Changeset: 445b9928fb70 Author: sherman Date: 2010-02-06 09:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/445b9928fb70 6923692: java/classes_util TEST_BUG:ReadZip.java fails when Summary: to create the test file at test.dir Reviewed-by: alanb ! test/java/util/zip/ZipFile/ReadZip.java Changeset: e79d95ea2e81 Author: lana Date: 2010-02-08 23:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e79d95ea2e81 Merge Changeset: 7e8c77ae401a Author: rkennke Date: 2010-02-02 16:38 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7e8c77ae401a 6888734: PIT: regression test fails when java.security.manager is enabled Summary: Load FontManager instance in privileged block to avoid AccessControlException Reviewed-by: igor, tdv ! src/share/classes/sun/font/FontManagerFactory.java + test/java/awt/PrintJob/Security/SecurityDialogTest.java + test/java/awt/PrintJob/Security/policy Changeset: cedd0cdd5b9a Author: rkennke Date: 2010-02-03 10:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cedd0cdd5b9a 6896335: GraphicsEnvironment.getDefaultScreenDevice() throws UnsatisfiedLinkError in headless mode Summary: Use local ge variable instead of localEnv field in GE. Reviewed-by: igor, prr ! src/share/classes/java/awt/GraphicsEnvironment.java + test/java/awt/GraphicsEnvironment/TestGetDefScreenDevice.java Changeset: 58d014485a29 Author: rkennke Date: 2010-02-07 11:07 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/58d014485a29 6904882: java.awt.Font.createFont() causes AccessControlException if executed with "-Djava.security.manager" Summary: Perform FontUtilities initialization in privileged block Reviewed-by: igor, prr ! src/share/classes/sun/font/FontUtilities.java + test/java/awt/FontClass/FontPrivilege.java Changeset: 89b0235188b5 Author: lana Date: 2010-02-09 00:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/89b0235188b5 Merge Changeset: 31a3f28f3326 Author: dcherepanov Date: 2009-12-23 01:22 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/31a3f28f3326 6908299: Missed changes for 6664512 during the merge with 6879044 Reviewed-by: mchung, art ! src/share/classes/sun/util/logging/PlatformLogger.java Changeset: 7b65af04d43c Author: dav Date: 2009-12-22 17:28 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7b65af04d43c 6893325: JComboBox and dragging to an item outside the bounds of the containing JFrame is not selecting that Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: 26280d1705b2 Author: dcherepanov Date: 2009-12-28 20:35 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/26280d1705b2 6857363: deadlock caused by sun.awt.X11.XTrayIconPeer$Tooltip.display Reviewed-by: ant, art ! src/solaris/classes/sun/awt/X11/InfoWindow.java Changeset: fd5bf5955e37 Author: uta Date: 2009-12-24 17:19 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fd5bf5955e37 4874070: invoking DragSource's startDrag with an Image renders no image on drag Reviewed-by: art, denis, alexp ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/make.depend ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java ! src/windows/classes/sun/awt/windows/WDataTransferer.java ! src/windows/classes/sun/awt/windows/WDragSourceContextPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/lib/flavormap.properties ! src/windows/native/sun/windows/awt.h + src/windows/native/sun/windows/awt_DCHolder.cpp + src/windows/native/sun/windows/awt_DCHolder.h ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_DnDDS.h ! src/windows/native/sun/windows/awt_DnDDT.cpp ! src/windows/native/sun/windows/awt_DnDDT.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h + src/windows/native/sun/windows/awt_ole.cpp + src/windows/native/sun/windows/awt_ole.h + test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.html + test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java + test/java/awt/dnd/DnDFileGroupDescriptor/DnDTarget.java + test/java/awt/dnd/ImageDecoratedDnD/DnDSource.java + test/java/awt/dnd/ImageDecoratedDnD/DnDTarget.java + test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.html + test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.java + test/java/awt/dnd/ImageDecoratedDnD/ImageGenerator.java + test/java/awt/dnd/ImageDecoratedDnD/MyCursor.java + test/java/awt/dnd/ImageDecoratedDnDInOut/DnDSource.java + test/java/awt/dnd/ImageDecoratedDnDInOut/DnDTarget.java + test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.html + test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.java + test/java/awt/dnd/ImageDecoratedDnDInOut/ImageGenerator.java + test/java/awt/dnd/ImageDecoratedDnDInOut/MyCursor.java + test/java/awt/dnd/ImageDecoratedDnDNegative/DnDSource.java + test/java/awt/dnd/ImageDecoratedDnDNegative/DnDTarget.java + test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.html + test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java + test/java/awt/dnd/ImageDecoratedDnDNegative/ImageGenerator.java + test/java/awt/dnd/ImageDecoratedDnDNegative/MyCursor.java Changeset: 4799006d0171 Author: uta Date: 2010-01-13 17:10 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4799006d0171 Merge Changeset: f154d4943a1a Author: uta Date: 2010-01-14 17:56 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f154d4943a1a 6916867: Fastdebug build failed after CR 4874070 fix putback. Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_DnDDS.cpp Changeset: 3cc5eff94552 Author: dcherepanov Date: 2010-01-20 01:33 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3cc5eff94552 6660258: Java application stops Windows logout/shutdown (regression in 1.5.0_14) Reviewed-by: anthony, art, uta ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awtmsg.h Changeset: 0f92194cd798 Author: dcherepanov Date: 2010-01-22 19:47 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0f92194cd798 6756774: fstdebug jvm fails with assertion (result != deleted_handle(),"Used a deleted global handle.") Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_MenuItem.cpp Changeset: d7c4baff3f96 Author: lana Date: 2010-01-28 18:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d7c4baff3f96 Merge - make/java/redist/FILES.gmk ! make/sun/awt/Makefile - make/sun/nio/FILES_java.gmk - src/share/classes/sun/dyn/util/BytecodeSignature.java - src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java Changeset: 66c193082586 Author: yan Date: 2010-02-08 17:02 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/66c193082586 6882912: Strange behaviours when typing @ or ' Summary: Eliminate stray lines without a proper unicode->regularKeyID pair (e.g. as there is no "arrow left" unicode, should be no pair) Reviewed-by: rupashka ! src/share/classes/sun/awt/ExtendedKeyCodes.java Changeset: b51982678191 Author: lana Date: 2010-02-09 00:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b51982678191 Merge Changeset: de7807599a9b Author: peytoia Date: 2009-12-15 14:50 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/de7807599a9b 5047314: [Col] Collator.compare() runs indefinitely for a certain set of Thai strings Reviewed-by: okutsu ! src/share/classes/java/text/CollationElementIterator.java + test/java/text/Collator/Bug5047314.java Changeset: 3efbbc00ac5f Author: lana Date: 2009-12-16 16:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3efbbc00ac5f Merge - make/tools/CharsetMapping/DoubleByte-X.java - make/tools/CharsetMapping/SingleByte-X.java - src/share/classes/sun/awt/ComponentAccessor.java - src/share/classes/sun/awt/WindowAccessor.java - src/share/classes/sun/security/provider/IdentityDatabase.java - src/share/classes/sun/security/provider/SystemIdentity.java - src/share/classes/sun/security/provider/SystemSigner.java - src/share/classes/sun/security/x509/X500Signer.java - src/share/classes/sun/security/x509/X509Cert.java - src/share/classes/sun/tools/jar/JarVerifierStream.java - src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java - test/java/util/Formatter/Basic-X.java - test/sun/tools/native2ascii/test2 - test/tools/launcher/SolarisDataModel.sh - test/tools/launcher/SolarisRunpath.sh - test/tools/launcher/libraryCaller.c - test/tools/launcher/libraryCaller.h - test/tools/launcher/libraryCaller.java Changeset: e2f7e92c30f1 Author: peterz Date: 2009-12-21 19:26 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e2f7e92c30f1 6860433: [Nimbus] Code to set a single slider's thumb background doesn't work as specified Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java + test/javax/swing/plaf/nimbus/ColorCustomizationTest.java Changeset: fffd21bc5657 Author: peterz Date: 2009-12-25 17:47 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fffd21bc5657 6860438: [Nimbus] Code to globally set slider's thumb background doesn't work as specified Reviewed-by: rupashka ! src/share/classes/javax/swing/MultiUIDefaults.java + test/javax/swing/MultiUIDefaults/4300666/bug4300666.html + test/javax/swing/MultiUIDefaults/4300666/bug4300666.java + test/javax/swing/MultiUIDefaults/4331767/bug4331767.java + test/javax/swing/MultiUIDefaults/Test6860438.java Changeset: e9ccd1dd6923 Author: andrew Date: 2010-01-08 12:51 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e9ccd1dd6923 6584033: (tz) wrong buffer length in TimeZone_md.c Summary: Add testcase for this bug Reviewed-by: darcy, okutsu + test/java/util/TimeZone/TimeZoneDatePermissionCheck.java + test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh Changeset: b129d0f7be40 Author: peytoia Date: 2010-01-13 15:40 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b129d0f7be40 6868503: RuleBasedBreakIterator is inefficient Reviewed-by: okutsu ! src/share/classes/java/text/RuleBasedBreakIterator.java Changeset: 9c5a24050392 Author: malenkov Date: 2010-01-21 21:45 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9c5a24050392 4922835: DOC: Statement javadoc should indicate that target and methodName cannot be null Reviewed-by: peterz ! src/share/classes/java/beans/Expression.java ! src/share/classes/java/beans/Statement.java Changeset: eba0ff97a252 Author: malenkov Date: 2010-01-21 21:53 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eba0ff97a252 4968536: DOC: Javadoc for java.beans.Encoder.getPersistenceDelegate is incomplete Reviewed-by: peterz ! src/share/classes/java/beans/Encoder.java Changeset: 3c61edecf44f Author: okutsu Date: 2010-01-26 15:42 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3c61edecf44f 6912866: (date) java.util.Date.before / after may be expensive Reviewed-by: peytoia ! src/share/classes/java/util/Date.java Changeset: e7127f3fa2f4 Author: peterz Date: 2010-01-28 17:06 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e7127f3fa2f4 6912118: Incosistency in several SynthUI classes between inherited specs ofupdate() and paint() methods Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthListUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 4eb3a8c95c24 Author: malenkov Date: 2010-01-28 20:49 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4eb3a8c95c24 6412286: DOC: LTP: Unspecified NPE in java.beans.DefaultPersistenceDelegate.instantiate method Reviewed-by: peterz ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/PersistenceDelegate.java Changeset: 3283bb8c1bcb Author: lana Date: 2010-01-28 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3283bb8c1bcb Merge - make/java/redist/FILES.gmk - make/sun/nio/FILES_java.gmk - src/share/classes/sun/dyn/util/BytecodeSignature.java - src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java Changeset: 3913691b3021 Author: malenkov Date: 2010-02-05 10:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3913691b3021 6921057: REGRESSION: persistence delegate issue on Windows and Linux against 5.u23b03/6u17b11 Reviewed-by: peterz, art ! src/share/classes/java/beans/Introspector.java ! test/java/beans/Introspector/6380849/TestBeanInfo.java ! test/java/beans/Introspector/Test5102804.java ! test/java/beans/XMLEncoder/Test4646747.java Changeset: 5c0c2882eed2 Author: lana Date: 2010-02-09 00:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5c0c2882eed2 Merge Changeset: 7cb9388bb1a1 Author: lana Date: 2010-02-14 23:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7cb9388bb1a1 Merge Changeset: a9b4fde406d4 Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a9b4fde406d4 Added tag jdk7-b84 for changeset 7cb9388bb1a1 ! .hgtags From vladimir.kozlov at sun.com Fri Feb 19 12:04:58 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 19 Feb 2010 20:04:58 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag Message-ID: <20100219200507.0AAB642871@hg.openjdk.java.net> Changeset: 2883969d09e7 Author: kvn Date: 2010-02-19 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2883969d09e7 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag Summary: Matcher::float_in_double should be true only when FPU is used for floats. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp From Vladimir.Kozlov at Sun.COM Fri Feb 19 12:06:18 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 19 Feb 2010 12:06:18 -0800 Subject: review (S) for 6927049: assert(is_Loop(),"invalid node class") In-Reply-To: <5F59DDBA-C5BF-4593-B131-4207EF2DF67E@sun.com> References: <5F59DDBA-C5BF-4593-B131-4207EF2DF67E@sun.com> Message-ID: <4B7EEF3A.4070201@sun.com> Thank you, Tom You are fast, I just tried to find this bug report few minutes ago :) Looks good. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6927049 > > 6927049: assert(is_Loop(),"invalid node class") > Reviewed-by: > > The loop predication code is missing a guard for is_Loop since it's > possible that the loop might simply by a Region if there are > irreducible loops in the loop tree. I also moved the other loop type > guards up so they would be together before any traps count logic. > Tested with failing test from report. > > src/share/vm/opto/loopTransform.cpp From john.coomes at sun.com Fri Feb 19 12:13:02 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Feb 2010 20:13:02 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 16 new changesets Message-ID: <20100219201350.BCBEA42874@hg.openjdk.java.net> Changeset: f23b985beb78 Author: jjg Date: 2010-01-19 14:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f23b985beb78 6917067: refactor type annotations code from TransTypes into new TypeAnnotations class Reviewed-by: jjg, darcy Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu + src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java Changeset: 0eaf89e08564 Author: jjg Date: 2010-01-20 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0eaf89e08564 6918127: improve handling of TypeAnnotationPosition fields Reviewed-by: jjg, darcy Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java Changeset: da0e3e2dd3ef Author: jjg Date: 2010-01-26 11:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/da0e3e2dd3ef 6919944: incorrect position given for duplicate annotation value error Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out Changeset: 59167312ed4e Author: jjg Date: 2010-01-26 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/59167312ed4e 6917130: should test that annotations that have been optimized away are not emitted to classfile Reviewed-by: jjg, darcy Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu + test/tools/javac/typeAnnotations/classfile/DeadCode.java Changeset: ff7a01f9eff3 Author: lana Date: 2010-01-27 14:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ff7a01f9eff3 Merge Changeset: 699ecefbdd4e Author: jjg Date: 2010-01-29 16:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/699ecefbdd4e 6919889: assorted position errors in compiler syntax trees Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/T6654037.java ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.out + test/tools/javac/treepostests/TreePosTest.java Changeset: 8e638442522a Author: jjg Date: 2010-01-29 16:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/8e638442522a 6499119: Created package-info class file modeled improperly 6920317: package-info.java file has to be specified on the javac cmdline, else it will not be avail. Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/6499119/ClassProcessor.java + test/tools/javac/processing/6499119/package-info.java + test/tools/javac/processing/T6920317.java Changeset: 732510cc3538 Author: jjg Date: 2010-02-01 17:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/732510cc3538 6919986: [308] change size of type_index (of CLASS_EXTENDS and THROWS) from byte to short Reviewed-by: darcy, jjg Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Changeset: b0a68258360a Author: jjg Date: 2010-02-02 10:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b0a68258360a 6918625: handle annotations on array class literals Reviewed-by: jjg, darcy Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java + test/tools/javap/typeAnnotations/ArrayClassLiterals2.java Changeset: 41ed86f86585 Author: jjg Date: 2010-02-03 11:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/41ed86f86585 6922429: extend tree position test waiver Reviewed-by: darcy ! test/tools/javac/treepostests/TreePosTest.java Changeset: f65d652cb6af Author: jjg Date: 2010-02-03 11:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f65d652cb6af 6922300: [308] populate the reference_info for type annotations targeting primitive class literals Reviewed-by: darcy, jjg Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu ! src/share/classes/com/sun/tools/javac/jvm/Gen.java Changeset: 4c844e609d81 Author: jjg Date: 2010-02-03 16:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4c844e609d81 6921979: add test program to verify annotations are attached to nodes as expected Reviewed-by: darcy + test/tools/javac/treeannotests/AnnoTreeTests.java + test/tools/javac/treeannotests/DA.java + test/tools/javac/treeannotests/TA.java + test/tools/javac/treeannotests/Test.java + test/tools/javac/treeannotests/TestProcessor.java Changeset: 4b4e282a3146 Author: jjg Date: 2010-02-04 10:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4b4e282a3146 6923080: TreeScanner.visitNewClass should scan tree.typeargs Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java + test/tools/javac/tree/T6923080.java + test/tools/javac/tree/TreeScannerTest.java Changeset: 56a46d079264 Author: lana Date: 2010-02-08 23:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/56a46d079264 Merge Changeset: d9cd5b8286e4 Author: lana Date: 2010-02-14 23:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d9cd5b8286e4 Merge Changeset: 75d5bd12eb86 Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/75d5bd12eb86 Added tag jdk7-b84 for changeset d9cd5b8286e4 ! .hgtags From Thomas.Rodriguez at Sun.COM Fri Feb 19 12:19:25 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 19 Feb 2010 12:19:25 -0800 Subject: review (S) for 6927049: assert(is_Loop(),"invalid node class") In-Reply-To: <4B7EEF3A.4070201@sun.com> References: <5F59DDBA-C5BF-4593-B131-4207EF2DF67E@sun.com> <4B7EEF3A.4070201@sun.com> Message-ID: <2A385A86-0523-42FB-A1E5-E158C4677DBD@Sun.COM> Sorry, I should have claimed it. Tony helped me reproduce it the day before yesterday but I just got around to sending out the review. Thanks! tom On Feb 19, 2010, at 12:06 PM, Vladimir Kozlov wrote: > Thank you, Tom > > You are fast, I just tried to find this bug report few minutes ago :) > > Looks good. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6927049 >> 6927049: assert(is_Loop(),"invalid node class") >> Reviewed-by: >> The loop predication code is missing a guard for is_Loop since it's >> possible that the loop might simply by a Region if there are >> irreducible loops in the loop tree. I also moved the other loop type >> guards up so they would be together before any traps count logic. >> Tested with failing test from report. >> src/share/vm/opto/loopTransform.cpp From Thomas.Rodriguez at Sun.COM Fri Feb 19 13:10:28 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 19 Feb 2010 13:10:28 -0800 Subject: review (S) for 6926979: should simplify catch_inline_exception Message-ID: <0A854803-B76E-422F-8B08-B79958A8A12B@sun.com> http://cr.openjdk.java.net/~never/6926979 6926979: should simplify catch_inline_exception Reviewed-by: This is the follow on fix to 6877221 that I'm proposing for hs18. That fix patched over some uncommon trap conditions that could result in unneeded uncommon traps during exception dispatch. This fix rewrites the exception paths to take advantage of the fast subtype checks to handle more cases inline and removes the use of the uncommon trap that used Reason_unhandled/Action_none to deal with unloaded classes or classes with subtypes. Instead we emit full subtype checks for catch classes with subclass and allow catch_call_exceptions to emit a Reason_unloaded exception handler for unloaded catch classes. This way we won't uncommon trap unless we really need to and in that case we'll throw out the code and recompile. src/share/vm/opto/doCall.cpp src/share/vm/opto/parse.hpp src/share/vm/opto/parse1.cpp From thomas.rodriguez at sun.com Fri Feb 19 15:01:41 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 19 Feb 2010 23:01:41 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6927049: assert(is_Loop(), "invalid node class") Message-ID: <20100219230145.4C675428A3@hg.openjdk.java.net> Changeset: b71f13525cc8 Author: never Date: 2010-02-19 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b71f13525cc8 6927049: assert(is_Loop(),"invalid node class") Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp From Vladimir.Kozlov at Sun.COM Mon Feb 22 16:43:29 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 22 Feb 2010 16:43:29 -0800 Subject: Request for reviews (XXS): 6928717: HS17 fails to build with SS11 C++ Message-ID: <4B8324B1.3020409@sun.com> http://cr.openjdk.java.net/~kvn/6928717/webrev Fixed 6928717: HS17 fails to build with SS11 C++ Problem: Changes for 4360113 added code to codeCache.cpp which requires default Handle constructor: xtty->method(methodOop(m)). But they missed to add handles.inline.hpp for codeCache.cpp. Solution: Add missing handles.inline.hpp. Reviewed by: Fix verified (y/n): y, build with SS11 Other testing: From Thomas.Rodriguez at Sun.COM Mon Feb 22 17:13:26 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 22 Feb 2010 17:13:26 -0800 Subject: Request for reviews (XXS): 6928717: HS17 fails to build with SS11 C++ In-Reply-To: <4B8324B1.3020409@sun.com> References: <4B8324B1.3020409@sun.com> Message-ID: <793C425D-C7CC-4AAE-854F-453E7B4EFC3C@sun.com> Looks good. tom On Feb 22, 2010, at 4:43 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6928717/webrev > > Fixed 6928717: HS17 fails to build with SS11 C++ > > Problem: > Changes for 4360113 added code to codeCache.cpp which requires > default Handle constructor: xtty->method(methodOop(m)). > But they missed to add handles.inline.hpp for codeCache.cpp. > > Solution: > Add missing handles.inline.hpp. > > Reviewed by: > > Fix verified (y/n): y, build with SS11 > > Other testing: > From vladimir.kozlov at sun.com Mon Feb 22 19:18:34 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 23 Feb 2010 03:18:34 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6928717: HS17 fails to build with SS11 C++ Message-ID: <20100223031838.4ACFC42D7C@hg.openjdk.java.net> Changeset: 8b38237bae55 Author: kvn Date: 2010-02-22 16:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8b38237bae55 6928717: HS17 fails to build with SS11 C++ Summary: Add missing handles.inline.hpp for codeCache.cpp. Reviewed-by: never ! src/share/vm/includeDB_core From Christian.Thalinger at Sun.COM Tue Feb 23 01:19:59 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 23 Feb 2010 10:19:59 +0100 Subject: review (S) for 6926979: should simplify catch_inline_exception In-Reply-To: <0A854803-B76E-422F-8B08-B79958A8A12B@sun.com> References: <0A854803-B76E-422F-8B08-B79958A8A12B@sun.com> Message-ID: <4B839DBF.1010702@Sun.COM> On 02/19/10 10:10 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6926979 > > 6926979: should simplify catch_inline_exception > Reviewed-by: > > This is the follow on fix to 6877221 that I'm proposing for hs18. > That fix patched over some uncommon trap conditions that could result > in unneeded uncommon traps during exception dispatch. This fix > rewrites the exception paths to take advantage of the fast subtype > checks to handle more cases inline and removes the use of the uncommon > trap that used Reason_unhandled/Action_none to deal with unloaded > classes or classes with subtypes. Instead we emit full subtype checks > for catch classes with subclass and allow catch_call_exceptions to > emit a Reason_unloaded exception handler for unloaded catch classes. > This way we won't uncommon trap unless we really need to and in that > case we'll throw out the code and recompile. > > src/share/vm/opto/doCall.cpp > src/share/vm/opto/parse.hpp > src/share/vm/opto/parse1.cpp I think this looks good. What about the removed comment that says: ! // %%% Now that subclass checking is very fast, we need to rewrite ! // this section and remove the option "DeutschShiffmanExceptions". Do we still need this option? -- Christian From Christian.Thalinger at Sun.COM Tue Feb 23 04:05:00 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 23 Feb 2010 13:05:00 +0100 Subject: Request for reviews (XXS): 6928839: JSR 292 typo in x86 _adapter_check_cast Message-ID: <4B83C46C.8060309@Sun.COM> http://cr.openjdk.java.net/~twisti/6928839/webrev.01/ There is a small typo in methodHandles_x86.cpp in MethodHandles::generate_method_handle_stub for _adapter_check_cast: the object null test is only a testl but should be a testptr. The fix is obvious. From Vladimir.Kozlov at Sun.COM Tue Feb 23 08:25:15 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 23 Feb 2010 08:25:15 -0800 Subject: Request for reviews (XXS): 6928839: JSR 292 typo in x86 _adapter_check_cast In-Reply-To: <4B83C46C.8060309@Sun.COM> References: <4B83C46C.8060309@Sun.COM> Message-ID: <4B84016B.8080801@sun.com> Looks good. Vladimir On 2/23/10 4:05 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6928839/webrev.01/ > > There is a small typo in methodHandles_x86.cpp in > MethodHandles::generate_method_handle_stub for _adapter_check_cast: > the object null test is only a testl but should be a testptr. The fix > is obvious. From volker.simonis at gmail.com Tue Feb 23 10:05:44 2010 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Feb 2010 19:05:44 +0100 Subject: hg: jdk7/hotspot-comp/hotspot: 6782260: Memory leak in CodeBuffer::create_patch_overflow In-Reply-To: <20090204042915.64D6A12719@hg.openjdk.java.net> References: <20090204042915.64D6A12719@hg.openjdk.java.net> Message-ID: Hi Tom, by incidence I've just found this problem while playing around with the Arena memory allocation in HS14. Now that I saw your change I'm confident that I've also done the right fix myself :) There's just one question I have regarding your solution: isn't "CodeBuffer::take_over_code_from()" a problem here, because it copies "_overflow_arena" from one CodeBuffer into another one. I think this may potentially lead to a double delete of the same Arena. Or isn't this possible logically. Perhaps it would be more secure to add another line like: DEBUG_ONLY(cb->_overflow_arena = (BufferBlob*)badAddress); to "CodeBuffer::take_over_code_from()" or even better set "_overflow_arena" to NULL after it was copied? What do you think? Regards, Volker On Wed, Feb 4, 2009 at 5:29 AM, wrote: > Changeset: 5bfdb08ea692 > Author: never > Date: 2009-02-03 18:05 -0800 > URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5bfdb08ea692 > > 6782260: Memory leak in CodeBuffer::create_patch_overflow > Reviewed-by: phh, kvn > > ! src/share/vm/asm/codeBuffer.cpp > > From Thomas.Rodriguez at Sun.COM Tue Feb 23 10:49:00 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 23 Feb 2010 10:49:00 -0800 Subject: hg: jdk7/hotspot-comp/hotspot: 6782260: Memory leak in CodeBuffer::create_patch_overflow In-Reply-To: References: <20090204042915.64D6A12719@hg.openjdk.java.net> Message-ID: <15BD65A3-236F-4D60-A1FD-110FD34E565F@Sun.COM> On Feb 23, 2010, at 10:05 AM, Volker Simonis wrote: > Hi Tom, > > by incidence I've just found this problem while playing around with > the Arena memory allocation in HS14. Now that I saw your change I'm > confident that I've also done the right fix myself :) > > There's just one question I have regarding your solution: isn't > "CodeBuffer::take_over_code_from()" a problem here, because it copies > "_overflow_arena" from one CodeBuffer into another one. I think this > may potentially lead to a double delete of the same Arena. Or isn't > this possible logically. Perhaps it would be more secure to add > another line like: Given the style of usage I don't think it's possible. The overflow_arena is only shared with blobs that are created by expand and they are freed in a different way than normal new/delete pair. Setting _overflow_arena to badAddress isn't a bad idea though. tom > > DEBUG_ONLY(cb->_overflow_arena = (BufferBlob*)badAddress); > > to "CodeBuffer::take_over_code_from()" or even better set > "_overflow_arena" to NULL after it was copied? > > What do you think? > > Regards, > Volker > > > On Wed, Feb 4, 2009 at 5:29 AM, wrote: >> Changeset: 5bfdb08ea692 >> Author: never >> Date: 2009-02-03 18:05 -0800 >> URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5bfdb08ea692 >> >> 6782260: Memory leak in CodeBuffer::create_patch_overflow >> Reviewed-by: phh, kvn >> >> ! src/share/vm/asm/codeBuffer.cpp >> >> From Christian.Thalinger at Sun.COM Tue Feb 23 11:25:22 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 23 Feb 2010 19:25:22 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6928839: JSR 292 typo in x86 _adapter_check_cast Message-ID: <20100223192525.B89494142A@hg.openjdk.java.net> Changeset: 855c5171834c Author: twisti Date: 2010-02-23 17:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/855c5171834c 6928839: JSR 292 typo in x86 _adapter_check_cast Summary: There is a small typo in methodHandles_x86.cpp. Reviewed-by: kvn ! src/cpu/x86/vm/methodHandles_x86.cpp From Thomas.Rodriguez at Sun.COM Tue Feb 23 13:09:08 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 23 Feb 2010 13:09:08 -0800 Subject: review (S) for 6926979: should simplify catch_inline_exception In-Reply-To: <4B839DBF.1010702@Sun.COM> References: <0A854803-B76E-422F-8B08-B79958A8A12B@sun.com> <4B839DBF.1010702@Sun.COM> Message-ID: <453C3414-8C4F-423C-87C2-2C3399FE96EE@Sun.COM> I've updated the webrev to delete that too. tom On Feb 23, 2010, at 1:19 AM, Christian Thalinger wrote: > On 02/19/10 10:10 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6926979 >> >> 6926979: should simplify catch_inline_exception >> Reviewed-by: >> >> This is the follow on fix to 6877221 that I'm proposing for hs18. >> That fix patched over some uncommon trap conditions that could result >> in unneeded uncommon traps during exception dispatch. This fix >> rewrites the exception paths to take advantage of the fast subtype >> checks to handle more cases inline and removes the use of the uncommon >> trap that used Reason_unhandled/Action_none to deal with unloaded >> classes or classes with subtypes. Instead we emit full subtype checks >> for catch classes with subclass and allow catch_call_exceptions to >> emit a Reason_unloaded exception handler for unloaded catch classes. >> This way we won't uncommon trap unless we really need to and in that >> case we'll throw out the code and recompile. >> >> src/share/vm/opto/doCall.cpp >> src/share/vm/opto/parse.hpp >> src/share/vm/opto/parse1.cpp > > I think this looks good. What about the removed comment that says: > > ! // %%% Now that subclass checking is very fast, we need to rewrite > ! // this section and remove the option "DeutschShiffmanExceptions". > > Do we still need this option? > > -- Christian From Christian.Thalinger at Sun.COM Tue Feb 23 13:59:05 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 23 Feb 2010 22:59:05 +0100 Subject: review (S) for 6926979: should simplify catch_inline_exception In-Reply-To: <453C3414-8C4F-423C-87C2-2C3399FE96EE@Sun.COM> References: <0A854803-B76E-422F-8B08-B79958A8A12B@sun.com> <4B839DBF.1010702@Sun.COM> <453C3414-8C4F-423C-87C2-2C3399FE96EE@Sun.COM> Message-ID: <1266962345.5654.26.camel@macbook> On Tue, 2010-02-23 at 13:09 -0800, Tom Rodriguez wrote: > I've updated the webrev to delete that too. Looks good. -- Christian From Ulf.Zibis at gmx.de Wed Feb 24 03:52:24 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 24 Feb 2010 12:52:24 +0100 Subject: review (S) for 6926979: should simplify catch_inline_exception In-Reply-To: <0A854803-B76E-422F-8B08-B79958A8A12B@sun.com> References: <0A854803-B76E-422F-8B08-B79958A8A12B@sun.com> Message-ID: <4B8512F8.7090105@gmx.de> Is this related to Bug Id: 6908240 ? -Ulf Am 19.02.2010 22:10, schrieb Tom Rodriguez: > http://cr.openjdk.java.net/~never/6926979 > > 6926979: should simplify catch_inline_exception > Reviewed-by: > > This is the follow on fix to 6877221 that I'm proposing for hs18. > That fix patched over some uncommon trap conditions that could result > in unneeded uncommon traps during exception dispatch. This fix > rewrites the exception paths to take advantage of the fast subtype > checks to handle more cases inline and removes the use of the uncommon > trap that used Reason_unhandled/Action_none to deal with unloaded > classes or classes with subtypes. Instead we emit full subtype checks > for catch classes with subclass and allow catch_call_exceptions to > emit a Reason_unloaded exception handler for unloaded catch classes. > This way we won't uncommon trap unless we really need to and in that > case we'll throw out the code and recompile. > > src/share/vm/opto/doCall.cpp > src/share/vm/opto/parse.hpp > src/share/vm/opto/parse1.cpp > > > From Christian.Thalinger at Sun.COM Wed Feb 24 03:56:30 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 24 Feb 2010 12:56:30 +0100 Subject: review (S) for 6926979: should simplify catch_inline_exception In-Reply-To: <4B8512F8.7090105@gmx.de> References: <0A854803-B76E-422F-8B08-B79958A8A12B@sun.com> <4B8512F8.7090105@gmx.de> Message-ID: <1267012590.6632.0.camel@macbook> On Wed, 2010-02-24 at 12:52 +0100, Ulf Zibis wrote: > Is this related to > > Bug Id: 6908240 ? No. -- Christian From Thomas.Rodriguez at Sun.COM Wed Feb 24 17:29:22 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 24 Feb 2010 17:29:22 -0800 Subject: review (S) for 6915557: assert(_gvn.type(l)->higher_equal(type), "must constrain OSR typestate") with debug build Message-ID: <2547500D-332D-4FE7-962B-389247450792@sun.com> http://cr.openjdk.java.net/~never/6915557 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build Reviewed-by: The fix for 6892079 to eliminate asserts about address types in OSR was insufficient because sometimes method liveness may consider locals to live that actually aren't because of the conservativeness of its analysis. I think the fix is simply to not check address types. If the OSR entry point has any live address we will fail this test but the resonsibility for making sure that we don't actually have a live jsr during OSR entry is managed by ciTypeFlow itself so it should be safe to simply skip the check. Tested with failing test case. src/share/vm/opto/parse1.cpp From Vladimir.Kozlov at Sun.COM Wed Feb 24 18:13:32 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 24 Feb 2010 18:13:32 -0800 Subject: review (S) for 6915557: assert(_gvn.type(l)->higher_equal(type), "must constrain OSR typestate") with debug build In-Reply-To: <2547500D-332D-4FE7-962B-389247450792@sun.com> References: <2547500D-332D-4FE7-962B-389247450792@sun.com> Message-ID: <4B85DCCC.5010306@sun.com> Tom, So it is safe to skip the type check at this place because in an other place (in ciTypeFlow) we already have such check? Your new comment says that we don't do type check because it will fail anyway but it does not explain why it is safe to skip it at that place. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6915557 > > 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build > Reviewed-by: > > The fix for 6892079 to eliminate asserts about address types in OSR > was insufficient because sometimes method liveness may consider locals > to live that actually aren't because of the conservativeness of its > analysis. I think the fix is simply to not check address types. If > the OSR entry point has any live address we will fail this test but > the resonsibility for making sure that we don't actually have a live > jsr during OSR entry is managed by ciTypeFlow itself so it should be > safe to simply skip the check. Tested with failing test case. > > src/share/vm/opto/parse1.cpp From Thomas.Rodriguez at Sun.COM Wed Feb 24 22:04:26 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 24 Feb 2010 22:04:26 -0800 Subject: review (S) for 6915557: assert(_gvn.type(l)->higher_equal(type), "must constrain OSR typestate") with debug build In-Reply-To: <4B85DCCC.5010306@sun.com> References: <2547500D-332D-4FE7-962B-389247450792@sun.com> <4B85DCCC.5010306@sun.com> Message-ID: On Feb 24, 2010, at 6:13 PM, Vladimir Kozlov wrote: > Tom, > > So it is safe to skip the type check at this place because > in an other place (in ciTypeFlow) we already have such check? > > Your new comment says that we don't do type check because it will fail anyway > but it does not explain why it is safe to skip it at that place. In our current system it's illegal to compile an OSR with a live jsr and it's ciTypeFlows responsibility to figure that out. See ciTypeFlow::JsrSet::apply_control. So any address in the OSR entry state must be invalid. A precise version of method liveness or a more complicated version of ciTypeFlow, would be able to prove that but since ours can't prove this we have to ignore them ourselves. This is something we've always been exposed to but it happened in the past that the copy of the OSR block that we chose to use as the entry had those locals as bottom instead of containing an address. Because of cloning caused by jsr/ret that are hundreds of copies of that block, some which say that local is bottom and the others all say it's some constant. If we chose a one with a constant address then we will hit this assert. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6915557 >> 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build >> Reviewed-by: >> The fix for 6892079 to eliminate asserts about address types in OSR >> was insufficient because sometimes method liveness may consider locals >> to live that actually aren't because of the conservativeness of its >> analysis. I think the fix is simply to not check address types. If >> the OSR entry point has any live address we will fail this test but >> the resonsibility for making sure that we don't actually have a live >> jsr during OSR entry is managed by ciTypeFlow itself so it should be >> safe to simply skip the check. Tested with failing test case. >> src/share/vm/opto/parse1.cpp From Vladimir.Kozlov at Sun.COM Wed Feb 24 22:11:52 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 24 Feb 2010 22:11:52 -0800 Subject: review (S) for 6915557: assert(_gvn.type(l)->higher_equal(type), "must constrain OSR typestate") with debug build In-Reply-To: References: <2547500D-332D-4FE7-962B-389247450792@sun.com> <4B85DCCC.5010306@sun.com> Message-ID: <4B8614A8.6040307@sun.com> Thank you, Tom, for explanation. Changes are good. Vladimir Tom Rodriguez wrote: > On Feb 24, 2010, at 6:13 PM, Vladimir Kozlov wrote: > >> Tom, >> >> So it is safe to skip the type check at this place because >> in an other place (in ciTypeFlow) we already have such check? >> >> Your new comment says that we don't do type check because it will fail anyway >> but it does not explain why it is safe to skip it at that place. > > In our current system it's illegal to compile an OSR with a live jsr and it's ciTypeFlows responsibility to figure that out. See ciTypeFlow::JsrSet::apply_control. So any address in the OSR entry state must be invalid. A precise version of method liveness or a more complicated version of ciTypeFlow, would be able to prove that but since ours can't prove this we have to ignore them ourselves. This is something we've always been exposed to but it happened in the past that the copy of the OSR block that we chose to use as the entry had those locals as bottom instead of containing an address. Because of cloning caused by jsr/ret that are hundreds of copies of that block, some which say that local is bottom and the others all say it's some constant. If we chose a one with a constant address then we will hit this assert. > > tom > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6915557 >>> 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build >>> Reviewed-by: >>> The fix for 6892079 to eliminate asserts about address types in OSR >>> was insufficient because sometimes method liveness may consider locals >>> to live that actually aren't because of the conservativeness of its >>> analysis. I think the fix is simply to not check address types. If >>> the OSR entry point has any live address we will fail this test but >>> the resonsibility for making sure that we don't actually have a live >>> jsr during OSR entry is managed by ciTypeFlow itself so it should be >>> safe to simply skip the check. Tested with failing test case. >>> src/share/vm/opto/parse1.cpp > From Thomas.Rodriguez at Sun.COM Wed Feb 24 22:21:27 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 24 Feb 2010 22:21:27 -0800 Subject: review (S) for 6915557: assert(_gvn.type(l)->higher_equal(type), "must constrain OSR typestate") with debug build In-Reply-To: <4B8614A8.6040307@sun.com> References: <2547500D-332D-4FE7-962B-389247450792@sun.com> <4B85DCCC.5010306@sun.com> <4B8614A8.6040307@sun.com> Message-ID: Do you think I should rewrite/expand the comment? tom On Feb 24, 2010, at 10:11 PM, Vladimir Kozlov wrote: > Thank you, Tom, for explanation. > Changes are good. > > Vladimir > > Tom Rodriguez wrote: >> On Feb 24, 2010, at 6:13 PM, Vladimir Kozlov wrote: >>> Tom, >>> >>> So it is safe to skip the type check at this place because >>> in an other place (in ciTypeFlow) we already have such check? >>> >>> Your new comment says that we don't do type check because it will fail anyway >>> but it does not explain why it is safe to skip it at that place. >> In our current system it's illegal to compile an OSR with a live jsr and it's ciTypeFlows responsibility to figure that out. See ciTypeFlow::JsrSet::apply_control. So any address in the OSR entry state must be invalid. A precise version of method liveness or a more complicated version of ciTypeFlow, would be able to prove that but since ours can't prove this we have to ignore them ourselves. This is something we've always been exposed to but it happened in the past that the copy of the OSR block that we chose to use as the entry had those locals as bottom instead of containing an address. Because of cloning caused by jsr/ret that are hundreds of copies of that block, some which say that local is bottom and the others all say it's some constant. If we chose a one with a constant address then we will hit this assert. >> tom >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6915557 >>>> 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build >>>> Reviewed-by: >>>> The fix for 6892079 to eliminate asserts about address types in OSR >>>> was insufficient because sometimes method liveness may consider locals >>>> to live that actually aren't because of the conservativeness of its >>>> analysis. I think the fix is simply to not check address types. If >>>> the OSR entry point has any live address we will fail this test but >>>> the resonsibility for making sure that we don't actually have a live >>>> jsr during OSR entry is managed by ciTypeFlow itself so it should be >>>> safe to simply skip the check. Tested with failing test case. >>>> src/share/vm/opto/parse1.cpp From Vladimir.Kozlov at Sun.COM Wed Feb 24 22:37:26 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 24 Feb 2010 22:37:26 -0800 Subject: review (S) for 6915557: assert(_gvn.type(l)->higher_equal(type), "must constrain OSR typestate") with debug build In-Reply-To: References: <2547500D-332D-4FE7-962B-389247450792@sun.com> <4B85DCCC.5010306@sun.com> <4B8614A8.6040307@sun.com> Message-ID: <4B861AA6.7000403@sun.com> It would be nice if you do since it is difficult to understand the problem from the current comment. At least add what you said in the request: If the OSR entry point has any live address we will fail this test but the responsibility for making sure that we don't actually have a live jsr during OSR entry is managed by ciTypeFlow itself so it should be safe to simply skip the check. Thanks, Vladimir Tom Rodriguez wrote: > Do you think I should rewrite/expand the comment? > > tom > > On Feb 24, 2010, at 10:11 PM, Vladimir Kozlov wrote: > >> Thank you, Tom, for explanation. >> Changes are good. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> On Feb 24, 2010, at 6:13 PM, Vladimir Kozlov wrote: >>>> Tom, >>>> >>>> So it is safe to skip the type check at this place because >>>> in an other place (in ciTypeFlow) we already have such check? >>>> >>>> Your new comment says that we don't do type check because it will fail anyway >>>> but it does not explain why it is safe to skip it at that place. >>> In our current system it's illegal to compile an OSR with a live jsr and it's ciTypeFlows responsibility to figure that out. See ciTypeFlow::JsrSet::apply_control. So any address in the OSR entry state must be invalid. A precise version of method liveness or a more complicated version of ciTypeFlow, would be able to prove that but since ours can't prove this we have to ignore them ourselves. This is something we've always been exposed to but it happened in the past that the copy of the OSR block that we chose to use as the entry had those locals as bottom instead of containing an address. Because of cloning caused by jsr/ret that are hundreds of copies of that block, some which say that local is bottom and the others all say it's some constant. If we chose a one with a constant address then we will hit this assert. >>> tom >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/6915557 >>>>> 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build >>>>> Reviewed-by: >>>>> The fix for 6892079 to eliminate asserts about address types in OSR >>>>> was insufficient because sometimes method liveness may consider locals >>>>> to live that actually aren't because of the conservativeness of its >>>>> analysis. I think the fix is simply to not check address types. If >>>>> the OSR entry point has any live address we will fail this test but >>>>> the resonsibility for making sure that we don't actually have a live >>>>> jsr during OSR entry is managed by ciTypeFlow itself so it should be >>>>> safe to simply skip the check. Tested with failing test case. >>>>> src/share/vm/opto/parse1.cpp > From Thomas.Rodriguez at Sun.COM Thu Feb 25 11:04:05 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 25 Feb 2010 11:04:05 -0800 Subject: review (S) for 6915557: assert(_gvn.type(l)->higher_equal(type), "must constrain OSR typestate") with debug build In-Reply-To: <4B861AA6.7000403@sun.com> References: <2547500D-332D-4FE7-962B-389247450792@sun.com> <4B85DCCC.5010306@sun.com> <4B8614A8.6040307@sun.com> <4B861AA6.7000403@sun.com> Message-ID: <62CC91EB-7133-44DA-8424-BAEFD5939C91@Sun.COM> I changed the comment to this: // In our current system it's illegal for jsr addresses to be // live into an OSR entry point because the compiler performs // inlining of jsrs. ciTypeFlow has a bailout that detect this // case and aborts the compile if addresses are live into an OSR // entry point. Because of that we can assume that any address // locals at the OSR entry point are dead. Method liveness // isn't precise enought to figure out that they are dead in all // cases so simply skip checking address locals all // together. Any type check is guaranteed to fail since the // interpreter type is the result of a load which might have any // value and the expected type is a constant. tom On Feb 24, 2010, at 10:37 PM, Vladimir Kozlov wrote: > It would be nice if you do since it is difficult to understand the problem from the current comment. > At least add what you said in the request: > > If the OSR entry point has any live address we will fail this test but > the responsibility for making sure that we don't actually have a live > jsr during OSR entry is managed by ciTypeFlow itself so it should be > safe to simply skip the check. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> Do you think I should rewrite/expand the comment? >> tom >> On Feb 24, 2010, at 10:11 PM, Vladimir Kozlov wrote: >>> Thank you, Tom, for explanation. >>> Changes are good. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> On Feb 24, 2010, at 6:13 PM, Vladimir Kozlov wrote: >>>>> Tom, >>>>> >>>>> So it is safe to skip the type check at this place because >>>>> in an other place (in ciTypeFlow) we already have such check? >>>>> >>>>> Your new comment says that we don't do type check because it will fail anyway >>>>> but it does not explain why it is safe to skip it at that place. >>>> In our current system it's illegal to compile an OSR with a live jsr and it's ciTypeFlows responsibility to figure that out. See ciTypeFlow::JsrSet::apply_control. So any address in the OSR entry state must be invalid. A precise version of method liveness or a more complicated version of ciTypeFlow, would be able to prove that but since ours can't prove this we have to ignore them ourselves. This is something we've always been exposed to but it happened in the past that the copy of the OSR block that we chose to use as the entry had those locals as bottom instead of containing an address. Because of cloning caused by jsr/ret that are hundreds of copies of that block, some which say that local is bottom and the others all say it's some constant. If we chose a one with a constant address then we will hit this assert. >>>> tom >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/6915557 >>>>>> 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build >>>>>> Reviewed-by: >>>>>> The fix for 6892079 to eliminate asserts about address types in OSR >>>>>> was insufficient because sometimes method liveness may consider locals >>>>>> to live that actually aren't because of the conservativeness of its >>>>>> analysis. I think the fix is simply to not check address types. If >>>>>> the OSR entry point has any live address we will fail this test but >>>>>> the resonsibility for making sure that we don't actually have a live >>>>>> jsr during OSR entry is managed by ciTypeFlow itself so it should be >>>>>> safe to simply skip the check. Tested with failing test case. >>>>>> src/share/vm/opto/parse1.cpp From Vladimir.Kozlov at Sun.COM Thu Feb 25 11:38:12 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 25 Feb 2010 11:38:12 -0800 Subject: review (S) for 6915557: assert(_gvn.type(l)->higher_equal(type), "must constrain OSR typestate") with debug build In-Reply-To: <62CC91EB-7133-44DA-8424-BAEFD5939C91@Sun.COM> References: <2547500D-332D-4FE7-962B-389247450792@sun.com> <4B85DCCC.5010306@sun.com> <4B8614A8.6040307@sun.com> <4B861AA6.7000403@sun.com> <62CC91EB-7133-44DA-8424-BAEFD5939C91@Sun.COM> Message-ID: <4B86D1A4.3020205@sun.com> Perfect :) Vladimir Tom Rodriguez wrote: > I changed the comment to this: > > // In our current system it's illegal for jsr addresses to be > // live into an OSR entry point because the compiler performs > // inlining of jsrs. ciTypeFlow has a bailout that detect this > // case and aborts the compile if addresses are live into an OSR > // entry point. Because of that we can assume that any address > // locals at the OSR entry point are dead. Method liveness > // isn't precise enought to figure out that they are dead in all > // cases so simply skip checking address locals all > // together. Any type check is guaranteed to fail since the > // interpreter type is the result of a load which might have any > // value and the expected type is a constant. > > tom > > On Feb 24, 2010, at 10:37 PM, Vladimir Kozlov wrote: > >> It would be nice if you do since it is difficult to understand the problem from the current comment. >> At least add what you said in the request: >> >> If the OSR entry point has any live address we will fail this test but >> the responsibility for making sure that we don't actually have a live >> jsr during OSR entry is managed by ciTypeFlow itself so it should be >> safe to simply skip the check. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> Do you think I should rewrite/expand the comment? >>> tom >>> On Feb 24, 2010, at 10:11 PM, Vladimir Kozlov wrote: >>>> Thank you, Tom, for explanation. >>>> Changes are good. >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> On Feb 24, 2010, at 6:13 PM, Vladimir Kozlov wrote: >>>>>> Tom, >>>>>> >>>>>> So it is safe to skip the type check at this place because >>>>>> in an other place (in ciTypeFlow) we already have such check? >>>>>> >>>>>> Your new comment says that we don't do type check because it will fail anyway >>>>>> but it does not explain why it is safe to skip it at that place. >>>>> In our current system it's illegal to compile an OSR with a live jsr and it's ciTypeFlows responsibility to figure that out. See ciTypeFlow::JsrSet::apply_control. So any address in the OSR entry state must be invalid. A precise version of method liveness or a more complicated version of ciTypeFlow, would be able to prove that but since ours can't prove this we have to ignore them ourselves. This is something we've always been exposed to but it happened in the past that the copy of the OSR block that we chose to use as the entry had those locals as bottom instead of containing an address. Because of cloning caused by jsr/ret that are hundreds of copies of that block, some which say that local is bottom and the others all say it's some constant. If we chose a one with a constant address then we will hit this assert. >>>>> tom >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> http://cr.openjdk.java.net/~never/6915557 >>>>>>> 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build >>>>>>> Reviewed-by: >>>>>>> The fix for 6892079 to eliminate asserts about address types in OSR >>>>>>> was insufficient because sometimes method liveness may consider locals >>>>>>> to live that actually aren't because of the conservativeness of its >>>>>>> analysis. I think the fix is simply to not check address types. If >>>>>>> the OSR entry point has any live address we will fail this test but >>>>>>> the resonsibility for making sure that we don't actually have a live >>>>>>> jsr during OSR entry is managed by ciTypeFlow itself so it should be >>>>>>> safe to simply skip the check. Tested with failing test case. >>>>>>> src/share/vm/opto/parse1.cpp > From thomas.rodriguez at sun.com Thu Feb 25 13:46:53 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 25 Feb 2010 21:46:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6915557: assert(_gvn.type(l)->higher_equal(type), "must constrain OSR typestate") with debug build Message-ID: <20100225214656.812C6417C2@hg.openjdk.java.net> Changeset: da9559b49b84 Author: never Date: 2010-02-25 11:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/da9559b49b84 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp From Vladimir.Kozlov at Sun.COM Thu Feb 25 19:13:03 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 25 Feb 2010 19:13:03 -0800 Subject: Request for reviews (S): 6930116: loop predication code does not handle If nodes with only one projection Message-ID: <4B873C3F.6040409@sun.com> http://cr.openjdk.java.net/~kvn/6930116/webrev Fixed 6930116: loop predication code does not handle If nodes with only one projection Problem: Loop predication codes expects all If nodes have 2 projections which could be not true for some dead paths. Solution: Add check for iff->outcnt() < 2. Reviewed by: Fix verified (y/n): y Other testing: JPRT I did not find where such If came from but other places has such check. It could came from some loop optimization and was not removed since IGVN cleaning code was not run yet (it is done at the end of all loop optimizations). From Thomas.Rodriguez at Sun.COM Thu Feb 25 19:21:04 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 25 Feb 2010 19:21:04 -0800 Subject: Request for reviews (S): 6930116: loop predication code does not handle If nodes with only one projection In-Reply-To: <4B873C3F.6040409@sun.com> References: <4B873C3F.6040409@sun.com> Message-ID: <67272FC1-1A27-4824-9474-3D3AD4B2B1F4@sun.com> Looks good. tom On Feb 25, 2010, at 7:13 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6930116/webrev > > Fixed 6930116: loop predication code does not handle If nodes with only one projection > > Problem: > Loop predication codes expects all If nodes have 2 projections which > could be not true for some dead paths. > > Solution: > Add check for iff->outcnt() < 2. > > Reviewed by: > > Fix verified (y/n): y > > Other testing: > JPRT > > I did not find where such If came from but other places has such check. > It could came from some loop optimization and was not removed since > IGVN cleaning code was not run yet (it is done at the end of all > loop optimizations). > From Vladimir.Kozlov at Sun.COM Thu Feb 25 19:21:38 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 25 Feb 2010 19:21:38 -0800 Subject: Request for reviews (S): 6930116: loop predication code does not handle If nodes with only one projection In-Reply-To: <67272FC1-1A27-4824-9474-3D3AD4B2B1F4@sun.com> References: <4B873C3F.6040409@sun.com> <67272FC1-1A27-4824-9474-3D3AD4B2B1F4@sun.com> Message-ID: <4B873E42.9090405@sun.com> Thanks, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Feb 25, 2010, at 7:13 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6930116/webrev >> >> Fixed 6930116: loop predication code does not handle If nodes with only one projection >> >> Problem: >> Loop predication codes expects all If nodes have 2 projections which >> could be not true for some dead paths. >> >> Solution: >> Add check for iff->outcnt() < 2. >> >> Reviewed by: >> >> Fix verified (y/n): y >> >> Other testing: >> JPRT >> >> I did not find where such If came from but other places has such check. >> It could came from some loop optimization and was not removed since >> IGVN cleaning code was not run yet (it is done at the end of all >> loop optimizations). >> > From vladimir.kozlov at sun.com Thu Feb 25 19:55:19 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 26 Feb 2010 03:55:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6930035: C2 type system incorrectly handles case j.l.Object->meet(constant AryPtr) Message-ID: <20100226035523.15B0841827@hg.openjdk.java.net> Changeset: 2432acbee618 Author: kvn Date: 2010-02-25 15:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2432acbee618 6930035: C2 type system incorrectly handles case j.l.Object->meet(constant AryPtr) Summary: Add missing code. Reviewed-by: never ! src/share/vm/opto/type.cpp From vladimir.kozlov at sun.com Fri Feb 26 01:24:31 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 26 Feb 2010 09:24:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6930116: loop predication code does not handle If nodes with only one projection Message-ID: <20100226092434.6FFC44188C@hg.openjdk.java.net> Changeset: 336c6c200f5f Author: kvn Date: 2010-02-25 22:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/336c6c200f5f 6930116: loop predication code does not handle If nodes with only one projection Summary: Add check for iff->outcnt() < 2. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp From Thomas.Rodriguez at Sun.COM Fri Feb 26 15:07:28 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 26 Feb 2010 15:07:28 -0800 Subject: review (S) for 6930398: fix for return address locals in OSR entries uses wrong test Message-ID: <9A24F498-8A25-40E2-AAFC-835BE226D6C7@Sun.COM> http://cr.openjdk.java.net/~never/6930398 6930398: fix for return address locals in OSR entries uses wrong test Reviewed-by: The fix for 6915557 is attempting to handle locals containing return address specially but the test it's using is wrong. C2's type system smears together T_ADDRESS with raw pointer types, so TypePtr::NULL_PTr->basic_type() == T_ADDRESS so the logic will trigger for locals which are provably null resulting in asserts later. The correct fix is to test the ciType of the local which correctly distinguishes these cases. Tested with failing tests from nightly. src/share/vm/opto/parse1.cpp From Vladimir.Kozlov at Sun.COM Fri Feb 26 15:21:47 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 26 Feb 2010 15:21:47 -0800 Subject: review (S) for 6930398: fix for return address locals in OSR entries uses wrong test In-Reply-To: <9A24F498-8A25-40E2-AAFC-835BE226D6C7@Sun.COM> References: <9A24F498-8A25-40E2-AAFC-835BE226D6C7@Sun.COM> Message-ID: <4B88578B.4000402@sun.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6930398 > > 6930398: fix for return address locals in OSR entries uses wrong test > Reviewed-by: > > The fix for 6915557 is attempting to handle locals containing return > address specially but the test it's using is wrong. C2's type system > smears together T_ADDRESS with raw pointer types, so > TypePtr::NULL_PTr->basic_type() == T_ADDRESS so the logic will trigger > for locals which are provably null resulting in asserts later. The > correct fix is to test the ciType of the local which correctly > distinguishes these cases. Tested with failing tests from nightly. > > src/share/vm/opto/parse1.cpp