From Changpeng.Fang at Sun.COM Fri May 1 11:30:52 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Fri, 01 May 2009 11:30:52 -0700 Subject: Request for review (S): 6833879 Assigning positive zero is ignored when old value is negative zero In-Reply-To: References: <49F8958D.8050709@Sun.COM> Message-ID: <49FB3FDC.5010207@Sun.COM> http://cr.openjdk.java.net/~cfang/6833879/webrev.01/ I have updated the fix to disable the identity optimization for all floating point comparison (i.e., is_cmove_id always returns NULL for flaot and double). Thanks, Changpeng On 04/29/09 12:32, Tom Rodriguez wrote: > BTW, you can use TypeF::ZERO and TypeD::ZERO to check for positive > zero constants instead of breaking them down, as in phase->type(f) == > TypeF::ZERO. I don't think this fix is sufficient. It has the same > problem for "if (v == -0.0f) v == -0.0f" and as you said originally it > won't work right dynamically either. > > tom > > On Apr 29, 2009, at 10:59 AM, Changpeng Fang wrote: > >> http://cr.openjdk.java.net/~cfang/6833879/webrev.00/ >> >> Problem: >> For the following case: >> public static double normalize(float v) { >> if (v == 0.0f) v = 0.0f; >> return v; >> } >> If -0.0 is passed, 0.0 is expected to be returned (it is the case for >> the interpreter). However, >> PhiNode::Identity optimized away the "if and assignment" statement >> and the server vm >> return -0.0. >> >> Proposed Solution: >> Don't perform this kind of identity optimization if either true path >> or false path is constant >> 0.0 or (-0.0) >> >> Open Issue: >> When the true path or false path is not constant, it may still be 0.0 >> (-0.0) at run time. >> Do we have to turn off this identity optimization completely for >> float and double (except >> for constant non-zeros)? >> Tests: Passed the test case in the CR report. >> >> Thanks, >> >> Changpeng > From Christian.Thalinger at Sun.COM Mon May 4 13:08:49 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 04 May 2009 22:08:49 +0200 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <1240729080.3340.1.camel@macbook> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> Message-ID: <1241467729.27789.63.camel@macbook> Here is the third version of the patch: http://cr.openjdk.java.net/~twisti/6823354/webrev.03/ This version includes all suggested changes from Vladimir and changes I talked about with Tom on the phone. Additionally I enhanced the testcase. -- Christian From Thomas.Rodriguez at Sun.COM Mon May 4 13:20:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 04 May 2009 13:20:15 -0700 Subject: review (S) for 6818666: G1: Type lost in g1 pre-barrierr In-Reply-To: <49F8D5EB.5000608@sun.com> References: <49F8D5EB.5000608@sun.com> Message-ID: <6988EA7C-C743-40FE-871C-D9C844D933D1@Sun.COM> On Apr 29, 2009, at 3:34 PM, Vladimir Kozlov wrote: > In GraphKit::store_oop_to_unknown() should you also check field- > >type()->is_loaded()? You're right. It should mirror the logic in do_put_xxx in parse3.cpp. I'm going to fix that and retest. I want to exercise that logic a bit more to make sure it's working the way I think. tom > > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6818666 From Vladimir.Kozlov at Sun.COM Mon May 4 14:36:35 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 04 May 2009 14:36:35 -0700 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <1241467729.27789.63.camel@macbook> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> Message-ID: <49FF5FE3.4030404@sun.com> Christian, assembler_x86.hpp - could you use one #ifdef ? + + #ifdef _LP64 + void bsfq(Register dst, Register src); + #endif + + void bsrl(Register dst, Register src); + + #ifdef _LP64 + void bsrq(Register dst, Register src); + #endif x86_32.ad - Why you did not remove TEMP dst? Do you need it? + effect(TEMP dst connode.cpp - new Ideal methods should be Value methods since it is the value transformation and it misses checks for Top: const Type* CountLeadingZerosINode::Value( PhaseTransform *phase ) const { const Type *t = phase->type( in(1) ); if( t == Type::TOP ) return Type::TOP; const TypeInt *ti = t->isa_int(); if (ti && ti->is_con()) { Thanks, Vladimir Christian Thalinger wrote: > Here is the third version of the patch: > > http://cr.openjdk.java.net/~twisti/6823354/webrev.03/ > > This version includes all suggested changes from Vladimir and changes I > talked about with Tom on the phone. Additionally I enhanced the > testcase. > > -- Christian > From Changpeng.Fang at Sun.COM Mon May 4 14:44:15 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Mon, 04 May 2009 14:44:15 -0700 Subject: (Please) Re: Request for review (S): 6833879 Assigning positive zero is ignored when old value is negative zero In-Reply-To: <49FB3FDC.5010207@Sun.COM> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> Message-ID: <49FF61AF.4090300@Sun.COM> On 05/01/09 11:30, Changpeng Fang wrote: http://cr.openjdk.java.net/~cfang/6833879/webrev.01/ > > I have updated the fix to disable the identity optimization for all > floating point > comparison (i.e., is_cmove_id always returns NULL for flaot and > double). > > Thanks, Changpeng > Thanks, > > Changpeng > > > > On 04/29/09 12:32, Tom Rodriguez wrote: >> BTW, you can use TypeF::ZERO and TypeD::ZERO to check for positive >> zero constants instead of breaking them down, as in phase->type(f) == >> TypeF::ZERO. I don't think this fix is sufficient. It has the same >> problem for "if (v == -0.0f) v == -0.0f" and as you said originally >> it won't work right dynamically either. >> >> tom >> >> On Apr 29, 2009, at 10:59 AM, Changpeng Fang wrote: >> >>> http://cr.openjdk.java.net/~cfang/6833879/webrev.00/ >>> >>> Problem: >>> For the following case: >>> public static double normalize(float v) { >>> if (v == 0.0f) v = 0.0f; >>> return v; >>> } >>> If -0.0 is passed, 0.0 is expected to be returned (it is the case >>> for the interpreter). However, >>> PhiNode::Identity optimized away the "if and assignment" statement >>> and the server vm >>> return -0.0. >>> >>> Proposed Solution: >>> Don't perform this kind of identity optimization if either true path >>> or false path is constant >>> 0.0 or (-0.0) >>> >>> Open Issue: >>> When the true path or false path is not constant, it may still be >>> 0.0 (-0.0) at run time. >>> Do we have to turn off this identity optimization completely for >>> float and double (except >>> for constant non-zeros)? >>> Tests: Passed the test case in the CR report. >>> >>> Thanks, >>> >>> Changpeng >> > > From Changpeng.Fang at Sun.COM Mon May 4 15:05:16 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Mon, 04 May 2009 15:05:16 -0700 Subject: Request for review (XS): 6837146 Should perform unswitch before maximally unroll in loop transformation In-Reply-To: <49FF61AF.4090300@Sun.COM> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> <49FF61AF.4090300@Sun.COM> Message-ID: <49FF669C.6060302@Sun.COM> http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ Summary: Change the ordering of do_unswitch and do_maximally_unroll in loop transformation. Thanks, Changpeng From Changpeng.Fang at Sun.COM Mon May 4 15:49:10 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Mon, 04 May 2009 15:49:10 -0700 Subject: (Resend with description) Re: Request for review (XS): 6837146 Should perform unswitch before maximally unroll in loop transformation In-Reply-To: <49FF669C.6060302@Sun.COM> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> <49FF61AF.4090300@Sun.COM> <49FF669C.6060302@Sun.COM> Message-ID: <49FF70E6.7010906@Sun.COM> http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ Problem Summary: The concern is the ordering of maximally unroll and unswitch of a loop in loop transformation. Current implementation is that maximally unroll is performed before loop unswitch. The problem is if a loop is maximally unrolled (fully unrolled), it will never be unswitched. This will leave many conditional statements (blocks) in the code which should not appear if the loop can be unswitched. Proposed Solution: Change the ordering of unswitch and maximally_unroll in loop transformation. After unswitch, the loop should still be able to be maximally unrolled. Thanks, Changpeng On 05/04/09 15:05, Changpeng Fang wrote: > http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ > > Summary: Change the ordering of do_unswitch and do_maximally_unroll in > loop transformation. > > Thanks, > > Changpeng > From Thomas.Rodriguez at Sun.COM Mon May 4 16:23:27 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 04 May 2009 16:23:27 -0700 Subject: (Please) Re: Request for review (S): 6833879 Assigning positive zero is ignored when old value is negative zero In-Reply-To: <49FF61AF.4090300@Sun.COM> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> <49FF61AF.4090300@Sun.COM> Message-ID: <589B06B4-53F7-4DD1-9513-5439AF7947FC@sun.com> It feels a bit extreme but I don't see how we can ignore that it produces the wrong result dynamically. tom On May 4, 2009, at 2:44 PM, Changpeng Fang wrote: > On 05/01/09 11:30, Changpeng Fang wrote: > > http://cr.openjdk.java.net/~cfang/6833879/webrev.01/ >> >> I have updated the fix to disable the identity optimization for all >> floating point >> comparison (i.e., is_cmove_id always returns NULL for flaot and >> double). >> >> > > Thanks, > > Changpeng > > >> Thanks, >> >> Changpeng >> >> >> >> On 04/29/09 12:32, Tom Rodriguez wrote: >>> BTW, you can use TypeF::ZERO and TypeD::ZERO to check for positive >>> zero constants instead of breaking them down, as in phase->type(f) >>> == TypeF::ZERO. I don't think this fix is sufficient. It has the >>> same problem for "if (v == -0.0f) v == -0.0f" and as you said >>> originally it won't work right dynamically either. >>> >>> tom >>> >>> On Apr 29, 2009, at 10:59 AM, Changpeng Fang wrote: >>> >>>> http://cr.openjdk.java.net/~cfang/6833879/webrev.00/ >>>> >>>> Problem: >>>> For the following case: >>>> public static double normalize(float v) { >>>> if (v == 0.0f) v = 0.0f; >>>> return v; >>>> } >>>> If -0.0 is passed, 0.0 is expected to be returned (it is the case >>>> for the interpreter). However, >>>> PhiNode::Identity optimized away the "if and assignment" >>>> statement and the server vm >>>> return -0.0. >>>> >>>> Proposed Solution: >>>> Don't perform this kind of identity optimization if either true >>>> path or false path is constant >>>> 0.0 or (-0.0) >>>> >>>> Open Issue: >>>> When the true path or false path is not constant, it may still be >>>> 0.0 (-0.0) at run time. >>>> Do we have to turn off this identity optimization completely for >>>> float and double (except >>>> for constant non-zeros)? >>>> Tests: Passed the test case in the CR report. >>>> >>>> Thanks, >>>> >>>> Changpeng >>> >> >> > From Thomas.Rodriguez at Sun.COM Mon May 4 16:33:36 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 04 May 2009 16:33:36 -0700 Subject: (Please) Re: Request for review (S): 6833879 Assigning positive zero is ignored when old value is negative zero In-Reply-To: <589B06B4-53F7-4DD1-9513-5439AF7947FC@sun.com> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> <49FF61AF.4090300@Sun.COM> <589B06B4-53F7-4DD1-9513-5439AF7947FC@sun.com> Message-ID: <3C42D6DB-BA60-41C7-B884-EE5241DF65EA@sun.com> Actually we can allow this transformation when the value being tested is any constant besides 0.0, right? tom On May 4, 2009, at 4:23 PM, Tom Rodriguez wrote: > It feels a bit extreme but I don't see how we can ignore that it > produces the wrong result dynamically. > > tom > > On May 4, 2009, at 2:44 PM, Changpeng Fang wrote: > >> On 05/01/09 11:30, Changpeng Fang wrote: >> >> http://cr.openjdk.java.net/~cfang/6833879/webrev.01/ >>> >>> I have updated the fix to disable the identity optimization for >>> all floating point >>> comparison (i.e., is_cmove_id always returns NULL for flaot and >>> double). >>> >>> >> >> Thanks, >> >> Changpeng >> >> >>> Thanks, >>> >>> Changpeng >>> >>> >>> >>> On 04/29/09 12:32, Tom Rodriguez wrote: >>>> BTW, you can use TypeF::ZERO and TypeD::ZERO to check for >>>> positive zero constants instead of breaking them down, as in >>>> phase->type(f) == TypeF::ZERO. I don't think this fix is >>>> sufficient. It has the same problem for "if (v == -0.0f) v == >>>> -0.0f" and as you said originally it won't work right dynamically >>>> either. >>>> >>>> tom >>>> >>>> On Apr 29, 2009, at 10:59 AM, Changpeng Fang wrote: >>>> >>>>> http://cr.openjdk.java.net/~cfang/6833879/webrev.00/ >>>>> >>>>> Problem: >>>>> For the following case: >>>>> public static double normalize(float v) { >>>>> if (v == 0.0f) v = 0.0f; >>>>> return v; >>>>> } >>>>> If -0.0 is passed, 0.0 is expected to be returned (it is the >>>>> case for the interpreter). However, >>>>> PhiNode::Identity optimized away the "if and assignment" >>>>> statement and the server vm >>>>> return -0.0. >>>>> >>>>> Proposed Solution: >>>>> Don't perform this kind of identity optimization if either true >>>>> path or false path is constant >>>>> 0.0 or (-0.0) >>>>> >>>>> Open Issue: >>>>> When the true path or false path is not constant, it may still >>>>> be 0.0 (-0.0) at run time. >>>>> Do we have to turn off this identity optimization completely >>>>> for float and double (except >>>>> for constant non-zeros)? >>>>> Tests: Passed the test case in the CR report. >>>>> >>>>> Thanks, >>>>> >>>>> Changpeng >>>> >>> >>> >> > From Thomas.Rodriguez at Sun.COM Mon May 4 16:34:50 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 04 May 2009 16:34:50 -0700 Subject: (Resend with description) Re: Request for review (XS): 6837146 Should perform unswitch before maximally unroll in loop transformation In-Reply-To: <49FF70E6.7010906@Sun.COM> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> <49FF61AF.4090300@Sun.COM> <49FF669C.6060302@Sun.COM> <49FF70E6.7010906@Sun.COM> Message-ID: <018DFCE4-378E-4267-98C7-AF8AC2E2B84E@sun.com> This seems ok. Was there an example that motivated this change? tom On May 4, 2009, at 3:49 PM, Changpeng Fang wrote: > http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ > > Problem Summary: > The concern is the ordering of maximally unroll and unswitch of a > loop in loop transformation. > Current implementation is that maximally unroll is performed before > loop unswitch. The problem > is if a loop is maximally unrolled (fully unrolled), it will never > be unswitched. This will leave > many conditional statements (blocks) in the code which should not > appear if the loop can be > unswitched. > > Proposed Solution: > Change the ordering of unswitch and maximally_unroll in loop > transformation. After unswitch, > the loop should still be able to be maximally unrolled. > > Thanks, > > Changpeng > > > > On 05/04/09 15:05, Changpeng Fang wrote: >> http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ >> >> Summary: Change the ordering of do_unswitch and do_maximally_unroll >> in loop transformation. >> >> Thanks, >> >> Changpeng >> > From Changpeng.Fang at Sun.COM Mon May 4 16:42:17 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Mon, 04 May 2009 16:42:17 -0700 Subject: (Please) Re: Request for review (S): 6833879 Assigning positive zero is ignored when old value is negative zero In-Reply-To: <3C42D6DB-BA60-41C7-B884-EE5241DF65EA@sun.com> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> <49FF61AF.4090300@Sun.COM> <589B06B4-53F7-4DD1-9513-5439AF7947FC@sun.com> <3C42D6DB-BA60-41C7-B884-EE5241DF65EA@sun.com> Message-ID: <49FF7D59.4030808@Sun.COM> On 05/04/09 16:33, Tom Rodriguez wrote: > Actually we can allow this transformation when the value being tested > is any constant besides 0.0, right? > I think for floating point, the cases that t==f?t:f is very limited so, disabling this identity optimization would have limited performance impact for java programs. And this is also the reason we don't bother to recognize the non-zero constant cases. Thanks, Changpeng > tom > > On May 4, 2009, at 4:23 PM, Tom Rodriguez wrote: > >> It feels a bit extreme but I don't see how we can ignore that it >> produces the wrong result dynamically. >> >> tom >> >> On May 4, 2009, at 2:44 PM, Changpeng Fang wrote: >> >>> On 05/01/09 11:30, Changpeng Fang wrote: >>> >>> http://cr.openjdk.java.net/~cfang/6833879/webrev.01/ >>>> >>>> I have updated the fix to disable the identity optimization for all >>>> floating point >>>> comparison (i.e., is_cmove_id always returns NULL for flaot and >>>> double). >>>> >>>> >>> >>> Thanks, >>> >>> Changpeng >>> >>> >>>> Thanks, >>>> >>>> Changpeng >>>> >>>> >>>> >>>> On 04/29/09 12:32, Tom Rodriguez wrote: >>>>> BTW, you can use TypeF::ZERO and TypeD::ZERO to check for positive >>>>> zero constants instead of breaking them down, as in phase->type(f) >>>>> == TypeF::ZERO. I don't think this fix is sufficient. It has the >>>>> same problem for "if (v == -0.0f) v == -0.0f" and as you said >>>>> originally it won't work right dynamically either. >>>>> >>>>> tom >>>>> >>>>> On Apr 29, 2009, at 10:59 AM, Changpeng Fang wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~cfang/6833879/webrev.00/ >>>>>> >>>>>> Problem: >>>>>> For the following case: >>>>>> public static double normalize(float v) { >>>>>> if (v == 0.0f) v = 0.0f; >>>>>> return v; >>>>>> } >>>>>> If -0.0 is passed, 0.0 is expected to be returned (it is the case >>>>>> for the interpreter). However, >>>>>> PhiNode::Identity optimized away the "if and assignment" >>>>>> statement and the server vm >>>>>> return -0.0. >>>>>> >>>>>> Proposed Solution: >>>>>> Don't perform this kind of identity optimization if either true >>>>>> path or false path is constant >>>>>> 0.0 or (-0.0) >>>>>> >>>>>> Open Issue: >>>>>> When the true path or false path is not constant, it may still be >>>>>> 0.0 (-0.0) at run time. >>>>>> Do we have to turn off this identity optimization completely for >>>>>> float and double (except >>>>>> for constant non-zeros)? >>>>>> Tests: Passed the test case in the CR report. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Changpeng >>>>> >>>> >>>> >>> >> > From Thomas.Rodriguez at Sun.COM Mon May 4 16:44:32 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 04 May 2009 16:44:32 -0700 Subject: (Please) Re: Request for review (S): 6833879 Assigning positive zero is ignored when old value is negative zero In-Reply-To: <49FF7D59.4030808@Sun.COM> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> <49FF61AF.4090300@Sun.COM> <589B06B4-53F7-4DD1-9513-5439AF7947FC@sun.com> <3C42D6DB-BA60-41C7-B884-EE5241DF65EA@sun.com> <49FF7D59.4030808@Sun.COM> Message-ID: ok by me. tom On May 4, 2009, at 4:42 PM, Changpeng Fang wrote: > On 05/04/09 16:33, Tom Rodriguez wrote: >> Actually we can allow this transformation when the value being >> tested is any constant besides 0.0, right? >> > I think for floating point, the cases that t==f?t:f is very limited > so, disabling this identity optimization would have limited > performance impact > for java programs. And this is also the reason we > don't bother to recognize the non-zero constant cases. > > Thanks, > > Changpeng > > > >> tom >> >> On May 4, 2009, at 4:23 PM, Tom Rodriguez wrote: >> >>> It feels a bit extreme but I don't see how we can ignore that it >>> produces the wrong result dynamically. >>> >>> tom >>> >>> On May 4, 2009, at 2:44 PM, Changpeng Fang wrote: >>> >>>> On 05/01/09 11:30, Changpeng Fang wrote: >>>> >>>> http://cr.openjdk.java.net/~cfang/6833879/webrev.01/ >>>>> >>>>> I have updated the fix to disable the identity optimization for >>>>> all floating point >>>>> comparison (i.e., is_cmove_id always returns NULL for flaot >>>>> and double). >>>>> >>>>> >>>> >>>> Thanks, >>>> >>>> Changpeng >>>> >>>> >>>>> Thanks, >>>>> >>>>> Changpeng >>>>> >>>>> >>>>> >>>>> On 04/29/09 12:32, Tom Rodriguez wrote: >>>>>> BTW, you can use TypeF::ZERO and TypeD::ZERO to check for >>>>>> positive zero constants instead of breaking them down, as in >>>>>> phase->type(f) == TypeF::ZERO. I don't think this fix is >>>>>> sufficient. It has the same problem for "if (v == -0.0f) v == >>>>>> -0.0f" and as you said originally it won't work right >>>>>> dynamically either. >>>>>> >>>>>> tom >>>>>> >>>>>> On Apr 29, 2009, at 10:59 AM, Changpeng Fang wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~cfang/6833879/webrev.00/ >>>>>>> >>>>>>> Problem: >>>>>>> For the following case: >>>>>>> public static double normalize(float v) { >>>>>>> if (v == 0.0f) v = 0.0f; >>>>>>> return v; >>>>>>> } >>>>>>> If -0.0 is passed, 0.0 is expected to be returned (it is the >>>>>>> case for the interpreter). However, >>>>>>> PhiNode::Identity optimized away the "if and assignment" >>>>>>> statement and the server vm >>>>>>> return -0.0. >>>>>>> >>>>>>> Proposed Solution: >>>>>>> Don't perform this kind of identity optimization if either >>>>>>> true path or false path is constant >>>>>>> 0.0 or (-0.0) >>>>>>> >>>>>>> Open Issue: >>>>>>> When the true path or false path is not constant, it may still >>>>>>> be 0.0 (-0.0) at run time. >>>>>>> Do we have to turn off this identity optimization completely >>>>>>> for float and double (except >>>>>>> for constant non-zeros)? >>>>>>> Tests: Passed the test case in the CR report. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Changpeng >>>>>> >>>>> >>>>> >>>> >>> >> > From thomas.rodriguez at sun.com Tue May 5 00:32:53 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Tue, 05 May 2009 07:32:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6837224: libsaproc.so on linux needs version of 6799141 Message-ID: <20090505073302.421EBEF0E@hg.openjdk.java.net> Changeset: 2b25645dab33 Author: never Date: 2009-05-04 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2b25645dab33 6837224: libsaproc.so on linux needs version of 6799141 Reviewed-by: kvn ! agent/src/os/linux/Makefile From Christian.Thalinger at Sun.COM Tue May 5 01:57:55 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 05 May 2009 10:57:55 +0200 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <49FF5FE3.4030404@sun.com> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> <49FF5FE3.4030404@sun.com> Message-ID: <1241513876.27789.120.camel@macbook> On Mon, 2009-05-04 at 14:36 -0700, Vladimir Kozlov wrote: > Christian, > > assembler_x86.hpp - could you use one #ifdef ? > > + > + #ifdef _LP64 > + void bsfq(Register dst, Register src); > + #endif > + > + void bsrl(Register dst, Register src); > + > + #ifdef _LP64 > + void bsrq(Register dst, Register src); > + #endif Sure. I just followed the style in the file, where all methods are strictly ordered. > x86_32.ad - Why you did not remove TEMP dst? Do you need it? > > + effect(TEMP dst I think I kept it because I'm not sure if one register of a long register pair can be the same as the dst register. Can it? > connode.cpp - new Ideal methods should be Value methods since > it is the value transformation and it misses checks for Top: > > const Type* CountLeadingZerosINode::Value( PhaseTransform *phase ) const { > const Type *t = phase->type( in(1) ); > if( t == Type::TOP ) return Type::TOP; > const TypeInt *ti = t->isa_int(); > if (ti && ti->is_con()) { I see. I'm currently trying to change that but I have some problems. Could you explain a little how Value() is supposed to work? -- Christian From Vladimir.Kozlov at Sun.COM Tue May 5 08:38:48 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 05 May 2009 08:38:48 -0700 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <1241513876.27789.120.camel@macbook> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> <49FF5FE3.4030404@sun.com> <1241513876.27789.120.camel@macbook> Message-ID: <4A005D88.8070107@sun.com> Christian Thalinger wrote: >> x86_32.ad - Why you did not remove TEMP dst? Do you need it? >> >> + effect(TEMP dst > > I think I kept it because I'm not sure if one register of a long > register pair can be the same as the dst register. Can it? Yes, you are right, it is needed. > >> connode.cpp - new Ideal methods should be Value methods since >> it is the value transformation and it misses checks for Top: >> >> const Type* CountLeadingZerosINode::Value( PhaseTransform *phase ) const { >> const Type *t = phase->type( in(1) ); >> if( t == Type::TOP ) return Type::TOP; >> const TypeInt *ti = t->isa_int(); >> if (ti && ti->is_con()) { > > I see. I'm currently trying to change that but I have some problems. > Could you explain a little how Value() is supposed to work? What problems do you have? Look on, for example, ConvL2INode::Value(). And your code: const Type* CountLeadingZerosINode::Value( PhaseTransform *phase ) const { const Type *t = phase->type( in(1) ); if( t == Type::TOP ) return Type::TOP; const TypeInt *ti = t->isa_int(); if (ti && ti->is_con()) { jint i = ti->get_con(); // HD, Figure 5-6 if (i == 0) return TypeInt::make(BitsPerInt); jint n = 1; unsigned int x = i; if (x >> 16 == 0) { n += 16; x <<= 16; } if (x >> 24 == 0) { n += 8; x <<= 8; } if (x >> 28 == 0) { n += 4; x <<= 4; } if (x >> 30 == 0) { n += 2; x <<= 2; } n -= x >> 31; return TypeInt::make(n); } return bottom_type(); } Vladimir From Christian.Thalinger at Sun.COM Tue May 5 08:42:11 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 05 May 2009 17:42:11 +0200 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <4A005D88.8070107@sun.com> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> <49FF5FE3.4030404@sun.com> <1241513876.27789.120.camel@macbook> <4A005D88.8070107@sun.com> Message-ID: <1241538132.9518.4.camel@macbook> On Tue, 2009-05-05 at 08:38 -0700, Vladimir Kozlov wrote: > What problems do you have? > Look on, for example, ConvL2INode::Value(). And your code: > > const Type* CountLeadingZerosINode::Value( PhaseTransform *phase ) const { > const Type *t = phase->type( in(1) ); > if( t == Type::TOP ) return Type::TOP; > const TypeInt *ti = t->isa_int(); > if (ti && ti->is_con()) { > jint i = ti->get_con(); > // HD, Figure 5-6 > if (i == 0) > return TypeInt::make(BitsPerInt); > jint n = 1; > unsigned int x = i; > if (x >> 16 == 0) { n += 16; x <<= 16; } > if (x >> 24 == 0) { n += 8; x <<= 8; } > if (x >> 28 == 0) { n += 4; x <<= 4; } > if (x >> 30 == 0) { n += 2; x <<= 2; } > n -= x >> 31; > return TypeInt::make(n); > } > return bottom_type(); > } My current version returns TypeInt::INT if it's not a constant. Is that correct? And if not, what's the difference between bottom_type() and TypeInt::INT in this case? -- Christian From Vladimir.Kozlov at Sun.COM Tue May 5 09:10:57 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 05 May 2009 09:10:57 -0700 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <1241538132.9518.4.camel@macbook> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> <49FF5FE3.4030404@sun.com> <1241513876.27789.120.camel@macbook> <4A005D88.8070107@sun.com> <1241538132.9518.4.camel@macbook> Message-ID: <4A006511.4010706@sun.com> It is the same since bottom_type() returns TypeInt::INT: + class CountBitsNode : public Node { + public: + CountBitsNode(Node* in1) : Node(0, in1) {} + const Type* bottom_type() const { return TypeInt::INT; } Vladimir Christian Thalinger wrote: >> return bottom_type(); >> } > > My current version returns TypeInt::INT if it's not a constant. Is that > correct? And if not, what's the difference between bottom_type() and > TypeInt::INT in this case? > > -- Christian > From Christian.Thalinger at Sun.COM Tue May 5 09:15:25 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 05 May 2009 18:15:25 +0200 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <4A006511.4010706@sun.com> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> <49FF5FE3.4030404@sun.com> <1241513876.27789.120.camel@macbook> <4A005D88.8070107@sun.com> <1241538132.9518.4.camel@macbook> <4A006511.4010706@sun.com> Message-ID: <1241540126.9518.5.camel@macbook> On Tue, 2009-05-05 at 09:10 -0700, Vladimir Kozlov wrote: > It is the same since bottom_type() returns TypeInt::INT: > > + class CountBitsNode : public Node { > + public: > + CountBitsNode(Node* in1) : Node(0, in1) {} > + const Type* bottom_type() const { return TypeInt::INT; } Right, sorry. Then I will use bottom_type(). -- Christian From Changpeng.Fang at Sun.COM Tue May 5 11:23:51 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Tue, 05 May 2009 11:23:51 -0700 Subject: (Resend with description) Re: Request for review (XS): 6837146 Should perform unswitch before maximally unroll in loop transformation In-Reply-To: <018DFCE4-378E-4267-98C7-AF8AC2E2B84E@sun.com> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> <49FF61AF.4090300@Sun.COM> <49FF669C.6060302@Sun.COM> <49FF70E6.7010906@Sun.COM> <018DFCE4-378E-4267-98C7-AF8AC2E2B84E@sun.com> Message-ID: <4A008437.3000005@Sun.COM> On 05/04/09 16:34, Tom Rodriguez wrote: > This seems ok. Was there an example that motivated this change? > For the following Test1.java with -XX:CompileOnly=Test1.init, you should see the loop is not unswitched. However, I could not observe perform difference with my proposed change even though the loop is unswitched after the change. Thanks, Changpeng class Test1 { public static void init(int src[], int dst[], int unknown) { // initialize the arrays for (int i =0; i<4; i++) { dst[i] = i; if(unknown >= 5) src[i] = i; } } public static void test() { int[] src = new int[4]; int[] dst = new int[4]; init(src, dst, 5); } public static void main(String[] args) { long start = System.currentTimeMillis(); for (int i=0; i< 2000000; i++) { test(); } long end = System.currentTimeMillis(); System.out.println(end-start); } } > On May 4, 2009, at 3:49 PM, Changpeng Fang wrote: > >> http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ >> >> Problem Summary: >> The concern is the ordering of maximally unroll and unswitch of a >> loop in loop transformation. >> Current implementation is that maximally unroll is performed before >> loop unswitch. The problem >> is if a loop is maximally unrolled (fully unrolled), it will never be >> unswitched. This will leave >> many conditional statements (blocks) in the code which should not >> appear if the loop can be >> unswitched. >> >> Proposed Solution: >> Change the ordering of unswitch and maximally_unroll in loop >> transformation. After unswitch, >> the loop should still be able to be maximally unrolled. >> >> Thanks, >> >> Changpeng >> >> >> >> On 05/04/09 15:05, Changpeng Fang wrote: >>> http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ >>> >>> Summary: Change the ordering of do_unswitch and do_maximally_unroll >>> in loop transformation. >>> >>> Thanks, >>> >>> Changpeng >>> >> > From Thomas.Rodriguez at Sun.COM Tue May 5 11:28:16 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 05 May 2009 11:28:16 -0700 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <1241540126.9518.5.camel@macbook> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> <49FF5FE3.4030404@sun.com> <1241513876.27789.120.camel@macbook> <4A005D88.8070107@sun.com> <1241538132.9518.4.camel@macbook> <4A006511.4010706@sun.com> <1241540126.9518.5.camel@macbook> Message-ID: I think returning TypeInt::INT directly would be preferred. bottom_type() is always virtual and you have to look elsewhere to see what it returns. tom On May 5, 2009, at 9:15 AM, Christian Thalinger wrote: > On Tue, 2009-05-05 at 09:10 -0700, Vladimir Kozlov wrote: >> It is the same since bottom_type() returns TypeInt::INT: >> >> + class CountBitsNode : public Node { >> + public: >> + CountBitsNode(Node* in1) : Node(0, in1) {} >> + const Type* bottom_type() const { return TypeInt::INT; } > > Right, sorry. Then I will use bottom_type(). > > -- Christian > From Thomas.Rodriguez at Sun.COM Tue May 5 11:49:18 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 05 May 2009 11:49:18 -0700 Subject: (Resend with description) Re: Request for review (XS): 6837146 Should perform unswitch before maximally unroll in loop transformation In-Reply-To: <4A008437.3000005@Sun.COM> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> <49FF61AF.4090300@Sun.COM> <49FF669C.6060302@Sun.COM> <49FF70E6.7010906@Sun.COM> <018DFCE4-378E-4267-98C7-AF8AC2E2B84E@sun.com> <4A008437.3000005@Sun.COM> Message-ID: <91DD51E7-0967-4C2B-98A7-1C8FB08545DF@Sun.COM> I think your test case is going to be dominated by allocation since the work is so small. Don't reallocate the array each time and make the unknown into a static field. Maybe this: class Test1 { static int unknown; public static void init(int src[], int dst[]) { // initialize the arrays for (int i =0; i<4; i++) { dst[i] = i; if(unknown >= 5) src[i] = i; } } static int[] src = new int[4]; static int[] dst = new int[4]; public static void test() { init(src, dst); } public static void main(String[] args) { long start = System.currentTimeMillis(); for (int i=0; i< 2000000; i++) { test(); } long end = System.currentTimeMillis(); System.out.println(end-start); } } The opto for that is kind of interesting because we end up unswitching and unrolling the 0 to 20000000 loop and produce code like this: 0e0 B10: # B10 B11 <- B9 B10 Loop: B10-B10 inner stride: not constant main of N249 Freq: 999988 0e0 + STW #0,[R_L4 + #12] 0e4 + STW R_L1,[R_L4 + #16] 0e8 + STW R_L3,[R_L4 + #20] 0ec + STW R_G4,[R_L4 + #24] 0f0 + STW R_L1,[R_L4 + #16] 0f4 + STW R_L3,[R_L4 + #20] 0f8 + STW R_G4,[R_L4 + #24] .... Surprisingly we don't eliminate the redundant stores though I believe we have code does that. The other unswitched loop is more interesting with a similar problem: 300 B32: # B32 B33 <- B31 B32 Loop: B32-B32 inner stride: not constant main of N220 Freq: 0.476827 300 + STW #0,[R_L4 + #12] 304 + STW #0,[R_L7 + #12] 308 + STW R_L1,[R_L4 + #16] 30c + STW R_L1,[R_L7 + #16] 310 + STW R_L3,[R_L4 + #20] 314 + STW R_L3,[R_L7 + #20] 318 + STW R_G4,[R_L4 + #24] 31c + STW R_G4,[R_L7 + #24] 320 + STW #0,[R_L4 + #12] 324 + STW #0,[R_L7 + #12] 328 + STW R_L1,[R_L4 + #16] 32c + STW R_L1,[R_L7 + #16] 330 + STW R_L3,[R_L4 + #20] 334 + STW R_L3,[R_L7 + #20] 338 + STW R_G4,[R_L4 + #24] 33c + STW R_G4,[R_L7 + #24] We can't know that L4 and L7 point to different objects but since we're storing the same value we could in fact eliminate the later stores. Neither of these pieces of code are that representative I think but they it's surprising we do badly on them. I think the version of you test below might give you measurable results. class Test1 { static int unknown; public static void init(int src[], int dst[]) { // initialize the arrays for (int i =0; i<4; i++) { dst[i] = i; if(unknown >= 5) src[i] = i; } } static int[] src = new int[4]; static int[] dst = new int[4]; public static void test() { init(src, dst); } public static void main(String[] args) { long start = System.currentTimeMillis(); for (int i=0; i< 2000000; i++) { unknown = i % 10; test(); } long end = System.currentTimeMillis(); System.out.println(end-start); } } tom On May 5, 2009, at 11:23 AM, Changpeng Fang wrote: > > On 05/04/09 16:34, Tom Rodriguez wrote: >> This seems ok. Was there an example that motivated this change? >> > For the following Test1.java with -XX:CompileOnly=Test1.init, you > should see > the loop is not unswitched. However, I could not observe perform > difference > with my proposed change even though the loop is unswitched after the > change. > > Thanks, > > Changpeng > > class Test1 { > > public static void init(int src[], int dst[], int unknown) { > // initialize the arrays > for (int i =0; i<4; i++) { > dst[i] = i; > if(unknown >= 5) > src[i] = i; } > } > > public static void test() { > int[] src = new int[4]; > int[] dst = new int[4]; > > init(src, dst, 5); > } > > public static void main(String[] args) { > long start = System.currentTimeMillis(); > for (int i=0; i< 2000000; i++) { > test(); > } > long end = System.currentTimeMillis(); > System.out.println(end-start); > } > } > > > > > > > > >> On May 4, 2009, at 3:49 PM, Changpeng Fang wrote: >> >>> http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ >>> >>> Problem Summary: >>> The concern is the ordering of maximally unroll and unswitch of a >>> loop in loop transformation. >>> Current implementation is that maximally unroll is performed >>> before loop unswitch. The problem >>> is if a loop is maximally unrolled (fully unrolled), it will never >>> be unswitched. This will leave >>> many conditional statements (blocks) in the code which should not >>> appear if the loop can be >>> unswitched. >>> >>> Proposed Solution: >>> Change the ordering of unswitch and maximally_unroll in loop >>> transformation. After unswitch, >>> the loop should still be able to be maximally unrolled. >>> >>> Thanks, >>> >>> Changpeng >>> >>> >>> >>> On 05/04/09 15:05, Changpeng Fang wrote: >>>> http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ >>>> >>>> Summary: Change the ordering of do_unswitch and >>>> do_maximally_unroll in loop transformation. >>>> >>>> Thanks, >>>> >>>> Changpeng >>>> >>> >> > From Christian.Thalinger at Sun.COM Tue May 5 12:17:43 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 05 May 2009 21:17:43 +0200 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> <49FF5FE3.4030404@sun.com> <1241513876.27789.120.camel@macbook> <4A005D88.8070107@sun.com> <1241538132.9518.4.camel@macbook> <4A006511.4010706@sun.com> <1241540126.9518.5.camel@macbook> Message-ID: <1241551064.9518.58.camel@macbook> On Tue, 2009-05-05 at 11:28 -0700, Tom Rodriguez wrote: > I think returning TypeInt::INT directly would be preferred. > bottom_type() is always virtual and you have to look elsewhere to see > what it returns. Sounds reasonable. Here is a new version of the patch: http://cr.openjdk.java.net/~twisti/6823354/webrev.04/ -- Christian From Vladimir.Kozlov at Sun.COM Tue May 5 12:23:50 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 05 May 2009 12:23:50 -0700 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <1241551064.9518.58.camel@macbook> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> <49FF5FE3.4030404@sun.com> <1241513876.27789.120.camel@macbook> <4A005D88.8070107@sun.com> <1241538132.9518.4.camel@macbook> <4A006511.4010706@sun.com> <1241540126.9518.5.camel@macbook> <1241551064.9518.58.camel@macbook> Message-ID: <4A009246.2030900@sun.com> Looks good. Did you rerun your test? Thanks, Vladimir Christian Thalinger wrote: > On Tue, 2009-05-05 at 11:28 -0700, Tom Rodriguez wrote: >> I think returning TypeInt::INT directly would be preferred. >> bottom_type() is always virtual and you have to look elsewhere to see >> what it returns. > > Sounds reasonable. Here is a new version of the patch: > > http://cr.openjdk.java.net/~twisti/6823354/webrev.04/ > > -- Christian > From Changpeng.Fang at Sun.COM Tue May 5 12:29:06 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Tue, 05 May 2009 12:29:06 -0700 Subject: (Resend with description) Re: Request for review (XS): 6837146 Should perform unswitch before maximally unroll in loop transformation In-Reply-To: <91DD51E7-0967-4C2B-98A7-1C8FB08545DF@Sun.COM> References: <49F8958D.8050709@Sun.COM> <49FB3FDC.5010207@Sun.COM> <49FF61AF.4090300@Sun.COM> <49FF669C.6060302@Sun.COM> <49FF70E6.7010906@Sun.COM> <018DFCE4-378E-4267-98C7-AF8AC2E2B84E@sun.com> <4A008437.3000005@Sun.COM> <91DD51E7-0967-4C2B-98A7-1C8FB08545DF@Sun.COM> Message-ID: <4A009382.8090405@Sun.COM> With the modified version of Test1, I saw a 3% improvement on x86 with my change. While the improvement itself is not impressive, I am just thinking the logic should be that unswitch should be performed before fully unroll. I remember that we can not eliminate redundant store if someone else uses the memory state of the first store. However, sometime, that memory state usage is not real use, it is just created during unrolling (the actual usage should be the Phi Node). I have an initial idea to detect such wrong memory state usage by dependence analysis, but I am afraid this will schedule most loads to the beginning of the loop in some case. Thanks, Changpeng On 05/05/09 11:49, Tom Rodriguez wrote: > I think your test case is going to be dominated by allocation since > the work is so small. Don't reallocate the array each time and make > the unknown into a static field. Maybe this: > > class Test1 { > > static int unknown; > > public static void init(int src[], int dst[]) { > // initialize the arrays > for (int i =0; i<4; i++) { > dst[i] = i; > if(unknown >= 5) > src[i] = i; } > } > > static int[] src = new int[4]; > static int[] dst = new int[4]; > > public static void test() { > init(src, dst); > } > > public static void main(String[] args) { > long start = System.currentTimeMillis(); > for (int i=0; i< 2000000; i++) { > test(); > } > long end = System.currentTimeMillis(); > System.out.println(end-start); > } > } > > The opto for that is kind of interesting because we end up unswitching > and unrolling the 0 to 20000000 loop and produce code like this: > > 0e0 B10: # B10 B11 <- B9 B10 Loop: B10-B10 inner stride: > not constant main of N249 Freq: 999988 > 0e0 + STW #0,[R_L4 + #12] > 0e4 + STW R_L1,[R_L4 + #16] > 0e8 + STW R_L3,[R_L4 + #20] > 0ec + STW R_G4,[R_L4 + #24] > 0f0 + STW R_L1,[R_L4 + #16] > 0f4 + STW R_L3,[R_L4 + #20] > 0f8 + STW R_G4,[R_L4 + #24] > .... > > Surprisingly we don't eliminate the redundant stores though I believe > we have code does that. The other unswitched loop is more interesting > with a similar problem: > > 300 B32: # B32 B33 <- B31 B32 Loop: B32-B32 inner stride: > not constant main of N220 Freq: 0.476827 > 300 + STW #0,[R_L4 + #12] > 304 + STW #0,[R_L7 + #12] > 308 + STW R_L1,[R_L4 + #16] > 30c + STW R_L1,[R_L7 + #16] > 310 + STW R_L3,[R_L4 + #20] > 314 + STW R_L3,[R_L7 + #20] > 318 + STW R_G4,[R_L4 + #24] > 31c + STW R_G4,[R_L7 + #24] > 320 + STW #0,[R_L4 + #12] > 324 + STW #0,[R_L7 + #12] > 328 + STW R_L1,[R_L4 + #16] > 32c + STW R_L1,[R_L7 + #16] > 330 + STW R_L3,[R_L4 + #20] > 334 + STW R_L3,[R_L7 + #20] > 338 + STW R_G4,[R_L4 + #24] > 33c + STW R_G4,[R_L7 + #24] > > We can't know that L4 and L7 point to different objects but since > we're storing the same value we could in fact eliminate the later > stores. Neither of these pieces of code are that representative I > think but they it's surprising we do badly on them. > > I think the version of you test below might give you measurable results. > > class Test1 { > > static int unknown; > > public static void init(int src[], int dst[]) { > // initialize the arrays > for (int i =0; i<4; i++) { > dst[i] = i; > if(unknown >= 5) > src[i] = i; } > } > > static int[] src = new int[4]; > static int[] dst = new int[4]; > > public static void test() { > init(src, dst); > } > > public static void main(String[] args) { > long start = System.currentTimeMillis(); > for (int i=0; i< 2000000; i++) { > unknown = i % 10; > test(); > } > long end = System.currentTimeMillis(); > System.out.println(end-start); > } > } > > tom > > On May 5, 2009, at 11:23 AM, Changpeng Fang wrote: > >> >> On 05/04/09 16:34, Tom Rodriguez wrote: >>> This seems ok. Was there an example that motivated this change? >>> >> For the following Test1.java with -XX:CompileOnly=Test1.init, you >> should see >> the loop is not unswitched. However, I could not observe perform >> difference >> with my proposed change even though the loop is unswitched after the >> change. >> >> Thanks, >> >> Changpeng >> >> class Test1 { >> >> public static void init(int src[], int dst[], int unknown) { >> // initialize the arrays >> for (int i =0; i<4; i++) { >> dst[i] = i; >> if(unknown >= 5) >> src[i] = i; } >> } >> >> public static void test() { >> int[] src = new int[4]; >> int[] dst = new int[4]; >> >> init(src, dst, 5); >> } >> >> public static void main(String[] args) { >> long start = System.currentTimeMillis(); >> for (int i=0; i< 2000000; i++) { >> test(); >> } >> long end = System.currentTimeMillis(); >> System.out.println(end-start); >> } >> } >> >> >> >> >> >> >> >> >>> On May 4, 2009, at 3:49 PM, Changpeng Fang wrote: >>> >>>> http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ >>>> >>>> Problem Summary: >>>> The concern is the ordering of maximally unroll and unswitch of a >>>> loop in loop transformation. >>>> Current implementation is that maximally unroll is performed before >>>> loop unswitch. The problem >>>> is if a loop is maximally unrolled (fully unrolled), it will never >>>> be unswitched. This will leave >>>> many conditional statements (blocks) in the code which should not >>>> appear if the loop can be >>>> unswitched. >>>> >>>> Proposed Solution: >>>> Change the ordering of unswitch and maximally_unroll in loop >>>> transformation. After unswitch, >>>> the loop should still be able to be maximally unrolled. >>>> >>>> Thanks, >>>> >>>> Changpeng >>>> >>>> >>>> >>>> On 05/04/09 15:05, Changpeng Fang wrote: >>>>> http://cr.openjdk.java.net/~cfang/6837146/webrev.00/ >>>>> >>>>> Summary: Change the ordering of do_unswitch and >>>>> do_maximally_unroll in loop transformation. >>>>> >>>>> Thanks, >>>>> >>>>> Changpeng >>>>> >>>> >>> >> > From Thomas.Rodriguez at Sun.COM Tue May 5 13:01:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 05 May 2009 13:01:15 -0700 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <1241551064.9518.58.camel@macbook> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> <49FF5FE3.4030404@sun.com> <1241513876.27789.120.camel@macbook> <4A005D88.8070107@sun.com> <1241538132.9518.4.camel@macbook> <4A006511.4010706@sun.com> <1241540126.9518.5.camel@macbook> <1241551064.9518.58.camel@macbook> Message-ID: looks good. tom On May 5, 2009, at 12:17 PM, Christian Thalinger wrote: > On Tue, 2009-05-05 at 11:28 -0700, Tom Rodriguez wrote: >> I think returning TypeInt::INT directly would be preferred. >> bottom_type() is always virtual and you have to look elsewhere to see >> what it returns. > > Sounds reasonable. Here is a new version of the patch: > > http://cr.openjdk.java.net/~twisti/6823354/webrev.04/ > > -- Christian > From Christian.Thalinger at Sun.COM Tue May 5 13:52:51 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 05 May 2009 22:52:51 +0200 Subject: Request for reviews (L): 6823354: Add intrinsics for{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() In-Reply-To: <4A009246.2030900@sun.com> References: <1240425443.1292.36.camel@macbook> <49EFA348.2030707@sun.com> <49EFC57B.7070205@sun.com> <1240483195.27794.223.camel@macbook> <1240498405.27794.240.camel@macbook> <49F09DE6.5060604@sun.com> <1240729080.3340.1.camel@macbook> <1241467729.27789.63.camel@macbook> <49FF5FE3.4030404@sun.com> <1241513876.27789.120.camel@macbook> <4A005D88.8070107@sun.com> <1241538132.9518.4.camel@macbook> <4A006511.4010706@sun.com> <1241540126.9518.5.camel@macbook> <1241551064.9518.58.camel@macbook> <4A009246.2030900@sun.com> Message-ID: <1241556771.9518.69.camel@macbook> On Tue, 2009-05-05 at 12:23 -0700, Vladimir Kozlov wrote: > Looks good. > Did you rerun your test? Yes I did. I added the numbers to the CR, but the variations seem to be in the noise. -- Christian From changpeng.fang at sun.com Tue May 5 19:27:28 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Wed, 06 May 2009 02:27:28 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6833879: Assigning positive zero is ignored when old value is negative zero Message-ID: <20090506022735.988A5E077@hg.openjdk.java.net> Changeset: 36ee9b69616e Author: cfang Date: 2009-05-05 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/36ee9b69616e 6833879: Assigning positive zero is ignored when old value is negative zero Summary: Don't perform CMOVE identity optimization for floating point types Reviewed-by: kvn, never ! src/share/vm/opto/connode.cpp From Christian.Thalinger at Sun.COM Wed May 6 02:59:35 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 06 May 2009 11:59:35 +0200 Subject: Request for reviews (XS): 6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm Message-ID: <1241603975.9518.75.camel@macbook> http://cr.openjdk.java.net/~twisti/6837011/webrev.01/ From Christian.Thalinger at Sun.COM Wed May 6 04:53:18 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 06 May 2009 13:53:18 +0200 Subject: Request for reviews (XXS): 6837906: compiler tests of 6636138 fail with IllegalAccessException Message-ID: <1241610798.9518.76.camel@macbook> http://cr.openjdk.java.net/~twisti/6837906/webrev.01/ From Vladimir.Kozlov at Sun.COM Wed May 6 08:40:07 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 06 May 2009 08:40:07 -0700 Subject: Request for reviews (XXS): 6837906: compiler tests of 6636138 fail with IllegalAccessException In-Reply-To: <1241610798.9518.76.camel@macbook> References: <1241610798.9518.76.camel@macbook> Message-ID: <4A01AF57.9040705@sun.com> Good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6837906/webrev.01/ > From rasbold at google.com Wed May 6 08:51:54 2009 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 6 May 2009 08:51:54 -0700 Subject: Request for reviews (XS): 6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm In-Reply-To: <1241603975.9518.75.camel@macbook> References: <1241603975.9518.75.camel@macbook> Message-ID: <4149a0430905060851j453bb6f2j947e9ceae45526b1@mail.gmail.com> Looks good. On Wed, May 6, 2009 at 2:59 AM, Christian Thalinger < Christian.Thalinger at sun.com> wrote: > http://cr.openjdk.java.net/~twisti/6837011/webrev.01/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090506/66fd6a2d/attachment.html From Thomas.Rodriguez at Sun.COM Wed May 6 09:26:34 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 06 May 2009 09:26:34 -0700 Subject: Request for reviews (XS): 6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm In-Reply-To: <1241603975.9518.75.camel@macbook> References: <1241603975.9518.75.camel@macbook> Message-ID: looks good. tom On May 6, 2009, at 2:59 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6837011/webrev.01/ > From Thomas.Rodriguez at Sun.COM Wed May 6 09:26:42 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 06 May 2009 09:26:42 -0700 Subject: Request for reviews (XXS): 6837906: compiler tests of 6636138 fail with IllegalAccessException In-Reply-To: <1241610798.9518.76.camel@macbook> References: <1241610798.9518.76.camel@macbook> Message-ID: <95D0F910-8C1D-4491-9D0A-251504124EDC@sun.com> looks good. tom On May 6, 2009, at 4:53 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6837906/webrev.01/ > From Thomas.Rodriguez at Sun.COM Wed May 6 12:41:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 06 May 2009 12:41:15 -0700 Subject: review (XS) for 6838154: make/linux/makefiles/sa.make needs hash-style fix Message-ID: http://cr.openjdk.java.net/~never/6838154 From John.Rose at Sun.COM Wed May 6 13:42:43 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 06 May 2009 13:42:43 -0700 Subject: review (XS) for 6838154: make/linux/makefiles/sa.make needs hash-style fix In-Reply-To: References: Message-ID: <99858EA5-D484-4FD5-A91D-F84B283D78CF@sun.com> Your fix looks fine. There is a similar one-off pattern in jsig.make. Both supply flags to ld via cc, going through $(CC) not through $(LINK.c). Only LINK.c picks up $(LFLAGS) and the required hash option. Do you think jsig needs a similar fix also? -- John On May 6, 2009, at 12:41 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6838154 From Thomas.Rodriguez at Sun.COM Wed May 6 13:57:01 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 06 May 2009 13:57:01 -0700 Subject: review (XS) for 6838154: make/linux/makefiles/sa.make needs hash-style fix In-Reply-To: <99858EA5-D484-4FD5-A91D-F84B283D78CF@sun.com> References: <99858EA5-D484-4FD5-A91D-F84B283D78CF@sun.com> Message-ID: <279E3C18-9FD9-4472-81A2-1CDEA4ACA8B6@Sun.COM> That's a good catch. ldd -r libjsig.so results in the SIGFPE problem. I'll add that. I ldd -r'd all the other libs in the image to make sure no others had problems and that seems to be it. I've updated the webrev. tom On May 6, 2009, at 1:42 PM, John Rose wrote: > Your fix looks fine. > > There is a similar one-off pattern in jsig.make. Both supply flags > to ld via cc, going through $(CC) not through $(LINK.c). Only > LINK.c picks up $(LFLAGS) and the required hash option. Do you > think jsig needs a similar fix also? > > -- John > > On May 6, 2009, at 12:41 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/6838154 > From Vladimir.Kozlov at Sun.COM Wed May 6 14:11:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 06 May 2009 14:11:20 -0700 Subject: review (XS) for 6838154: make/linux/makefiles/sa.make needs hash-style fix In-Reply-To: <279E3C18-9FD9-4472-81A2-1CDEA4ACA8B6@Sun.COM> References: <99858EA5-D484-4FD5-A91D-F84B283D78CF@sun.com> <279E3C18-9FD9-4472-81A2-1CDEA4ACA8B6@Sun.COM> Message-ID: <4A01FCF8.1020804@sun.com> Looks good Vladimir Tom Rodriguez wrote: > That's a good catch. ldd -r libjsig.so results in the SIGFPE problem. > I'll add that. I ldd -r'd all the other libs in the image to make sure > no others had problems and that seems to be it. I've updated the webrev. > > tom > > On May 6, 2009, at 1:42 PM, John Rose wrote: > >> Your fix looks fine. >> >> There is a similar one-off pattern in jsig.make. Both supply flags to >> ld via cc, going through $(CC) not through $(LINK.c). Only LINK.c >> picks up $(LFLAGS) and the required hash option. Do you think jsig >> needs a similar fix also? >> >> -- John >> >> On May 6, 2009, at 12:41 PM, Tom Rodriguez wrote: >> >>> http://cr.openjdk.java.net/~never/6838154 >> > From Christian.Thalinger at Sun.COM Wed May 6 17:11:21 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 07 May 2009 00:11:21 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm Message-ID: <20090507001130.191ABE394@hg.openjdk.java.net> Changeset: cecd04fc6f93 Author: twisti Date: 2009-05-06 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cecd04fc6f93 6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm Summary: The CR's test crashes with SIGSEGV when running with "-server -Xcomp" using using 32bit jvm. Reviewed-by: kvn, never, rasbold ! src/share/vm/opto/divnode.cpp + test/compiler/6837011/Test6837011.java From thomas.rodriguez at sun.com Wed May 6 22:20:20 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 07 May 2009 05:20:20 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6838154: make/linux/makefiles/sa.make needs hash-style fix Message-ID: <20090507052027.E91A1E3E5@hg.openjdk.java.net> Changeset: f96f285ed3dd Author: never Date: 2009-05-06 17:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f96f285ed3dd 6838154: make/linux/makefiles/sa.make needs hash-style fix Reviewed-by: kvn, jrose ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make From Christian.Thalinger at Sun.COM Thu May 7 02:47:44 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 07 May 2009 09:47:44 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090507094802.CA9A6E424@hg.openjdk.java.net> Changeset: 93c14e5562c4 Author: twisti Date: 2009-05-06 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/93c14e5562c4 6823354: Add intrinsics for {Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() Summary: These methods can be instrinsified by using bit scan, bit test, and population count instructions. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/runtime/globals.hpp + test/compiler/6823354/Test6823354.java Changeset: e85af0c0c94b Author: twisti Date: 2009-05-07 00:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e85af0c0c94b Merge From Christian.Thalinger at Sun.COM Thu May 7 06:24:56 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 07 May 2009 15:24:56 +0200 Subject: Request for reviews (L): 6814842: Load shortening optimizations In-Reply-To: <1236622538.2239.867.camel@localhost.localdomain> References: <1236622538.2239.867.camel@localhost.localdomain> Message-ID: <1241702696.9518.111.camel@macbook> http://cr.openjdk.java.net/~twisti/6814842/webrev.01/ Here is a version that covers most shortening patterns as AD instructs. -- Christian From Ulf.Zibis at gmx.de Thu May 7 06:40:57 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 07 May 2009 15:40:57 +0200 Subject: Request for reviews (L): 6814842: Load shortening optimizations In-Reply-To: <1241702696.9518.111.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> Message-ID: <4A02E4E9.9070007@gmx.de> Hi Christian, is there any Bug ID about load widening optimizations? E.g.: char decode(byte b) { return (char)(b & 0xFF); } void decode(byte[] ba, char[] ca) { for (int i=0; i http://cr.openjdk.java.net/~twisti/6814842/webrev.01/ > > Here is a version that covers most shortening patterns as AD instructs. > > -- Christian > > > From Christian.Thalinger at Sun.COM Thu May 7 06:55:48 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 07 May 2009 15:55:48 +0200 Subject: Request for reviews (L): 6814842: Load shortening optimizations In-Reply-To: <4A02E4E9.9070007@gmx.de> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <4A02E4E9.9070007@gmx.de> Message-ID: <1241704548.9518.112.camel@macbook> On Thu, 2009-05-07 at 15:40 +0200, Ulf Zibis wrote: > Hi Christian, > > is there any Bug ID about load widening optimizations? Yes. > E.g.: > char decode(byte b) { > return (char)(b & 0xFF); > } This is handled by HotSpot for a long time. > void decode(byte[] ba, char[] ca) { > for (int i=0; i ca[i] = (char)(ba[i] & 0xFF); > } And this is covered by 6797305. -- Christian From Christian.Thalinger at Sun.COM Thu May 7 13:18:39 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 07 May 2009 20:18:39 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090507201849.16360E575@hg.openjdk.java.net> Changeset: f53b154d959d Author: twisti Date: 2009-05-06 08:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f53b154d959d 6837906: compiler tests of 6636138 fail with IllegalAccessException Summary: The compiler tests of 6636138 fail with an IllegalAccessException. Reviewed-by: kvn ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java Changeset: f2954231d190 Author: twisti Date: 2009-05-07 04:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f2954231d190 Merge From Vladimir.Kozlov at Sun.COM Thu May 7 19:56:09 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 07 May 2009 19:56:09 -0700 Subject: Request for reviews (M): 6788527: Server vm intermittently fails with assertion "live value must not be garbage" with fastdebug bits Message-ID: <4A039F49.9060504@sun.com> http://cr.openjdk.java.net/~kvn/6788527/webrev.00 Fixed 6788527: Server vm intermittently fails with assertion "live value must not be garbage" with fastdebug bits Problem: Jvmti and DTrace threads may change global flags used by Compiler in the middle of compilation. These leads to inconsistent answers from MethodLiveness which leads to the failure during parsing. It also invalidates dependencies constructed during compilation. Solution: Cache Jvmti and DTrace flags used by Compiler at the start in the ciEnv and validate them at the end of the compile. Reviewed by: Fix verified (y/n): y, bugs case Other testing: JPRT From Thomas.Rodriguez at Sun.COM Thu May 7 20:10:18 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 07 May 2009 20:10:18 -0700 Subject: Request for reviews (M): 6788527: Server vm intermittently fails with assertion "live value must not be garbage" with fastdebug bits In-Reply-To: <4A039F49.9060504@sun.com> References: <4A039F49.9060504@sun.com> Message-ID: <2C941A3D-AB00-40B7-A970-9A528EB9D6CE@sun.com> looks good. tom On May 7, 2009, at 7:56 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6788527/webrev.00 > > Fixed 6788527: Server vm intermittently fails with assertion "live > value must not be garbage" with fastdebug bits > > Problem: > Jvmti and DTrace threads may change global flags used by Compiler > in the middle of compilation. These leads to inconsistent answers > from MethodLiveness which leads to the failure during parsing. > It also invalidates dependencies constructed during compilation. > > Solution: > Cache Jvmti and DTrace flags used by Compiler at the start > in the ciEnv and validate them at the end of the compile. > > Reviewed by: > > Fix verified (y/n): y, bugs case > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Thu May 7 20:29:04 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 07 May 2009 20:29:04 -0700 Subject: Request for reviews (S): 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException Message-ID: <4A03A700.9010600@sun.com> http://cr.openjdk.java.net/~kvn/6836054/webrev.00 Fixed 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException Problem: Escape Analysis requires that allocations should have exact type (by using CheckCastPP node) for restoring objects during deoptimization. But reflection allocation set type to j.l.Object assuming that caller will cast to exact type. In the failing case there is no cast to array type so debug info contains incorrect type (j.l.Object) for scalar replaced array allocation. It causes the Exception after deoptimization. Solution: Do not mark an allocation as scalar replaceable if it does not have exact type. Reviewed by: Fix verified (y/n): y, bugs case Other testing: JPRT, CTW From Ulf.Zibis at gmx.de Fri May 8 03:29:19 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 08 May 2009 12:29:19 +0200 Subject: Request for reviews (L): 6814842: Load shortening optimizations In-Reply-To: <1241704548.9518.112.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <4A02E4E9.9070007@gmx.de> <1241704548.9518.112.camel@macbook> Message-ID: <4A04097F.1060406@gmx.de> Much thanks for your fast answer and accepting my little error. ;-) Am 07.05.2009 15:55, Christian Thalinger schrieb: > On Thu, 2009-05-07 at 15:40 +0200, Ulf Zibis wrote: > >> E.g.: >> char decode(byte b) { >> return (char)(b & 0xFF); >> } >> > > This is handled by HotSpot for a long time. > Hm, I can't share this experience. Results from my benchmark on JDK7 b51: time for (char)a: 1652 ms time for (char)(a & 0xFF): 2772 ms IMHO (char)(a & 0xFF) should be faster, or at least as fast as (char)a, because only basic LoadUB should be executed. -Ulf From Christian.Thalinger at Sun.COM Fri May 8 05:01:17 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 08 May 2009 14:01:17 +0200 Subject: Request for reviews (L): 6814842: Load shortening optimizations In-Reply-To: <4A04097F.1060406@gmx.de> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <4A02E4E9.9070007@gmx.de> <1241704548.9518.112.camel@macbook> <4A04097F.1060406@gmx.de> Message-ID: <1241784078.27008.21.camel@macbook> On Fri, 2009-05-08 at 12:29 +0200, Ulf Zibis wrote: > Am 07.05.2009 15:55, Christian Thalinger schrieb: > > On Thu, 2009-05-07 at 15:40 +0200, Ulf Zibis wrote: > > > >> E.g.: > >> char decode(byte b) { > >> return (char)(b & 0xFF); > >> } > >> > > > > This is handled by HotSpot for a long time. > > > > Hm, I can't share this experience. > > Results from my benchmark on JDK7 b51: > > > time for (char)a: 1652 ms > time for (char)(a & 0xFF): 2772 ms > > IMHO (char)(a & 0xFF) should be faster, or at least as fast as (char)a, > because only basic LoadUB should be executed. I already said that once, it's not the code the makes the second one slower, it's the register allocation. When running with: -XX:LoopUnrollLimit=1 you get more accurate numbers regarding the generated code. I looked at the code of loop3 and loop4 and they are actually identical. Except loop4 uses a zero-extension move instead of a sign-extension one, which is what we want. time for (char)a: 1350 ms time for (char)(a & 0xFF): 1429 ms time for inlined (char)a: 1493 ms time for inlined (char)(a & 0xFF): 1494 ms The differences in runtime might be related to other things (cache, ...), since loop3/loop4 generate exact the same code as inline3/inline4. -- Christian From Ulf.Zibis at gmx.de Fri May 8 09:36:39 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 08 May 2009 18:36:39 +0200 Subject: Request for reviews (L): 6814842: Load shortening optimizations In-Reply-To: <1241784078.27008.21.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <4A02E4E9.9070007@gmx.de> <1241704548.9518.112.camel@macbook> <4A04097F.1060406@gmx.de> <1241784078.27008.21.camel@macbook> Message-ID: <4A045F97.6000103@gmx.de> Thanks for detailed information. Some more questions: - Where can I find information about -XX:LoopUnrollLimit? - Where can I find information about other -XX hotspot options (for jdk7)? - How to see the generated optimized code from hotspot? I don't know where to find the option flag docu. > it's not the code the makes the second one slower, it's the register allocation. Does that mean, that sign-extension has faster register access than zero-extension? -Ulf Am 08.05.2009 14:01, Christian Thalinger schrieb: > On Fri, 2009-05-08 at 12:29 +0200, Ulf Zibis wrote: > >> Am 07.05.2009 15:55, Christian Thalinger schrieb: >> >>> On Thu, 2009-05-07 at 15:40 +0200, Ulf Zibis wrote: >>> >>> >>>> E.g.: >>>> char decode(byte b) { >>>> return (char)(b & 0xFF); >>>> } >>>> >>>> >>> This is handled by HotSpot for a long time. >>> >>> >> Hm, I can't share this experience. >> >> Results from my benchmark on JDK7 b51: >> >> >> time for (char)a: 1652 ms >> time for (char)(a & 0xFF): 2772 ms >> >> IMHO (char)(a & 0xFF) should be faster, or at least as fast as (char)a, >> because only basic LoadUB should be executed. >> > > I already said that once, it's not the code the makes the second one > slower, it's the register allocation. When running with: > > -XX:LoopUnrollLimit=1 > > you get more accurate numbers regarding the generated code. > > I looked at the code of loop3 and loop4 and they are actually identical. > Except loop4 uses a zero-extension move instead of a sign-extension one, > which is what we want. > > time for (char)a: 1350 ms > time for (char)(a & 0xFF): 1429 ms > > time for inlined (char)a: 1493 ms > time for inlined (char)(a & 0xFF): 1494 ms > > The differences in runtime might be related to other things > (cache, ...), since loop3/loop4 generate exact the same code as > inline3/inline4. > > -- Christian > > > From Ulf.Zibis at gmx.de Fri May 8 10:01:16 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 08 May 2009 19:01:16 +0200 Subject: Request for reviews (L): 6814842: Load shortening optimizations In-Reply-To: <1241784078.27008.21.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <4A02E4E9.9070007@gmx.de> <1241704548.9518.112.camel@macbook> <4A04097F.1060406@gmx.de> <1241784078.27008.21.camel@macbook> Message-ID: <4A04655C.6040106@gmx.de> Am 08.05.2009 14:01, Christian Thalinger schrieb: > On Fri, 2009-05-08 at 12:29 +0200, Ulf Zibis wrote: > >> >> Results from my benchmark on JDK7 b51: >> >> >> time for (char)a: 1652 ms >> time for (char)(a & 0xFF): 2772 ms >> >> IMHO (char)(a & 0xFF) should be faster, or at least as fast as (char)a, >> because only basic LoadUB should be executed. >> > > I already said that once, it's not the code the makes the second one > slower, it's the register allocation. Does that mean, that I should use (char)a to decode ASCII-bytes [0x00..0x7F] and (char)(a & 0xFF) to decode ISO-8859-1-bytes [0x00..0xFF] to have best performance? Using (char)(a & 0xFF) in general would waste performance for only-ASCII-bytes (...but win for ISO-8859-1-bytes, if using -XX:LoopUnrollLimit=1, see below). > When running with: > > -XX:LoopUnrollLimit=1 > Result: time for (char)a: 2280 ms time for (char)(a & 0xFF): 2284 ms How should I interpret this? In case of ISO-8859-1-bytes it's faster than without -XX:LoopUnrollLimit=1, but slower in case of only-ASCII-bytes. Which values are relevant for real world case? I'm not sure, which java code to use for most fast charset decoders. -Ulf From Christian.Thalinger at Sun.COM Fri May 8 11:10:52 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 08 May 2009 20:10:52 +0200 Subject: Request for reviews (L): 6814842: Load shortening optimizations In-Reply-To: <4A045F97.6000103@gmx.de> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <4A02E4E9.9070007@gmx.de> <1241704548.9518.112.camel@macbook> <4A04097F.1060406@gmx.de> <1241784078.27008.21.camel@macbook> <4A045F97.6000103@gmx.de> Message-ID: <1241806253.27008.30.camel@macbook> On Fri, 2009-05-08 at 18:36 +0200, Ulf Zibis wrote: > Thanks for detailed information. > > Some more questions: > - Where can I find information about -XX:LoopUnrollLimit? > - Where can I find information about other -XX hotspot options (for jdk7)? -Xprintflags gives you a list of all flags and it's values. More information about the flags can be found in the various header files which define them: src/share/vm/gc_implementation/g1/g1_globals.hpp src/share/vm/opto/c2_globals.hpp src/share/vm/c1/c1_globals.hpp src/share/vm/runtime/globals.hpp > - How to see the generated optimized code from hotspot? I don't know > where to find the option flag docu. You can use -XX:+PrintOptoAssembly in any debug build to see an output that is almost identical with the generated code, but it does not print the actual code (this is part of HotSpot). -XX:+PrintAssembly uses libraries from binutils to disassemble the actually generated code (that one is accurate), but you need to compile the library wrapper yourself. See: http://wikis.sun.com/display/HotSpotInternals/PrintAssembly > > it's not the code the makes the second one slower, it's the register > allocation. > Does that mean, that sign-extension has faster register access than > zero-extension? No, it's the register allocation in the unrolled loop around the load. -- Christian From vladimir.kozlov at sun.com Fri May 8 12:59:31 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 08 May 2009 19:59:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 11 new changesets Message-ID: <20090508195957.41914E781@hg.openjdk.java.net> Changeset: 2b6c55e36143 Author: tonyp Date: 2009-04-23 16:58 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2b6c55e36143 6829013: G1: set the default value of G1VerifyConcMarkPrintRechable to false Summary: Turn off G1VerifyConcMarkPrintReachable by default to minimize the amount of verbose output we generate by default. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 4753e4079a5a Author: apetrusenko Date: 2009-04-27 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4753e4079a5a Merge Changeset: b803b1b9e206 Author: iveresov Date: 2009-04-27 16:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b803b1b9e206 6819098: G1: reduce RSet scanning times Summary: Added a feedback-driven exponential skipping for parallel RSet scanning. Reviewed-by: tonyp, apetrusenko ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 51285b431bb2 Author: apetrusenko Date: 2009-05-04 02:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/51285b431bb2 Merge Changeset: 81a249214991 Author: poonam Date: 2009-05-04 17:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/81a249214991 6829234: Refix 6822407 and 6812971 Summary: Fixes two SA issues 6822407 and 6812971 Reviewed-by: swamyv, acorn, kvn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java Changeset: c8f1f4de26c9 Author: kamg Date: 2009-05-07 11:44 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c8f1f4de26c9 Merge Changeset: 20c6f43950b5 Author: johnc Date: 2009-04-30 15:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/20c6f43950b5 6490395: G1: Tidy up command line flags. Summary: Change G1 flag names to be more consistent and disable some in 'product' mode. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a2957df801a1 Author: johnc Date: 2009-05-05 22:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a2957df801a1 6833576: G1: assert illegal index, growableArray.hpp:186 Summary: The code that calculates the heap region index for an object address incorrectly used signed arithmetic. Reviewed-by: jcoomes, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp Changeset: a58ad611cc63 Author: jcoomes Date: 2009-05-07 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a58ad611cc63 Merge Changeset: 9b3a41ccc927 Author: kvn Date: 2009-05-07 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9b3a41ccc927 Merge Changeset: d0e0d6d824d8 Author: kvn Date: 2009-05-08 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d0e0d6d824d8 Merge ! src/share/vm/runtime/globals.hpp From Vladimir.Kozlov at Sun.COM Fri May 8 13:12:29 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 08 May 2009 13:12:29 -0700 Subject: Request for reviews (S): 6832293: JIT compiler got wrong result in type checking with -server Message-ID: <4A04922D.6080506@sun.com> http://cr.openjdk.java.net/~kvn/6832293/webrev.00 Fixed 6832293: JIT compiler got wrong result in type checking with -server Problem: The code in CmpPNode::sub is broken for arrays of interface types. Solution: In CmpPNode::sub compare klasses of obj arrays elements.. Reviewed by: Fix verified (y/n): y, modified (for jdk7) bug's test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Fri May 8 13:56:48 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 08 May 2009 13:56:48 -0700 Subject: Request for reviews (S): 6832293: JIT compiler got wrong result in type checking with -server In-Reply-To: <4A04922D.6080506@sun.com> References: <4A04922D.6080506@sun.com> Message-ID: <51064557-7DF1-4AF8-A60B-D2B255E3F2A1@sun.com> That doesn't seem quite right to me or maybe I just don't like the way it's phrased. The rules for subtyping for arrays are different than instances, so walking up the classes would change the subtype test. It also creates in consistency between klass and xklass. What about this: diff --git a/src/share/vm/opto/subnode.cpp b/src/share/vm/opto/ subnode.cpp --- a/src/share/vm/opto/subnode.cpp +++ b/src/share/vm/opto/subnode.cpp @@ -639,8 +639,11 @@ const Type *CmpPNode::sub( const Type *t int kps = (p0->isa_klassptr()?1:0) + (p1->isa_klassptr()?1:0); if (klass0 && klass1 && kps != 1 && // both or neither are klass pointers - klass0->is_loaded() && !klass0->is_interface() && // do not trust interfaces - klass1->is_loaded() && !klass1->is_interface()) { + // do not trust interfaces + klass0->is_loaded() && !klass0->is_interface() && + (!klass0->is_obj_array_klass() || !klass0- >as_obj_array_klass()->base_element_klass()->is_interface()) && + klass1->is_loaded() && !klass1->is_interface() && + (!klass1->is_obj_array_klass() || !klass1- >as_obj_array_klass()->base_element_klass()->is_interface())) { bool unrelated_classes = false; // See if neither subclasses the other, or if the class on top // is precise. In either of these cases, the compare is known tom On May 8, 2009, at 1:12 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6832293/webrev.00 > > Fixed 6832293: JIT compiler got wrong result in type checking with - > server > > Problem: > The code in CmpPNode::sub is broken for arrays of interface types. > > Solution: > In CmpPNode::sub compare klasses of obj arrays elements.. > > Reviewed by: > > Fix verified (y/n): y, modified (for jdk7) bug's test > > Other testing: > JPRT > From Thomas.Rodriguez at Sun.COM Fri May 8 14:01:42 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 08 May 2009 14:01:42 -0700 Subject: Request for reviews (S): 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException In-Reply-To: <4A03A700.9010600@sun.com> References: <4A03A700.9010600@sun.com> Message-ID: <5FDE85EA-884A-4B96-8162-41B21C3F5D14@sun.com> I have to admit I don't really follow this logic in the code. How is it that we can allocate something but not know it's actual type? Isn't that required to emit the allocation in the first place? tom On May 7, 2009, at 8:29 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6836054/webrev.00 > > Fixed 6836054: java/util/Arrays/CopyMethods.java fails on solaris- > sparc with IllegalArgumentException > > Problem: > Escape Analysis requires that allocations should have > exact type (by using CheckCastPP node) for restoring > objects during deoptimization. But reflection allocation > set type to j.l.Object assuming that caller will cast > to exact type. In the failing case there is no cast > to array type so debug info contains incorrect type > (j.l.Object) for scalar replaced array allocation. > It causes the Exception after deoptimization. > > Solution: > Do not mark an allocation as scalar replaceable if > it does not have exact type. > > Reviewed by: > > Fix verified (y/n): y, bugs case > > Other testing: > JPRT, CTW > From Vladimir.Kozlov at Sun.COM Fri May 8 14:49:56 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 08 May 2009 14:49:56 -0700 Subject: Request for reviews (S): 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException In-Reply-To: <5FDE85EA-884A-4B96-8162-41B21C3F5D14@sun.com> References: <4A03A700.9010600@sun.com> <5FDE85EA-884A-4B96-8162-41B21C3F5D14@sun.com> Message-ID: <4A04A904.1030508@sun.com> We don't know statically during a method compilation the actual type because it is loaded dynamically for reflaction allocation. Escape Analysis requires to know the type statically to pass it to debug info: const Type *t = local->bottom_type(); // Is it a safepoint scalar object node? if (local->is_SafePointScalarObject()) { SafePointScalarObjectNode* spobj = local->as_SafePointScalarObject(); ObjectValue* sv = Compile::sv_for_node_id(objs, spobj->_idx); if (sv == NULL) { ciKlass* cik = t->is_oopptr()->klass(); assert(cik->is_instance_klass() || cik->is_array_klass(), "Not supported allocation."); sv = new ObjectValue(spobj->_idx, new ConstantOopWriteValue(cik->encoding())); Vladimir Tom Rodriguez wrote: > I have to admit I don't really follow this logic in the code. How is it > that we can allocate something but not know it's actual type? Isn't > that required to emit the allocation in the first place? > > tom > > On May 7, 2009, at 8:29 PM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6836054/webrev.00 >> >> Fixed 6836054: java/util/Arrays/CopyMethods.java fails on >> solaris-sparc with IllegalArgumentException >> >> Problem: >> Escape Analysis requires that allocations should have >> exact type (by using CheckCastPP node) for restoring >> objects during deoptimization. But reflection allocation >> set type to j.l.Object assuming that caller will cast >> to exact type. In the failing case there is no cast >> to array type so debug info contains incorrect type >> (j.l.Object) for scalar replaced array allocation. >> It causes the Exception after deoptimization. >> >> Solution: >> Do not mark an allocation as scalar replaceable if >> it does not have exact type. >> >> Reviewed by: >> >> Fix verified (y/n): y, bugs case >> >> Other testing: >> JPRT, CTW >> > From Vladimir.Kozlov at Sun.COM Fri May 8 15:03:42 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 08 May 2009 15:03:42 -0700 Subject: Request for reviews (S): 6832293: JIT compiler got wrong result in type checking with -server In-Reply-To: <51064557-7DF1-4AF8-A60B-D2B255E3F2A1@sun.com> References: <4A04922D.6080506@sun.com> <51064557-7DF1-4AF8-A60B-D2B255E3F2A1@sun.com> Message-ID: <4A04AC3E.1050104@sun.com> Tom, With this you will have the same problem with 2- multi- dimensional arrays which I try to avoid with my changes. But I agree, may be element klasses should be used only for interface and subtype checks. On other hand why we are not using p0->meet(p1) == p0 || == p1? Vladimir Tom Rodriguez wrote: > That doesn't seem quite right to me or maybe I just don't like the way > it's phrased. The rules for subtyping for arrays are different than > instances, so walking up the classes would change the subtype test. It > also creates in consistency between klass and xklass. What about this: > > diff --git a/src/share/vm/opto/subnode.cpp b/src/share/vm/opto/subnode.cpp > --- a/src/share/vm/opto/subnode.cpp > +++ b/src/share/vm/opto/subnode.cpp > @@ -639,8 +639,11 @@ const Type *CmpPNode::sub( const Type *t > int kps = (p0->isa_klassptr()?1:0) + (p1->isa_klassptr()?1:0); > if (klass0 && klass1 && > kps != 1 && // both or neither are klass pointers > - klass0->is_loaded() && !klass0->is_interface() && // do not > trust interfaces > - klass1->is_loaded() && !klass1->is_interface()) { > + // do not trust interfaces > + klass0->is_loaded() && !klass0->is_interface() && > + (!klass0->is_obj_array_klass() || > !klass0->as_obj_array_klass()->base_element_klass()->is_interface()) && > + klass1->is_loaded() && !klass1->is_interface() && > + (!klass1->is_obj_array_klass() || > !klass1->as_obj_array_klass()->base_element_klass()->is_interface())) { > bool unrelated_classes = false; > // See if neither subclasses the other, or if the class on top > // is precise. In either of these cases, the compare is known > > tom > > On May 8, 2009, at 1:12 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6832293/webrev.00 >> >> Fixed 6832293: JIT compiler got wrong result in type checking with >> -server >> >> Problem: >> The code in CmpPNode::sub is broken for arrays of interface types. >> >> Solution: >> In CmpPNode::sub compare klasses of obj arrays elements.. >> >> Reviewed by: >> >> Fix verified (y/n): y, modified (for jdk7) bug's test >> >> Other testing: >> JPRT >> > From vladimir.kozlov at sun.com Fri May 8 15:22:11 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 08 May 2009 22:22:11 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6788527: Server vm intermittently fails with assertion "live value must not be garbage" with fastdebug bits Message-ID: <20090508222213.CE438E7A9@hg.openjdk.java.net> Changeset: c96bf21b756f Author: kvn Date: 2009-05-08 10:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c96bf21b756f 6788527: Server vm intermittently fails with assertion "live value must not be garbage" with fastdebug bits Summary: Cache Jvmti and DTrace flags used by Compiler. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp From Thomas.Rodriguez at Sun.COM Fri May 8 15:32:37 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 08 May 2009 15:32:37 -0700 Subject: Request for reviews (S): 6832293: JIT compiler got wrong result in type checking with -server In-Reply-To: <4A04AC3E.1050104@sun.com> References: <4A04922D.6080506@sun.com> <51064557-7DF1-4AF8-A60B-D2B255E3F2A1@sun.com> <4A04AC3E.1050104@sun.com> Message-ID: <202A1AB6-BE43-4477-9643-C8F515E5FB42@Sun.COM> On May 8, 2009, at 3:03 PM, Vladimir Kozlov wrote: > Tom, > > With this you will have the same problem with 2- multi- dimensional > arrays > which I try to avoid with my changes. But I agree, may be element > klasses > should be used only for interface and subtype checks. What problem is that? base_element_klass is the instanceKlass at the bottom of the objArray, irrespective of the arity of the array. > On other hand why we are not using p0->meet(p1) == p0 || == p1? Something like that might do a better job without duplicating logic, though I think we might need to handle interfaces explicitly anyway. tom > > > Vladimir > > > Tom Rodriguez wrote: >> That doesn't seem quite right to me or maybe I just don't like the >> way it's phrased. The rules for subtyping for arrays are different >> than instances, so walking up the classes would change the subtype >> test. It also creates in consistency between klass and xklass. >> What about this: >> diff --git a/src/share/vm/opto/subnode.cpp b/src/share/vm/opto/ >> subnode.cpp >> --- a/src/share/vm/opto/subnode.cpp >> +++ b/src/share/vm/opto/subnode.cpp >> @@ -639,8 +639,11 @@ const Type *CmpPNode::sub( const Type *t >> int kps = (p0->isa_klassptr()?1:0) + (p1->isa_klassptr()?1:0); >> if (klass0 && klass1 && >> kps != 1 && // both or neither are klass pointers >> - klass0->is_loaded() && !klass0->is_interface() && // do >> not trust interfaces >> - klass1->is_loaded() && !klass1->is_interface()) { >> + // do not trust interfaces >> + klass0->is_loaded() && !klass0->is_interface() && >> + (!klass0->is_obj_array_klass() || !klass0- >> >as_obj_array_klass()->base_element_klass()->is_interface()) && >> + klass1->is_loaded() && !klass1->is_interface() && >> + (!klass1->is_obj_array_klass() || !klass1- >> >as_obj_array_klass()->base_element_klass()->is_interface())) { >> bool unrelated_classes = false; >> // See if neither subclasses the other, or if the class on top >> // is precise. In either of these cases, the compare is known >> tom >> On May 8, 2009, at 1:12 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6832293/webrev.00 >>> >>> Fixed 6832293: JIT compiler got wrong result in type checking with >>> -server >>> >>> Problem: >>> The code in CmpPNode::sub is broken for arrays of interface types. >>> >>> Solution: >>> In CmpPNode::sub compare klasses of obj arrays elements.. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, modified (for jdk7) bug's test >>> >>> Other testing: >>> JPRT >>> From Vladimir.Kozlov at Sun.COM Fri May 8 15:47:09 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 08 May 2009 15:47:09 -0700 Subject: Request for reviews (S): 6832293: JIT compiler got wrong result in type checking with -server In-Reply-To: <202A1AB6-BE43-4477-9643-C8F515E5FB42@Sun.COM> References: <4A04922D.6080506@sun.com> <51064557-7DF1-4AF8-A60B-D2B255E3F2A1@sun.com> <4A04AC3E.1050104@sun.com> <202A1AB6-BE43-4477-9643-C8F515E5FB42@Sun.COM> Message-ID: <4A04B66D.4040508@sun.com> Tom Rodriguez wrote: > > On May 8, 2009, at 3:03 PM, Vladimir Kozlov wrote: > >> Tom, >> >> With this you will have the same problem with 2- multi- dimensional >> arrays >> which I try to avoid with my changes. But I agree, may be element klasses >> should be used only for interface and subtype checks. > > What problem is that? base_element_klass is the instanceKlass at the > bottom of the objArray, irrespective of the arity of the array. Sorry, I missed that you used base_element_klass() instead of element_klass(). Yes, your code will work. I will update changes. > >> On other hand why we are not using p0->meet(p1) == p0 || == p1? > > Something like that might do a better job without duplicating logic, > though I think we might need to handle interfaces explicitly anyway. Yes, I tried and it does not work with interfaces. Thanks, Vladimir > > tom > > >> >> >> Vladimir >> >> >> Tom Rodriguez wrote: >>> That doesn't seem quite right to me or maybe I just don't like the >>> way it's phrased. The rules for subtyping for arrays are different >>> than instances, so walking up the classes would change the subtype >>> test. It also creates in consistency between klass and xklass. What >>> about this: >>> diff --git a/src/share/vm/opto/subnode.cpp >>> b/src/share/vm/opto/subnode.cpp >>> --- a/src/share/vm/opto/subnode.cpp >>> +++ b/src/share/vm/opto/subnode.cpp >>> @@ -639,8 +639,11 @@ const Type *CmpPNode::sub( const Type *t >>> int kps = (p0->isa_klassptr()?1:0) + (p1->isa_klassptr()?1:0); >>> if (klass0 && klass1 && >>> kps != 1 && // both or neither are klass pointers >>> - klass0->is_loaded() && !klass0->is_interface() && // do not >>> trust interfaces >>> - klass1->is_loaded() && !klass1->is_interface()) { >>> + // do not trust interfaces >>> + klass0->is_loaded() && !klass0->is_interface() && >>> + (!klass0->is_obj_array_klass() || >>> !klass0->as_obj_array_klass()->base_element_klass()->is_interface()) && >>> + klass1->is_loaded() && !klass1->is_interface() && >>> + (!klass1->is_obj_array_klass() || >>> !klass1->as_obj_array_klass()->base_element_klass()->is_interface())) { >>> bool unrelated_classes = false; >>> // See if neither subclasses the other, or if the class on top >>> // is precise. In either of these cases, the compare is known >>> tom >>> On May 8, 2009, at 1:12 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/6832293/webrev.00 >>>> >>>> Fixed 6832293: JIT compiler got wrong result in type checking with >>>> -server >>>> >>>> Problem: >>>> The code in CmpPNode::sub is broken for arrays of interface types. >>>> >>>> Solution: >>>> In CmpPNode::sub compare klasses of obj arrays elements.. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y, modified (for jdk7) bug's test >>>> >>>> Other testing: >>>> JPRT >>>> > From Vladimir.Kozlov at Sun.COM Fri May 8 15:57:14 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 08 May 2009 15:57:14 -0700 Subject: Request for reviews (S): 6832293: JIT compiler got wrong result in type checking with -server Message-ID: <4A04B8CA.50405@sun.com> I updated changes based on Tom's suggestion http://cr.openjdk.java.net/~kvn/6832293/webrev.01 Fixed 6832293: JIT compiler got wrong result in type checking with -server Problem: The code in CmpPNode::sub is broken for arrays of interface types. Solution: Check for an object array of interface. Reviewed by: Fix verified (y/n): y, modified (for jdk7) bug's test Other testing: JPRT From kelly.ohair at sun.com Sat May 9 01:24:27 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 09 May 2009 08:24:27 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090509082440.9AFA8E911@hg.openjdk.java.net> Changeset: 44ccd7a9065c Author: ohair Date: 2009-05-08 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/44ccd7a9065c 6839151: Add a JPRT default test of -Xshare:dump when new hotspot is built Reviewed-by: never, kvn ! make/jprt.properties ! test/Makefile Changeset: 900e4df4b0c3 Author: ohair Date: 2009-05-08 23:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/900e4df4b0c3 Merge From Christian.Thalinger at Sun.COM Mon May 11 01:55:11 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 11 May 2009 10:55:11 +0200 Subject: Request for reviews (L): 6814842: Load shortening optimizations In-Reply-To: <4A04655C.6040106@gmx.de> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <4A02E4E9.9070007@gmx.de> <1241704548.9518.112.camel@macbook> <4A04097F.1060406@gmx.de> <1241784078.27008.21.camel@macbook> <4A04655C.6040106@gmx.de> Message-ID: <1242032112.27008.48.camel@macbook> On Fri, 2009-05-08 at 19:01 +0200, Ulf Zibis wrote: > > I already said that once, it's not the code the makes the second one > > slower, it's the register allocation. > > Does that mean, that I should use (char)a to decode ASCII-bytes > [0x00..0x7F] and (char)(a & 0xFF) to decode ISO-8859-1-bytes > [0x00..0xFF] to have best performance? Using (char)(a & 0xFF) in general > would waste performance for only-ASCII-bytes (...but win for > ISO-8859-1-bytes, if using -XX:LoopUnrollLimit=1, see below). No, the & 0xFF case should always be faster, because the shifter unit is not involved. This is definitely the case on SPARC, I'm not sure if there is any performance benefit on x86 CPUs. > > > When running with: > > > > -XX:LoopUnrollLimit=1 > > > > Result: > time for (char)a: 2280 ms > time for (char)(a & 0xFF): 2284 ms > > How should I interpret this? The performance is the same. > In case of ISO-8859-1-bytes it's faster than without > -XX:LoopUnrollLimit=1, but slower in case of only-ASCII-bytes. > Which values are relevant for real world case? I'm not sure, which java > code to use for most fast charset decoders. That's hard to tell and depends a lot on the call-site and the code around what we are currently talking about. A good recipe is to write code as straightforward as Java can be, since that code can be optimized best from the VM in all use-cases and not only a particular one. -- Christian From Christian.Thalinger at Sun.COM Mon May 11 08:23:15 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 11 May 2009 17:23:15 +0200 Subject: Request for reviews .02 (L): 6814842: Load shortening optimizations In-Reply-To: <1241702696.9518.111.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> Message-ID: <1242055396.27008.93.camel@macbook> http://cr.openjdk.java.net/~twisti/6814842/webrev.02/ Here is an updated version because, as I noticed last Thursday after some testing, that ADLC has a bug and Tom fixed that for me. -- Christian From Vladimir.Kozlov at Sun.COM Mon May 11 12:00:39 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 11 May 2009 12:00:39 -0700 Subject: Request for reviews (S): 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException In-Reply-To: <4A04A904.1030508@sun.com> References: <4A03A700.9010600@sun.com> <5FDE85EA-884A-4B96-8162-41B21C3F5D14@sun.com> <4A04A904.1030508@sun.com> Message-ID: <4A0875D7.6050903@sun.com> Sorry for long output. Here is the generated code which loads the allocation's actual type dynamically: 195 ConL === 0 [[ 196 211 ]] #long:24 190 CastPP === 182 11 [[ 176 196 196 206 242 ]] #java/lang/Class:NotNull:exact * Oop:java/lang/Class:NotNull:exact * !jvms: Array::newInstance @ bci:2 CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 196 AddP === _ 190 190 195 [[ 197 ]] Oop:java/lang/Class:NotNull:exact+24 * !jvms: Array::newInstance @ bci:2 CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 197 LoadKlass === _ 7 196 [[ 198 203 ]] @rawptr:BotPTR, idx=Raw; # * Klass: * !jvms: Array::newInstance @ bci:2 CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 203 CastPP === 202 197 [[ 211 211 234 ]] #klass java/lang/Object: 0x00000000004bcd58 * Klass:klass java/lang/Object: 0x00000000004bcd58 * !jvms: Array::newInstance @ bci:2 CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 234 AllocateArray === 202 91 92 8 1 ( 232 203 24 24 10 11 68 130 24 1 1 1 1 1 1 24 11 1 1 1 1 ) [[ 235 236 237 244 245 246 ]] rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 !jvms: Array::newInstance @ bci:2 CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 Vladimir Vladimir Kozlov wrote: > We don't know statically during a method compilation the actual type > because it is loaded dynamically for reflaction allocation. > Escape Analysis requires to know the type statically to pass it to debug > info: > > const Type *t = local->bottom_type(); > // Is it a safepoint scalar object node? > if (local->is_SafePointScalarObject()) { > SafePointScalarObjectNode* spobj = local->as_SafePointScalarObject(); > > ObjectValue* sv = Compile::sv_for_node_id(objs, spobj->_idx); > if (sv == NULL) { > ciKlass* cik = t->is_oopptr()->klass(); > assert(cik->is_instance_klass() || > cik->is_array_klass(), "Not supported allocation."); > sv = new ObjectValue(spobj->_idx, > new ConstantOopWriteValue(cik->encoding())); > > Vladimir > > Tom Rodriguez wrote: >> I have to admit I don't really follow this logic in the code. How is >> it that we can allocate something but not know it's actual type? >> Isn't that required to emit the allocation in the first place? >> >> tom >> >> On May 7, 2009, at 8:29 PM, Vladimir Kozlov wrote: >> >>> >>> http://cr.openjdk.java.net/~kvn/6836054/webrev.00 >>> >>> Fixed 6836054: java/util/Arrays/CopyMethods.java fails on >>> solaris-sparc with IllegalArgumentException >>> >>> Problem: >>> Escape Analysis requires that allocations should have >>> exact type (by using CheckCastPP node) for restoring >>> objects during deoptimization. But reflection allocation >>> set type to j.l.Object assuming that caller will cast >>> to exact type. In the failing case there is no cast >>> to array type so debug info contains incorrect type >>> (j.l.Object) for scalar replaced array allocation. >>> It causes the Exception after deoptimization. >>> >>> Solution: >>> Do not mark an allocation as scalar replaceable if >>> it does not have exact type. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, bugs case >>> >>> Other testing: >>> JPRT, CTW >>> >> From Thomas.Rodriguez at Sun.COM Mon May 11 13:31:00 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 11 May 2009 13:31:00 -0700 Subject: Request for reviews .02 (L): 6814842: Load shortening optimizations In-Reply-To: <1242055396.27008.93.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> Message-ID: <2E3E93B9-2668-4958-9417-05E569EDC0B0@sun.com> Just to clarify the fix I gave to Christian, the code for constructing cisc spills doesn't go through the Expand method so it ends up skipping the logic that rearranges the inputs and operands to deal with repeated uses of the same input in the match rule. In particular is skips the logic that corrects the number of operands. This fix adds that update to the cisc spill construction code. tom On May 11, 2009, at 8:23 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6814842/webrev.02/ > > Here is an updated version because, as I noticed last Thursday after > some testing, that ADLC has a bug and Tom fixed that for me. > > -- Christian > From Thomas.Rodriguez at Sun.COM Mon May 11 13:38:33 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 11 May 2009 13:38:33 -0700 Subject: Request for reviews .02 (L): 6814842: Load shortening optimizations In-Reply-To: <1242055396.27008.93.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> Message-ID: <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> I don't think the assert in formssel.cpp is needed because it replicates the logic in this test that guards enabling cisc spill. I'd given that to you originally before I fully realized what was going wrong. 1127 if( def_oper == NameList::Not_in_list && instr->num_opnds() == num_opnds()) { in sparc.ad you use simm13 instead of 13 bit in the comments since that's the sparc terminology. otherwise it looks fine. tom On May 11, 2009, at 8:23 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6814842/webrev.02/ > > Here is an updated version because, as I noticed last Thursday after > some testing, that ADLC has a bug and Tom fixed that for me. > > -- Christian > From Thomas.Rodriguez at Sun.COM Mon May 11 17:21:00 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 11 May 2009 17:21:00 -0700 Subject: Request for reviews (S): 6832293: JIT compiler got wrong result in type checking with -server In-Reply-To: <4A04B8CA.50405@sun.com> References: <4A04B8CA.50405@sun.com> Message-ID: <1AE74035-E25C-4A40-A7CD-CE494ABB9F67@sun.com> looks good to me. tom On May 8, 2009, at 3:57 PM, Vladimir Kozlov wrote: > I updated changes based on Tom's suggestion > > http://cr.openjdk.java.net/~kvn/6832293/webrev.01 > > Fixed 6832293: JIT compiler got wrong result in type checking with - > server > > Problem: > The code in CmpPNode::sub is broken for arrays of interface types. > > Solution: > Check for an object array of interface. > > Reviewed by: > > Fix verified (y/n): y, modified (for jdk7) bug's test > > Other testing: > JPRT > From Thomas.Rodriguez at Sun.COM Mon May 11 17:26:06 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 11 May 2009 17:26:06 -0700 Subject: Request for reviews (S): 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException In-Reply-To: <4A0875D7.6050903@sun.com> References: <4A03A700.9010600@sun.com> <5FDE85EA-884A-4B96-8162-41B21C3F5D14@sun.com> <4A04A904.1030508@sun.com> <4A0875D7.6050903@sun.com> Message-ID: Right. I get what you're saying and I think I follow it now. Looks good apart from the typo: accept -> except. tom On May 11, 2009, at 12:00 PM, Vladimir Kozlov wrote: > Sorry for long output. Here is the generated code which > loads the allocation's actual type dynamically: > > 195 ConL === 0 [[ 196 211 ]] #long:24 > 190 CastPP === 182 11 [[ 176 196 196 206 242 ]] #java/ > lang/Class:NotNull:exact * Oop:java/lang/Class:NotNull:exact * ! > jvms: Array::newInstance @ bci:2 CopyMethods::makeArray @ bci:2 > CopyMethods::fullTests @ bci:72 > 196 AddP === _ 190 190 195 [[ 197 ]] Oop:java/lang/ > Class:NotNull:exact+24 * !jvms: Array::newInstance @ bci:2 > CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 > 197 LoadKlass === _ 7 196 [[ 198 203 ]] > @rawptr:BotPTR, idx=Raw; # * Klass: * !jvms: Array::newInstance @ > bci:2 CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 > 203 CastPP === 202 197 [[ 211 211 234 ]] #klass java/lang/ > Object: 0x00000000004bcd58 * Klass:klass java/lang/Object: > 0x00000000004bcd58 * !jvms: Array::newInstance @ bci:2 > CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 > 234 AllocateArray === 202 91 92 8 1 ( 232 203 24 24 > 10 11 68 130 24 1 1 1 1 1 1 24 11 1 1 1 1 ) [[ 235 > 236 237 244 245 246 ]] rawptr:NotNull ( int:>=0, java/lang/ > Object:NotNull *, bool, int ) Array::newInstance @ bci:2 > CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 ! > jvms: Array::newInstance @ bci:2 CopyMethods::makeArray @ bci:2 > CopyMethods::fullTests @ bci:72 > > Vladimir > > Vladimir Kozlov wrote: >> We don't know statically during a method compilation the actual type >> because it is loaded dynamically for reflaction allocation. >> Escape Analysis requires to know the type statically to pass it to >> debug info: >> const Type *t = local->bottom_type(); >> // Is it a safepoint scalar object node? >> if (local->is_SafePointScalarObject()) { >> SafePointScalarObjectNode* spobj = local- >> >as_SafePointScalarObject(); >> ObjectValue* sv = Compile::sv_for_node_id(objs, spobj->_idx); >> if (sv == NULL) { >> ciKlass* cik = t->is_oopptr()->klass(); >> assert(cik->is_instance_klass() || >> cik->is_array_klass(), "Not supported allocation."); >> sv = new ObjectValue(spobj->_idx, >> new ConstantOopWriteValue(cik- >> >encoding())); >> Vladimir >> Tom Rodriguez wrote: >>> I have to admit I don't really follow this logic in the code. How >>> is it that we can allocate something but not know it's actual >>> type? Isn't that required to emit the allocation in the first >>> place? >>> >>> tom >>> >>> On May 7, 2009, at 8:29 PM, Vladimir Kozlov wrote: >>> >>>> >>>> http://cr.openjdk.java.net/~kvn/6836054/webrev.00 >>>> >>>> Fixed 6836054: java/util/Arrays/CopyMethods.java fails on solaris- >>>> sparc with IllegalArgumentException >>>> >>>> Problem: >>>> Escape Analysis requires that allocations should have >>>> exact type (by using CheckCastPP node) for restoring >>>> objects during deoptimization. But reflection allocation >>>> set type to j.l.Object assuming that caller will cast >>>> to exact type. In the failing case there is no cast >>>> to array type so debug info contains incorrect type >>>> (j.l.Object) for scalar replaced array allocation. >>>> It causes the Exception after deoptimization. >>>> >>>> Solution: >>>> Do not mark an allocation as scalar replaceable if >>>> it does not have exact type. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y, bugs case >>>> >>>> Other testing: >>>> JPRT, CTW >>>> >>> From Vladimir.Kozlov at Sun.COM Mon May 11 17:45:34 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 11 May 2009 17:45:34 -0700 Subject: Request for reviews (S): 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException In-Reply-To: References: <4A03A700.9010600@sun.com> <5FDE85EA-884A-4B96-8162-41B21C3F5D14@sun.com> <4A04A904.1030508@sun.com> <4A0875D7.6050903@sun.com> Message-ID: <4A08C6AE.2000702@sun.com> Thanks. I fixed typo. Vladimir Tom Rodriguez wrote: > Right. I get what you're saying and I think I follow it now. Looks > good apart from the typo: accept -> except. > > tom > > On May 11, 2009, at 12:00 PM, Vladimir Kozlov wrote: > >> Sorry for long output. Here is the generated code which >> loads the allocation's actual type dynamically: >> >> 195 ConL === 0 [[ 196 211 ]] #long:24 >> 190 CastPP === 182 11 [[ 176 196 196 206 242 ]] >> #java/lang/Class:NotNull:exact * Oop:java/lang/Class:NotNull:exact * >> !jvms: Array::newInstance @ bci:2 CopyMethods::makeArray @ bci:2 >> CopyMethods::fullTests @ bci:72 >> 196 AddP === _ 190 190 195 [[ 197 ]] >> Oop:java/lang/Class:NotNull:exact+24 * !jvms: Array::newInstance @ >> bci:2 CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 >> 197 LoadKlass === _ 7 196 [[ 198 203 ]] @rawptr:BotPTR, >> idx=Raw; # * Klass: * !jvms: Array::newInstance @ bci:2 >> CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 >> 203 CastPP === 202 197 [[ 211 211 234 ]] #klass >> java/lang/Object: 0x00000000004bcd58 * Klass:klass java/lang/Object: >> 0x00000000004bcd58 * !jvms: Array::newInstance @ bci:2 >> CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 >> 234 AllocateArray === 202 91 92 8 1 ( 232 203 24 24 10 >> 11 68 130 24 1 1 1 1 1 1 24 11 1 1 1 1 ) [[ 235 236 >> 237 244 245 246 ]] rawptr:NotNull ( int:>=0, >> java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 >> CopyMethods::makeArray @ bci:2 CopyMethods::fullTests @ bci:72 !jvms: >> Array::newInstance @ bci:2 CopyMethods::makeArray @ bci:2 >> CopyMethods::fullTests @ bci:72 >> >> Vladimir >> >> Vladimir Kozlov wrote: >>> We don't know statically during a method compilation the actual type >>> because it is loaded dynamically for reflaction allocation. >>> Escape Analysis requires to know the type statically to pass it to >>> debug info: >>> const Type *t = local->bottom_type(); >>> // Is it a safepoint scalar object node? >>> if (local->is_SafePointScalarObject()) { >>> SafePointScalarObjectNode* spobj = local->as_SafePointScalarObject(); >>> ObjectValue* sv = Compile::sv_for_node_id(objs, spobj->_idx); >>> if (sv == NULL) { >>> ciKlass* cik = t->is_oopptr()->klass(); >>> assert(cik->is_instance_klass() || >>> cik->is_array_klass(), "Not supported allocation."); >>> sv = new ObjectValue(spobj->_idx, >>> new ConstantOopWriteValue(cik->encoding())); >>> Vladimir >>> Tom Rodriguez wrote: >>>> I have to admit I don't really follow this logic in the code. How >>>> is it that we can allocate something but not know it's actual type? >>>> Isn't that required to emit the allocation in the first place? >>>> >>>> tom >>>> >>>> On May 7, 2009, at 8:29 PM, Vladimir Kozlov wrote: >>>> >>>>> >>>>> http://cr.openjdk.java.net/~kvn/6836054/webrev.00 >>>>> >>>>> Fixed 6836054: java/util/Arrays/CopyMethods.java fails on >>>>> solaris-sparc with IllegalArgumentException >>>>> >>>>> Problem: >>>>> Escape Analysis requires that allocations should have >>>>> exact type (by using CheckCastPP node) for restoring >>>>> objects during deoptimization. But reflection allocation >>>>> set type to j.l.Object assuming that caller will cast >>>>> to exact type. In the failing case there is no cast >>>>> to array type so debug info contains incorrect type >>>>> (j.l.Object) for scalar replaced array allocation. >>>>> It causes the Exception after deoptimization. >>>>> >>>>> Solution: >>>>> Do not mark an allocation as scalar replaceable if >>>>> it does not have exact type. >>>>> >>>>> Reviewed by: >>>>> >>>>> Fix verified (y/n): y, bugs case >>>>> >>>>> Other testing: >>>>> JPRT, CTW >>>>> >>>> > From vladimir.kozlov at sun.com Mon May 11 21:17:36 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 12 May 2009 04:17:36 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6832293: JIT compiler got wrong result in type checking with -server Message-ID: <20090512041746.CA8AEEA5D@hg.openjdk.java.net> Changeset: a9e116455022 Author: kvn Date: 2009-05-11 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a9e116455022 6832293: JIT compiler got wrong result in type checking with -server Summary: Check for an object array of interface in CmpPNode::sub(). Reviewed-by: never ! src/share/vm/opto/subnode.cpp + test/compiler/6832293/Test.java From vladimir.kozlov at sun.com Mon May 11 23:45:00 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 12 May 2009 06:45:00 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException Message-ID: <20090512064508.16F36EA6F@hg.openjdk.java.net> Changeset: b2934faac289 Author: kvn Date: 2009-05-11 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b2934faac289 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException Summary: Do not mark an allocation as scalar replaceable if its actual type in unknown statically. Reviewed-by: never ! src/share/vm/opto/escape.cpp From Christian.Thalinger at Sun.COM Tue May 12 03:02:23 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 12 May 2009 12:02:23 +0200 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> Message-ID: <1242122546.27008.110.camel@macbook> On Mon, 2009-05-11 at 13:38 -0700, Tom Rodriguez wrote: > I don't think the assert in formssel.cpp is needed because it > replicates the logic in this test that guards enabling cisc spill. > I'd given that to you originally before I fully realized what was > going wrong. I removed the assert. > > 1127 if( def_oper == NameList::Not_in_list && instr->num_opnds() > == num_opnds()) { > > in sparc.ad you use simm13 instead of 13 bit in the comments since > that's the sparc terminology. I changed the ones I added, the others are just copied. http://cr.openjdk.java.net/~twisti/6814842/webrev.03/ -- Christian From Thomas.Rodriguez at Sun.COM Tue May 12 09:23:21 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 12 May 2009 09:23:21 -0700 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <1242122546.27008.110.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> Message-ID: <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> looks good. tom On May 12, 2009, at 3:02 AM, Christian Thalinger wrote: > On Mon, 2009-05-11 at 13:38 -0700, Tom Rodriguez wrote: >> I don't think the assert in formssel.cpp is needed because it >> replicates the logic in this test that guards enabling cisc spill. >> I'd given that to you originally before I fully realized what was >> going wrong. > > I removed the assert. > >> >> 1127 if( def_oper == NameList::Not_in_list && instr->num_opnds() >> == num_opnds()) { >> >> in sparc.ad you use simm13 instead of 13 bit in the comments since >> that's the sparc terminology. > > I changed the ones I added, the others are just copied. > > http://cr.openjdk.java.net/~twisti/6814842/webrev.03/ > > -- Christian > From Vladimir.Kozlov at Sun.COM Tue May 12 10:26:16 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 12 May 2009 10:26:16 -0700 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> Message-ID: <4A09B138.5000302@sun.com> Christian, in immL13m7() it should be <= (-4096L <= (n->get_long() + 7L)) ^ Can you explain how indOffset13m7 memory reference is generated when offset does not fit into 13 bits? I did not find the explanation in this thread. For example: + format %{ "LDSB $mem+1,$dst\t! short -> byte" %} + ins_encode %{ + __ ldsb($mem$$Address, $dst$$Register, 1); + %} Let mem.disp == -4100 (so that -4100+7 > -4096) and with ldsb(mem, reg, 1) you will get mem.disp == -4099 which does not fit into 13 bits. Thanks, Vladimir Tom Rodriguez wrote: > looks good. > > tom > > On May 12, 2009, at 3:02 AM, Christian Thalinger wrote: > >> On Mon, 2009-05-11 at 13:38 -0700, Tom Rodriguez wrote: >>> I don't think the assert in formssel.cpp is needed because it >>> replicates the logic in this test that guards enabling cisc spill. >>> I'd given that to you originally before I fully realized what was >>> going wrong. >> >> I removed the assert. >> >>> >>> 1127 if( def_oper == NameList::Not_in_list && instr->num_opnds() >>> == num_opnds()) { >>> >>> in sparc.ad you use simm13 instead of 13 bit in the comments since >>> that's the sparc terminology. >> >> I changed the ones I added, the others are just copied. >> >> http://cr.openjdk.java.net/~twisti/6814842/webrev.03/ >> >> -- Christian >> > From Vladimir.Kozlov at Sun.COM Tue May 12 10:38:59 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 12 May 2009 10:38:59 -0700 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <4A09B138.5000302@sun.com> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> Message-ID: <4A09B433.7080102@sun.com> It could be solved by using next restriction on indOffset13m7: predicate((-4096L <= (n->get_long())) && ((n->get_long() + 7L) <= 4095L)); Vladimir Vladimir Kozlov wrote: > Christian, > > in immL13m7() it should be <= > > (-4096L <= (n->get_long() + 7L)) > ^ > > Can you explain how indOffset13m7 memory reference is generated > when offset does not fit into 13 bits? I did not find the explanation > in this thread. > > For example: > > + format %{ "LDSB $mem+1,$dst\t! short -> byte" %} > + ins_encode %{ > + __ ldsb($mem$$Address, $dst$$Register, 1); > + %} > > Let mem.disp == -4100 (so that -4100+7 > -4096) and with ldsb(mem, reg, 1) > you will get mem.disp == -4099 which does not fit into 13 bits. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> looks good. >> >> tom >> >> On May 12, 2009, at 3:02 AM, Christian Thalinger wrote: >> >>> On Mon, 2009-05-11 at 13:38 -0700, Tom Rodriguez wrote: >>>> I don't think the assert in formssel.cpp is needed because it >>>> replicates the logic in this test that guards enabling cisc spill. >>>> I'd given that to you originally before I fully realized what was >>>> going wrong. >>> >>> I removed the assert. >>> >>>> >>>> 1127 if( def_oper == NameList::Not_in_list && instr->num_opnds() >>>> == num_opnds()) { >>>> >>>> in sparc.ad you use simm13 instead of 13 bit in the comments since >>>> that's the sparc terminology. >>> >>> I changed the ones I added, the others are just copied. >>> >>> http://cr.openjdk.java.net/~twisti/6814842/webrev.03/ >>> >>> -- Christian >>> >> From Thomas.Rodriguez at Sun.COM Tue May 12 11:24:03 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 12 May 2009 11:24:03 -0700 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <4A09B433.7080102@sun.com> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> <4A09B433.7080102@sun.com> Message-ID: <87AA0492-1A22-4668-B3AC-EF9D56D680E5@Sun.COM> indOffset13m7 uses immX13m7 so it effectively contains this predicate. Why would it need it again? tom On May 12, 2009, at 10:38 AM, Vladimir Kozlov wrote: > It could be solved by using next restriction on indOffset13m7: > > predicate((-4096L <= (n->get_long())) && ((n->get_long() + 7L) <= > 4095L)); > > Vladimir > > Vladimir Kozlov wrote: >> Christian, >> in immL13m7() it should be <= >> (-4096L <= (n->get_long() + 7L)) >> ^ >> Can you explain how indOffset13m7 memory reference is generated >> when offset does not fit into 13 bits? I did not find the explanation >> in this thread. >> For example: >> + format %{ "LDSB $mem+1,$dst\t! short -> byte" %} >> + ins_encode %{ >> + __ ldsb($mem$$Address, $dst$$Register, 1); >> + %} >> Let mem.disp == -4100 (so that -4100+7 > -4096) and with ldsb(mem, >> reg, 1) >> you will get mem.disp == -4099 which does not fit into 13 bits. >> Thanks, >> Vladimir >> Tom Rodriguez wrote: >>> looks good. >>> >>> tom >>> >>> On May 12, 2009, at 3:02 AM, Christian Thalinger wrote: >>> >>>> On Mon, 2009-05-11 at 13:38 -0700, Tom Rodriguez wrote: >>>>> I don't think the assert in formssel.cpp is needed because it >>>>> replicates the logic in this test that guards enabling cisc spill. >>>>> I'd given that to you originally before I fully realized what was >>>>> going wrong. >>>> >>>> I removed the assert. >>>> >>>>> >>>>> 1127 if( def_oper == NameList::Not_in_list && instr- >>>>> >num_opnds() >>>>> == num_opnds()) { >>>>> >>>>> in sparc.ad you use simm13 instead of 13 bit in the comments since >>>>> that's the sparc terminology. >>>> >>>> I changed the ones I added, the others are just copied. >>>> >>>> http://cr.openjdk.java.net/~twisti/6814842/webrev.03/ >>>> >>>> -- Christian >>>> >>> From Christian.Thalinger at Sun.COM Tue May 12 11:25:21 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 12 May 2009 20:25:21 +0200 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <4A09B433.7080102@sun.com> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> <4A09B433.7080102@sun.com> Message-ID: <1242152732.27008.122.camel@macbook> On Tue, 2009-05-12 at 10:38 -0700, Vladimir Kozlov wrote: > It could be solved by using next restriction on indOffset13m7: > > predicate((-4096L <= (n->get_long())) && ((n->get_long() + 7L) <= 4095L)); Exactly. I wanted to suggest the same thing. I will change that and submit, if you are fine with that. -- Christian From Vladimir.Kozlov at Sun.COM Tue May 12 11:27:45 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 12 May 2009 11:27:45 -0700 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <87AA0492-1A22-4668-B3AC-EF9D56D680E5@Sun.COM> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> <4A09B433.7080102@sun.com> <87AA0492-1A22-4668-B3AC-EF9D56D680E5@Sun.COM> Message-ID: <4A09BFA1.4010209@sun.com> Tom Rodriguez wrote: > indOffset13m7 uses immX13m7 so it effectively contains this predicate. > Why would it need it again? I misspoke, I meant immX13m7. What I am saying the used predicate is wrong: it should be (for int and long) -4096 <= n->get_int() instead of -4096 <= (n->get_int() + 7) Vladimir > > tom > > On May 12, 2009, at 10:38 AM, Vladimir Kozlov wrote: > >> It could be solved by using next restriction on indOffset13m7: >> >> predicate((-4096L <= (n->get_long())) && ((n->get_long() + 7L) <= >> 4095L)); >> >> Vladimir >> >> Vladimir Kozlov wrote: >>> Christian, >>> in immL13m7() it should be <= >>> (-4096L <= (n->get_long() + 7L)) >>> ^ >>> Can you explain how indOffset13m7 memory reference is generated >>> when offset does not fit into 13 bits? I did not find the explanation >>> in this thread. >>> For example: >>> + format %{ "LDSB $mem+1,$dst\t! short -> byte" %} >>> + ins_encode %{ >>> + __ ldsb($mem$$Address, $dst$$Register, 1); >>> + %} >>> Let mem.disp == -4100 (so that -4100+7 > -4096) and with ldsb(mem, >>> reg, 1) >>> you will get mem.disp == -4099 which does not fit into 13 bits. >>> Thanks, >>> Vladimir >>> Tom Rodriguez wrote: >>>> looks good. >>>> >>>> tom >>>> >>>> On May 12, 2009, at 3:02 AM, Christian Thalinger wrote: >>>> >>>>> On Mon, 2009-05-11 at 13:38 -0700, Tom Rodriguez wrote: >>>>>> I don't think the assert in formssel.cpp is needed because it >>>>>> replicates the logic in this test that guards enabling cisc spill. >>>>>> I'd given that to you originally before I fully realized what was >>>>>> going wrong. >>>>> >>>>> I removed the assert. >>>>> >>>>>> >>>>>> 1127 if( def_oper == NameList::Not_in_list && instr->num_opnds() >>>>>> == num_opnds()) { >>>>>> >>>>>> in sparc.ad you use simm13 instead of 13 bit in the comments since >>>>>> that's the sparc terminology. >>>>> >>>>> I changed the ones I added, the others are just copied. >>>>> >>>>> http://cr.openjdk.java.net/~twisti/6814842/webrev.03/ >>>>> >>>>> -- Christian >>>>> >>>> > From Vladimir.Kozlov at Sun.COM Tue May 12 11:29:42 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 12 May 2009 11:29:42 -0700 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <1242152732.27008.122.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> <4A09B433.7080102@sun.com> <1242152732.27008.122.camel@macbook> Message-ID: <4A09C016.5050802@sun.com> Christian, You have to replace also + predicate(Assembler::is_simm13(n->get_int() + 7)); with explicit predicate as for long. Vladimir Christian Thalinger wrote: > On Tue, 2009-05-12 at 10:38 -0700, Vladimir Kozlov wrote: >> It could be solved by using next restriction on indOffset13m7: >> >> predicate((-4096L <= (n->get_long())) && ((n->get_long() + 7L) <= 4095L)); > > Exactly. I wanted to suggest the same thing. I will change that and > submit, if you are fine with that. > > -- Christian > From Christian.Thalinger at Sun.COM Tue May 12 11:30:57 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 12 May 2009 20:30:57 +0200 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <87AA0492-1A22-4668-B3AC-EF9D56D680E5@Sun.COM> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> <4A09B433.7080102@sun.com> <87AA0492-1A22-4668-B3AC-EF9D56D680E5@Sun.COM> Message-ID: <1242153062.27008.125.camel@macbook> On Tue, 2009-05-12 at 11:24 -0700, Tom Rodriguez wrote: > indOffset13m7 uses immX13m7 so it effectively contains this > predicate. Why would it need it again? I think the predicate of immX13m7 should be changed to: predicate((-4096L < n->get_long()) && ((n->get_long() + 7L) <= 4095L)); -- Christian From Christian.Thalinger at Sun.COM Tue May 12 11:35:07 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 12 May 2009 20:35:07 +0200 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <4A09C016.5050802@sun.com> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> <4A09B433.7080102@sun.com> <1242152732.27008.122.camel@macbook> <4A09C016.5050802@sun.com> Message-ID: <1242153323.27008.126.camel@macbook> On Tue, 2009-05-12 at 11:29 -0700, Vladimir Kozlov wrote: > Christian, > > You have to replace also > > + predicate(Assembler::is_simm13(n->get_int() + 7)); > > with explicit predicate as for long. True, I missed that. Thanks. -- Christian From Thomas.Rodriguez at Sun.COM Tue May 12 11:54:54 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 12 May 2009 11:54:54 -0700 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <4A09BFA1.4010209@sun.com> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> <4A09B433.7080102@sun.com> <87AA0492-1A22-4668-B3AC-EF9D56D680E5@Sun.COM> <4A09BFA1.4010209@sun.com> Message-ID: Ah right, the is_simm13 test isn't correct at the bottom since we're smearing a bunch of potential offsets together. tom On May 12, 2009, at 11:27 AM, Vladimir Kozlov wrote: > > Tom Rodriguez wrote: >> indOffset13m7 uses immX13m7 so it effectively contains this >> predicate. Why would it need it again? > > I misspoke, I meant immX13m7. > What I am saying the used predicate is wrong: > > it should be (for int and long) > > -4096 <= n->get_int() > > instead of > > -4096 <= (n->get_int() + 7) > > Vladimir > >> tom >> On May 12, 2009, at 10:38 AM, Vladimir Kozlov wrote: >>> It could be solved by using next restriction on indOffset13m7: >>> >>> predicate((-4096L <= (n->get_long())) && ((n->get_long() + 7L) <= >>> 4095L)); >>> >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> Christian, >>>> in immL13m7() it should be <= >>>> (-4096L <= (n->get_long() + 7L)) >>>> ^ >>>> Can you explain how indOffset13m7 memory reference is generated >>>> when offset does not fit into 13 bits? I did not find the >>>> explanation >>>> in this thread. >>>> For example: >>>> + format %{ "LDSB $mem+1,$dst\t! short -> byte" %} >>>> + ins_encode %{ >>>> + __ ldsb($mem$$Address, $dst$$Register, 1); >>>> + %} >>>> Let mem.disp == -4100 (so that -4100+7 > -4096) and with >>>> ldsb(mem, reg, 1) >>>> you will get mem.disp == -4099 which does not fit into 13 bits. >>>> Thanks, >>>> Vladimir >>>> Tom Rodriguez wrote: >>>>> looks good. >>>>> >>>>> tom >>>>> >>>>> On May 12, 2009, at 3:02 AM, Christian Thalinger wrote: >>>>> >>>>>> On Mon, 2009-05-11 at 13:38 -0700, Tom Rodriguez wrote: >>>>>>> I don't think the assert in formssel.cpp is needed because it >>>>>>> replicates the logic in this test that guards enabling cisc >>>>>>> spill. >>>>>>> I'd given that to you originally before I fully realized what >>>>>>> was >>>>>>> going wrong. >>>>>> >>>>>> I removed the assert. >>>>>> >>>>>>> >>>>>>> 1127 if( def_oper == NameList::Not_in_list && instr- >>>>>>> >num_opnds() >>>>>>> == num_opnds()) { >>>>>>> >>>>>>> in sparc.ad you use simm13 instead of 13 bit in the comments >>>>>>> since >>>>>>> that's the sparc terminology. >>>>>> >>>>>> I changed the ones I added, the others are just copied. >>>>>> >>>>>> http://cr.openjdk.java.net/~twisti/6814842/webrev.03/ >>>>>> >>>>>> -- Christian >>>>>> >>>>> From Christian.Thalinger at Sun.COM Tue May 12 13:22:36 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 12 May 2009 22:22:36 +0200 Subject: Request for reviews (L): 5057225: Remove useless I2L conversions Message-ID: <1242159760.15714.5.camel@macbook> http://cr.openjdk.java.net/~twisti/5057225/webrev.01/ Please ignore the duplicated code (and same bugs) as in 6814842. Firstly I will commit 6814842 and then use the code in this CR. -- Christian From yamauchi at google.com Tue May 12 13:26:06 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 12 May 2009 13:26:06 -0700 Subject: Announcement: Visualization tool for client compiler In-Reply-To: <4702DE51.1020605@sun.com> References: <00a101c80392$c1ce9930$d8914e8c@Bianca> <00ac01c8040e$eca83900$d8914e8c@Bianca> <4702DE51.1020605@sun.com> Message-ID: Hi, Has this C2 visualizer been released? Is there a way to get access to it now? Thanks, Hiroshi On Tue, Oct 2, 2007 at 5:12 PM, Tom Rodriguez wrote: > I recently putback changes to C2 to output the files that the C2 visualizer > expects and we're trying to figure out how we want to handle licensing of it > so that we can put the visualizer up as a java.net project as well. > ?Hopefully we can get figure this out fairly quickly. > > tom > > Christian Wimmer wrote: >> >> Hi >> >>> looks like a great Tool. Any plans do extend this for the C2 compiler? >> >> A visualizer for C2 is also under development at the University Linz, see >> e.g. the following master's thesis: >> http://www.ssw.uni-linz.ac.at/Research/Papers/Wuerthinger07Master/ >> >> It is developed in a research project together with Sun, so a bunch of >> legal >> issues must be resolved before it is possibly published. >> >> Christian >> > From wimmer at ssw.jku.at Tue May 12 13:38:57 2009 From: wimmer at ssw.jku.at (Christian Wimmer) Date: Tue, 12 May 2009 13:38:57 -0700 Subject: Announcement: Visualization tool for client compiler In-Reply-To: References: <00a101c80392$c1ce9930$d8914e8c@Bianca> <00ac01c8040e$eca83900$d8914e8c@Bianca> <4702DE51.1020605@sun.com> Message-ID: <0F36BED2-76B0-4E0B-8A00-8DA97D768C88@ssw.jku.at> Hi, > Has this C2 visualizer been released? Is there a way to get access > to it now? Yes. It is part of HotSpot in the OpenJDK distribution. However, the newest version and the development is going on on Kenai: http://kenai.com/projects/igv Christian From Christian.Thalinger at Sun.COM Tue May 12 13:52:31 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 12 May 2009 22:52:31 +0200 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <1242153323.27008.126.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> <4A09B433.7080102@sun.com> <1242152732.27008.122.camel@macbook> <4A09C016.5050802@sun.com> <1242153323.27008.126.camel@macbook> Message-ID: <1242161555.15714.10.camel@macbook> On Tue, 2009-05-12 at 20:35 +0200, Christian Thalinger wrote: > On Tue, 2009-05-12 at 11:29 -0700, Vladimir Kozlov wrote: > > Christian, > > > > You have to replace also > > > > + predicate(Assembler::is_simm13(n->get_int() + 7)); > > > > with explicit predicate as for long. > > True, I missed that. Thanks. This should be it: http://cr.openjdk.java.net/~twisti/6814842/webrev.04/ -- Christian From Vladimir.Kozlov at Sun.COM Tue May 12 13:57:19 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 12 May 2009 13:57:19 -0700 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <1242161555.15714.10.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> <4A09B433.7080102@sun.com> <1242152732.27008.122.camel@macbook> <4A09C016.5050802@sun.com> <1242153323.27008.126.camel@macbook> <1242161555.15714.10.camel@macbook> Message-ID: <4A09E2AF.3090009@sun.com> Looks good. Vladimir Christian Thalinger wrote: > On Tue, 2009-05-12 at 20:35 +0200, Christian Thalinger wrote: >> On Tue, 2009-05-12 at 11:29 -0700, Vladimir Kozlov wrote: >>> Christian, >>> >>> You have to replace also >>> >>> + predicate(Assembler::is_simm13(n->get_int() + 7)); >>> >>> with explicit predicate as for long. >> True, I missed that. Thanks. > > This should be it: > > http://cr.openjdk.java.net/~twisti/6814842/webrev.04/ > > -- Christian > From yamauchi at google.com Tue May 12 14:28:56 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 12 May 2009 14:28:56 -0700 Subject: Announcement: Visualization tool for client compiler In-Reply-To: <0F36BED2-76B0-4E0B-8A00-8DA97D768C88@ssw.jku.at> References: <00a101c80392$c1ce9930$d8914e8c@Bianca> <00ac01c8040e$eca83900$d8914e8c@Bianca> <4702DE51.1020605@sun.com> <0F36BED2-76B0-4E0B-8A00-8DA97D768C88@ssw.jku.at> Message-ID: Hi Christian, Good news. Where in the OpenJDK distribution is the tool? Hiroshi On Tue, May 12, 2009 at 1:38 PM, Christian Wimmer wrote: > Hi, > >> Has this C2 visualizer been released? Is there a way to get access to it >> now? > > Yes. It is part of HotSpot in the OpenJDK distribution. However, the newest > version and the development is going on on Kenai: > http://kenai.com/projects/igv > > Christian > > From Thomas.Rodriguez at Sun.COM Tue May 12 16:41:54 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 12 May 2009 16:41:54 -0700 Subject: Request for reviews .03 (L): 6814842: Load shortening optimizations In-Reply-To: <1242161555.15714.10.camel@macbook> References: <1236622538.2239.867.camel@localhost.localdomain> <1241702696.9518.111.camel@macbook> <1242055396.27008.93.camel@macbook> <7073BFAC-F9EC-49D4-A899-9295300790D7@sun.com> <1242122546.27008.110.camel@macbook> <84718398-05D2-4848-B8DF-688F2773AAF5@Sun.COM> <4A09B138.5000302@sun.com> <4A09B433.7080102@sun.com> <1242152732.27008.122.camel@macbook> <4A09C016.5050802@sun.com> <1242153323.27008.126.camel@macbook> <1242161555.15714.10.camel@macbook> Message-ID: looks good. tom On May 12, 2009, at 1:52 PM, Christian Thalinger wrote: > On Tue, 2009-05-12 at 20:35 +0200, Christian Thalinger wrote: >> On Tue, 2009-05-12 at 11:29 -0700, Vladimir Kozlov wrote: >>> Christian, >>> >>> You have to replace also >>> >>> + predicate(Assembler::is_simm13(n->get_int() + 7)); >>> >>> with explicit predicate as for long. >> >> True, I missed that. Thanks. > > This should be it: > > http://cr.openjdk.java.net/~twisti/6814842/webrev.04/ > > -- Christian > From Christian.Thalinger at Sun.COM Wed May 13 03:03:46 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 13 May 2009 10:03:46 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6814842: Load shortening optimizations Message-ID: <20090513100353.87152ECBF@hg.openjdk.java.net> Changeset: 2056494941db Author: twisti Date: 2009-05-13 00:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2056494941db 6814842: Load shortening optimizations Summary: 6797305 handles load widening but no shortening which should be covered here. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/output_c.cpp + test/compiler/6814842/Test6814842.java From Christian.Thalinger at Sun.COM Wed May 13 04:18:54 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 13 May 2009 13:18:54 +0200 Subject: Request for reviews .02 (L): 5057225: Remove useless I2L conversions In-Reply-To: <1242159760.15714.5.camel@macbook> References: <1242159760.15714.5.camel@macbook> Message-ID: <1242213534.15714.24.camel@macbook> http://cr.openjdk.java.net/~twisti/5057225/webrev.02/ This is an updated version with the changes of 6814842 merged in. -- Christian From Thomas.Rodriguez at Sun.COM Wed May 13 10:50:23 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 13 May 2009 10:50:23 -0700 Subject: Announcement: Visualization tool for client compiler In-Reply-To: References: <00a101c80392$c1ce9930$d8914e8c@Bianca> <00ac01c8040e$eca83900$d8914e8c@Bianca> <4702DE51.1020605@sun.com> <0F36BED2-76B0-4E0B-8A00-8DA97D768C88@ssw.jku.at> Message-ID: <22663119-3B3F-469E-B674-59888026D3CB@sun.com> It's in src/share/tools/IdealGraphVisualizer. The README provides some more detail about how to build and use it. The version on kenai that Christian mentioned is a somewhat improved version by the student that designed and built the tool, Thomas Wuerthinger. I believe he has Java Web Start links that would let you launch and use the tool without having to build it. tom On May 12, 2009, at 2:28 PM, Hiroshi Yamauchi wrote: > Hi Christian, > > Good news. Where in the OpenJDK distribution is the tool? > > Hiroshi > > On Tue, May 12, 2009 at 1:38 PM, Christian Wimmer > wrote: >> Hi, >> >>> Has this C2 visualizer been released? Is there a way to get access >>> to it >>> now? >> >> Yes. It is part of HotSpot in the OpenJDK distribution. However, >> the newest >> version and the development is going on on Kenai: >> http://kenai.com/projects/igv >> >> Christian >> >> From Christian.Thalinger at Sun.COM Thu May 14 05:01:32 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 14 May 2009 14:01:32 +0200 Subject: Request for reviews .02 (L): 5057225: Remove useless I2L conversions In-Reply-To: <1242213534.15714.24.camel@macbook> References: <1242159760.15714.5.camel@macbook> <1242213534.15714.24.camel@macbook> Message-ID: <1242302492.1482.5.camel@macbook> On Wed, 2009-05-13 at 13:18 +0200, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/5057225/webrev.02/ > > This is an updated version with the changes of 6814842 merged in. I found a problem during testing and have to investigate that further. -- Christian From john.coomes at sun.com Thu May 14 21:29:12 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 04:29:12 +0000 Subject: hg: jdk7/hotspot-comp: 2 new changesets Message-ID: <20090515042912.865E7EEBD@hg.openjdk.java.net> Changeset: 030142474602 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/030142474602 Added tag jdk7-b58 for changeset 59b497130f82 ! .hgtags Changeset: 0d76c4da605f Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/0d76c4da605f Added tag jdk7-b59 for changeset 030142474602 ! .hgtags From john.coomes at sun.com Thu May 14 21:33:06 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 04:33:06 +0000 Subject: hg: jdk7/hotspot-comp/corba: 4 new changesets Message-ID: <20090515043310.82975EEC4@hg.openjdk.java.net> Changeset: e149090eb21a Author: tbell Date: 2009-05-04 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/e149090eb21a 6529590: flaw in com.sun.corba.se.impl.presentation.rmi.IDLNameTranslatorImpl Reviewed-by: darcy ! make/com/sun/corba/se/sources/Makefile ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java ! src/share/classes/com/sun/tools/corba/se/idl/first.set ! src/share/classes/com/sun/tools/corba/se/idl/follow.set ! src/share/classes/com/sun/tools/corba/se/idl/grammar.idl ! src/share/classes/com/sun/tools/corba/se/idl/grammar3.idl ! src/share/classes/com/sun/tools/corba/se/idl/idl.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp Changeset: 2e3b8edab3ef Author: tbell Date: 2009-05-04 22:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/2e3b8edab3ef Merge Changeset: 7e6b2b55c00c Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/7e6b2b55c00c Added tag jdk7-b58 for changeset 2e3b8edab3ef ! .hgtags Changeset: e9ba2b962ddf Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/e9ba2b962ddf Added tag jdk7-b59 for changeset 7e6b2b55c00c ! .hgtags From john.coomes at sun.com Thu May 14 21:41:09 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 04:41:09 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 4 new changesets Message-ID: <20090515044115.B81A7EEC9@hg.openjdk.java.net> Changeset: 3abf80631f99 Author: tbell Date: 2009-05-04 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/3abf80631f99 6588002: XSLTProcessorApplet still allows reading from forbidden URLs Reviewed-by: darcy - src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java - src/share/classes/com/sun/org/apache/xalan/internal/client/package.html Changeset: 13bf67d8c634 Author: tbell Date: 2009-05-04 22:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/13bf67d8c634 Merge - src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java - src/share/classes/com/sun/org/apache/xalan/internal/client/package.html Changeset: 75113d7ce083 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/75113d7ce083 Added tag jdk7-b58 for changeset 13bf67d8c634 ! .hgtags Changeset: 748976d69503 Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/748976d69503 Added tag jdk7-b59 for changeset 75113d7ce083 ! .hgtags From john.coomes at sun.com Thu May 14 21:45:10 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 04:45:10 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 4 new changesets Message-ID: <20090515044515.EA378EECE@hg.openjdk.java.net> Changeset: 42dfec6871f6 Author: tbell Date: 2009-05-04 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/42dfec6871f6 6658158: Mutable statics in SAAJ (findbugs) 6658163: txw2.DatatypeWriter.BUILDIN is a mutable static (findbugs) Reviewed-by: darcy ! src/share/classes/com/sun/codemodel/internal/JClassContainer.java ! src/share/classes/com/sun/codemodel/internal/JDefinedClass.java ! src/share/classes/com/sun/codemodel/internal/JForEach.java ! src/share/classes/com/sun/codemodel/internal/JMethod.java ! src/share/classes/com/sun/codemodel/internal/JMods.java ! src/share/classes/com/sun/codemodel/internal/util/SingleByteEncoder.java ! src/share/classes/com/sun/codemodel/internal/util/Surrogate.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CommentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/RejectDoctypeSaxFilter.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/transform/EfficientStreamingTransformer.java ! src/share/classes/com/sun/xml/internal/txw2/DatatypeWriter.java ! src/share/classes/com/sun/xml/internal/txw2/Document.java Changeset: 5fb4fbea81c3 Author: tbell Date: 2009-05-04 22:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/5fb4fbea81c3 Merge Changeset: f64566bf4c2b Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/f64566bf4c2b Added tag jdk7-b58 for changeset 5fb4fbea81c3 ! .hgtags Changeset: 4fa7398559d0 Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/4fa7398559d0 Added tag jdk7-b59 for changeset f64566bf4c2b ! .hgtags From john.coomes at sun.com Thu May 14 21:50:25 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 04:50:25 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 27 new changesets Message-ID: <20090515045614.0C16FEED3@hg.openjdk.java.net> Changeset: b056c42ea5b4 Author: tbell Date: 2009-05-04 18:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b056c42ea5b4 6837214: Update JDK7 man pages Reviewed-by: darcy, bpatel, tbell Contributed-by: jacob.royal at sun.com ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/apt.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/apt.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/javaws.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/apt.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/apt.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 ! src/solaris/doc/sun/man/man1/ja/javaws.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/javaws.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 Changeset: a33222e53611 Author: prr Date: 2009-04-02 10:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a33222e53611 6753173: No need to read all the TrueType 'post' table to get underline info Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/TrueTypeFont.java Changeset: e3b4eb55a696 Author: lana Date: 2009-04-08 15:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e3b4eb55a696 Merge - make/common/shared/Compiler.gmk - make/jprt.config - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: e61d93fc8ed1 Author: mchung Date: 2009-04-14 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e61d93fc8ed1 6818072: Load Ductus using Class.forName if exist instead of using the service loader Summary: First attempt Class.forName to load Ductus class before using service loader Reviewed-by: flar, prr ! src/share/classes/sun/java2d/pipe/RenderingEngine.java Changeset: d609ae2faac2 Author: jgodinez Date: 2009-04-15 08:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d609ae2faac2 6827989: Use Unsafe.copyMemory for array->Unsafe copy operations in RenderBuffer Reviewed-by: campbell, flar Contributed-by: linuxhippy ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/java2d/pipe/RenderBuffer.java - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: c3aaa11e4eb6 Author: jgodinez Date: 2009-04-20 12:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c3aaa11e4eb6 6821495: test/java/awt/print/PrinterJob/PrtException.java fails Reviewed-by: igor, prr ! test/java/awt/PrintJob/EdgeTest/EdgeTest.java ! test/java/awt/PrintJob/MultipleEnd/MultipleEnd.java + test/java/awt/print/PrinterJob/Collate2DPrintingTest.java + test/java/awt/print/PrinterJob/PrtException.java ! test/javax/print/CheckDupFlavor.java + test/javax/print/LookupServices.java ! test/javax/print/TestRaceCond.java + test/javax/print/attribute/Chroma.java + test/javax/print/attribute/ChromaticityValues.java + test/javax/print/attribute/GetCopiesSupported.java ! test/javax/print/attribute/PSCopiesFlavorTest.java + test/javax/print/attribute/SidesPageRangesTest.java + test/javax/print/attribute/SupportedPrintableAreas.java + test/javax/print/attribute/autosense/PrintAutoSenseData.java Changeset: 53ca5822bdfe Author: jgodinez Date: 2009-04-21 09:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/53ca5822bdfe 6829678: StrokeShapeTest: createStrokedShape() behaves differently Reviewed-by: igor, flar Contributed-by: rkennke ! src/share/classes/sun/java2d/pisces/Stroker.java + test/sun/pisces/StrokeShapeTest.java Changeset: b4450e6de8a3 Author: jgodinez Date: 2009-04-28 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b4450e6de8a3 Merge ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/font/TrueTypeFont.java - src/share/classes/sun/text/normalizer/UProperty.java - src/share/native/java/util/zip/ZipEntry.c - src/windows/native/sun/windows/awt_KeyboardFocusManager.h Changeset: 662a327cfe1d Author: jgodinez Date: 2009-04-29 12:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/662a327cfe1d Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: f8b061ea131c Author: jgodinez Date: 2009-05-05 09:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f8b061ea131c Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: 057e4afcf978 Author: alanb Date: 2009-04-23 19:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/057e4afcf978 6832557: TEST_BUG: java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java fails to compile Reviewed-by: darcy, mcimadamore ! test/java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java Changeset: 164ce9ff8b58 Author: mchung Date: 2009-04-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/164ce9ff8b58 6829503: addShutdownHook fails if called after shutdown has commenced. Summary: allow shutdown hook to be added during shutdown and handle properly if it fails to add Reviewed-by: alanb, dholmes, martin ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/DeleteOnExitHook.java ! src/share/classes/java/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Shutdown.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java + test/java/lang/Runtime/shutdown/ShutdownHooks.java + test/java/lang/Runtime/shutdown/ShutdownHooks.sh Changeset: d2114c1adb2d Author: sherman Date: 2009-05-01 12:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d2114c1adb2d 6836489: Incorrect @link usage in java.util.zip API doc Summary: correct the wrong @link tag Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java Changeset: e1a713f0361f Author: alanb Date: 2009-05-04 19:25 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e1a713f0361f 6834246: (ch) AsynchronousSocketChannel#write completes with wrong number of bytes written under load (win) Reviewed-by: sherman ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c + test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Changeset: b3720710a4ba Author: tbell Date: 2009-05-04 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b3720710a4ba Merge Changeset: d201987cb76c Author: jrose Date: 2009-05-05 22:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d201987cb76c 6829144: JSR 292 JVM features need a provisional Java API Summary: JDK API and runtime (partial) for anonk, meth, indy Reviewed-by: mr ! make/docs/CORE_PKGS.gmk ! make/java/Makefile + make/java/dyn/Makefile + src/share/classes/java/dyn/CallSite.java + src/share/classes/java/dyn/InvokeDynamic.java + src/share/classes/java/dyn/InvokeDynamicBootstrapError.java + src/share/classes/java/dyn/JavaMethodHandle.java + src/share/classes/java/dyn/Linkage.java + src/share/classes/java/dyn/LinkagePermission.java + src/share/classes/java/dyn/MethodHandle.java + src/share/classes/java/dyn/MethodHandles.java + src/share/classes/java/dyn/MethodType.java + src/share/classes/java/dyn/MethodTypeForm.java + src/share/classes/java/dyn/NoAccessException.java + src/share/classes/java/dyn/WrongMethodTypeException.java + src/share/classes/java/dyn/package-info.java + src/share/classes/sun/dyn/Access.java + src/share/classes/sun/dyn/AdapterMethodHandle.java + src/share/classes/sun/dyn/BoundMethodHandle.java + src/share/classes/sun/dyn/CallSiteImpl.java + src/share/classes/sun/dyn/DirectMethodHandle.java + src/share/classes/sun/dyn/FilterGeneric.java + src/share/classes/sun/dyn/FilterOneArgument.java + src/share/classes/sun/dyn/FromGeneric.java + src/share/classes/sun/dyn/Invokers.java + src/share/classes/sun/dyn/MemberName.java + src/share/classes/sun/dyn/MethodHandleImpl.java + src/share/classes/sun/dyn/MethodHandleNatives.java + src/share/classes/sun/dyn/MethodTypeImpl.java + src/share/classes/sun/dyn/ToGeneric.java + src/share/classes/sun/dyn/anon/AnonymousClassLoader.java + src/share/classes/sun/dyn/anon/ConstantPoolParser.java + src/share/classes/sun/dyn/anon/ConstantPoolPatch.java + src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java + src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java + src/share/classes/sun/dyn/empty/Empty.java + src/share/classes/sun/dyn/package-info.java + src/share/classes/sun/dyn/util/BytecodeName.java + src/share/classes/sun/dyn/util/BytecodeSignature.java + src/share/classes/sun/dyn/util/ValueConversions.java + src/share/classes/sun/dyn/util/VerifyAccess.java + src/share/classes/sun/dyn/util/VerifyType.java + src/share/classes/sun/dyn/util/Wrapper.java + src/share/classes/sun/dyn/util/package-info.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/javavm/export/classfile_constants.h ! src/share/native/common/check_code.c ! src/share/native/common/opcodes.in_out Changeset: 9ba256e2e5c1 Author: tbell Date: 2009-05-05 23:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9ba256e2e5c1 Merge Changeset: 878863c9072d Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/878863c9072d Added tag jdk7-b58 for changeset 9ba256e2e5c1 ! .hgtags Changeset: 2007e3d9c195 Author: anthony Date: 2009-05-05 14:45 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2007e3d9c195 6762511: Translucency is not working on Linux using Metacity Summary: Introduced additional blits and new X11 surface types (ARGB, ABGR) Reviewed-by: art, avu ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: ba95c9101e50 Author: art Date: 2009-05-06 12:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ba95c9101e50 6837004: java.awt.GraphicsDevice.setFullScreenWindow throws NPE for windows with background color not set Reviewed-by: yan, dcherepanov ! src/share/classes/java/awt/GraphicsDevice.java + test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java Changeset: b28b073e72b6 Author: anthony Date: 2009-05-06 20:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b28b073e72b6 6838046: Rollback 6762511 due to build failure (6838003) Reviewed-by: yan ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: 2b86dbc51d11 Author: yan Date: 2009-05-06 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2b86dbc51d11 Merge Changeset: 0c6f5f1c58fd Author: yan Date: 2009-05-12 00:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0c6f5f1c58fd Merge Changeset: 2387e3b1994e Author: jrose Date: 2009-05-11 21:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2387e3b1994e 6839802: java.dyn needs to be on the CORE_PKGS list Summary: fix makefile to expose the new APIs in the core list; edit some javadocs for correctness Reviewed-by: mr ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java Changeset: 29180ef374c8 Author: jrose Date: 2009-05-12 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/29180ef374c8 6839839: access checking logic is wrong at three points in MethodHandles Summary: point fixes to access checking logic Reviewed-by: mr ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/sun/dyn/DirectMethodHandle.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/util/VerifyAccess.java Changeset: 2a5a1b269e89 Author: xdono Date: 2009-05-12 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2a5a1b269e89 Merge Changeset: 827a93c4d06a Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/827a93c4d06a Added tag jdk7-b59 for changeset 2a5a1b269e89 ! .hgtags From john.coomes at sun.com Thu May 14 22:09:18 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 05:09:18 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 4 new changesets Message-ID: <20090515050926.34475EED8@hg.openjdk.java.net> Changeset: e2722bd43f3a Author: jrose Date: 2009-05-04 21:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e2722bd43f3a 6829189: Java programming with JSR 292 needs language support Summary: Language changes documented in http://wikis.sun.com/display/mlvm/ProjectCoinProposal Reviewed-by: jjg, darcy, mcimadamore ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! src/share/classes/sun/tools/javap/JavapPrinter.java ! src/share/classes/sun/tools/javap/RuntimeConstants.java + test/tools/javac/meth/InvokeDyn.java + test/tools/javac/meth/InvokeMH.java + test/tools/javac/meth/MakeNegTests.sh + test/tools/javac/quid/MakeNegTests.sh + test/tools/javac/quid/QuotedIdent.java + test/tools/javac/quid/QuotedIdent2.java Changeset: 5bcac54d408b Author: tbell Date: 2009-05-04 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/5bcac54d408b Merge Changeset: 88bcb6772159 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/88bcb6772159 Added tag jdk7-b58 for changeset 5bcac54d408b ! .hgtags Changeset: 0f653be1a42f Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0f653be1a42f Added tag jdk7-b59 for changeset 88bcb6772159 ! .hgtags From Christian.Thalinger at Sun.COM Fri May 15 05:30:41 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 15 May 2009 14:30:41 +0200 Subject: possible bug in x86 MacroAssembler::delayed_value_impl Message-ID: <1242390641.29179.23.camel@macbook> Hi! While looking at the code I found this one: diff --git a/src/cpu/x86/vm/assembler_x86.cpp b/src/cpu/x86/vm/assembler_x86.cpp --- a/src/cpu/x86/vm/assembler_x86.cpp +++ b/src/cpu/x86/vm/assembler_x86.cpp @@ -7644,7 +7644,7 @@ RegisterOrConstant MacroAssembler::delay #ifdef ASSERT Label L; - testl(tmp, tmp); + testptr(tmp, tmp); jccb(Assembler::notZero, L); hlt(); bind(L); I think it's a bug since tmp is a pointer. Maybe an overlook during 32/64-bit merging? -- Christian From Thomas.Rodriguez at Sun.COM Fri May 15 10:53:29 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 15 May 2009 10:53:29 -0700 Subject: possible bug in x86 MacroAssembler::delayed_value_impl In-Reply-To: <1242390641.29179.23.camel@macbook> References: <1242390641.29179.23.camel@macbook> Message-ID: <69668440-2B35-41C3-A43B-6A69BEA89D24@sun.com> The delayed_value came after the assembler merge but it was probably developed in a workspace predating the assembler merge. It's definitely a bug though. I don't love the use of hlt() there since it would fail somewhat mysteriously when it happened. Normally we'd use something like stop("unexpected null") but maybe John didn't want to expand the code so much? tom On May 15, 2009, at 5:30 AM, Christian Thalinger wrote: > Hi! > > While looking at the code I found this one: > > diff --git a/src/cpu/x86/vm/assembler_x86.cpp b/src/cpu/x86/vm/ > assembler_x86.cpp > --- a/src/cpu/x86/vm/assembler_x86.cpp > +++ b/src/cpu/x86/vm/assembler_x86.cpp > @@ -7644,7 +7644,7 @@ RegisterOrConstant MacroAssembler::delay > > #ifdef ASSERT > Label L; > - testl(tmp, tmp); > + testptr(tmp, tmp); > jccb(Assembler::notZero, L); > hlt(); > bind(L); > > I think it's a bug since tmp is a pointer. Maybe an overlook during > 32/64-bit merging? > > -- Christian > From John.Rose at Sun.COM Fri May 15 11:21:36 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 15 May 2009 11:21:36 -0700 Subject: possible bug in x86 MacroAssembler::delayed_value_impl In-Reply-To: <69668440-2B35-41C3-A43B-6A69BEA89D24@sun.com> References: <1242390641.29179.23.camel@macbook> <69668440-2B35-41C3-A43B-6A69BEA89D24@sun.com> Message-ID: On May 15, 2009, at 10:53 AM, Tom Rodriguez wrote: > It's definitely a bug though. I don't love the use of hlt() there > since it would fail somewhat mysteriously when it happened. > Normally we'd use something like stop("unexpected null") but maybe > John didn't want to expand the code so much? Yes; it's about code size, but a stop would be OK too, since it's just an assert. -- John From Christian.Thalinger at Sun.COM Fri May 15 11:27:22 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 15 May 2009 20:27:22 +0200 Subject: possible bug in x86 MacroAssembler::delayed_value_impl In-Reply-To: References: <1242390641.29179.23.camel@macbook> <69668440-2B35-41C3-A43B-6A69BEA89D24@sun.com> Message-ID: <1242412042.29179.26.camel@macbook> On Fri, 2009-05-15 at 11:21 -0700, John Rose wrote: > On May 15, 2009, at 10:53 AM, Tom Rodriguez wrote: > > > It's definitely a bug though. I don't love the use of hlt() there > > since it would fail somewhat mysteriously when it happened. > > Normally we'd use something like stop("unexpected null") but maybe > > John didn't want to expand the code so much? > > Yes; it's about code size, but a stop would be OK too, since it's just > an assert. Should I file a CR and fix it or will you do it John? -- Christian From John.Rose at Sun.COM Fri May 15 12:22:19 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 15 May 2009 12:22:19 -0700 Subject: possible bug in x86 MacroAssembler::delayed_value_impl In-Reply-To: <1242412042.29179.26.camel@macbook> References: <1242390641.29179.23.camel@macbook> <69668440-2B35-41C3-A43B-6A69BEA89D24@sun.com> <1242412042.29179.26.camel@macbook> Message-ID: On May 15, 2009, at 11:27 AM, Christian Thalinger wrote: > Should I file a CR and fix it or will you do it John? Let's just roll it into this bug, which it is a part of: 6829192 JSR 292 needs to support 64-bit x86 -- John From kelly.ohair at sun.com Sun May 17 13:08:40 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sun, 17 May 2009 20:08:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 5 new changesets Message-ID: <20090517200849.8F0FBE11A@hg.openjdk.java.net> Changeset: 5d4dd2f5f6a1 Author: aph Date: 2009-04-17 15:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5d4dd2f5f6a1 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: 53d9bf689e80 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/53d9bf689e80 Added tag jdk7-b57 for changeset f4cbf78110c7 ! .hgtags Changeset: 7a485bc4da16 Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7a485bc4da16 Merge Changeset: 116b019a3961 Author: ohair Date: 2009-05-08 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/116b019a3961 6839126: Type error found by newer windows compiler Reviewed-by: never, kvn ! src/share/vm/adlc/filebuff.hpp Changeset: 27d660246893 Author: ohair Date: 2009-05-15 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/27d660246893 Merge ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make From Christian.Thalinger at Sun.COM Mon May 18 09:01:37 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 18 May 2009 18:01:37 +0200 Subject: Request for reviews .03 (L): 5057225: Remove useless I2L conversions In-Reply-To: <1242302492.1482.5.camel@macbook> References: <1242159760.15714.5.camel@macbook> <1242213534.15714.24.camel@macbook> <1242302492.1482.5.camel@macbook> Message-ID: <1242662497.29179.35.camel@macbook> On Thu, 2009-05-14 at 14:01 +0200, Christian Thalinger wrote: > On Wed, 2009-05-13 at 13:18 +0200, Christian Thalinger wrote: > > http://cr.openjdk.java.net/~twisti/5057225/webrev.02/ > > > > This is an updated version with the changes of 6814842 merged in. > > I found a problem during testing and have to investigate that further. This patch fixes the above problem: http://cr.openjdk.java.net/~twisti/5057225/webrev.03/ -- Christian From Vladimir.Kozlov at Sun.COM Wed May 20 14:17:53 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 20 May 2009 14:17:53 -0700 Subject: Request for reviews (XS): 6772683: Thread.isInterrupted() fails to return true on multiprocessor PC Message-ID: <4A147381.8050903@sun.com> http://cr.openjdk.java.net/~kvn/6772683/webrev.01 Fixed 6772683: Thread.isInterrupted() fails to return true on multiprocessor PC Problem: The C2 intrinsic isInterrupted() misses a control edge setting for the field thread::_interrupted load. The load use raw (not oop) thread pointer for which we don't generate a NULL check which prevents in an oop case the load to flow up. In the bug case the field load flow up from the loop and the field check follows it which is wrong. Solution: Set the control edge for the field _interrupted load. Added the regression test. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Wed May 20 16:29:46 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 20 May 2009 16:29:46 -0700 Subject: Request for reviews (XS): 6772683: Thread.isInterrupted() fails to return true on multiprocessor PC In-Reply-To: <4A147381.8050903@sun.com> References: <4A147381.8050903@sun.com> Message-ID: Looks good, though I'd probably say "prevent it floating up" in the comment. tom On May 20, 2009, at 2:17 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6772683/webrev.01 > > Fixed 6772683: Thread.isInterrupted() fails to return true on > multiprocessor PC > > Problem: > The C2 intrinsic isInterrupted() misses a control edge setting for > the field thread::_interrupted load. The load use raw (not oop) thread > pointer for which we don't generate a NULL check which prevents in > an oop case the load to flow up. > In the bug case the field load flow up from the loop and the field > check > follows it which is wrong. > > Solution: > Set the control edge for the field _interrupted load. > Added the regression test. > > Reviewed by: > > Fix verified (y/n): y, bug's test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Wed May 20 16:47:05 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 20 May 2009 16:47:05 -0700 Subject: Request for reviews (XS): 6772683: Thread.isInterrupted() fails to return true on multiprocessor PC In-Reply-To: References: <4A147381.8050903@sun.com> Message-ID: <4A149679.7070106@sun.com> Thank you, Tom I will fix the comment. Vladimir Tom Rodriguez wrote: > Looks good, though I'd probably say "prevent it floating up" in the > comment. > > tom > > On May 20, 2009, at 2:17 PM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6772683/webrev.01 >> >> Fixed 6772683: Thread.isInterrupted() fails to return true on >> multiprocessor PC >> >> Problem: >> The C2 intrinsic isInterrupted() misses a control edge setting for >> the field thread::_interrupted load. The load use raw (not oop) thread >> pointer for which we don't generate a NULL check which prevents in >> an oop case the load to flow up. >> In the bug case the field load flow up from the loop and the field check >> follows it which is wrong. >> >> Solution: >> Set the control edge for the field _interrupted load. >> Added the regression test. >> >> Reviewed by: >> >> Fix verified (y/n): y, bug's test >> >> Other testing: >> JPRT >> > From vladimir.kozlov at sun.com Thu May 21 13:47:50 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 21 May 2009 20:47:50 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6772683: Thread.isInterrupted() fails to return true on multiprocessor PC Message-ID: <20090521204801.8F7A4E787@hg.openjdk.java.net> Changeset: aabd393cf1ee Author: kvn Date: 2009-05-21 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/aabd393cf1ee 6772683: Thread.isInterrupted() fails to return true on multiprocessor PC Summary: Set the control edge for the field _interrupted load in inline_native_isInterrupted(). Reviewed-by: never ! src/share/vm/opto/library_call.cpp + test/compiler/6772683/InterruptedTest.java From Vladimir.Kozlov at Sun.COM Fri May 22 19:45:30 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 22 May 2009 19:45:30 -0700 Subject: Request for reviews (XS): 6843752: missing code for an anti-dependent Phi in GCM Message-ID: <4A17634A.5070709@sun.com> http://cr.openjdk.java.net/~kvn/6843752/webrev.00 Fixed 6843752: missing code for an anti-dependent Phi in GCM Problem: Changes for 6470497 (part G) incorrectly removed the code for anti-dependent PHI pinned below load's 'early' block. As result the load placed below this phi into the block with lowest frequency and a wrong value is loaded. In the test case the load placed inside loop which modifies the loaded value to NULL. As result we got NULL exception. Solution: Don't place a load below anti-dependent PHI. Added the regression test modified to show the problem in latest VM (the loop body executed less time then the code before the loop). Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT From Christian.Thalinger at Sun.COM Mon May 25 15:15:47 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 26 May 2009 00:15:47 +0200 Subject: constant pool question Message-ID: <1243289747.26040.47.camel@macbook> Hi! Can someone explain to me why e.g. constantPoolOopDesc::uncached_klass_ref_index_at() uses field_or_method_at(), which does a is_field_or_method() check on the tag? This is also the case for constantPoolOopDesc::uncached_name_and_type_ref_index_at(). -- Christian From Thomas.Rodriguez at Sun.COM Tue May 26 09:47:21 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 26 May 2009 09:47:21 -0700 Subject: constant pool question In-Reply-To: <1243289747.26040.47.camel@macbook> References: <1243289747.26040.47.camel@macbook> Message-ID: What do you think is wrong with using is_field_or_method in these calls? tom On May 25, 2009, at 3:15 PM, Christian Thalinger wrote: > Hi! > > Can someone explain to me why e.g. > constantPoolOopDesc::uncached_klass_ref_index_at() uses > field_or_method_at(), which does a is_field_or_method() check on the > tag? This is also the case for > constantPoolOopDesc::uncached_name_and_type_ref_index_at(). > > -- Christian > From Christian.Thalinger at Sun.COM Tue May 26 10:19:19 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 26 May 2009 19:19:19 +0200 Subject: constant pool question In-Reply-To: References: <1243289747.26040.47.camel@macbook> Message-ID: <1243358360.24377.15.camel@macbook> On Tue, 2009-05-26 at 09:47 -0700, Tom Rodriguez wrote: > What do you think is wrong with using is_field_or_method in these calls? Well, I thought a method like constantPoolOopDesc::impl_name_and_type_ref_index_at() should check for JVM_CONSTANT_NameAndType, no? -- Christian From Vladimir.Kozlov at Sun.COM Wed May 27 09:31:47 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 27 May 2009 09:31:47 -0700 Subject: Request for reviews (XS): 6843752: missing code for an anti-dependent Phi in GCM Message-ID: <4A1D6AF3.1000803@sun.com> Resending. http://cr.openjdk.java.net/~kvn/6843752/webrev.00 Fixed 6843752: missing code for an anti-dependent Phi in GCM Problem: Changes for 6470497 (part G) incorrectly removed the code for anti-dependent PHI pinned below load's 'early' block. As result the load placed below this phi into the block with lowest frequency and a wrong value is loaded. In the test case the load placed inside loop which modifies the loaded value to NULL. As result we got NULL exception. Solution: Don't place a load below anti-dependent PHI. Added the regression test modified to show the problem in latest VM (the loop body executed less time then the code before the loop). Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Wed May 27 10:18:07 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 27 May 2009 10:18:07 -0700 Subject: Request for reviews (XS): 6843752: missing code for an anti-dependent Phi in GCM In-Reply-To: <4A1D6AF3.1000803@sun.com> References: <4A1D6AF3.1000803@sun.com> Message-ID: <53F51FB1-576F-4069-B194-A6BC1125A991@sun.com> Based on the old code that case definitely seems needed and I believe I follow the logic enough to think that it would end up handling it the same as the old code. Looks good. tom On May 27, 2009, at 9:31 AM, Vladimir Kozlov wrote: > Resending. > > http://cr.openjdk.java.net/~kvn/6843752/webrev.00 > > Fixed 6843752: missing code for an anti-dependent Phi in GCM > > Problem: > Changes for 6470497 (part G) incorrectly removed the code > for anti-dependent PHI pinned below load's 'early' block. > As result the load placed below this phi into the block with > lowest frequency and a wrong value is loaded. > In the test case the load placed inside loop which modifies > the loaded value to NULL. As result we got NULL exception. > > Solution: > Don't place a load below anti-dependent PHI. > Added the regression test modified to show the problem > in latest VM (the loop body executed less time then > the code before the loop). > > Reviewed by: > > Fix verified (y/n): y, bug's test > > Other testing: > JPRT > From vladimir.kozlov at sun.com Wed May 27 18:07:36 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 28 May 2009 01:07:36 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6843752: missing code for an anti-dependent Phi in GCM Message-ID: <20090528010744.730C2EB37@hg.openjdk.java.net> Changeset: 1851e1fb420e Author: kvn Date: 2009-05-27 12:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1851e1fb420e 6843752: missing code for an anti-dependent Phi in GCM Summary: Don't place a load below anti-dependent PHI. Reviewed-by: never, twisti ! src/share/vm/opto/gcm.cpp + test/compiler/6843752/Test.java From Christian.Thalinger at Sun.COM Thu May 28 07:21:39 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 28 May 2009 16:21:39 +0200 Subject: TypeAryPtr::make has no implementation Message-ID: <1243520499.24377.62.camel@macbook> Hi! I just wanted to use: static const TypeAryPtr* TypeAryPtr::make(ciObject* o); and found out that there is no implementation for that method. Should we remove that declaration? -- Christian From Thomas.Rodriguez at Sun.COM Thu May 28 08:50:56 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 28 May 2009 08:50:56 -0700 Subject: TypeAryPtr::make has no implementation In-Reply-To: <1243520499.24377.62.camel@macbook> References: <1243520499.24377.62.camel@macbook> Message-ID: <1D3B6CF3-023E-4AA9-AB54-63DBF8FE855A@sun.com> I just tripped across that myself. I'm deleting it as part of my changes. The method you actually want is probably TypeOopPtr::make_from_constant. tom On May 28, 2009, at 7:21 AM, Christian Thalinger wrote: > Hi! > > I just wanted to use: > > static const TypeAryPtr* TypeAryPtr::make(ciObject* o); > > and found out that there is no implementation for that method. Should > we remove that declaration? > > -- Christian > From Christian.Thalinger at Sun.COM Thu May 28 10:53:55 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 28 May 2009 19:53:55 +0200 Subject: TypeAryPtr::make has no implementation In-Reply-To: <1D3B6CF3-023E-4AA9-AB54-63DBF8FE855A@sun.com> References: <1243520499.24377.62.camel@macbook> <1D3B6CF3-023E-4AA9-AB54-63DBF8FE855A@sun.com> Message-ID: <1243533236.24377.63.camel@macbook> On Thu, 2009-05-28 at 08:50 -0700, Tom Rodriguez wrote: > I just tripped across that myself. I'm deleting it as part of my > changes. Thanks. -- Christian From changpeng.fang at sun.com Thu May 28 12:08:55 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Thu, 28 May 2009 19:08:55 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6837146: Should perform unswitch before maximally unroll in loop transformation Message-ID: <20090528190857.63D1DED2D@hg.openjdk.java.net> Changeset: 273b2358ef1a Author: cfang Date: 2009-05-28 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/273b2358ef1a 6837146: Should perform unswitch before maximally unroll in loop transformation Summary: Move loop unswitch before maximally unroll Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp From Vladimir.Kozlov at Sun.COM Thu May 28 15:22:00 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 28 May 2009 15:22:00 -0700 Subject: Request for reviews (L): 6837472: com/sun/jdi/MonitorFrameInfo.java fails with Escape Analysis Message-ID: <4A1F0E88.1080306@sun.com> http://cr.openjdk.java.net/~kvn/6837472/webrev.00 Fixed 6837472: com/sun/jdi/MonitorFrameInfo.java fails with Escape Analysis Problem: JDI test sets a breakpoint in callee method and expects to be inside the lock in caller method. But EA eliminated the locked object and the lock in caller method since the object does not escape. Solution: Disable escape analysis when jvmti/debugger is used. Add the information about scalar replaced objects into MonitorInfo and StackValue. Add support for scalar replaced objects and eliminated locks into Serviceability Agent. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT, CTW, NSK testing with EA.