From John.Cuthbertson at Sun.COM Thu Oct 1 11:29:34 2009 From: John.Cuthbertson at Sun.COM (john cuthbertson - Sun Microsystems) Date: Thu, 01 Oct 2009 11:29:34 -0700 Subject: Please Review (XXXS): Fix for 6887186: G1: Incorrect code generated for G1 pre-barrier by C1 on SPARC Message-ID: <4AC4F50E.4030100@sun.com> Hi Everyone, Can I have a couple of volunteers review the changes for this CR? The webrev can be found at http://cr.openjdk.java.net/~johnc/6887186/webrev.0/. The issue is that the wrong C1 operand was passed to the generator of the G1 pre-barrier code for the Unsafe.CompareAndSwap intrinsic. The old code was passing the operand representing the base object rather than that representing the address of the object.field that was passed to the CAS. This caused the G1 pre-barrier code to store a mark word in the SATB buffer rather than the previous contents of object.field. Thanks, JohnC From Thomas.Rodriguez at Sun.COM Thu Oct 1 12:31:43 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 01 Oct 2009 12:31:43 -0700 Subject: Please Review (XXXS): Fix for 6887186: G1: Incorrect code generated for G1 pre-barrier by C1 on SPARC In-Reply-To: <4AC4F50E.4030100@sun.com> References: <4AC4F50E.4030100@sun.com> Message-ID: That looks good. tom On Oct 1, 2009, at 11:29 AM, john cuthbertson - Sun Microsystems wrote: > Hi Everyone, > > Can I have a couple of volunteers review the changes for this CR? > The webrev can be found at http://cr.openjdk.java.net/~johnc/6887186/webrev.0/ > . > > The issue is that the wrong C1 operand was passed to the generator > of the G1 pre-barrier code for the Unsafe.CompareAndSwap intrinsic. > The old code was passing the operand representing the base object > rather than that representing the address of the object.field that > was passed to the CAS. This caused the G1 pre-barrier code to store > a mark word in the SATB buffer rather than the previous contents of > object.field. > > Thanks, > > JohnC From Christian.Thalinger at Sun.COM Fri Oct 2 03:32:53 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 02 Oct 2009 12:32:53 +0200 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 In-Reply-To: <09FB22A5-36C4-4CA2-8806-41AF0D6FA3DA@Sun.COM> References: <4AB78F32.5000105@Sun.COM> <4AB7BDD0.2010104@sun.com> <2E9EE0A1-3B14-4C02-B0EC-2D8EB0D6EF5F@sun.com> <4AB901E5.20509@Sun.COM> <09FB22A5-36C4-4CA2-8806-41AF0D6FA3DA@Sun.COM> Message-ID: <1254479573.10133.2.camel@macbook> On Tue, 2009-09-22 at 10:10 -0700, Tom Rodriguez wrote: > We could convert arg_slot/next_arg_slot to return RegisterOrConstant > and fix this uniformly. The existing code assumes that the offsets > fit in 32 bit mode but don't in 64 bit which seems dubious. arg_slot > could then be used everywhere, as long as we add an assert that > value_offset_in_bytes == 0. Just for the record... I have already prepared another webrev but did had time yet to post it: http://cr.openjdk.java.net/~twisti/6879902/webrev.02/ and Tom had a look at it: I looked at this again and I don't think that stf should be using arg_slot. c2i only uses arg_slot/next_arg_slot for loads which is correct since we should be moving it from interpreter layout to compiled layout. Using it for stores is wrong. After Vladimir's comment I thought that other compiled code was already using arg_slot for stores so it wasn't any worse but now I can see that it's not true. I think the original fix of just correcting the stf code was the way to go. It can use RegisterOrConstant with ensure_rs2. We can keep the other changes or not depending on how you feel about them. They generate better code for 64-bit and deals with the simm13 issue in general which I like. If you keep them I'd suggest using ensure_rs2 in you arg_slot routines instead of hand coding that. I wouldn't mind renaming ensure_rs2 since it's such a useless name. -- Christian From volker.simonis at gmail.com Fri Oct 2 10:35:03 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 2 Oct 2009 19:35:03 +0200 Subject: 6880034: Change 6420645 causes SIGBUS during deoptimisation at a safepoint on 64bit-SPARC In-Reply-To: <4AC3AF10.1030209@sun.com> References: <6DBF4B78-515D-423E-BBED-DA492C6FD3BA@sun.com> <4AC3AF10.1030209@sun.com> Message-ID: Hi Vladimir, Tom, thank you for your evaluation. You can find a webrev for this change at: http://www.progdoc.de/webrev/6880034/ Could you please be so kind to review and submit it in case it's ok? Thanks, Volker On 9/30/09, Vladimir Kozlov wrote: > Volker Simonis wrote: > > I don't know why this strange encoding has been chosen for the 16 > > upper double registers in sparc.ad, but changing it to: > > > > reg_def R_D32x(SOC, SOC, Op_RegD,255, F32->as_VMReg()->next()); > > reg_def R_D32 (SOC, SOC, Op_RegD, 1, F32->as_VMReg()); > > reg_def R_D34x(SOC, SOC, Op_RegD,255, F34->as_VMReg()->next()); > > reg_def R_D34 (SOC, SOC, Op_RegD, 3, F34->as_VMReg()); > > ... > > reg_def R_D62x(SOC, SOC, Op_RegD,255, F62->as_VMReg()->next()); > > reg_def R_D62 (SOC, SOC, Op_RegD, 31, F62->as_VMReg()); > > > > which seems more natural to me, solved the SIGBUS issue and didn't > > revealed any other problems in the tests which I run so far. > > > > Could you please comment on the proposed solution of changing the > > VMReg numbering of F32-F62 or advice a better solution if you think > > that the proposed one will not work in the general case? > > > > Thank you and best regards, > > Volker > > Your changes are correct but I would also swap definitions > to be more clear. > > reg_def R_D32 (SOC, SOC, Op_RegD, 1, F32->as_VMReg()); > reg_def R_D32x(SOC, SOC, Op_RegD,255, F32->as_VMReg()->next()); > reg_def R_D34 (SOC, SOC, Op_RegD, 3, F34->as_VMReg()); > reg_def R_D34x(SOC, SOC, Op_RegD,255, F34->as_VMReg()->next()); > > I looked on the history and originally it was > > reg_def R_D32( SOC, SOC, Op_RegD, 1, 0 ); > reg_def R_D32L(SOC, SOC, Op_RegD, 99, 0 ); > reg_def R_D34( SOC, SOC, Op_RegD, 3, 0 ); > reg_def R_D34L(SOC, SOC, Op_RegD, 99, 0 ); > > where R_D32L and R_D34L represented nonexisting F33 and F35 > low 32 bits halves of D32 and D34. > > Then the ordering of declarations was changed and introduced > the confusion: > > reg_def R_D32x(SOC, SOC, Op_RegD,255, 0 ); > reg_def R_D32 (SOC, SOC, Op_RegD, 1, 0 ); > reg_def R_D34x(SOC, SOC, Op_RegD,255, 0 ); > reg_def R_D34 (SOC, SOC, Op_RegD, 3, 0 ); > > Vladimir > > Tom Rodriguez wrote: > > > > > > The problem can be easily solved by switching back to the old > > > implementation of frame::oopmapreg_to_location(), but I > assume there > > > was a rational behind the change and that the new implementation is > > > probably necessary for compressed oops (at least that's what the whole > > > change was all about). So I dug a little further and found that in my > > > opinion the root cause of the whole problem is the strange numbering > > > of the 16 upper double registers in sparc.ad. They are defined as > > > follows: > > > > > > reg_def R_D32x(SOC, SOC, Op_RegD,255, F32->as_VMReg()); > > > reg_def R_D32 (SOC, SOC, Op_RegD, 1, F32->as_VMReg()->next()); > > > reg_def R_D34x(SOC, SOC, Op_RegD,255, F34->as_VMReg()); > > > reg_def R_D34 (SOC, SOC, Op_RegD, 3, F34->as_VMReg()->next()); > > > ... > > > reg_def R_D62x(SOC, SOC, Op_RegD,255, F62->as_VMReg()); > > > reg_def R_D62 (SOC, SOC, Op_RegD, 31, F62->as_VMReg()->next()); > > > > > > > I don't really know why it's done this way. It's certainly not consistent > with the others. If it all works better I'd be ok with correcting. > > > > > > > PS: while I was hunting the error, I also stumbled across the > > > following code in RegisterSaver::save_live_registers(): > > > > > > // Save all the FP registers > > > int offset = d00_offset; > > > for( int i=0; i<64; i+=2 ) { > > > FloatRegister f = as_FloatRegister(i); > > > __ stf(FloatRegisterImpl::D, f, SP, offset+STACK_BIAS); > > > > map->set_callee_saved(VMRegImpl::stack2reg(offset>>2), > f->as_VMReg()); > > > if (true) { > > > map->set_callee_saved(VMRegImpl::stack2reg((offset > + > > > sizeof(float))>>2), f->as_VMReg()->next()); > > > } > > > offset += sizeof(double); > > > } > > > > > > > That would probably be ok too. > > > > tom > > > > > > > > > > In my opinion, this could be changed to: > > > > > > // Save all the FP registers > > > int offset = d00_offset; > > > for( int i=0; i<64; i+=2 ) { > > > FloatRegister f = as_FloatRegister(i); > > > __ stf(FloatRegisterImpl::D, f, SP, offset+STACK_BIAS); > > > > map->set_callee_saved(VMRegImpl::stack2reg(offset>>2), > f->as_VMReg()); > > > if (i < 32) { // VS 2009-08-31: the 16 upper double registers > > > can't be used as floats anyway > > > map->set_callee_saved(VMRegImpl::stack2reg((offset > + > > > sizeof(float))>>2), f->as_VMReg()->next()); > > > } > > > offset += sizeof(double); > > > } > > > > > > because the 16 upper double registers can't be used as floats anyway. > > > Again, I didn't found any regression in my few tests. What do you > > > think? > > > > > > > > > > > From Christian.Thalinger at Sun.COM Mon Oct 5 10:03:04 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 05 Oct 2009 19:03:04 +0200 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 In-Reply-To: <1254479573.10133.2.camel@macbook> References: <4AB78F32.5000105@Sun.COM> <4AB7BDD0.2010104@sun.com> <2E9EE0A1-3B14-4C02-B0EC-2D8EB0D6EF5F@sun.com> <4AB901E5.20509@Sun.COM> <09FB22A5-36C4-4CA2-8806-41AF0D6FA3DA@Sun.COM> <1254479573.10133.2.camel@macbook> Message-ID: <1254762184.20096.0.camel@macbook> On Fri, 2009-10-02 at 12:32 +0200, Christian Thalinger wrote: > Just for the record... I have already prepared another webrev but did > had time yet to post it: > > http://cr.openjdk.java.net/~twisti/6879902/webrev.02/ > > and Tom had a look at it: > > I looked at this again and I don't think that stf should be using > arg_slot. c2i only uses arg_slot/next_arg_slot for loads which is > correct since we should be moving it from interpreter layout to > compiled layout. Using it for stores is wrong. After Vladimir's > comment I thought that other compiled code was already using arg_slot > for stores so it wasn't any worse but now I can see that it's not > true. I think the original fix of just correcting the stf code was > the way to go. It can use RegisterOrConstant with ensure_rs2. We can > keep the other changes or not depending on how you feel about them. > They generate better code for 64-bit and deals with the simm13 issue > in general which I like. If you keep them I'd suggest using > ensure_rs2 in you arg_slot routines instead of hand coding that. I > wouldn't mind renaming ensure_rs2 since it's such a useless name. Here is an updated webrev: http://cr.openjdk.java.net/~twisti/6879902/webrev.03/ -- Christian From Thomas.Rodriguez at Sun.COM Mon Oct 5 12:11:09 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 05 Oct 2009 12:11:09 -0700 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 In-Reply-To: <1254762184.20096.0.camel@macbook> References: <4AB78F32.5000105@Sun.COM> <4AB7BDD0.2010104@sun.com> <2E9EE0A1-3B14-4C02-B0EC-2D8EB0D6EF5F@sun.com> <4AB901E5.20509@Sun.COM> <09FB22A5-36C4-4CA2-8806-41AF0D6FA3DA@Sun.COM> <1254479573.10133.2.camel@macbook> <1254762184.20096.0.camel@macbook> Message-ID: Looks good. tom On Oct 5, 2009, at 10:03 AM, Christian Thalinger wrote: > On Fri, 2009-10-02 at 12:32 +0200, Christian Thalinger wrote: >> Just for the record... I have already prepared another webrev but did >> had time yet to post it: >> >> http://cr.openjdk.java.net/~twisti/6879902/webrev.02/ >> >> and Tom had a look at it: >> >> I looked at this again and I don't think that stf should be using >> arg_slot. c2i only uses arg_slot/next_arg_slot for loads which is >> correct since we should be moving it from interpreter layout to >> compiled layout. Using it for stores is wrong. After Vladimir's >> comment I thought that other compiled code was already using arg_slot >> for stores so it wasn't any worse but now I can see that it's not >> true. I think the original fix of just correcting the stf code was >> the way to go. It can use RegisterOrConstant with ensure_rs2. We >> can >> keep the other changes or not depending on how you feel about them. >> They generate better code for 64-bit and deals with the simm13 issue >> in general which I like. If you keep them I'd suggest using >> ensure_rs2 in you arg_slot routines instead of hand coding that. I >> wouldn't mind renaming ensure_rs2 since it's such a useless name. > > Here is an updated webrev: > > http://cr.openjdk.java.net/~twisti/6879902/webrev.03/ > > -- Christian > From Vladimir.Kozlov at Sun.COM Mon Oct 5 12:47:43 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 05 Oct 2009 12:47:43 -0700 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 In-Reply-To: <1254762184.20096.0.camel@macbook> References: <4AB78F32.5000105@Sun.COM> <4AB7BDD0.2010104@sun.com> <2E9EE0A1-3B14-4C02-B0EC-2D8EB0D6EF5F@sun.com> <4AB901E5.20509@Sun.COM> <09FB22A5-36C4-4CA2-8806-41AF0D6FA3DA@Sun.COM> <1254479573.10133.2.camel@macbook> <1254762184.20096.0.camel@macbook> Message-ID: <4ACA4D5F.2070407@sun.com> Good. Vladimir Christian Thalinger wrote: > On Fri, 2009-10-02 at 12:32 +0200, Christian Thalinger wrote: >> Just for the record... I have already prepared another webrev but did >> had time yet to post it: >> >> http://cr.openjdk.java.net/~twisti/6879902/webrev.02/ >> >> and Tom had a look at it: >> >> I looked at this again and I don't think that stf should be using >> arg_slot. c2i only uses arg_slot/next_arg_slot for loads which is >> correct since we should be moving it from interpreter layout to >> compiled layout. Using it for stores is wrong. After Vladimir's >> comment I thought that other compiled code was already using arg_slot >> for stores so it wasn't any worse but now I can see that it's not >> true. I think the original fix of just correcting the stf code was >> the way to go. It can use RegisterOrConstant with ensure_rs2. We can >> keep the other changes or not depending on how you feel about them. >> They generate better code for 64-bit and deals with the simm13 issue >> in general which I like. If you keep them I'd suggest using >> ensure_rs2 in you arg_slot routines instead of hand coding that. I >> wouldn't mind renaming ensure_rs2 since it's such a useless name. > > Here is an updated webrev: > > http://cr.openjdk.java.net/~twisti/6879902/webrev.03/ > > -- Christian > From Vladimir.Kozlov at Sun.COM Mon Oct 5 16:26:29 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 05 Oct 2009 16:26:29 -0700 Subject: Request for reviews (S): 6880034 for HS16 and HS17 Message-ID: <4ACA80A5.8090609@sun.com> http://cr.openjdk.java.net/~kvn/6880034/webrev.01 Fixed 6880034: SIGBUS during deoptimisation at a safepoint on 64bit-SPARC Problem (found and described by Volker Simonis): Wrong numbering of the 16 upper double registers in sparc.ad maps the invalid half (R_D32x, R_D34x, ..) of the double registers F32-F62 to even VMReg numbers (96, 98, ..) and the valid part (R_D32, R_D34, ..) to odd VMReg numbers (97, 99, ..). Later on, when the locals array for the safepoint is constructed in Compile::FillLocArray(), the call to OptoReg::as_VMReg(regnum) for a valid, even double register >= F32 (e.g. 96) returns the invalid, odd part (e.g. 97). This odd VMReg number is than stored in the Location part of the local and leads to the the fact that reg->reg2stack() returns odd values for float registers >= F32. This finally leads to a BUS error due to an unaligned double read when the location of the register is accessed through the reg_map during deoptimisation in StackValue::create_stack_value(). Solution: Fix the double register encodings in sparc.ad. Use FloatRegisterImpl::number_of_registers instead of 64 in RegisterSaver::save_live_registers() and restore_live_registers(). Replace if(true) with comments in save_live_registers(). Contributed by: volker.simonis at gmail.com Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT, CTW From Thomas.Rodriguez at Sun.COM Mon Oct 5 17:11:57 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 05 Oct 2009 17:11:57 -0700 Subject: Request for reviews (S): 6880034 for HS16 and HS17 In-Reply-To: <4ACA80A5.8090609@sun.com> References: <4ACA80A5.8090609@sun.com> Message-ID: Looks good. Volker, thanks for the fix. tom On Oct 5, 2009, at 4:26 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6880034/webrev.01 > > Fixed 6880034: SIGBUS during deoptimisation at a safepoint on 64bit- > SPARC > > Problem (found and described by Volker Simonis): > Wrong numbering of the 16 upper double registers in sparc.ad > maps the invalid half (R_D32x, R_D34x, ..) of the double > registers F32-F62 to even VMReg numbers (96, 98, ..) and the valid > part (R_D32, R_D34, ..) to odd VMReg numbers (97, 99, ..). Later on, > when the locals array for the safepoint is constructed in > Compile::FillLocArray(), the call to OptoReg::as_VMReg(regnum) for a > valid, even double register >= F32 (e.g. 96) returns the invalid, odd > part (e.g. 97). This odd VMReg number is than stored in the Location > part of the local and leads to the the fact that reg->reg2stack() > returns odd values for float registers >= F32. > This finally leads to a BUS error due to an unaligned double read > when the location of the register is accessed through the reg_map > during deoptimisation in StackValue::create_stack_value(). > > Solution: > Fix the double register encodings in sparc.ad. > Use FloatRegisterImpl::number_of_registers instead of 64 > in RegisterSaver::save_live_registers() and restore_live_registers(). > Replace if(true) with comments in save_live_registers(). > > Contributed by: volker.simonis at gmail.com > > Reviewed by: > > Fix verified (y/n): y, bug's test > > Other testing: > JPRT, CTW > From John.Rose at Sun.COM Mon Oct 5 22:38:37 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 05 Oct 2009 22:38:37 -0700 Subject: Request for reviews (S): 6880034 for HS16 and HS17 In-Reply-To: <4ACA80A5.8090609@sun.com> References: <4ACA80A5.8090609@sun.com> Message-ID: <8C01A380-3E4D-4D2C-93BF-ACF68533585A@sun.com> I believe the only sane way to number the 32-bit halves of 64-bit values is with some sort of consistently applied rule. Given that goal, the most consistent rule is to appeal first to memory storage order (first word then second word in memory layout) and project that order into the register file. This means arithmetic order is irrelevant to naming conventions, since the "high" word is the first word on big-endian systems, but the second word in x86, etc. The present fix is a good cleanup which makes register numbering more consistent. (Historically, the SPARC code of HotSpot was ported from x86, where an arithmetic low-order word is also the memory first-order word. On Intel you can be sloppy about which is the "high word", but on a big-endian machine you cannot. The SPARC code still has some traces of sloppiness.) Note that the integer registers are still inconsistently numbered from this viewpoint. In order to cope with a buggy choice of subword numbering, we have (in the past) debugged our way to a bunch of local fixes where the words are swapped as needed, at each use point. Doing a cleanup like this might have a bug tail (which is why we haven't been eager to attempt it). The bug tail, if it exists, will manifest in further stack walker or deoptimization bugs where words get swapped, and (upon examination) the swapping code can be simply deleted, given the more rational numbering scheme. This is the right time to do such cleanups. Thanks! -- John On Oct 5, 2009, at 4:26 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6880034/webrev.01 > > Fixed 6880034: SIGBUS during deoptimisation at a safepoint on 64bit- > SPARC > > Problem (found and described by Volker Simonis): > Wrong numbering of the 16 upper double registers in sparc.ad > maps the invalid half (R_D32x, R_D34x, ..) of the double > registers F32-F62 to even VMReg numbers (96, 98, ..) and the valid > part (R_D32, R_D34, ..) to odd VMReg numbers (97, 99, ..). Later on, > when the locals array for the safepoint is constructed in > Compile::FillLocArray(), the call to OptoReg::as_VMReg(regnum) for a > valid, even double register >= F32 (e.g. 96) returns the invalid, odd > part (e.g. 97). This odd VMReg number is than stored in the Location > part of the local and leads to the the fact that reg->reg2stack() > returns odd values for float registers >= F32. > This finally leads to a BUS error due to an unaligned double read > when the location of the register is accessed through the reg_map > during deoptimisation in StackValue::create_stack_value(). > > Solution: > Fix the double register encodings in sparc.ad. > Use FloatRegisterImpl::number_of_registers instead of 64 > in RegisterSaver::save_live_registers() and restore_live_registers(). > Replace if(true) with comments in save_live_registers(). > > Contributed by: volker.simonis at gmail.com > > Reviewed by: > > Fix verified (y/n): y, bug's test > > Other testing: > JPRT, CTW > From Christian.Thalinger at Sun.COM Tue Oct 6 05:01:57 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 06 Oct 2009 12:01:57 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 Message-ID: <20091006120200.6AEFC41ED2@hg.openjdk.java.net> Changeset: dcf03e02b020 Author: twisti Date: 2009-10-06 02:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dcf03e02b020 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 Summary: For signatures with a large number of arguments the offset for the float store becomes too big and does not fit in 13-bit. Reviewed-by: kvn, never ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp + test/compiler/6879902/Test6879902.java From Vladimir.Kozlov at Sun.COM Tue Oct 6 10:07:57 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 06 Oct 2009 10:07:57 -0700 Subject: Request for reviews (S): 6880034 for HS16 and HS17 In-Reply-To: <8C01A380-3E4D-4D2C-93BF-ACF68533585A@sun.com> References: <4ACA80A5.8090609@sun.com> <8C01A380-3E4D-4D2C-93BF-ACF68533585A@sun.com> Message-ID: <4ACB796D.2010907@sun.com> Thank you, John I will push this to HS17 first and let it be tested for some time before pushing to HS16. Thanks, Vladimir John Rose wrote: > I believe the only sane way to number the 32-bit halves of 64-bit values > is with some sort of consistently applied rule. Given that goal, the > most consistent rule is to appeal first to memory storage order (first > word then second word in memory layout) and project that order into the > register file. This means arithmetic order is irrelevant to naming > conventions, since the "high" word is the first word on big-endian > systems, but the second word in x86, etc. > > The present fix is a good cleanup which makes register numbering more > consistent. (Historically, the SPARC code of HotSpot was ported from > x86, where an arithmetic low-order word is also the memory first-order > word. On Intel you can be sloppy about which is the "high word", but on > a big-endian machine you cannot. The SPARC code still has some traces > of sloppiness.) Note that the integer registers are still > inconsistently numbered from this viewpoint. > > In order to cope with a buggy choice of subword numbering, we have (in > the past) debugged our way to a bunch of local fixes where the words are > swapped as needed, at each use point. Doing a cleanup like this might > have a bug tail (which is why we haven't been eager to attempt it). The > bug tail, if it exists, will manifest in further stack walker or > deoptimization bugs where words get swapped, and (upon examination) the > swapping code can be simply deleted, given the more rational numbering > scheme. > > This is the right time to do such cleanups. Thanks! > > -- John > > On Oct 5, 2009, at 4:26 PM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6880034/webrev.01 >> >> Fixed 6880034: SIGBUS during deoptimisation at a safepoint on 64bit-SPARC >> >> Problem (found and described by Volker Simonis): >> Wrong numbering of the 16 upper double registers in sparc.ad >> maps the invalid half (R_D32x, R_D34x, ..) of the double >> registers F32-F62 to even VMReg numbers (96, 98, ..) and the valid >> part (R_D32, R_D34, ..) to odd VMReg numbers (97, 99, ..). Later on, >> when the locals array for the safepoint is constructed in >> Compile::FillLocArray(), the call to OptoReg::as_VMReg(regnum) for a >> valid, even double register >= F32 (e.g. 96) returns the invalid, odd >> part (e.g. 97). This odd VMReg number is than stored in the Location >> part of the local and leads to the the fact that reg->reg2stack() >> returns odd values for float registers >= F32. >> This finally leads to a BUS error due to an unaligned double read >> when the location of the register is accessed through the reg_map >> during deoptimisation in StackValue::create_stack_value(). >> >> Solution: >> Fix the double register encodings in sparc.ad. >> Use FloatRegisterImpl::number_of_registers instead of 64 >> in RegisterSaver::save_live_registers() and restore_live_registers(). >> Replace if(true) with comments in save_live_registers(). >> >> Contributed by: volker.simonis at gmail.com >> >> Reviewed by: >> >> Fix verified (y/n): y, bug's test >> >> Other testing: >> JPRT, CTW >> > From vladimir.kozlov at sun.com Tue Oct 6 13:11:26 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 06 Oct 2009 20:11:26 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6880034: SIGBUS during deoptimisation at a safepoint on 64bit-SPARC Message-ID: <20091006201130.3E6C441F5C@hg.openjdk.java.net> Changeset: 1ce3281a8e93 Author: kvn Date: 2009-10-06 10:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1ce3281a8e93 6880034: SIGBUS during deoptimisation at a safepoint on 64bit-SPARC Summary: Fix problem with the double register encodings in sparc.ad Reviewed-by: never, jrose Contributed-by: volker.simonis at gmail.com ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad + test/compiler/6880034/Test6880034.java From Thomas.Rodriguez at Sun.COM Tue Oct 6 15:31:41 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 06 Oct 2009 15:31:41 -0700 Subject: review (S) for 6885584: A particular class structure causes large allocation spike for jit Message-ID: http://cr.openjdk.java.net/~never/6885584 From Vladimir.Kozlov at Sun.COM Tue Oct 6 16:42:14 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 06 Oct 2009 16:42:14 -0700 Subject: review (S) for 6885584: A particular class structure causes large allocation spike for jit In-Reply-To: References: Message-ID: <4ACBD5D6.60601@sun.com> Tom, why changes are different for Int and Long? For longs you replaced max_jlong, min_jlong with max,min in make() parameters and conditions. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6885584 From Thomas.Rodriguez at Sun.COM Tue Oct 6 16:49:12 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 06 Oct 2009 16:49:12 -0700 Subject: review (S) for 6885584: A particular class structure causes large allocation spike for jit In-Reply-To: <4ACBD5D6.60601@sun.com> References: <4ACBD5D6.60601@sun.com> Message-ID: On Oct 6, 2009, at 4:42 PM, Vladimir Kozlov wrote: > Tom, why changes are different for Int and Long? > For longs you replaced max_jlong, min_jlong with max,min I did them separately and didn't notice that they were different. I've fixed them to be the same. tom > in make() parameters and conditions. > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6885584 From Vladimir.Kozlov at Sun.COM Tue Oct 6 17:14:51 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 06 Oct 2009 17:14:51 -0700 Subject: review (S) for 6885584: A particular class structure causes large allocation spike for jit In-Reply-To: References: <4ACBD5D6.60601@sun.com> Message-ID: <4ACBDD7B.3000508@sun.com> Tom, For longs it is possible that max < max_juint. So can we change the next condition: if (_hi < max_juint) return make(_lo, max_juint, WidenMax); else return make(_lo, max, WidenMax); to next?: if (_hi < max_juint && max_juint < max) return make(_lo, max_juint, WidenMax); else return make(_lo, max, WidenMax); Vladimir Tom Rodriguez wrote: > > On Oct 6, 2009, at 4:42 PM, Vladimir Kozlov wrote: > >> Tom, why changes are different for Int and Long? >> For longs you replaced max_jlong, min_jlong with max,min > > I did them separately and didn't notice that they were different. I've > fixed them to be the same. > > tom > >> in make() parameters and conditions. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6885584 > From Thomas.Rodriguez at Sun.COM Wed Oct 7 11:02:10 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 07 Oct 2009 11:02:10 -0700 Subject: review (S) for 6885584: A particular class structure causes large allocation spike for jit In-Reply-To: <4ACBDD7B.3000508@sun.com> References: <4ACBD5D6.60601@sun.com> <4ACBDD7B.3000508@sun.com> Message-ID: On Oct 6, 2009, at 5:14 PM, Vladimir Kozlov wrote: > Tom, > > For longs it is possible that max < max_juint. > So can we change the next condition: You're right. I recoded it as: if (max >= max_juint && _hi < max_juint) tom > > if (_hi < max_juint) > return make(_lo, max_juint, WidenMax); > else > return make(_lo, max, WidenMax); > to next?: > > if (_hi < max_juint && max_juint < max) > return make(_lo, max_juint, WidenMax); > else > return make(_lo, max, WidenMax); > > Vladimir > > Tom Rodriguez wrote: >> On Oct 6, 2009, at 4:42 PM, Vladimir Kozlov wrote: >>> Tom, why changes are different for Int and Long? >>> For longs you replaced max_jlong, min_jlong with max,min >> I did them separately and didn't notice that they were different. >> I've fixed them to be the same. >> tom >>> in make() parameters and conditions. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6885584 From vladimir.kozlov at sun.com Wed Oct 7 14:57:48 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 07 Oct 2009 21:57:48 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6875959: CTW fails hotspot/src/share/vm/opto/reg_split.cpp:1087 Message-ID: <20091007215751.8D6B641453@hg.openjdk.java.net> Changeset: e90521d61f9a Author: kvn Date: 2009-10-07 12:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e90521d61f9a 6875959: CTW fails hotspot/src/share/vm/opto/reg_split.cpp:1087 Summary: To break spill ties choose bound live range over unbound to free register or one with smaller cost to spill. Reviewed-by: never, jrose ! src/share/vm/opto/chaitin.cpp From thomas.rodriguez at sun.com Wed Oct 7 18:29:19 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 08 Oct 2009 01:29:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6885584: A particular class structure causes large allocation spike for jit Message-ID: <20091008012922.AF73C41491@hg.openjdk.java.net> Changeset: 03b336640699 Author: never Date: 2009-10-07 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/03b336640699 6885584: A particular class structure causes large allocation spike for jit Reviewed-by: kvn ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/6885584/Test6885584.java From John.Rose at Sun.COM Wed Oct 7 22:51:04 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 07 Oct 2009 22:51:04 -0700 Subject: review (S) for 6885584: A particular class structure causes large allocation spike for jit In-Reply-To: References: <4ACBD5D6.60601@sun.com> <4ACBDD7B.3000508@sun.com> Message-ID: <8F6E4D45-7B74-4A54-9608-E6817B06527A@sun.com> Yes, that's a good fix. Thanks for puzzling out that death march. Now I'd like to push Type::filter into Type::widen, except that it's used in a couple of other places. -- John From Vladimir.Kozlov at Sun.COM Thu Oct 8 12:31:02 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 08 Oct 2009 12:31:02 -0700 Subject: Request for reviews (XS): 6722084: JPRT make file doesn't create required symbolic link to libjvm.so Message-ID: <4ACE3DF6.7020004@sun.com> Resending to groups aliases since I did not get this mail from hotspot-dev at openjdk.java.net Sorry for spam if you got it already. Vladimir -------- Original Message -------- Subject: Request for reviews (XS): 6722084: JPRT make file doesn't create required symbolic link to libjvm.so Date: Thu, 08 Oct 2009 11:28:56 -0700 From: Vladimir Kozlov To: hotspot-dev http://cr.openjdk.java.net/~kvn/6722084/webrev.01 Fixed 6722084: JPRT make file doesn't create required symbolic link to libjvm.so Problem: There are several annoying Nightly testing failures which nobody fixing for years. Caused by hotspot JPRT build bundles have normal .so libraries instead of symbolic links as in JDK. Solution: The fix suggested by Kelly very simple: use -y zip option to preserve symbolic links. I also fixed incorrect installation of libjsig.so in JPRT build bundles which put it into client/server subdirectories. Reviewed by: Fix verified (y/n): y, JPRT From Thomas.Rodriguez at Sun.COM Thu Oct 8 16:40:14 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 08 Oct 2009 16:40:14 -0700 Subject: review (XS) for 6889869: assert(!Interpreter::bytecode_should_reexecute(code), "should not reexecute") Message-ID: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> http://cr.openjdk.java.net/~never/6889869/ From John.Rose at Sun.COM Thu Oct 8 16:47:37 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 08 Oct 2009 16:47:37 -0700 Subject: review (XS) for 6889869: assert(!Interpreter::bytecode_should_reexecute(code), "should not reexecute") In-Reply-To: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> References: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> Message-ID: <0810121F-A927-4E09-B004-48DA82165957@sun.com> That's good. -- John On Oct 8, 2009, at 4:40 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6889869/ From John.Coomes at sun.com Thu Oct 8 16:58:35 2009 From: John.Coomes at sun.com (John Coomes) Date: Thu, 8 Oct 2009 16:58:35 -0700 Subject: Request for reviews (XS): 6722084: JPRT make file doesn't create required symbolic link to libjvm.so In-Reply-To: <4ACE3DF6.7020004@sun.com> References: <4ACE3DF6.7020004@sun.com> Message-ID: <19150.31915.381931.831508@sun.com> Vladimir Kozlov (Vladimir.Kozlov at Sun.COM) wrote: > ... > > http://cr.openjdk.java.net/~kvn/6722084/webrev.01 > > Fixed 6722084: JPRT make file doesn't create required symbolic link to libjvm.so > > Problem: > There are several annoying Nightly testing failures which > nobody fixing for years. Caused by hotspot JPRT build bundles > have normal .so libraries instead of symbolic links as in JDK. > > Solution: > The fix suggested by Kelly very simple: use -y zip option > to preserve symbolic links. > I also fixed incorrect installation of libjsig.so > in JPRT build bundles which put it into client/server > subdirectories. Looks good to me. -John From Thomas.Rodriguez at Sun.COM Thu Oct 8 17:15:14 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 08 Oct 2009 17:15:14 -0700 Subject: Request for reviews (XS): 6722084: JPRT make file doesn't create required symbolic link to libjvm.so In-Reply-To: <4ACE3DF6.7020004@sun.com> References: <4ACE3DF6.7020004@sun.com> Message-ID: <04242EB7-DD97-4D0E-8F53-C682450511D9@sun.com> Looks good. tom On Oct 8, 2009, at 12:31 PM, Vladimir Kozlov wrote: > Resending to groups aliases since I did not get this mail from hotspot-dev at openjdk.java.net > > Sorry for spam if you got it already. > > Vladimir > > -------- Original Message -------- > Subject: Request for reviews (XS): 6722084: JPRT make file doesn't > create required symbolic link to libjvm.so > Date: Thu, 08 Oct 2009 11:28:56 -0700 > From: Vladimir Kozlov > To: hotspot-dev > > http://cr.openjdk.java.net/~kvn/6722084/webrev.01 > > Fixed 6722084: JPRT make file doesn't create required symbolic link > to libjvm.so > > Problem: > There are several annoying Nightly testing failures which > nobody fixing for years. Caused by hotspot JPRT build bundles > have normal .so libraries instead of symbolic links as in JDK. > > Solution: > The fix suggested by Kelly very simple: use -y zip option > to preserve symbolic links. > I also fixed incorrect installation of libjsig.so > in JPRT build bundles which put it into client/server > subdirectories. > > Reviewed by: > > Fix verified (y/n): y, JPRT > > From Vladimir.Kozlov at Sun.COM Thu Oct 8 17:16:02 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 08 Oct 2009 17:16:02 -0700 Subject: review (XS) for 6889869: assert(!Interpreter::bytecode_should_reexecute(code), "should not reexecute") In-Reply-To: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> References: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> Message-ID: <4ACE80C2.5010802@sun.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6889869/ From Changpeng.Fang at Sun.COM Thu Oct 8 17:52:03 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Thu, 08 Oct 2009 17:52:03 -0700 Subject: review (XS) for 6889869: assert(!Interpreter::bytecode_should_reexecute(code), "should not reexecute") In-Reply-To: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> References: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> Message-ID: <4ACE8933.2050202@sun.com> On 10/08/09 16:40, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6889869/ Looks Good! Thanks for fixing the problem. Changpeng From Vladimir.Kozlov at Sun.COM Fri Oct 9 07:44:08 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 09 Oct 2009 07:44:08 -0700 Subject: Request for reviews (S): 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify,"Live range was lo-degree before coalesce Message-ID: <4ACF4C38.3060902@sun.com> http://cr.openjdk.java.net/~kvn/6889656/webrev.00 Fixed 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify,"Live range was lo-degree before coalesce Problem: Because of initial loop's "i" value change in 6875959 fix the first _hi_degree lrg was not checked for lo_degree(). Solution: Restore the original code: uint i = _hi_degree. I also cached calculation of live ranges. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT From John.Rose at Sun.COM Fri Oct 9 08:32:16 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 09 Oct 2009 08:32:16 -0700 Subject: Request for reviews (S): 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify,"Live range was lo-degree before coalesce In-Reply-To: <4ACF4C38.3060902@sun.com> References: <4ACF4C38.3060902@sun.com> Message-ID: <401B3608-9BC0-470C-B2F5-DDC4B23A6D44@sun.com> Foo. It was that sneaky "break", wasn't it? Three cheers for assert- rich code. Reviewed. -- John On Oct 9, 2009, at 7:44 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6889656/webrev.00 From Vladimir.Kozlov at Sun.COM Fri Oct 9 08:43:15 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 09 Oct 2009 08:43:15 -0700 Subject: Request for reviews (S): 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify,"Live range was lo-degree before coalesce In-Reply-To: <401B3608-9BC0-470C-B2F5-DDC4B23A6D44@sun.com> References: <4ACF4C38.3060902@sun.com> <401B3608-9BC0-470C-B2F5-DDC4B23A6D44@sun.com> Message-ID: <4ACF5A13.9080407@sun.com> Thank you, John. John Rose wrote: > Foo. It was that sneaky "break", wasn't it? Three cheers for Yes. > assert-rich code. Reviewed. -- John > > On Oct 9, 2009, at 7:44 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6889656/webrev.00 > Vladimir From Vladimir.Kozlov at Sun.COM Fri Oct 9 08:48:03 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 09 Oct 2009 08:48:03 -0700 Subject: Request for reviews (S): 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't return dead nodes") Message-ID: <4ACF5B33.6010701@sun.com> http://cr.openjdk.java.net/~kvn/6889300/webrev.00 Fixed 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't return dead nodes") Problem: Customer hit this assert in transform_old() when PhiNode::Ideal() method returns Phi node with no users when before the Ideal() call it only references itself with the edge corresponding to the dead control path. Solution: Return TOP for such case if it is IGVN transformation. Add verification that during IGVN new Phi nodes should be hooked before calling transform(). We need this restriction to catch dead paths. The only place which missed it was split_if() and I fixed it. Reviewed by: Other testing: JPRT, CTW, NSK From John.Rose at Sun.COM Fri Oct 9 08:57:47 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 09 Oct 2009 08:57:47 -0700 Subject: Request for reviews (S): 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't return dead nodes") In-Reply-To: <4ACF5B33.6010701@sun.com> References: <4ACF5B33.6010701@sun.com> Message-ID: Reviewed. -- John On Oct 9, 2009, at 8:48 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6889300/webrev.00 > > Fixed 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't > return dead nodes") From Vladimir.Kozlov at Sun.COM Fri Oct 9 08:59:54 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 09 Oct 2009 08:59:54 -0700 Subject: Request for reviews (S): 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't return dead nodes") In-Reply-To: References: <4ACF5B33.6010701@sun.com> Message-ID: <4ACF5DFA.8000702@sun.com> Thank you, John Vladimir John Rose wrote: > Reviewed. -- John > > On Oct 9, 2009, at 8:48 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6889300/webrev.00 >> >> Fixed 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't >> return dead nodes") > From Thomas.Rodriguez at Sun.COM Fri Oct 9 09:15:40 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 09 Oct 2009 09:15:40 -0700 Subject: Request for reviews (S): 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't return dead nodes") In-Reply-To: <4ACF5B33.6010701@sun.com> References: <4ACF5B33.6010701@sun.com> Message-ID: Looks good. tom On Oct 9, 2009, at 8:48 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6889300/webrev.00 > > Fixed 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't > return dead nodes") > > Problem: > Customer hit this assert in transform_old() when > PhiNode::Ideal() method returns Phi node with no users > when before the Ideal() call it only references itself > with the edge corresponding to the dead control path. > > Solution: > Return TOP for such case if it is IGVN transformation. > Add verification that during IGVN new Phi nodes should > be hooked before calling transform(). We need this > restriction to catch dead paths. The only place > which missed it was split_if() and I fixed it. > > Reviewed by: > > Other testing: > JPRT, CTW, NSK > From Vladimir.Kozlov at Sun.COM Fri Oct 9 09:16:36 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 09 Oct 2009 09:16:36 -0700 Subject: Request for reviews (S): 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't return dead nodes") In-Reply-To: References: <4ACF5B33.6010701@sun.com> Message-ID: <4ACF61E4.3030009@sun.com> Thanks, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 9, 2009, at 8:48 AM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6889300/webrev.00 >> >> Fixed 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't >> return dead nodes") >> >> Problem: >> Customer hit this assert in transform_old() when >> PhiNode::Ideal() method returns Phi node with no users >> when before the Ideal() call it only references itself >> with the edge corresponding to the dead control path. >> >> Solution: >> Return TOP for such case if it is IGVN transformation. >> Add verification that during IGVN new Phi nodes should >> be hooked before calling transform(). We need this >> restriction to catch dead paths. The only place >> which missed it was split_if() and I fixed it. >> >> Reviewed by: >> >> Other testing: >> JPRT, CTW, NSK >> > From Thomas.Rodriguez at Sun.COM Fri Oct 9 09:35:43 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 09 Oct 2009 09:35:43 -0700 Subject: Request for reviews (S): 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify,"Live range was lo-degree before coalesce In-Reply-To: <4ACF4C38.3060902@sun.com> References: <4ACF4C38.3060902@sun.com> Message-ID: <78B406EC-E56C-427C-9EC3-32152FAC5F5F@sun.com> On Oct 9, 2009, at 7:44 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6889656/webrev.00 > > Fixed 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify,"Live > range was lo-degree before coalesce > > Problem: > Because of initial loop's "i" value change in 6875959 fix > the first _hi_degree lrg was not checked for lo_degree(). > > Solution: > Restore the original code: uint i = _hi_degree. I missed that you changed the bounds in the original review. > I also cached calculation of live ranges. I don't really see the motivation for this and I'd prefer that this fix to a fix just contained the fix and not other stuff, particularly since the last bug was caused by "optimizing" the original code. tom > > Reviewed by: > > Fix verified (y/n): y, bug's test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Fri Oct 9 09:37:01 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 09 Oct 2009 09:37:01 -0700 Subject: Request for reviews (S): 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify,"Live range was lo-degree before coalesce In-Reply-To: <78B406EC-E56C-427C-9EC3-32152FAC5F5F@sun.com> References: <4ACF4C38.3060902@sun.com> <78B406EC-E56C-427C-9EC3-32152FAC5F5F@sun.com> Message-ID: <4ACF66AD.5040507@sun.com> Ok. I will just restore the original code for bounds. Thanks, Vladimir Tom Rodriguez wrote: > > On Oct 9, 2009, at 7:44 AM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6889656/webrev.00 >> >> Fixed 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify,"Live >> range was lo-degree before coalesce >> >> Problem: >> Because of initial loop's "i" value change in 6875959 fix >> the first _hi_degree lrg was not checked for lo_degree(). >> >> Solution: >> Restore the original code: uint i = _hi_degree. > > I missed that you changed the bounds in the original review. > >> I also cached calculation of live ranges. > > I don't really see the motivation for this and I'd prefer that this fix > to a fix just contained the fix and not other stuff, particularly since > the last bug was caused by "optimizing" the original code. > > tom > >> >> Reviewed by: >> >> Fix verified (y/n): y, bug's test >> >> Other testing: >> JPRT >> > From Christian.Thalinger at Sun.COM Mon Oct 12 00:41:03 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 12 Oct 2009 09:41:03 +0200 Subject: review (XS) for 6889869: assert(!Interpreter::bytecode_should_reexecute(code), "should not reexecute") In-Reply-To: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> References: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> Message-ID: <1255333263.29170.1.camel@macbook> On Thu, 2009-10-08 at 16:40 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6889869/ I guess I have to do the same change for the is_method_handle_invoke flag. Maybe we should compare the whole _flags.word instead of every single bit in there? -- Christian From eric.caspole at amd.com Mon Oct 12 09:53:41 2009 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 12 Oct 2009 09:53:41 -0700 Subject: Possibility of code cache unloading Message-ID: We discovered some app servers do not have really well behaved class loader schemes, so that in a long running process with multiple re- deployments of the same web app, the old stuff never gets unloaded and the first thing to run out of space in this case was the code cache. In this event the compiler shuts itself off and does not turn itself on regardless of what happens in later GC/sweep cycles. We have been wondering what it would take to do some kind of code cache unloading so long running applications like this won't end up having the later redeployments running interpreter-only. Many users do not even know when this has happened and may or may not notice a gradual mysterious slowdown until they just restart the process. In various discussions ideas have popped up from marking some amount of existing nmethods non-entrant so they will get unloaded in the existing code cache, to more elaborate reallocation schemes for the whole code cache. If necessary, a short term slowdown before getting back to having all the hot methods recompiled seems better than restarting the process. Perhaps there could be some JMX notification for this situation. One idea that came out of our testing was the idea of a current working set of hot methods. We saw that if enough space could be regained in the code cache, the program's normal operation would require recompiles only of the current hot method set, which is hopefully a lot smaller than the whole code cache size. Then it would quickly resume normal operation, and only in the event of one or more web app redeployments as mentioned above would the code cache require another flush operation, hopefully days or weeks later. Lastly, it is probably desirable to have a fallback plan of giving up and shutting off the compiler if the flush cycles are happening too often, for example if the hot method working set size is too close to the whole code cache size, and the application performance won't be any worse than it gets today. We'd like to hear if anyone else has a strong opinion or great idea on this topic, and what corner case did we not think of. I remember a wise crack about this topic at the JVM Languages Summit a few weeks ago so it seems someone out there is thinking about it. Thanks, Eric From Thomas.Rodriguez at Sun.COM Mon Oct 12 12:45:19 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 12 Oct 2009 12:45:19 -0700 Subject: Possibility of code cache unloading In-Reply-To: References: Message-ID: <292470BD-78BD-4CD5-A0E3-A0B3B433B1AD@sun.com> There are two main problems. First is how to identify nmethods which aren't being used without penalizing execution too much and also without introducing new races. Reclamation of nmethods is somewhat tricky and reusing existing mechanisms would be good. Second is the policy part. Reclamation of nmethods isn't prompt so you have to get enough warning that the code cache is getting full to start reclamation before you run out. It's basically a GC policy problem though we can always simply delay compilation until some storage has been reclaimed. A hiccup near the transition would still be better than our current policy of simply stopping compilation. For the first part, I'd always imagined we end up with some strategy where we marked methods as speculatively not entrant and if they weren't used within some time period we'd transition them fully to not entrant and reclaim the nmethod storage. One problem with this is the repatching of the nmethod back into a normal state. I guess if it's done at a safepoint it wouldn't be a big deal. On the other hand it occurred to me today that we could rely on the same guarantees that the nmethod sweeper uses to do this without requiring patching. There are only two ways to get into compiled code. You either grab the nmethod entry point from the methodOop you are invoking, which is how interpreter invokes and polymorphic dispatch work, or you have a CompiledIC that jumps you there directly which is the normal way compiled code works. If you break both of these kinds of links then an nmethod can no longer be invoked. This is essentially how making an nmethod not entrant works but since the cleaning of inline caches is done at a safepoint we also patch the entry point of the nmethod to dispatch back into the call resolution code. This allows the cleaning of the CompiledICs to be done lazily because any caller that still references the nmethod will still end up back in the resolution code. I think we could use the same strategy for identifying unused nmethods. We simply break the reference from the methodOop to the nmethod and start a cache cleaning but without patching the entry point. If we ever invoke those nmethods again we'll end up going through the call resolution code where we can detect that the nmethod is really being used and simply restore the nmethod and continue using it. If it's never referenced within some time period the nmethod can simply be freed because we know that it's clean. As far as policy goes we could simply mark every nmethod this way when we get into trouble but I think we'd want a more GC like policy that would begin identifying nmethods once the code cache started filling up and reclaim them before we actually run out. tom On Oct 12, 2009, at 9:53 AM, Eric Caspole wrote: > We discovered some app servers do not have really well behaved class > loader schemes, so that in a long running process with multiple re- > deployments of the same web app, the old stuff never gets unloaded > and the first thing to run out of space in this case was the code > cache. In this event the compiler shuts itself off and does not turn > itself on regardless of what happens in later GC/sweep cycles. > > We have been wondering what it would take to do some kind of code > cache unloading so long running applications like this won't end up > having the later redeployments running interpreter-only. Many users > do not even know when this has happened and may or may not notice a > gradual mysterious slowdown until they just restart the process. > > In various discussions ideas have popped up from marking some amount > of existing nmethods non-entrant so they will get unloaded in the > existing code cache, to more elaborate reallocation schemes for the > whole code cache. If necessary, a short term slowdown before getting > back to having all the hot methods recompiled seems better than > restarting the process. Perhaps there could be some JMX notification > for this situation. > > One idea that came out of our testing was the idea of a current > working set of hot methods. We saw that if enough space could be > regained in the code cache, the program's normal operation would > require recompiles only of the current hot method set, which is > hopefully a lot smaller than the whole code cache size. Then it > would quickly resume normal operation, and only in the event of one > or more web app redeployments as mentioned above would the code > cache require another flush operation, hopefully days or weeks later. > > Lastly, it is probably desirable to have a fallback plan of giving > up and shutting off the compiler if the flush cycles are happening > too often, for example if the hot method working set size is too > close to the whole code cache size, and the application performance > won't be any worse than it gets today. > > We'd like to hear if anyone else has a strong opinion or great idea > on this topic, and what corner case did we not think of. I remember > a wise crack about this topic at the JVM Languages Summit a few > weeks ago so it seems someone out there is thinking about it. > > Thanks, > Eric > > From eric.caspole at amd.com Mon Oct 12 17:51:18 2009 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 12 Oct 2009 17:51:18 -0700 Subject: Possibility of code cache unloading In-Reply-To: <292470BD-78BD-4CD5-A0E3-A0B3B433B1AD@sun.com> References: <292470BD-78BD-4CD5-A0E3-A0B3B433B1AD@sun.com> Message-ID: <1480C7D9-BB6A-45A1-8FA7-F88A9D8E2236@amd.com> Tom, Thanks for your comments. Your idea is a good extension of what I have been playing with. I am going to do some experiments on the big apps I have access to. Eric On Oct 12, 2009, at 12:45 PM, Tom Rodriguez wrote: > There are two main problems. First is how to identify nmethods > which aren't being used without penalizing execution too much and > also without introducing new races. Reclamation of nmethods is > somewhat tricky and reusing existing mechanisms would be good. > Second is the policy part. Reclamation of nmethods isn't prompt so > you have to get enough warning that the code cache is getting full > to start reclamation before you run out. It's basically a GC > policy problem though we can always simply delay compilation until > some storage has been reclaimed. A hiccup near the transition > would still be better than our current policy of simply stopping > compilation. > > For the first part, I'd always imagined we end up with some > strategy where we marked methods as speculatively not entrant and > if they weren't used within some time period we'd transition them > fully to not entrant and reclaim the nmethod storage. One problem > with this is the repatching of the nmethod back into a normal > state. I guess if it's done at a safepoint it wouldn't be a big deal. > > On the other hand it occurred to me today that we could rely on the > same guarantees that the nmethod sweeper uses to do this without > requiring patching. There are only two ways to get into compiled > code. You either grab the nmethod entry point from the methodOop > you are invoking, which is how interpreter invokes and polymorphic > dispatch work, or you have a CompiledIC that jumps you there > directly which is the normal way compiled code works. If you break > both of these kinds of links then an nmethod can no longer be > invoked. This is essentially how making an nmethod not entrant > works but since the cleaning of inline caches is done at a > safepoint we also patch the entry point of the nmethod to dispatch > back into the call resolution code. This allows the cleaning of > the CompiledICs to be done lazily because any caller that still > references the nmethod will still end up back in the resolution code. > > I think we could use the same strategy for identifying unused > nmethods. We simply break the reference from the methodOop to the > nmethod and start a cache cleaning but without patching the entry > point. If we ever invoke those nmethods again we'll end up going > through the call resolution code where we can detect that the > nmethod is really being used and simply restore the nmethod and > continue using it. If it's never referenced within some time > period the nmethod can simply be freed because we know that it's > clean. > > As far as policy goes we could simply mark every nmethod this way > when we get into trouble but I think we'd want a more GC like > policy that would begin identifying nmethods once the code cache > started filling up and reclaim them before we actually run out. > > tom > > On Oct 12, 2009, at 9:53 AM, Eric Caspole wrote: > >> We discovered some app servers do not have really well behaved >> class loader schemes, so that in a long running process with >> multiple re-deployments of the same web app, the old stuff never >> gets unloaded and the first thing to run out of space in this case >> was the code cache. In this event the compiler shuts itself off >> and does not turn itself on regardless of what happens in later GC/ >> sweep cycles. >> >> We have been wondering what it would take to do some kind of code >> cache unloading so long running applications like this won't end >> up having the later redeployments running interpreter-only. Many >> users do not even know when this has happened and may or may not >> notice a gradual mysterious slowdown until they just restart the >> process. >> >> In various discussions ideas have popped up from marking some >> amount of existing nmethods non-entrant so they will get unloaded >> in the existing code cache, to more elaborate reallocation schemes >> for the whole code cache. If necessary, a short term slowdown >> before getting back to having all the hot methods recompiled seems >> better than restarting the process. Perhaps there could be some >> JMX notification for this situation. >> >> One idea that came out of our testing was the idea of a current >> working set of hot methods. We saw that if enough space could be >> regained in the code cache, the program's normal operation would >> require recompiles only of the current hot method set, which is >> hopefully a lot smaller than the whole code cache size. Then it >> would quickly resume normal operation, and only in the event of >> one or more web app redeployments as mentioned above would the >> code cache require another flush operation, hopefully days or >> weeks later. >> >> Lastly, it is probably desirable to have a fallback plan of giving >> up and shutting off the compiler if the flush cycles are happening >> too often, for example if the hot method working set size is too >> close to the whole code cache size, and the application >> performance won't be any worse than it gets today. >> >> We'd like to hear if anyone else has a strong opinion or great >> idea on this topic, and what corner case did we not think of. I >> remember a wise crack about this topic at the JVM Languages Summit >> a few weeks ago so it seems someone out there is thinking about it. >> >> Thanks, >> Eric >> >> > > From Thomas.Rodriguez at Sun.COM Mon Oct 12 13:14:14 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 12 Oct 2009 13:14:14 -0700 Subject: review (XS) for 6889869: assert(!Interpreter::bytecode_should_reexecute(code), "should not reexecute") In-Reply-To: <1255333263.29170.1.camel@macbook> References: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> <1255333263.29170.1.camel@macbook> Message-ID: I'd considered adding an is_same_info method to PcDesc and that's a good reason to do it. Actually looking at it some more there's another latent issue because it doesn't check _obj_decode_offset either. I'll change it do this. openjdk.java.net is still borked so I'll update the webrev when it's back but it's basically this: diff -r 03b336640699 src/share/vm/code/pcDesc.hpp --- a/src/share/vm/code/pcDesc.hpp Wed Oct 07 15:38:37 2009 -0700 +++ b/src/share/vm/code/pcDesc.hpp Mon Oct 12 13:11:54 2009 -0700 @@ -39,6 +39,7 @@ class PcDesc VALUE_OBJ_CLASS_SPEC { struct { unsigned int reexecute: 1; } bits; + operator ==(const PcDescFlags& other) { return word == other.word; } } _flags; public: @@ -64,6 +65,13 @@ class PcDesc VALUE_OBJ_CLASS_SPEC { bool should_reexecute() const { return _flags.bits.reexecute; } void set_should_reexecute(bool z) { _flags.bits.reexecute = z; } + // Does pd refer to the same information as pd? + bool is_same_info(const PcDesc* pd) { + return _scope_decode_offset == pd->_scope_decode_offset && + _obj_decode_offset == pd->_obj_decode_offset && + _flags == pd->_flags; + } + // Returns the real pc address real_pc(const nmethod* code) const; diff -r 03b336640699 src/share/vm/code/debugInfoRec.cpp --- a/src/share/vm/code/debugInfoRec.cpp Wed Oct 07 15:38:37 2009 -0700 +++ b/src/share/vm/code/debugInfoRec.cpp Mon Oct 12 13:07:49 2009 -0700 @@ -356,8 +356,7 @@ void DebugInformationRecorder::end_scope // search forward until it finds last. // In addition, it does not matter if the last PcDesc // is for a safepoint or not. - if (_prev_safepoint_pc < prev->pc_offset() && - prev->scope_decode_offset() == last->scope_decode_offset()) { + if (_prev_safepoint_pc < prev->pc_offset() && prev- >is_same_info(last)) { assert(prev == last-1, "sane"); prev->set_pc_offset(pc_offset); _pcs_length -= 1; tom On Oct 12, 2009, at 12:41 AM, Christian Thalinger wrote: > On Thu, 2009-10-08 at 16:40 -0700, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6889869/ > > I guess I have to do the same change for the is_method_handle_invoke > flag. Maybe we should compare the whole _flags.word instead of every > single bit in there? > > -- Christian > From thomas.rodriguez at sun.com Tue Oct 13 14:06:55 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Tue, 13 Oct 2009 21:06:55 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6890308: integrate zero assembler hotspot changes Message-ID: <20091013210657.D1B5041423@hg.openjdk.java.net> Changeset: 354d3184f6b2 Author: never Date: 2009-10-13 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/354d3184f6b2 6890308: integrate zero assembler hotspot changes Reviewed-by: never Contributed-by: gbenson at redhat.com ! make/Makefile ! make/defs.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make + make/linux/makefiles/zero.make + make/linux/makefiles/zeroshark.make + make/linux/platform_zero.in + src/cpu/zero/vm/assembler_zero.cpp + src/cpu/zero/vm/assembler_zero.hpp + src/cpu/zero/vm/assembler_zero.inline.hpp + src/cpu/zero/vm/bytecodeInterpreter_zero.cpp + src/cpu/zero/vm/bytecodeInterpreter_zero.hpp + src/cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp + src/cpu/zero/vm/bytecodes_zero.cpp + src/cpu/zero/vm/bytecodes_zero.hpp + src/cpu/zero/vm/bytes_zero.hpp + src/cpu/zero/vm/codeBuffer_zero.hpp + src/cpu/zero/vm/copy_zero.hpp + src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp + src/cpu/zero/vm/cppInterpreter_zero.cpp + src/cpu/zero/vm/cppInterpreter_zero.hpp + src/cpu/zero/vm/debug_zero.cpp + src/cpu/zero/vm/depChecker_zero.cpp + src/cpu/zero/vm/depChecker_zero.hpp + src/cpu/zero/vm/disassembler_zero.cpp + src/cpu/zero/vm/disassembler_zero.hpp + src/cpu/zero/vm/dump_zero.cpp + src/cpu/zero/vm/entryFrame_zero.hpp + src/cpu/zero/vm/entry_zero.hpp + src/cpu/zero/vm/fakeStubFrame_zero.hpp + src/cpu/zero/vm/frame_zero.cpp + src/cpu/zero/vm/frame_zero.hpp + src/cpu/zero/vm/frame_zero.inline.hpp + src/cpu/zero/vm/globalDefinitions_zero.hpp + src/cpu/zero/vm/globals_zero.hpp + src/cpu/zero/vm/icBuffer_zero.cpp + src/cpu/zero/vm/icache_zero.cpp + src/cpu/zero/vm/icache_zero.hpp + src/cpu/zero/vm/interp_masm_zero.cpp + src/cpu/zero/vm/interp_masm_zero.hpp + src/cpu/zero/vm/interpreterFrame_zero.hpp + src/cpu/zero/vm/interpreterGenerator_zero.hpp + src/cpu/zero/vm/interpreterRT_zero.cpp + src/cpu/zero/vm/interpreterRT_zero.hpp + src/cpu/zero/vm/interpreter_zero.cpp + src/cpu/zero/vm/interpreter_zero.hpp + src/cpu/zero/vm/javaFrameAnchor_zero.hpp + src/cpu/zero/vm/jniFastGetField_zero.cpp + src/cpu/zero/vm/jniTypes_zero.hpp + src/cpu/zero/vm/jni_zero.h + src/cpu/zero/vm/methodHandles_zero.cpp + src/cpu/zero/vm/nativeInst_zero.cpp + src/cpu/zero/vm/nativeInst_zero.hpp + src/cpu/zero/vm/registerMap_zero.hpp + src/cpu/zero/vm/register_definitions_zero.cpp + src/cpu/zero/vm/register_zero.cpp + src/cpu/zero/vm/register_zero.hpp + src/cpu/zero/vm/relocInfo_zero.cpp + src/cpu/zero/vm/relocInfo_zero.hpp + src/cpu/zero/vm/sharedRuntime_zero.cpp + src/cpu/zero/vm/sharkFrame_zero.hpp + src/cpu/zero/vm/stack_zero.hpp + src/cpu/zero/vm/stubGenerator_zero.cpp + src/cpu/zero/vm/stubRoutines_zero.cpp + src/cpu/zero/vm/stubRoutines_zero.hpp + src/cpu/zero/vm/templateInterpreterGenerator_zero.hpp + src/cpu/zero/vm/templateInterpreter_zero.cpp + src/cpu/zero/vm/templateInterpreter_zero.hpp + src/cpu/zero/vm/templateTable_zero.cpp + src/cpu/zero/vm/templateTable_zero.hpp + src/cpu/zero/vm/vmStructs_zero.hpp + src/cpu/zero/vm/vm_version_zero.cpp + src/cpu/zero/vm/vm_version_zero.hpp + src/cpu/zero/vm/vmreg_zero.cpp + src/cpu/zero/vm/vmreg_zero.hpp + src/cpu/zero/vm/vmreg_zero.inline.hpp + src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os/linux/vm/os_linux.cpp + src/os_cpu/linux_zero/vm/assembler_linux_zero.cpp + src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp + src/os_cpu/linux_zero/vm/bytes_linux_zero.inline.hpp + src/os_cpu/linux_zero/vm/globals_linux_zero.hpp + src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp + src/os_cpu/linux_zero/vm/os_linux_zero.cpp + src/os_cpu/linux_zero/vm/os_linux_zero.hpp + src/os_cpu/linux_zero/vm/prefetch_linux_zero.inline.hpp + src/os_cpu/linux_zero/vm/threadLS_linux_zero.cpp + src/os_cpu/linux_zero/vm/threadLS_linux_zero.hpp + src/os_cpu/linux_zero/vm/thread_linux_zero.cpp + src/os_cpu/linux_zero/vm/thread_linux_zero.hpp + src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp + src/os_cpu/linux_zero/vm/vm_version_linux_zero.cpp + src/share/vm/includeDB_zero ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/vmError.cpp From thomas.rodriguez at sun.com Tue Oct 13 19:17:18 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 14 Oct 2009 02:17:18 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6889302: TraceExceptions output should include detail message Message-ID: <20091014021721.3C12B41486@hg.openjdk.java.net> Changeset: fcb148c6b605 Author: never Date: 2009-10-13 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fcb148c6b605 6889302: TraceExceptions output should include detail message Reviewed-by: twisti, jrose, kvn ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp From vladimir.kozlov at sun.com Tue Oct 13 23:08:40 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 14 Oct 2009 06:08:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify, "Live range was lo-degree before coalesce Message-ID: <20091014060842.DED04414C6@hg.openjdk.java.net> Changeset: 5f29a958a545 Author: kvn Date: 2009-10-13 20:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5f29a958a545 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify,"Live range was lo-degree before coalesce Summary: Restore the original code: uint i = _hi_degree. Reviewed-by: never, jrose ! src/share/vm/opto/chaitin.cpp From vladimir.kozlov at sun.com Wed Oct 14 01:07:11 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 14 Oct 2009 08:07:11 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't return dead nodes") Message-ID: <20091014080713.53223414E8@hg.openjdk.java.net> Changeset: ce590301ae2a Author: kvn Date: 2009-10-13 22:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ce590301ae2a 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't return dead nodes") Summary: PhiNode::Ideal() should return TOP for Phi node with no users. Reviewed-by: never, jrose ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/ifnode.cpp From Christian.Thalinger at Sun.COM Wed Oct 14 01:06:58 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 14 Oct 2009 10:06:58 +0200 Subject: review (XS) for 6889869: assert(!Interpreter::bytecode_should_reexecute(code), "should not reexecute") In-Reply-To: References: <44CD0CD4-6BA7-4301-916F-A85FCC948E1E@sun.com> <1255333263.29170.1.camel@macbook> Message-ID: <1255507618.795.54.camel@macbook> On Mon, 2009-10-12 at 13:14 -0700, Tom Rodriguez wrote: > I'd considered adding an is_same_info method to PcDesc and that's a > good reason to do it. Actually looking at it some more there's > another latent issue because it doesn't check _obj_decode_offset > either. I'll change it do this. openjdk.java.net is still borked so > I'll update the webrev when it's back but it's basically this: > > diff -r 03b336640699 src/share/vm/code/pcDesc.hpp > --- a/src/share/vm/code/pcDesc.hpp Wed Oct 07 15:38:37 2009 -0700 > +++ b/src/share/vm/code/pcDesc.hpp Mon Oct 12 13:11:54 2009 -0700 > @@ -39,6 +39,7 @@ class PcDesc VALUE_OBJ_CLASS_SPEC { > struct { > unsigned int reexecute: 1; > } bits; > + operator ==(const PcDescFlags& other) { return word == > other.word; } > } _flags; > > public: > @@ -64,6 +65,13 @@ class PcDesc VALUE_OBJ_CLASS_SPEC { > bool should_reexecute() const { return > _flags.bits.reexecute; } > void set_should_reexecute(bool z) > { _flags.bits.reexecute = z; } > > + // Does pd refer to the same information as pd? > + bool is_same_info(const PcDesc* pd) { > + return _scope_decode_offset == pd->_scope_decode_offset && > + _obj_decode_offset == pd->_obj_decode_offset && > + _flags == pd->_flags; > + } > + > // Returns the real pc > address real_pc(const nmethod* code) const; > > diff -r 03b336640699 src/share/vm/code/debugInfoRec.cpp > --- a/src/share/vm/code/debugInfoRec.cpp Wed Oct 07 15:38:37 > 2009 -0700 > +++ b/src/share/vm/code/debugInfoRec.cpp Mon Oct 12 13:07:49 > 2009 -0700 > @@ -356,8 +356,7 @@ void DebugInformationRecorder::end_scope > // search forward until it finds last. > // In addition, it does not matter if the last PcDesc > // is for a safepoint or not. > - if (_prev_safepoint_pc < prev->pc_offset() && > - prev->scope_decode_offset() == last->scope_decode_offset()) { > + if (_prev_safepoint_pc < prev->pc_offset() && prev- > >is_same_info(last)) { > assert(prev == last-1, "sane"); > prev->set_pc_offset(pc_offset); > _pcs_length -= 1; That looks very good. -- Christian From thomas.rodriguez at sun.com Wed Oct 14 12:35:32 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 14 Oct 2009 19:35:32 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6889869: assert(!Interpreter::bytecode_should_reexecute(code), "should not reexecute") Message-ID: <20091014193534.34927415EE@hg.openjdk.java.net> Changeset: 8e954aedbb81 Author: never Date: 2009-10-14 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8e954aedbb81 6889869: assert(!Interpreter::bytecode_should_reexecute(code),"should not reexecute") Reviewed-by: jrose, kvn, cfang, twisti ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/pcDesc.hpp From Vladimir.Kozlov at Sun.COM Wed Oct 14 14:14:12 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 14 Oct 2009 14:14:12 -0700 Subject: Request for reviews (XS): 6890984: Comparison of 2 arrays could cause VM crash Message-ID: <4AD63F24.4060600@sun.com> http://cr.openjdk.java.net/~kvn/6890984/webrev.00 Fixed 6890984: Comparison of 2 arrays could cause VM crash Problem: I did incorrect "optimization" in 6827605 changes - replaced 2 null pointer checks with andptr(p1,p2) instruction which damages the result register. I should have use testptr(p1,p2) but it is also incorrect. There is problem on sparc also - br() instruction is used instead of brx() when comparing pointers. Solution: Restore original null checks for x86. Use brx() when comparing pointers on sparc. Reviewed by: Fix verified (y/n): y, bug's test on both platforms with 32- and 64-bit VM Other testing: JPRT From Changpeng.Fang at Sun.COM Wed Oct 14 14:45:52 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Wed, 14 Oct 2009 14:45:52 -0700 Subject: Request for reviews (XS): 6890984: Comparison of 2 arrays could cause VM crash In-Reply-To: <4AD63F24.4060600@sun.com> References: <4AD63F24.4060600@sun.com> Message-ID: <4AD64690.40904@sun.com> Looks Good! Changpeng On 10/14/09 14:14, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6890984/webrev.00 > > Fixed 6890984: Comparison of 2 arrays could cause VM crash > > Problem: > I did incorrect "optimization" in 6827605 changes - > replaced 2 null pointer checks with andptr(p1,p2) > instruction which damages the result register. > I should have use testptr(p1,p2) but it is also incorrect. > There is problem on sparc also - br() instruction is used > instead of brx() when comparing pointers. > > Solution: > Restore original null checks for x86. > Use brx() when comparing pointers on sparc. > > Reviewed by: > > Fix verified (y/n): y, bug's test on both platforms with 32- and > 64-bit VM > > Other testing: > JPRT > From Thomas.Rodriguez at Sun.COM Wed Oct 14 14:46:43 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 14 Oct 2009 14:46:43 -0700 Subject: Request for reviews (XS): 6890984: Comparison of 2 arrays could cause VM crash In-Reply-To: <4AD63F24.4060600@sun.com> References: <4AD63F24.4060600@sun.com> Message-ID: <38580EC9-3658-4DA4-AE4B-6A2A4796F930@sun.com> That looks good. tom On Oct 14, 2009, at 2:14 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6890984/webrev.00 > > Fixed 6890984: Comparison of 2 arrays could cause VM crash > > Problem: > I did incorrect "optimization" in 6827605 changes - > replaced 2 null pointer checks with andptr(p1,p2) > instruction which damages the result register. > I should have use testptr(p1,p2) but it is also incorrect. > There is problem on sparc also - br() instruction is used > instead of brx() when comparing pointers. > > Solution: > Restore original null checks for x86. > Use brx() when comparing pointers on sparc. > > Reviewed by: > > Fix verified (y/n): y, bug's test on both platforms with 32- and 64- > bit VM > > Other testing: > JPRT > From vladimir.kozlov at sun.com Wed Oct 14 15:55:54 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 14 Oct 2009 22:55:54 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6722084: JPRT make file doesn't create required symbolic link to libjvm.so Message-ID: <20091014225556.8C6A54162C@hg.openjdk.java.net> Changeset: 23862fc517bb Author: kvn Date: 2009-10-14 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/23862fc517bb 6722084: JPRT make file doesn't create required symbolic link to libjvm.so Summary: Use -y zip option to preserve symbolic links. Reviewed-by: never, jcoomes, kamg ! make/jprt.gmk ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make From vladimir.kozlov at sun.com Wed Oct 14 17:53:51 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 15 Oct 2009 00:53:51 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6890984: Comparison of 2 arrays could cause VM crash Message-ID: <20091015005353.9958F4164E@hg.openjdk.java.net> Changeset: d40f03b57795 Author: kvn Date: 2009-10-14 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d40f03b57795 6890984: Comparison of 2 arrays could cause VM crash Summary: Restore original null checks. Reviewed-by: never, cfang ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp From Thomas.Rodriguez at Sun.COM Wed Oct 14 17:54:20 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 14 Oct 2009 17:54:20 -0700 Subject: review (XS) for 6891750: deopt blob kills values in O5 Message-ID: <9A1424A3-AD20-4C9A-87EE-6D2824DC6315@Sun.COM> http://cr.openjdk.java.net/~never/6891750 From John.Rose at Sun.COM Wed Oct 14 18:45:13 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 14 Oct 2009 18:45:13 -0700 Subject: upcoming coordinated pushes; pre-integration testing Message-ID: Two "interesting" changes (as in "we live in interesting times") are coming soon to our JDK7 workflow in the Hotspot team, and specifically in the hotspot-comp repository. Here is a heads-up. 1. Christian and I are going to push some coordinated changes for JSR 292 to hotspot-comp, which will then flow up through hotspot into JDK7. The changes are coordinated because they affect both jdk and hotspot sub-repositories, and must be pushed together. They involve changes to the JSR 292 API and the JVM, which have to be packaged together. These changes will have to be pushed together by the gatekeeper at the hotspot-comp level and at the parent level (the integration repo.). 2. These changes will come with new regression tests, in hotspot-comp/ jdk/test/java/dyn/. These regression tests will be packaged as JUnit 4.5 tests. In order to run them, I've enhanced jtreg (with Mark and Jon G's help) to accept such tests. (I suspect having a jtreg to JUnit bridge will make other people happy too.) If you use jtreg to run regression tests, the JUnit-based tests in jdk/ test/java/dyn will fail unless you upgrade jtreg. We are working on this change, which is tracked under bug 6891715 and may be inspected here: http://cr.openjdk.java.net/~jrose/6891715/webrev.00/ . If you need a provisional binary, you can find one at http://hg.openjdk.java.net/mlvm/mlvm/file/tip/jtreg/ . Follow the instructions to drop junit.jar into the jtreg installation. The first step will consist of a "trial balloon" in which I will push a single JUnit test file to jdk, which performs a warm-and-breathing test on the API which is currently in the JDK7 builds (the JavaOne Preview version). Stay tuned for a review request. -- John From Christian.Thalinger at Sun.COM Thu Oct 15 01:16:10 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Oct 2009 10:16:10 +0200 Subject: review (XS) for 6891750: deopt blob kills values in O5 In-Reply-To: <9A1424A3-AD20-4C9A-87EE-6D2824DC6315@Sun.COM> References: <9A1424A3-AD20-4C9A-87EE-6D2824DC6315@Sun.COM> Message-ID: <1255594570.795.94.camel@macbook> On Wed, 2009-10-14 at 17:54 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6891750 Looks good. -- Christian From John.Rose at Sun.COM Thu Oct 15 01:47:19 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 15 Oct 2009 01:47:19 -0700 Subject: review (S) for 6891770: JSR 292 API needs initial unit tests Message-ID: Here is the first JUnit-based test for JSR 292: http://cr.openjdk.java.net/~jrose/6891770/webrev.00 I have marked this review as small (S) because there is little or no need to look at the details of the unit test, as an API test. (Although you may if you like!) The important thing is the "@test" comment which links it into the jtreg regression suite in the JDK. The test is a backport of the corresponding test 'MethodHandlesTest.java' in the following mlvm patch: http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/indy.tests.patch To backport it for the present purpose, I simply removed test cases that do not pass on the JDK7 M3 version of the JSR 292 RI, which is what is in the JDK7 repo. at this moment. (There is more to come soon!) This unit test passes fully, both the full version in the mlvm patch repo (running on a JDK7 with those patches), and the abbreviated version (running on the present unpatched JDK7). This test is known to work on i386 platforms. It automatically senses other platforms and excludes itself. See the method named 'checkImplementedPlatform'. (There are tracking bugs filed for JSR 292 on those platforms.) In order to successfully run this unit test, jtreg must be upgraded (to 4.1, including JUnit support). This means that some nightly and pre-integration jtreg runs are likely to show this new test failing, in an uninteresting way. I have verified that this happens in a clean way with jtreg 4.0, and that the other unit tests will run correctly. The error looks like this: test result: Error. Bad action for script: junit The new test may appear to fail in nightly and pre-integration testing, until the upgraded test harness is accepted and installed by SQE. (It is not clear whether this will happen, because the selection of tests might not include java.dyn.) Independently of this push, I am working with them on the appropriate upgrades and test inclusions. -- John From Christian.Thalinger at Sun.COM Thu Oct 15 08:33:40 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Oct 2009 17:33:40 +0200 Subject: review (S) for 6891770: JSR 292 API needs initial unit tests In-Reply-To: References: Message-ID: <1255620820.795.120.camel@macbook> On Thu, 2009-10-15 at 01:47 -0700, John Rose wrote: > Here is the first JUnit-based test for JSR 292: > http://cr.openjdk.java.net/~jrose/6891770/webrev.00 I downloaded the modified jtreg version you mentioned in your earlier email, copied the make files from a jdk test directory and ran the tests with: $ make JPRT_JTREG_HOME=$HOME/mlvm/jtreg-no-junit/jtreg PRODUCT_HOME= $HOME/mlvm/hotspot/build/solaris/jdk-solaris-i586/debug/ TESTDIRS=test and the run was: -------------------------------------------------- TEST: test/java/dyn/MethodHandlesTest.java TEST RESULT: Passed. Execution successful -------------------------------------------------- Test results: passed: 1 So, the changes look good. -- Christian From John.Rose at Sun.COM Thu Oct 15 11:59:51 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 15 Oct 2009 11:59:51 -0700 Subject: review (S) for 6891770: JSR 292 API needs initial unit tests In-Reply-To: <1255620820.795.120.camel@macbook> References: <1255620820.795.120.camel@macbook> Message-ID: <50B0FA2B-0617-4B5A-85DE-3F86DBB9E610@Sun.COM> Thanks! I'm glad it actually works for someone else. -- John On Oct 15, 2009, at 8:33 AM, Christian Thalinger wrote: > On Thu, 2009-10-15 at 01:47 -0700, John Rose wrote: >> Here is the first JUnit-based test for JSR 292: >> http://cr.openjdk.java.net/~jrose/6891770/webrev.00 > > I downloaded the modified jtreg version you mentioned in your earlier > email, copied the make files from a jdk test directory and ran the > tests > with: > > $ make JPRT_JTREG_HOME=$HOME/mlvm/jtreg-no-junit/jtreg PRODUCT_HOME= > $HOME/mlvm/hotspot/build/solaris/jdk-solaris-i586/debug/ TESTDIRS=test > > and the run was: > > -------------------------------------------------- > TEST: test/java/dyn/MethodHandlesTest.java > TEST RESULT: Passed. Execution successful > -------------------------------------------------- > Test results: passed: 1 > > So, the changes look good. > > -- Christian > From Thomas.Rodriguez at Sun.COM Thu Oct 15 17:09:04 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 15 Oct 2009 17:09:04 -0700 Subject: phi/mergemem transformations Message-ID: I've got the following pattern: 164 MergeMem === 1 160 165 [[ 110 105 96 ]] { N165:rawptr:BotPTR } Memory: @BotPTR *+bot, idx=Bot; 94 Region === 94 53 88 30 [[ 111 97 110 96 95 94 ]] 96 Phi === 94 48 164 7 [[ 54 ]] #memory Memory: @BotPTR *+bot, idx=Bot; 110 Phi === 94 48 164 26 [[ 54 ]] #memory Memory: @rawptr:BotPTR, idx=Raw; and PhiNode::Ideal seems happy to distribute the slice of the MergeMem to the raw Phi but not to the BotPTR phi. I noticed this piece of code in PhiNode::Ideal: // This restriction is temporarily necessary to ensure termination: if (!saw_self && adr_type() == TypePtr::BOTTOM) merge_width = 0; which seems like the main disabler. The code is from 2000 and there's no real information about what problem it was really trying to solve. D 1.170.2.3 00/07/11 13:44:38 nips 440 430 00267/00045/01966 MRs: COMMENTS: Merged changes between child workspace "/net/jano/export/disk05/ hotspot/users/nips/c2_merge" and parent workspace "/net/jano/export/disk05/hotspot/ws/main/baseline". Any memories from the wayback machine or theories? tom From John.Rose at Sun.COM Thu Oct 15 17:31:09 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 15 Oct 2009 17:31:09 -0700 Subject: phi/mergemem transformations In-Reply-To: References: Message-ID: It's actually this delta: D 1.174 00/06/19 00:47:54 jrose 434 431 Phi nodes of type Memory now record their alias type also. Add factory methods PhiNode::make/make_blank/slice_memory. Teach PhiNode::Ideal to split phis through memory merges. Add manifest constants regarding Phi/Region layout. Add PhiNode::region() accessor, degrade_to_copy operation. Adjust PhiNode::Ideal logic to split Phis through MergeMems. Make CreateExNode::bottom_type be accurate. I don't remember the problem, nor why it was "temporary". I suppose I ran into optimizer loops where a degenerate phi nest could cause this split logic to repeat forever. Perhaps our eager dead code elimination makes this a thing of the past. -- John From Thomas.Rodriguez at Sun.COM Thu Oct 15 18:23:51 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 15 Oct 2009 18:23:51 -0700 Subject: phi/mergemem transformations In-Reply-To: References: Message-ID: <98FA934D-9595-4905-8323-C527A986ADF6@Sun.COM> On Oct 15, 2009, at 5:31 PM, John Rose wrote: > It's actually this delta: > D 1.174 00/06/19 00:47:54 jrose 434 431 > Phi nodes of type Memory now record their alias type also. > Add factory methods PhiNode::make/make_blank/slice_memory. > Teach PhiNode::Ideal to split phis through memory merges. > Add manifest constants regarding Phi/Region layout. > Add PhiNode::region() accessor, degrade_to_copy operation. > Adjust PhiNode::Ideal logic to split Phis through MergeMems. > Make CreateExNode::bottom_type be accurate. I bow to your superior archaeology skills. ;) > > I don't remember the problem, nor why it was "temporary". > > I suppose I ran into optimizer loops where a degenerate phi nest > could cause this split logic to repeat forever. > > Perhaps our eager dead code elimination makes this a thing of the > past. That was my thinking as well. I don't know how common it is for normal code but the late inlining work creates some different patterns that I would have expected to get cleaned up. I'll look into relaxing this at a later point. Thanks! tom > > -- John From thomas.rodriguez at sun.com Thu Oct 15 23:17:07 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 16 Oct 2009 06:17:07 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6891750: deopt blob kills values in O5 Message-ID: <20091016061710.1BE7141858@hg.openjdk.java.net> Changeset: 0a46d0c5dccb Author: never Date: 2009-10-15 11:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0a46d0c5dccb 6891750: deopt blob kills values in O5 Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp + test/compiler/6891750/Test6891750.java From john.coomes at sun.com Fri Oct 16 02:25:32 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 09:25:32 +0000 Subject: hg: jdk7/hotspot-comp: 7 new changesets Message-ID: <20091016092532.2678F41891@hg.openjdk.java.net> Changeset: e76b72562a98 Author: ohair Date: 2009-09-03 17:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/e76b72562a98 6855174: Improve log output when builds transition from one workspace to another Reviewed-by: jjg ! make/Defs-internal.gmk ! make/corba-rules.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/jdk-rules.gmk ! make/langtools-rules.gmk ! make/sponsors-rules.gmk Changeset: 931f7f7501da Author: ohair Date: 2009-09-17 13:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/931f7f7501da Merge Changeset: 76f6380ac0b4 Author: xdono Date: 2009-09-18 09:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/76f6380ac0b4 Merge Changeset: d70b157f6407 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/d70b157f6407 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! make/corba-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/langtools-rules.gmk ! make/sponsors-rules.gmk Changeset: 3ac6dcf78232 Author: robilad Date: 2009-09-23 20:06 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/3ac6dcf78232 6872735: Further update build readme for new platforms 6641691: Bring build readme's up-to-date Summary: Added build instructions for Debian, Ubuntu 8.04, 8.10, 9.04, Fedora 10, 11, OpenSolaris 2009.06, OpenSUSE and Mandriva Reviewed-by: ohair, andrew ! README-builds.html Changeset: 2c88089b6e1c Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/2c88089b6e1c Added tag jdk7-b73 for changeset 3ac6dcf78232 ! .hgtags Changeset: d1516b9f2395 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/d1516b9f2395 Added tag jdk7-b74 for changeset 2c88089b6e1c ! .hgtags From john.coomes at sun.com Fri Oct 16 02:25:36 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 09:25:36 +0000 Subject: hg: jdk7/hotspot-comp/corba: 8 new changesets Message-ID: <20091016092544.6D0A241892@hg.openjdk.java.net> Changeset: 1c130e7b7a2e Author: ohair Date: 2009-09-02 09:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/1c130e7b7a2e 6875240: Reduce Makefile build time by limiting repeated exec's (mostly for cygwin building) Reviewed-by: jjg, iris ! make/Makefile ! make/common/BuildToolJar.gmk ! make/common/CancelImplicits.gmk ! make/common/Defs.gmk ! make/common/Rules.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk ! make/jprt.properties Changeset: 085333867e39 Author: xdono Date: 2009-09-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/085333867e39 Merge Changeset: 546970b224ca Author: xdono Date: 2009-09-18 09:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/546970b224ca Merge Changeset: 31ce3cac3cc1 Author: ohair Date: 2009-09-18 16:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/31ce3cac3cc1 6883790: corba build problem related to wildcard and vpath, regression Reviewed-by: tbell ! make/common/Rules.gmk Changeset: 2aa5665d86a5 Author: ohair Date: 2009-09-18 17:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/2aa5665d86a5 6883816: corba fix for missing javax/transaction/xa classes (the real fix) Reviewed-by: tbell ! make/common/Rules.gmk Changeset: b751c528c555 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/b751c528c555 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! make/common/CancelImplicits.gmk Changeset: 5d0cf59a3203 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/5d0cf59a3203 Added tag jdk7-b73 for changeset b751c528c555 ! .hgtags Changeset: 0fb137085952 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/0fb137085952 Added tag jdk7-b74 for changeset 5d0cf59a3203 ! .hgtags From john.coomes at sun.com Fri Oct 16 02:28:35 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 09:28:35 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 6 new changesets Message-ID: <20091016092847.0E61741893@hg.openjdk.java.net> Changeset: 534e23823a1b Author: ohair Date: 2009-09-21 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/534e23823a1b 6856630: Restructure jaxp/jaxws repositories Reviewed-by: darcy, tbell ! .hgignore ! README + build-defs.xml + build-drop-template.xml + build.properties + build.xml + jaxp.properties ! make/Makefile - make/build.properties - make/build.xml ! make/jprt.properties - make/tools/StripProperties/StripProperties.java - make/tools/StripProperties/StripPropertiesTask.java + nbproject/findbugs.settings + nbproject/project.xml + nbproject/sqe.properties + patches/jaxp_src/README Changeset: 0748962aa825 Author: ohair Date: 2009-09-21 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/0748962aa825 6884220: Have drop sources ignore the output.dir property Reviewed-by: xdono ! build.properties Changeset: ee9c7578aca5 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/ee9c7578aca5 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java Changeset: feb05980f9f2 Author: ohair Date: 2009-09-28 19:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/feb05980f9f2 6886359: Missing jaxws property files and missing changes in jaxp/jaxws drop bundles Reviewed-by: jjg, tbell ! build-defs.xml ! jaxp.properties Changeset: ea7b88c676dd Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/ea7b88c676dd Added tag jdk7-b73 for changeset feb05980f9f2 ! .hgtags Changeset: 555fb78ee4ce Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/555fb78ee4ce Added tag jdk7-b74 for changeset ea7b88c676dd ! .hgtags From john.coomes at sun.com Fri Oct 16 02:28:52 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 09:28:52 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 5 new changesets Message-ID: <20091016092901.804D741894@hg.openjdk.java.net> Changeset: ae2bec597586 Author: ohair Date: 2009-09-21 13:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/ae2bec597586 6856630: Restructure jaxp/jaxws repositories Reviewed-by: darcy, tbell ! .hgignore ! README + build-defs.xml + build-drop-template.xml + build.properties + build.xml + jaxws.properties ! make/Makefile - make/build.properties - make/build.xml ! make/jprt.properties - make/tools/StripProperties/StripProperties.java - make/tools/StripProperties/StripPropertiesTask.java + nbproject/findbugs.settings + nbproject/project.xml + nbproject/sqe.properties + patches/jaxws_src/README Changeset: 77708e68db52 Author: ohair Date: 2009-09-21 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/77708e68db52 6884220: Have drop sources ignore the output.dir property Reviewed-by: xdono ! build.properties Changeset: 558985e26fe1 Author: ohair Date: 2009-09-28 19:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/558985e26fe1 6886359: Missing jaxws property files and missing changes in jaxp/jaxws drop bundles Reviewed-by: jjg, tbell ! build-defs.xml ! jaxws.properties Changeset: f4466e1b6080 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/f4466e1b6080 Added tag jdk7-b73 for changeset 558985e26fe1 ! .hgtags Changeset: fcf2b8b5d606 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/fcf2b8b5d606 Added tag jdk7-b74 for changeset f4466e1b6080 ! .hgtags From john.coomes at sun.com Fri Oct 16 02:32:25 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 09:32:25 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 101 new changesets Message-ID: <20091016095416.59B8C4189C@hg.openjdk.java.net> Changeset: fdf11ce72e8e Author: mchung Date: 2009-08-06 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fdf11ce72e8e 4917309: (cl) Reduce internal usage of ClassNotFoundExceptions during class-loading Summary: Change findBootstrapClass to return null instead of throwing CNFE if class not found Reviewed-by: alanb, dholmes, iris ! src/share/classes/java/lang/ClassLoader.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/ClassLoader.c Changeset: 3323e6c925f9 Author: mchung Date: 2009-08-06 16:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3323e6c925f9 6864028: Update the java launcher to use the new entry point JVM_FindClassFromBootLoader Summary: Update the java launcher to use the new entry point JVM_FindClassFromBootLoader Reviewed-by: ksrini ! src/share/bin/java.h ! src/solaris/bin/java_md.c ! src/windows/bin/java_md.c Changeset: 1f1c824e6244 Author: mchung Date: 2009-08-24 10:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1f1c824e6244 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 799731b1cd03 Author: mchung Date: 2009-08-27 12:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/799731b1cd03 Merge - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: dfb5cf81d8cd Author: mchung Date: 2009-09-03 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dfb5cf81d8cd Merge Changeset: b9b7f56bdfa3 Author: mchung Date: 2009-09-04 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b9b7f56bdfa3 Merge Changeset: 466915134131 Author: mchung Date: 2009-09-08 12:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/466915134131 Merge Changeset: 0d50d40a4a39 Author: martin Date: 2009-09-08 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0d50d40a4a39 6850958: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit Summary: Test hotspot/jvmti fix 6850957 using ProcessBuilder test infrastructure Reviewed-by: tbell, dholmes, alanb, ysr ! test/java/lang/ProcessBuilder/Basic.java Changeset: 8252729d51a3 Author: mullan Date: 2009-09-09 09:54 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8252729d51a3 6745437: Add option to only check revocation of end-entity certificate in a chain of certificates 6869739: Cannot check revocation of single certificate without validating the entire chain Reviewed-by: xuelei + src/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java ! src/share/classes/sun/security/provider/certpath/Builder.java ! src/share/classes/sun/security/provider/certpath/CertId.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java + src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! src/share/classes/sun/security/x509/AccessDescription.java Changeset: 7b85ef3d752e Author: mullan Date: 2009-09-09 09:59 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7b85ef3d752e Merge Changeset: f1eb4c28b313 Author: lancea Date: 2009-09-09 20:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f1eb4c28b313 6737212: Fixed javadoc warning messages in RowSet classes Reviewed-by: darcy ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlReader.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java Changeset: 46406871599c Author: sherman Date: 2009-09-11 16:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/46406871599c 6881337: ZipEntry.setComment() was accidentally changed back to old spec/impl in jdk7-b64 Summary: restored the correct spec and implementation of setComment Reviewed-by: martin ! src/share/classes/java/util/zip/ZipEntry.java Changeset: 020a0fed38c9 Author: martin Date: 2009-09-12 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/020a0fed38c9 6881442: (reflect) Race condition in Class.getName() Summary: only read "name" field racily once Reviewed-by: darcy ! src/share/classes/java/lang/Class.java Changeset: 060c4c7082ef Author: alanb Date: 2009-09-14 15:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/060c4c7082ef 6529758: JVMTI Waiters demo crashes. Double free. Reviewed-by: ohair, tbell ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp Changeset: aac01ec2cec4 Author: alanb Date: 2009-09-14 17:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aac01ec2cec4 6876541: (file) Files.walkFileTree(...): no SecurityException if read access to the starting file is denied Reviewed-by: chegar ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java + test/java/nio/file/Files/WalkWithSecurity.java + test/java/nio/file/Files/denyAll.policy + test/java/nio/file/Files/grantAll.policy + test/java/nio/file/Files/grantTopOnly.policy Changeset: eb19c5dc52bf Author: kevinw Date: 2009-09-14 20:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eb19c5dc52bf 6842838: 64-bit failure in handling invalid manifest in launcher. Summary: Don't compare with hard-coded 32-bit -1 when checking zip fields. Reviewed-by: ksrini ! src/share/bin/parse_manifest.c + test/tools/launcher/6842838/CreateBadJar.java + test/tools/launcher/6842838/Test6842838.sh Changeset: c7e469ae3edb Author: mchung Date: 2009-09-14 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c7e469ae3edb 6878481: Add performance counters in the JDK Summary: Added new performance counters in the JDK to track performance metrics Reviewed-by: alanb, dholmes, iris, forax, andrew ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/util/zip/ZipFile.java + src/share/classes/sun/misc/PerfCounter.java ! src/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java Changeset: 0a3244fe7142 Author: mchung Date: 2009-09-14 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0a3244fe7142 Merge Changeset: f0182203084a Author: dcubed Date: 2009-09-14 18:45 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f0182203084a 6862295: JDWP threadid changes during debugging session (leading to ingored breakpoints) Summary: New test for the above fix. Reviewed-by: tbell + test/com/sun/jdi/BreakpointWithFullGC.sh Changeset: f78b7d9973b7 Author: dcubed Date: 2009-09-14 18:54 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f78b7d9973b7 Merge Changeset: e8c2dd4b8bac Author: dcubed Date: 2009-09-15 22:11 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e8c2dd4b8bac 6882363: 4/4 typos in java.util.logging javadocs Summary: Fix typos, some grammar and some inconsistencies in phrasing. Reviewed-by: tbell ! src/share/classes/java/util/logging/ErrorManager.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Formatter.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java Changeset: 81b85ea694f8 Author: tbell Date: 2009-09-16 09:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/81b85ea694f8 Merge Changeset: ee68feef41d2 Author: jccollet Date: 2009-09-18 10:51 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ee68feef41d2 6737819: sun.misc.net.DefaultProxySelector doesn't use proxy setting to localhost Summary: Move default nonProxyHosts from hardcoded to property default value Reviewed-by: chegar ! src/share/classes/java/net/doc-files/net-properties.html ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/lib/net.properties + test/java/net/ProxySelector/B6737819.java Changeset: 39c15c0a71f7 Author: andrew Date: 2009-09-10 19:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/39c15c0a71f7 6882745: Add DISABLE_INTREE_EC option to make new EC provider optional. Summary: Don't build the ec subdirectory when DISABLE_INTREE_EC is defined. Reviewed-by: vinnie ! make/sun/security/Makefile Changeset: f119e21c0ca7 Author: tbell Date: 2009-09-18 08:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f119e21c0ca7 Merge Changeset: c9cbd2a09fd4 Author: chegar Date: 2009-09-18 16:24 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c9cbd2a09fd4 6882609: Move default InMemoryCookieStore to java.net Summary: remove static dependency on sun.net.www.protocol.http Reviewed-by: alanb, jccollet ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/CookieManager.java + src/share/classes/java/net/InMemoryCookieStore.java - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java Changeset: 9cd7133ea287 Author: chegar Date: 2009-09-18 22:18 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9cd7133ea287 6882594: Remove static dependancy on NTLM authentication Reviewed-by: alanb, weijun ! make/sun/net/FILES_java.gmk ! src/share/classes/sun/net/www/protocol/http/AuthCache.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java + src/share/classes/sun/net/www/protocol/http/AuthScheme.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: 45a343706f73 Author: chegar Date: 2009-09-18 22:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/45a343706f73 Merge Changeset: d3281fa8e46c Author: mchung Date: 2009-09-17 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d3281fa8e46c 6882376: Add internal support for JRE implementation to eliminate the dependency on logging Summary: Added sun.util.logging.PlatformLogger for JRE implementation to log messages. Reviewed-by: alanb, naoto ! make/java/logging/Makefile ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/sun/util/LocaleServiceProviderPool.java + src/share/classes/sun/util/logging/PlatformLogger.java ! src/windows/classes/java/util/prefs/WindowsPreferences.java + test/sun/util/logging/PlatformLoggerTest.java Changeset: 7b4e73ca6fd7 Author: mchung Date: 2009-09-18 17:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7b4e73ca6fd7 Merge Changeset: 845fefff00a4 Author: vinnie Date: 2009-09-21 23:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/845fefff00a4 6884175: CR cleanup for 6840752: Provide out-of-the-box support for ECC algorithms Reviewed-by: wetmore ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! src/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/share/classes/sun/security/ec/SunEC.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/native/sun/security/ec/ECC_JNI.cpp - src/share/native/sun/security/ec/ec.c + src/share/native/sun/security/ec/impl/ec.c + src/share/native/sun/security/ec/impl/ec.h + src/share/native/sun/security/ec/impl/ec2.h + src/share/native/sun/security/ec/impl/ec2_163.c + src/share/native/sun/security/ec/impl/ec2_193.c + src/share/native/sun/security/ec/impl/ec2_233.c + src/share/native/sun/security/ec/impl/ec2_aff.c + src/share/native/sun/security/ec/impl/ec2_mont.c + src/share/native/sun/security/ec/impl/ec_naf.c + src/share/native/sun/security/ec/impl/ecc_impl.h + src/share/native/sun/security/ec/impl/ecdecode.c + src/share/native/sun/security/ec/impl/ecl-curve.h + src/share/native/sun/security/ec/impl/ecl-exp.h + src/share/native/sun/security/ec/impl/ecl-priv.h + src/share/native/sun/security/ec/impl/ecl.c + src/share/native/sun/security/ec/impl/ecl.h + src/share/native/sun/security/ec/impl/ecl_curve.c + src/share/native/sun/security/ec/impl/ecl_gf.c + src/share/native/sun/security/ec/impl/ecl_mult.c + src/share/native/sun/security/ec/impl/ecp.h + src/share/native/sun/security/ec/impl/ecp_192.c + src/share/native/sun/security/ec/impl/ecp_224.c + src/share/native/sun/security/ec/impl/ecp_256.c + src/share/native/sun/security/ec/impl/ecp_384.c + src/share/native/sun/security/ec/impl/ecp_521.c + src/share/native/sun/security/ec/impl/ecp_aff.c + src/share/native/sun/security/ec/impl/ecp_jac.c + src/share/native/sun/security/ec/impl/ecp_jm.c + src/share/native/sun/security/ec/impl/ecp_mont.c + src/share/native/sun/security/ec/impl/logtab.h + src/share/native/sun/security/ec/impl/mp_gf2m-priv.h + src/share/native/sun/security/ec/impl/mp_gf2m.c + src/share/native/sun/security/ec/impl/mp_gf2m.h + src/share/native/sun/security/ec/impl/mpi-config.h + src/share/native/sun/security/ec/impl/mpi-priv.h + src/share/native/sun/security/ec/impl/mpi.c + src/share/native/sun/security/ec/impl/mpi.h + src/share/native/sun/security/ec/impl/mplogic.c + src/share/native/sun/security/ec/impl/mplogic.h + src/share/native/sun/security/ec/impl/mpmontg.c + src/share/native/sun/security/ec/impl/mpprime.h + src/share/native/sun/security/ec/impl/oid.c + src/share/native/sun/security/ec/impl/secitem.c + src/share/native/sun/security/ec/impl/secoidt.h ! test/sun/security/ec/TestEC.java + test/sun/security/ec/certs/sunlabscerts.pem + test/sun/security/ec/keystore + test/sun/security/ec/truststore ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/sslecc/CipherTest.java Changeset: 81dffe63c913 Author: weijun Date: 2009-09-22 10:01 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/81dffe63c913 6877357: IPv6 address does not work Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/krb5/KrbKdcReq.java + test/sun/security/krb5/IPv6.java Changeset: 023063a403ed Author: chegar Date: 2009-09-22 14:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/023063a403ed 6882654: Remove dependency on java.util.concurrent from KeepAlive implementaion Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java Changeset: 44ccaa4bb8a0 Author: chegar Date: 2009-09-22 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/44ccaa4bb8a0 6882384: Update http protocol handler to use PlatformLogger Reviewed-by: jccollet, alanb ! src/share/classes/sun/net/www/http/HttpCapture.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/share/classes/sun/util/logging/PlatformLogger.java Changeset: b8004f6f4812 Author: kevinw Date: 2009-09-22 17:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b8004f6f4812 6882768: (launcher) test for 6842838 is broken Summary: Testcase correction. Reviewed-by: ksrini ! test/tools/launcher/6842838/Test6842838.sh Changeset: f708138c9aca Author: kevinw Date: 2009-09-22 17:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f708138c9aca Merge Changeset: 59b45d636384 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/59b45d636384 Added tag jdk7-b73 for changeset f708138c9aca ! .hgtags Changeset: 8e5d45fc8d1e Author: jgodinez Date: 2009-07-01 12:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8e5d45fc8d1e 6848799: Reg-test java/awt/print/PageFormat/PageFormatFromAttributes.java fails on Rhel_5 Reviewed-by: tdv, prr ! src/solaris/classes/sun/print/IPPPrintService.java + test/java/awt/print/PageFormat/PageFormatFromAttributes.java Changeset: 837bb8760bad Author: yan Date: 2009-07-13 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/837bb8760bad Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - src/share/classes/sun/swing/AccessibleMethod.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: a0b315ecdc78 Author: rkennke Date: 2009-07-22 15:52 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a0b315ecdc78 6857358: Two testcases are failing in jdk7 b64 pit build with java.security.AccessControlException Summary: Try to load GraphicsEnvironment with bootclassloader first, only then try app classloader. Reviewed-by: prr, tdv, igor ! src/share/classes/java/awt/GraphicsEnvironment.java Changeset: 9fa696ed1f38 Author: jgodinez Date: 2009-07-30 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9fa696ed1f38 Merge Changeset: 7fe0497ee5b5 Author: jgodinez Date: 2009-08-04 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7fe0497ee5b5 6829673: ThinLineTest: A line < 1 pixel disappears. Reviewed-by: igor, prr Contributed-by: rkennke ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java + test/sun/pisces/ThinLineTest.java Changeset: 64b0c953635d Author: rkennke Date: 2009-08-07 18:31 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/64b0c953635d 6795908: Refactor FontManager Reviewed-by: prr, igor ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/make.depend ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/font/mapfile-vers ! make/sun/font/mapfile-vers.openjdk ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/font/CMap.java ! src/share/classes/sun/font/CompositeFont.java ! src/share/classes/sun/font/CompositeGlyphMapper.java ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontDesignMetrics.java ! src/share/classes/sun/font/FontFamily.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/FontManagerNativeLibrary.java ! src/share/classes/sun/font/FontResolver.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/classes/sun/font/PhysicalStrike.java ! src/share/classes/sun/font/StandardGlyphVector.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/TrueTypeGlyphMapper.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/font/Type1GlyphMapper.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/PathGraphics.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/font/sunfontids.h ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/font/NativeFont.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/windows/WFontConfiguration.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: 92607d652d7a Author: rkennke Date: 2009-08-07 19:36 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/92607d652d7a 6869705: Missing files of CR6795908, FontManager refactoring Reviewed-by: prr, igor + src/share/classes/sun/font/FontAccess.java + src/share/classes/sun/font/FontManagerFactory.java + src/share/classes/sun/font/FontManagerForSGE.java + src/share/classes/sun/font/FontUtilities.java + src/share/classes/sun/font/SunFontManager.java + src/solaris/classes/sun/awt/X11FontManager.java + src/solaris/classes/sun/font/FontConfigManager.java + src/windows/classes/sun/awt/Win32FontManager.java Changeset: 11b38980893c Author: rkennke Date: 2009-08-12 17:21 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/11b38980893c 6870238: Font2DTest fails on Debian after FontManager refactoring Summary: Use fontManager field instead of querying the FontManagerFactory Reviewed-by: igor, prr ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: a389af17df10 Author: prr Date: 2009-08-14 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a389af17df10 6867603: sun.font.FontManager.getDefaultPlatformFont throws NPE in OpenJDK on Solaris 10 10/08 Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FontConfigManager.java ! src/solaris/native/sun/awt/fontpath.c Changeset: e90f58148115 Author: jgodinez Date: 2009-09-16 19:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e90f58148115 Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java - src/share/classes/com/sun/crypto/provider/JarVerifier.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Component.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/classes/sun/security/pkcs11/JarVerifier.java ! src/share/classes/sun/swing/SwingUtilities2.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h ! src/solaris/classes/sun/awt/X11/XToolkit.java - src/windows/classes/sun/security/mscapi/JarVerifier.java - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 27d58a02bb9d Author: srl Date: 2009-09-28 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/27d58a02bb9d 6795060: VM crash on Linux in ICU layout library when processing \u0DDD (Sinhalese) Reviewed-by: igor, prr ! src/share/native/sun/font/layout/IndicClassTables.cpp + test/java/awt/font/TextLayout/TestSinhalaChar.java Changeset: e6ced7714609 Author: jgodinez Date: 2009-09-29 09:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e6ced7714609 Merge - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java - src/share/native/sun/security/ec/ec.c Changeset: c74d38ef118c Author: srl Date: 2009-09-29 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c74d38ef118c 6501644: sync LayoutEngine *code* structure to match ICU Reviewed-by: prr ! make/sun/font/Makefile ! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp ! src/share/native/sun/font/layout/AlternateSubstSubtables.h ! src/share/native/sun/font/layout/AnchorTables.cpp ! src/share/native/sun/font/layout/AnchorTables.h ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/ArabicShaping.h ! src/share/native/sun/font/layout/AttachmentPosnSubtables.h ! src/share/native/sun/font/layout/CanonData.cpp ! src/share/native/sun/font/layout/CanonShaping.cpp ! src/share/native/sun/font/layout/CanonShaping.h ! src/share/native/sun/font/layout/CharSubstitutionFilter.h ! src/share/native/sun/font/layout/ClassDefinitionTables.cpp ! src/share/native/sun/font/layout/ClassDefinitionTables.h ! src/share/native/sun/font/layout/ContextualGlyphInsertion.h ! src/share/native/sun/font/layout/ContextualGlyphSubstProc.cpp ! src/share/native/sun/font/layout/ContextualGlyphSubstProc.h ! src/share/native/sun/font/layout/ContextualGlyphSubstitution.h ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CoverageTables.h ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.h ! src/share/native/sun/font/layout/DefaultCharMapper.h ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/DeviceTables.h ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/Features.cpp ! src/share/native/sun/font/layout/Features.h ! src/share/native/sun/font/layout/GDEFMarkFilter.cpp ! src/share/native/sun/font/layout/GDEFMarkFilter.h ! src/share/native/sun/font/layout/GXLayoutEngine.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.h ! src/share/native/sun/font/layout/GlyphDefinitionTables.cpp ! src/share/native/sun/font/layout/GlyphDefinitionTables.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphLookupTables.cpp ! src/share/native/sun/font/layout/GlyphLookupTables.h ! src/share/native/sun/font/layout/GlyphPositionAdjustments.cpp ! src/share/native/sun/font/layout/GlyphPositionAdjustments.h ! src/share/native/sun/font/layout/GlyphPositioningTables.cpp ! src/share/native/sun/font/layout/GlyphPositioningTables.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphPosnLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp ! src/share/native/sun/font/layout/GlyphSubstitutionTables.h ! src/share/native/sun/font/layout/HanLayoutEngine.cpp ! src/share/native/sun/font/layout/HanLayoutEngine.h ! src/share/native/sun/font/layout/IndicClassTables.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.h ! src/share/native/sun/font/layout/IndicRearrangement.h ! src/share/native/sun/font/layout/IndicRearrangementProcessor.cpp ! src/share/native/sun/font/layout/IndicRearrangementProcessor.h ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/KernTable.h ! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.h ! src/share/native/sun/font/layout/KhmerReordering.cpp ! src/share/native/sun/font/layout/KhmerReordering.h ! src/share/native/sun/font/layout/LEFontInstance.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphFilter.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEInsertionList.cpp ! src/share/native/sun/font/layout/LEInsertionList.h ! src/share/native/sun/font/layout/LELanguages.h ! src/share/native/sun/font/layout/LEScripts.h + src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LESwaps.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LayoutTables.h ! src/share/native/sun/font/layout/LigatureSubstProc.cpp ! src/share/native/sun/font/layout/LigatureSubstProc.h ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LigatureSubstSubtables.h ! src/share/native/sun/font/layout/LigatureSubstitution.h ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/LookupProcessor.h ! src/share/native/sun/font/layout/LookupTables.cpp ! src/share/native/sun/font/layout/LookupTables.h ! src/share/native/sun/font/layout/Lookups.cpp ! src/share/native/sun/font/layout/Lookups.h ! src/share/native/sun/font/layout/MPreFixups.cpp ! src/share/native/sun/font/layout/MPreFixups.h ! src/share/native/sun/font/layout/MarkArrays.cpp ! src/share/native/sun/font/layout/MarkArrays.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.h ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.h ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.h ! src/share/native/sun/font/layout/MirroredCharData.cpp ! src/share/native/sun/font/layout/MorphStateTables.h ! src/share/native/sun/font/layout/MorphTables.cpp ! src/share/native/sun/font/layout/MorphTables.h ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.h ! src/share/native/sun/font/layout/NonContextualGlyphSubst.h ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.cpp ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.h ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/OpenTypeTables.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp ! src/share/native/sun/font/layout/OpenTypeUtilities.h ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.h ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguage.h ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp ! src/share/native/sun/font/layout/SegmentArrayProcessor.h ! src/share/native/sun/font/layout/SegmentSingleProcessor.cpp ! src/share/native/sun/font/layout/SegmentSingleProcessor.h ! src/share/native/sun/font/layout/ShapingTypeData.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.h ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.h ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.h ! src/share/native/sun/font/layout/SingleTableProcessor.cpp ! src/share/native/sun/font/layout/SingleTableProcessor.h ! src/share/native/sun/font/layout/StateTableProcessor.cpp ! src/share/native/sun/font/layout/StateTableProcessor.h ! src/share/native/sun/font/layout/StateTables.h ! src/share/native/sun/font/layout/SubstitutionLookups.cpp ! src/share/native/sun/font/layout/SubstitutionLookups.h ! src/share/native/sun/font/layout/SubtableProcessor.cpp ! src/share/native/sun/font/layout/SubtableProcessor.h ! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp ! src/share/native/sun/font/layout/ThaiLayoutEngine.h ! src/share/native/sun/font/layout/ThaiShaping.cpp ! src/share/native/sun/font/layout/ThaiShaping.h ! src/share/native/sun/font/layout/ThaiStateTables.cpp ! src/share/native/sun/font/layout/TrimmedArrayProcessor.cpp ! src/share/native/sun/font/layout/TrimmedArrayProcessor.h ! src/share/native/sun/font/layout/ValueRecords.cpp ! src/share/native/sun/font/layout/ValueRecords.h Changeset: e8a764450aa7 Author: srl Date: 2009-09-29 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e8a764450aa7 Merge - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java - src/share/native/sun/security/ec/ec.c Changeset: e8b1b4c00e8a Author: srl Date: 2009-09-29 16:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e8b1b4c00e8a 6886718: missing license info Reviewed-by: igor, prr ! test/java/awt/font/TextLayout/TestSinhalaChar.java Changeset: ec67b240b727 Author: mchung Date: 2009-09-29 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ec67b240b727 6879044: Eliminate the dependency on logging from the AWT/2D/Swing classes Summary: Replace calls to Logger with sun.util.logging.PlatformLogger Reviewed-by: prr, art, alexp, dcherepanov, igor, dav, anthony ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AttributeValue.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/ComponentAccessor.java ! src/share/classes/sun/awt/DebugSettings.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/ScrollPaneWheelScroller.java ! src/share/classes/sun/awt/SunDisplayChanger.java ! src/share/classes/sun/awt/SunGraphicsCallback.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/WindowAccessor.java ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11/InfoWindow.java ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/UnsafeXDisposerRecord.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XCheckboxMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XContentWindow.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFocusProxyWindow.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java ! src/solaris/classes/sun/awt/X11/XInputMethod.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XMSelection.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XMenuPeer.java ! src/solaris/classes/sun/awt/X11/XMenuWindow.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XQueryTree.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java ! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XWINProtocol.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XWrapperBase.java ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/classes/sun/awt/X11FontManager.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11InputMethod.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/font/FontConfigManager.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/classes/sun/awt/windows/WPanelPeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 5b52851b0927 Author: mchung Date: 2009-09-29 22:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5b52851b0927 Merge Changeset: 633806cdab51 Author: jgodinez Date: 2009-10-05 18:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/633806cdab51 Merge Changeset: c715b68cdcaf Author: darcy Date: 2009-09-22 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c715b68cdcaf 6468534: (reflect) Exception types cannot be parameterized, rephrase getGenericExceptionTypes. Reviewed-by: alanb ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java Changeset: bbb543254c63 Author: martin Date: 2009-09-22 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bbb543254c63 4245470: algorithm of java.lang.Byte.hashCode() is not specified Summary: Specify some hashCode methods are equivalent to intValue Reviewed-by: darcy ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Short.java + test/java/lang/HashCode.java Changeset: eb92c939b8a7 Author: martin Date: 2009-09-22 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eb92c939b8a7 6582946: Add suite of compare(T, T) methods for ints, longs etc Reviewed-by: darcy Contributed-by: kevinb at google.com ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java + test/java/lang/Compare.java Changeset: bd928aefe692 Author: weijun Date: 2009-09-24 21:35 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bd928aefe692 6885166: regression test for 6877357 (IPv6 address does not work) error (timed out) Reviewed-by: xuelei ! test/sun/security/krb5/IPv6.java Changeset: 5b1aaf2d7504 Author: ptisnovs Date: 2009-09-30 11:49 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5b1aaf2d7504 6884837: JTReg test SetOutgoingIf is not correct Summary: Added check of network interfaces status Reviewed-by: alanb, chegar ! test/java/net/MulticastSocket/SetOutgoingIf.java Changeset: dd724911c90a Author: michaelm Date: 2009-09-29 10:00 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dd724911c90a 6886108: Test case B4933582 binding to fixed port number Reviewed-by: chegar ! test/java/net/Authenticator/B4933582.java ! test/sun/net/www/httptest/HttpTransaction.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java Changeset: 896cbd9c91f4 Author: michaelm Date: 2009-10-01 11:25 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/896cbd9c91f4 Merge Changeset: 527ad9cbc9cf Author: weijun Date: 2009-10-02 18:44 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/527ad9cbc9cf 6324292: keytool -help is unhelpful Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/keytool/newhelp.sh Changeset: 56bad48e2810 Author: weijun Date: 2009-10-02 18:47 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/56bad48e2810 6862679: ESC: AD Authentication with user with umlauts fails Reviewed-by: valeriep, mullan ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/ETypeInfo.java ! src/share/classes/sun/security/krb5/internal/ETypeInfo2.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/crypto/Des.java + src/share/classes/sun/security/krb5/internal/util/KerberosString.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java + test/sun/security/krb5/RFC396xTest.java Changeset: a2d24418be6c Author: weijun Date: 2009-10-02 18:49 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a2d24418be6c 6874472: display address lists for tickets in klist tool Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java Changeset: a6046f6e720e Author: weijun Date: 2009-10-02 18:49 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a6046f6e720e 6868579: RFE: jarsigner to support reading password from environment variable Reviewed-by: xuelei, wetmore ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/jarsigner/passtype.sh Changeset: f0fdc4dd97d5 Author: michaelm Date: 2009-10-02 13:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f0fdc4dd97d5 6870935: DIGEST proxy authentication fails to connect to URLs with no trailing slash Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/NTLMAuthentication.java + test/java/net/Authenticator/B6870935.java Changeset: e782a9564eae Author: michaelm Date: 2009-10-02 13:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e782a9564eae Merge Changeset: 9fcca0aae3da Author: tbell Date: 2009-10-02 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9fcca0aae3da 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails Reviewed-by: dcubed ! test/com/sun/jdi/ShellScaffold.sh Changeset: 97f17e6d0560 Author: alanb Date: 2009-10-04 15:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/97f17e6d0560 6884800: (file) Path.newInputStream does not usefully implement available() Reviewed-by: martin, chegar ! src/share/classes/sun/nio/ch/ChannelInputStream.java ! test/java/nio/channels/Channels/Basic.java Changeset: a4f31836660a Author: alanb Date: 2009-10-05 16:45 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a4f31836660a 6854954: Eliminate static dependency on java.awt.AWTPermission Reviewed-by: mullan, mchung, anthony ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/MouseInfo.java ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/javax/swing/JPopupMenu.java + src/share/classes/sun/awt/AWTPermissionFactory.java ! src/share/classes/sun/security/provider/PolicyFile.java + src/share/classes/sun/security/util/PermissionFactory.java ! src/share/classes/sun/security/util/SecurityConstants.java Changeset: 54118c8e0ebe Author: vinnie Date: 2009-10-05 23:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/54118c8e0ebe 6885204: JSSE should not require Kerberos to be present Reviewed-by: wetmore, alanb ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/JsseJce.java Changeset: c499401bc138 Author: mchung Date: 2009-10-05 18:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c499401bc138 6612680: Remove classloader dependency on jkernel Summary: Add a new sun.misc.BootClassLoaderHook that DownloadManager will implement Reviewed-by: alanb, forax, igor ! make/sun/jkernel/Makefile ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/sun/jkernel/DownloadManager.java + src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/VM.java ! src/share/native/sun/misc/VM.c Changeset: 572791538be5 Author: darcy Date: 2009-10-06 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/572791538be5 5062288: (reflect) Core reflection uses raw types when it could be using wildcards Reviewed-by: alanb ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/sun/reflect/LangReflectAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/annotation/AnnotationType.java Changeset: 1b81fc851b20 Author: mchung Date: 2009-10-06 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1b81fc851b20 6888802: sun.misc.BootClassLoaderHook.getBootstrapPaths stack overflow Summary: Fixed sun.misc.BootClassLoaderHook.getBootstrapPaths calls hook.getAdditionalBootstrapPaths Reviewed-by: alanb, tbell ! src/share/classes/sun/misc/BootClassLoaderHook.java + test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: f69b40e43bff Author: kamg Date: 2009-10-06 22:01 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f69b40e43bff 6885916: Memory leak in inferencing verifier (libverify.so) Summary: Use the memory management already present to track allocated memory Reviewed-by: coleenp, acorn ! src/share/native/common/check_code.c Changeset: f864c15f6779 Author: chegar Date: 2009-10-07 17:23 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f864c15f6779 6887364: SetOutgoingIf.java fails if run on multihomed machine without PIv6 on all interfaces Reviewed-by: alanb ! test/java/net/MulticastSocket/SetOutgoingIf.java Changeset: 777714bd992a Author: tbell Date: 2009-10-07 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/777714bd992a 6888888: new javah throws NullPointerException when building in jdk/make/java/nio Summary: Use the bootstrap javah during the build until bug-ID 6889255 is fixed Reviewed-by: jjg ! make/common/shared/Defs-java.gmk Changeset: e7ad502130ba Author: darcy Date: 2009-10-07 14:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e7ad502130ba 6480728: Byte.valueOf(byte) returns a cached value but Byte.valueOf(String) 6655735: Integer.toString() and String.valueOf(int) contain slow delegations Reviewed-by: lancea ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java Changeset: 405fd587f13f Author: tbell Date: 2009-10-07 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/405fd587f13f Merge ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java Changeset: 317ac0bf2285 Author: anthony Date: 2009-09-15 16:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/317ac0bf2285 6868255: Requirements for correct operating of the HW/LW Mixing feature need to be specified Summary: The specification is updated Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java Changeset: 986ec552383f Author: yan Date: 2009-09-22 01:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/986ec552383f Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: b6980b0d8440 Author: dcherepanov Date: 2009-09-30 13:21 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b6980b0d8440 6853592: VM test nsk.regression.b4261880 fails with "X Error of failed request: BadWindow" inconsistently. Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: a21d00087df9 Author: dcherepanov Date: 2009-09-30 15:48 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a21d00087df9 6878284: Sometimes test/javax/swing/system/6799345/TestShutdown.java "hangs" Reviewed-by: art, ant ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/AWTAutoShutdown.java Changeset: cf3f9c09ba1d Author: anthony Date: 2009-10-01 14:48 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cf3f9c09ba1d 6886868: giflib has a memory leak in the MakeMapObject() function Summary: free() the object before returning NULL Reviewed-by: art, dcherepanov ! src/share/native/sun/awt/giflib/gifalloc.c Changeset: 80db944866a9 Author: anthony Date: 2009-10-01 15:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/80db944866a9 6862611: Reg testcase closed/java/awt/Component/NativeInLightShow/NativeInLightShow.html fails Summary: The recursiveShowHeavyweightChildren() must be invoked unconditionally in mixOnShowing() Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Container.java Changeset: 4358934555bc Author: yan Date: 2009-10-06 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4358934555bc Merge ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 6216604c05e2 Author: alexp Date: 2009-09-09 17:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6216604c05e2 6878792: Sample provided in javax.swing.JLayer class description is not usable Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java Changeset: afd85f72784b Author: peterz Date: 2009-09-10 12:30 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/afd85f72784b 6827786: Mnemonic cycling for multiple equal mnemonic armed menu items stops when encountering a submenu Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java Changeset: 51ccbb892a1f Author: alexp Date: 2009-09-15 16:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/51ccbb892a1f 6875716: JLayer.remove((Component)null) should behave consistently in (not) throwing NPE Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6875716/bug6875716.java Changeset: a64dbe61a984 Author: gsm Date: 2009-09-16 16:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a64dbe61a984 4337267: Arabic Numeral Shaping Reviewed-by: peterz ! src/share/classes/javax/swing/text/TextLayoutStrategy.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JComponent/4337267/bug4337267.java Changeset: 481c01572c62 Author: alexp Date: 2009-09-17 19:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/481c01572c62 4833524: BasicTreeUI.isToggleSelectionEvent() does not properly handle popup triggers Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/text/DefaultCaret.java Changeset: 1c7abc800502 Author: rupashka Date: 2009-09-18 15:11 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1c7abc800502 6840086: JFileChooser lacks icons on top right when running on Windows 7 Reviewed-by: peterz, uta ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/native/sun/windows/ShellFolder2.cpp + test/javax/swing/JFileChooser/6840086/bug6840086.java Changeset: fa71ca7a3655 Author: yan Date: 2009-09-21 01:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fa71ca7a3655 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 9d78c3d9def2 Author: alexp Date: 2009-09-21 17:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9d78c3d9def2 6883341: SWAT: jdk7-b72 swat build(2009-09-17) threw exceptions when running Java2D demo by clicking Paint ta Reviewed-by: peterz ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JMenuItem/6883341/bug6883341.java Changeset: 6115613a3386 Author: peterz Date: 2009-09-23 21:14 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6115613a3386 6857888: closed/javax/swing/JMenuItem/6458123/bug6458123.java fails with InvocationTargetException. Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/nimbus/skin.laf ! src/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java Changeset: d5045dd60c29 Author: rupashka Date: 2009-10-06 17:01 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d5045dd60c29 6489130: FileChooserDemo hung by keeping pressing Enter key Reviewed-by: alexp ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/6489130/bug6489130.java Changeset: dca0ab1a1ac3 Author: yan Date: 2009-10-06 23:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dca0ab1a1ac3 Merge ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 77f213891ce3 Author: lana Date: 2009-10-13 15:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/77f213891ce3 Merge Changeset: eacb36e30327 Author: vinnie Date: 2009-10-14 23:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eacb36e30327 6891632: Remove duplicate ECC source files Reviewed-by: wetmore - src/share/native/sun/security/ec/ec.h - src/share/native/sun/security/ec/ec2.h - src/share/native/sun/security/ec/ec2_163.c - src/share/native/sun/security/ec/ec2_193.c - src/share/native/sun/security/ec/ec2_233.c - src/share/native/sun/security/ec/ec2_aff.c - src/share/native/sun/security/ec/ec2_mont.c - src/share/native/sun/security/ec/ec_naf.c - src/share/native/sun/security/ec/ecc_impl.h - src/share/native/sun/security/ec/ecdecode.c - src/share/native/sun/security/ec/ecl-curve.h - src/share/native/sun/security/ec/ecl-exp.h - src/share/native/sun/security/ec/ecl-priv.h - src/share/native/sun/security/ec/ecl.c - src/share/native/sun/security/ec/ecl.h - src/share/native/sun/security/ec/ecl_curve.c - src/share/native/sun/security/ec/ecl_gf.c - src/share/native/sun/security/ec/ecl_mult.c - src/share/native/sun/security/ec/ecp.h - src/share/native/sun/security/ec/ecp_192.c - src/share/native/sun/security/ec/ecp_224.c - src/share/native/sun/security/ec/ecp_256.c - src/share/native/sun/security/ec/ecp_384.c - src/share/native/sun/security/ec/ecp_521.c - src/share/native/sun/security/ec/ecp_aff.c - src/share/native/sun/security/ec/ecp_jac.c - src/share/native/sun/security/ec/ecp_jm.c - src/share/native/sun/security/ec/ecp_mont.c - src/share/native/sun/security/ec/logtab.h - src/share/native/sun/security/ec/mp_gf2m-priv.h - src/share/native/sun/security/ec/mp_gf2m.c - src/share/native/sun/security/ec/mp_gf2m.h - src/share/native/sun/security/ec/mpi-config.h - src/share/native/sun/security/ec/mpi-priv.h - src/share/native/sun/security/ec/mpi.c - src/share/native/sun/security/ec/mpi.h - src/share/native/sun/security/ec/mplogic.c - src/share/native/sun/security/ec/mplogic.h - src/share/native/sun/security/ec/mpmontg.c - src/share/native/sun/security/ec/mpprime.h - src/share/native/sun/security/ec/oid.c - src/share/native/sun/security/ec/secitem.c - src/share/native/sun/security/ec/secoidt.h Changeset: 99dfeece98e2 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/99dfeece98e2 Added tag jdk7-b74 for changeset eacb36e30327 ! .hgtags From john.coomes at sun.com Fri Oct 16 03:02:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 10:02:21 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 18 new changesets Message-ID: <20091016100256.348F04189F@hg.openjdk.java.net> Changeset: 14735c7932d7 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/14735c7932d7 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java ! test/com/sun/javadoc/testCRLineSeparator/pkg/MyClass.java ! test/com/sun/javadoc/testNoPackagesFile/TestNoPackagesFile.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/tools/apt/Basics/apt.sh ! test/tools/apt/Basics/print.sh ! test/tools/apt/Compile/compile.sh ! test/tools/javac/4846262/Test.sh ! test/tools/javac/6302184/T6302184.sh ! test/tools/javac/6627362/T6627362.java ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/MissingInclude.sh ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/T5090006/compiler.sh ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/Sibling.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javac/constDebug/ConstDebug.sh ! test/tools/javac/fatalErrors/NoJavaLang.sh ! test/tools/javac/generics/inference/6302954/T6476073.java ! test/tools/javac/innerClassFile/Driver.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/meth/MakeNegTests.sh ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/quid/MakeNegTests.sh ! test/tools/javac/quid/QuotedIdent.java ! test/tools/javac/quid/QuotedIdent2.java ! test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/unicode/SupplementaryJavaID6.sh ! test/tools/javah/6257087/foo.sh ! test/tools/javah/ConstMacroTest.sh ! test/tools/javah/MissingParamClassTest.sh ! test/tools/javah/ReadOldClass.sh ! test/tools/javap/T4975569.java ! test/tools/javap/pathsep.sh ! test/tools/javap/stackmap/T6271292.sh Changeset: ebb6ad5a95bb Author: jjg Date: 2009-09-08 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ebb6ad5a95bb 5093723: REGRESSION: ClassCastException in SingleIndexWriter Reviewed-by: jjg Contributed-by: ahe at google.com ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties + test/com/sun/javadoc/5093723/DocumentedClass.java + test/com/sun/javadoc/5093723/T5093723.java + test/com/sun/javadoc/5093723/UndocumentedClass.java Changeset: 071a4e36cd87 Author: jjg Date: 2009-09-08 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/071a4e36cd87 6709246: ClassCastException in javadoc Reviewed-by: jjg Contributed-by: ahe at google.com ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java + test/tools/javadoc/annotations/missing/Main.java + test/tools/javadoc/annotations/missing/somepackage/MissingAnnotationClass.java Changeset: f8be8bf150c3 Author: jjg Date: 2009-09-14 17:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f8be8bf150c3 6881317: regression: NPE in CloseableURLClassLoader Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/CloseableURLClassLoader.java Changeset: 9dd34ed62341 Author: jjg Date: 2009-09-15 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/9dd34ed62341 6882235: invalid exponent causes silent javac crash Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/T6882235.java + test/tools/javac/T6882235.out Changeset: 69eaccd3ea85 Author: jjg Date: 2009-09-15 18:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/69eaccd3ea85 6860965: Project Coin: binary literals 6860973: Project Coin: Underscores in literals Summary: [Portions contributed by Bruce Chapman] Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/enum/6384542/T6384542.out + test/tools/javac/literals/BadBinaryLiterals.6.out + test/tools/javac/literals/BadBinaryLiterals.7.out + test/tools/javac/literals/BadBinaryLiterals.java + test/tools/javac/literals/BadUnderscoreLiterals.6.out + test/tools/javac/literals/BadUnderscoreLiterals.7.out + test/tools/javac/literals/BadUnderscoreLiterals.java + test/tools/javac/literals/BinaryLiterals.java + test/tools/javac/literals/UnderscoreLiterals.java Changeset: 5dd400fd62d9 Author: tbell Date: 2009-09-18 08:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/5dd400fd62d9 Merge Changeset: 789ee1acf107 Author: darcy Date: 2009-09-21 21:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/789ee1acf107 6884227: Clarify ordering requirements of javax.lang.model.TypeElement.getEnclosedElements Reviewed-by: ahe ! src/share/classes/javax/lang/model/element/TypeElement.java Changeset: 9596dff46093 Author: tbell Date: 2009-09-25 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/9596dff46093 Merge Changeset: d498d6ef9c6c Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d498d6ef9c6c Added tag jdk7-b73 for changeset 9596dff46093 ! .hgtags Changeset: e992e602788e Author: darcy Date: 2009-09-23 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e992e602788e 6517779: javax.lang.model.util.Elements.getConstantExpression() doesn't throw any exception 6517907: javax.lang.model.util.Elements.getConstantExpression() with negative byte value fails Summary: Fix various problems with Elements.getConstantExpression() Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/Constants.java ! src/share/classes/com/sun/tools/javac/util/Convert.java + test/tools/javac/processing/model/util/elements/Foo.java + test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java Changeset: 49359d0e6a9c Author: jjg Date: 2009-09-23 18:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/49359d0e6a9c 6410637: Make decision on deprecated methods in DefaultFileManager and BaseFileObject. 6747645: ZipFileObject.getName is incorrectly deprecated 6885123: JavaFileObject getName issues Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java - src/share/classes/com/sun/tools/javac/file/Old199.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/javax/tools/SimpleJavaFileObject.java + test/tools/javac/4241573/T4241573.java ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T6705935.java ! test/tools/javac/api/6411310/T6411310.java + test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/6733837/T6733837.java Changeset: c287d51c57da Author: jjg Date: 2009-09-23 19:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c287d51c57da 6572945: javah should be written as an annotation processor, not a doclet Reviewed-by: darcy ! make/build.xml ! src/share/classes/com/sun/tools/javah/Gen.java + src/share/classes/com/sun/tools/javah/InternalError.java ! src/share/classes/com/sun/tools/javah/JNI.java + src/share/classes/com/sun/tools/javah/JavahFileManager.java + src/share/classes/com/sun/tools/javah/JavahTask.java + src/share/classes/com/sun/tools/javah/JavahTool.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Main.java - src/share/classes/com/sun/tools/javah/MainDoclet.java ! src/share/classes/com/sun/tools/javah/Mangle.java + src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javah/Util.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties ! src/share/classes/com/sun/tools/javah/resources/l10n.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java + test/tools/javah/6572945/T6572945.java + test/tools/javah/6572945/TestClass1.java + test/tools/javah/6572945/TestClass2.java + test/tools/javah/6572945/TestClass3.java + test/tools/javah/6572945/gold/jni.dir.1/TestClass1.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner1.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner2.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass2.h + test/tools/javah/6572945/gold/jni.file.1 + test/tools/javah/6572945/gold/jni.file.2 + test/tools/javah/6572945/gold/jni.file.3 ! test/tools/javah/MissingParamClassTest.sh + test/tools/javah/compareTest/CompareTest.java + test/tools/javah/compareTest/CompareTest.sh + test/tools/javah/compareTest/FindNativeFiles.java + test/tools/javah/compareTest/README Changeset: d0f541480556 Author: darcy Date: 2009-09-24 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d0f541480556 6337964: should ignore last comma in annotation array Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/annotations/pos/TrailingComma.java Changeset: 4776a869fdfa Author: tbell Date: 2009-09-25 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4776a869fdfa Merge ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java - src/share/classes/com/sun/tools/javac/file/Old199.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java - src/share/classes/com/sun/tools/javah/MainDoclet.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties ! test/tools/javah/MissingParamClassTest.sh Changeset: c6d0c55b1aba Author: jjg Date: 2009-09-28 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c6d0c55b1aba 6886348: apt incorrectly uses Scope.table Reviewed-by: darcy ! src/share/classes/com/sun/tools/apt/comp/Apt.java Changeset: 1a66b08deed0 Author: tbell Date: 2009-10-07 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/1a66b08deed0 Merge - src/share/classes/com/sun/tools/javac/file/Old199.java - src/share/classes/com/sun/tools/javah/MainDoclet.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties Changeset: 79c13af9217e Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/79c13af9217e Added tag jdk7-b74 for changeset 1a66b08deed0 ! .hgtags From Vladimir.Kozlov at Sun.COM Fri Oct 16 11:17:21 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 16 Oct 2009 11:17:21 -0700 Subject: Request for reviews (XS): 6892265: System.arraycopy unable to reference elements beyond Integer.MAX_VALUE bytes Message-ID: <4AD8B8B1.4060600@sun.com> http://cr.openjdk.java.net/~kvn/6892265/webrev.00 Fixed 6892265: System.arraycopy unable to reference elements beyond Integer.MAX_VALUE bytes Problem: Runtime method typeArrayKlass::copy_array() uses int type for pointers calculation. Solution: Use size_t type in typeArrayKlass::copy_array(). I verified that compiled by C2 code which uses arraycopy stubs works fine. I did not add a regression test since it needs 4Gb java heap and not all our test machines have such memory. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT From changpeng.fang at sun.com Fri Oct 16 20:12:03 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Sat, 17 Oct 2009 03:12:03 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 16 new changesets Message-ID: <20091017031236.8688D419CB@hg.openjdk.java.net> Changeset: a0107ba3bc53 Author: johnc Date: 2009-10-01 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a0107ba3bc53 6887186: G1: Incorrect code generated for G1 pre-barrier by C1 on SPARC Summary: Modify operand passed to C1 pre-barrier to be the operand representing the address of the object field that is being stored. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp Changeset: 708275a44e4a Author: tonyp Date: 2009-10-03 10:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/708275a44e4a Merge ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp Changeset: 6e6427f797c0 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6e6427f797c0 Added tag jdk7-b71 for changeset 50a95aa4a247 ! .hgtags Changeset: a94714c55065 Author: trims Date: 2009-09-15 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a94714c55065 Merge Changeset: 1e5f0e56d242 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1e5f0e56d242 Added tag jdk7-b72 for changeset a94714c55065 ! .hgtags Changeset: 89e0543e1737 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/89e0543e1737 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! agent/make/saenv.sh ! agent/make/saenv64.sh ! agent/src/os/solaris/proc/Makefile ! agent/src/os/solaris/proc/mapfile ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeChunk.java ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 7a102acc9f17 Author: trims Date: 2009-09-25 12:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7a102acc9f17 Merge ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/prims/jvm.h Changeset: faf94d94786b Author: trims Date: 2009-09-25 12:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/faf94d94786b 6885900: Bump the HS17 build number to 02 Summary: Update the HS17 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6ddec5389232 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6ddec5389232 Added tag jdk7-b73 for changeset faf94d94786b ! .hgtags Changeset: a1423fe86a18 Author: trims Date: 2009-10-09 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a1423fe86a18 Merge ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: f4b900403d6e Author: trims Date: 2009-10-09 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f4b900403d6e 6890293: Bump the HS17 build number to 03 Summary: Update the HS17 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 528d98fe1037 Author: xlu Date: 2009-09-24 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/528d98fe1037 6880029: JDK 1.6.0_u14p Application crashed very early Reviewed-by: never, ysr, acorn ! src/share/vm/runtime/safepoint.cpp Changeset: 054afbef9081 Author: acorn Date: 2009-09-28 12:27 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/054afbef9081 Merge Changeset: a2ad635573fb Author: xlu Date: 2009-10-14 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a2ad635573fb Merge Changeset: e715b51789d8 Author: cfang Date: 2009-10-16 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e715b51789d8 Merge ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/phaseX.cpp Changeset: 71fdc5052e49 Author: cfang Date: 2009-10-16 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/71fdc5052e49 Merge From rasbold at google.com Mon Oct 19 11:15:14 2009 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 19 Oct 2009 11:15:14 -0700 Subject: Question about MemNode In-Reply-To: References: Message-ID: <4149a0430910191115v7c8e2618n70493716e56cbc59@mail.gmail.com> Moving this question to hotspot-compiler-dev.... 2009/10/17 Ram?n Garc?a > > I am trying to understand the code in memnode.hpp > > What is the meaning of the nodes Control, Memory and Address that a MemNode > has? > > I understand more or less that a MemNode defines a memory reference, > Memory defines the base and Address defines the offset. But the > meaning of Control is still unclear to me (a comment describes it as > "// When is it safe to do this load?"). > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20091019/d89133d7/attachment.html From rasbold at google.com Mon Oct 19 11:17:41 2009 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 19 Oct 2009 11:17:41 -0700 Subject: Question about MemNode In-Reply-To: <4149a0430910191115v7c8e2618n70493716e56cbc59@mail.gmail.com> References: <4149a0430910191115v7c8e2618n70493716e56cbc59@mail.gmail.com> Message-ID: <4149a0430910191117g1c221c35g8d58afdb31d68174@mail.gmail.com> In C2, every node has a control edge field, specified by input zero or in(0). The control edge is used to specify control dependencies, that is, a dependency on a node where a data dependency can not adequately represent all of the input constraints on a node. A control edge will restrict the placement of a node when the sea of nodes is reduced a more conventional CFG. Typical examples of possible control inputs are SafePointNodes (CallNodes are a subclass of these), CProjNodes (IfTrue, IfFalse and CatchProj) and RegionNodes. For pure dataflow nodes, such as an AddNode, the control edge is always null since data constraints properly fix the operation in the sea of nodes. As a special case, RegionNodes always point to themselves on the control edge. -- Chuck 2009/10/19 Chuck Rasbold > Moving this question to hotspot-compiler-dev.... > > 2009/10/17 Ram?n Garc?a > > > > I am trying to understand the code in memnode.hpp >> >> What is the meaning of the nodes Control, Memory and Address that a >> MemNode has? >> >> I understand more or less that a MemNode defines a memory reference, >> Memory defines the base and Address defines the offset. But the >> meaning of Control is still unclear to me (a comment describes it as >> "// When is it safe to do this load?"). >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20091019/15552fe9/attachment.html From Vladimir.Kozlov at Sun.COM Mon Oct 19 12:30:35 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 19 Oct 2009 12:30:35 -0700 Subject: Request for reviews (M): 6892186: SA does not dump debug info for scalar replaced objects Message-ID: <4ADCBE5B.9020107@sun.com> http://cr.openjdk.java.net/~kvn/6892186/webrev.00 Fixed 6892186: SA does not dump debug info for scalar replaced objects Problem: Part of these changes are from Tom's SA disassembler work. Dumping nmethods with scalar replaced objects results in exceptions from the SA since it was not implemented. Solution: Implement scalar replaced objects debug info dump in SA. Fix PrintOptoAssembly output for such info since it was not correct. Add missing NULL checks in SA dump code. Reformat SA debug info output to easy read. Add "dumpcodecache" instruction to SA to dump all nmethods in codecache. Reviewed by: Fix verified (y/n): y, test output Other testing: JPRT Here is OptoAssembly output: 177 CALL,static java.lang.Object::wait # sleep::test @ bci:126 L[0]=#ScObj0 L[1]=#ScObj1 L[2]=#ScObj2 L[3]=#ScObj3 L[4]=#ScObj4 L[5]=#Ptr0x080cffd8 L[6]=_ MON-BOX0=esp+32 MON-OBJ[0]=#Ptr0x080cffd8 # ScObj0 sleep={ [iii :0]=#12 } # ScObj1 int[2]={ [0]=#0 , [1]=#34 } # ScObj2 sleep[2]={ [0]=#ScObj0 , [1]=esp + #12 } # ScObj3 int[2][]={ [0]=esp + #16 , [1]=#ScObj1 } # ScObj4 sleep[2][]={ [0]=esp + #8 , [1]=#ScObj2 } # OopMap{[8]=Oop [12]=Oop [16]=Oop [20]=Derived_oop_[8] off=380} here is SA: 0xfa4d24b7: call 0xfa4d0dd0 static int test() @0xb61b3228 of public class sleep @0xb61b3278 @ bci = 126, line = 31 locals ([0], #ScObj0) ([1], #ScObj1) ([2], #ScObj2) ([3], #ScObj3) ([4], #ScObj4) ([5], oop 0xb61b33c8) ([6], illegal) monitors (owner = oop 0xb61b33c8, lock = stack[32], normal) ScObj0 sleep={ [iii :0]=(#int 12) } ScObj1 int[2]={ [0]=(#int 0) [1]=(#int 34) } ScObj2 sleep[2]={ [0]=(##ScObj0) [1]=(#stack[12], oop) } ScObj3 int[2][]={ [0]=(#stack[16], oop) [1]=(##ScObj1) } ScObj4 sleep[2][]={ [0]=(#stack[8], oop) [1]=(##ScObj2) } OopMap: Oops:[8] [12] [16] Derived oops:[20] = [8] and here the java source: sleep sl = new sleep(); sl.iii = 12; int[] ia = new int[2]; ia[1] = 34; sleep[] sa = new sleep[2]; sa[0] = sl; sa[1] = new sleep(); sa[1].iii = 56; int[][] ia2 = new int[2][]; ia2[0] = new int[1]; ia2[1] = ia; ia2[0][0] = 78; sleep[][] sa2 = new sleep[2][]; sa2[0] = new sleep[1]; sa2[1] = sa; sa2[0][0] = new sleep(); sa2[0][0].iii = 90; synchronized (sleep.class) { sleep.class.wait(1); } From Christian.Thalinger at Sun.COM Tue Oct 20 01:17:36 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 20 Oct 2009 10:17:36 +0200 Subject: Request for reviews (M): 6892186: SA does not dump debug info for scalar replaced objects In-Reply-To: <4ADCBE5B.9020107@sun.com> References: <4ADCBE5B.9020107@sun.com> Message-ID: <1256026656.820.93.camel@macbook> On Mon, 2009-10-19 at 12:30 -0700, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6892186/webrev.00 > > Fixed 6892186: SA does not dump debug info for scalar replaced objects > > Problem: > Part of these changes are from Tom's SA disassembler work. > Dumping nmethods with scalar replaced objects results in > exceptions from the SA since it was not implemented. > > Solution: > Implement scalar replaced objects debug info dump in SA. > Fix PrintOptoAssembly output for such info since it was not correct. > Add missing NULL checks in SA dump code. > Reformat SA debug info output to easy read. > Add "dumpcodecache" instruction to SA to dump all nmethods in codecache. Looks good. -- Christian From Christian.Thalinger at Sun.COM Tue Oct 20 13:04:52 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 20 Oct 2009 22:04:52 +0200 Subject: Request for reviews (M): 6829192: JSR 292 needs to support 64-bit x86 Message-ID: <1256069092.820.117.camel@macbook> Let's start the review round with a patch that does not fit logically into the order but is small: http://cr.openjdk.java.net/~twisti/6829192/webrev.01/ -- Christian From Christian.Thalinger at Sun.COM Tue Oct 20 13:10:37 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 20 Oct 2009 22:10:37 +0200 Subject: Request for reviews (L): 6893081: method handle & invokedynamic code needs additional cleanup (post 6815692, 6858164) Message-ID: <1256069437.820.123.camel@macbook> This patch is one of the first ones: http://cr.openjdk.java.net/~twisti/6893081/webrev.01/ It depends on a mlvm patch called meth.walker.patch, which may be sent out tomorrow (or the day after). -- Christian From john.rose at sun.com Tue Oct 20 17:34:21 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Wed, 21 Oct 2009 00:34:21 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6815692: method handle code needs some cleanup (post-6655638) Message-ID: <20091021003427.6C20D41FA9@hg.openjdk.java.net> Changeset: 987e948ebbc8 Author: jrose Date: 2009-10-17 19:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/987e948ebbc8 6815692: method handle code needs some cleanup (post-6655638) Summary: correctly raise exceptions, support safe bitwise "raw" conversions, fix bugs revealed by VerifyMethodHandles, remove dead code, improve debugging support Reviewed-by: never, twisti ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp From Vladimir.Kozlov at Sun.COM Tue Oct 20 17:32:24 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 20 Oct 2009 17:32:24 -0700 Subject: Request for reviews (M): 6829192: JSR 292 needs to support 64-bit x86 In-Reply-To: <1256069092.820.117.camel@macbook> References: <1256069092.820.117.camel@macbook> Message-ID: <4ADE5698.3080803@sun.com> src/cpu/x86/vm/interp_masm_x86_64.cpp: In InterpreterMacroAssembler::get_cache_index_at_bcp() the assert is not clear. Add comment and explain what you are testing to how next instruction should be changed. src/cpu/x86/vm/templateInterpreter_x86_64.cpp: In TemplateInterpreterGenerator::generate_WrongMethodType_handler() what rbx and rax contain and why you need to verify oop? I don't like outline code in generate_return_entry_for(). Why do you need to move it down? src/share/vm/classfile/classFileParser.cpp: Don't leave commented code. Remove it if you don't need it. Vladimir Christian Thalinger wrote: > Let's start the review round with a patch that does not fit logically > into the order but is small: > > http://cr.openjdk.java.net/~twisti/6829192/webrev.01/ > > -- Christian > From Christian.Thalinger at Sun.COM Wed Oct 21 08:15:15 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 21 Oct 2009 17:15:15 +0200 Subject: Request for reviews (M): 6829192: JSR 292 needs to support 64-bit x86 In-Reply-To: <4ADE5698.3080803@sun.com> References: <1256069092.820.117.camel@macbook> <4ADE5698.3080803@sun.com> Message-ID: <1256138115.21356.21.camel@macbook> On Tue, 2009-10-20 at 17:32 -0700, Vladimir Kozlov wrote: > src/cpu/x86/vm/interp_masm_x86_64.cpp: > In InterpreterMacroAssembler::get_cache_index_at_bcp() the assert > is not clear. Add comment and explain what you are testing to how > next instruction should be changed. Added. > > src/cpu/x86/vm/templateInterpreter_x86_64.cpp: > In TemplateInterpreterGenerator::generate_WrongMethodType_handler() > what rbx and rax contain and why you need to verify oop? I can only tell what the registers contain, John should know why it needs to be verified. > > I don't like outline code in generate_return_entry_for(). > Why do you need to move it down? I guess John wrote it that way because it's not the default case. John? > > src/share/vm/classfile/classFileParser.cpp: > Don't leave commented code. Remove it if you don't need it. Yeah, that commented code was just a hack to get it working, the real fix is to add this field "magically". John and I decided to do that after M5. But I will remove the commented code. -- Christian From vladimir.kozlov at sun.com Wed Oct 21 12:19:04 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 21 Oct 2009 19:19:04 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6892186: SA does not dump debug info for scalar replaced objects Message-ID: <20091021191911.C0A3341414@hg.openjdk.java.net> Changeset: 873ec3787992 Author: kvn Date: 2009-10-21 09:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/873ec3787992 6892186: SA does not dump debug info for scalar replaced objects Summary: Implement scalar replaced objects debug info dump in SA. Reviewed-by: twisti ! agent/make/saenv.sh ! agent/make/saenv64.sh ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! src/share/vm/opto/callnode.cpp ! src/share/vm/runtime/vmStructs.cpp From John.Rose at Sun.COM Wed Oct 21 17:59:40 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 21 Oct 2009 17:59:40 -0700 Subject: Request for reviews (M): 6829192: JSR 292 needs to support 64-bit x86 In-Reply-To: <1256138115.21356.21.camel@macbook> References: <1256069092.820.117.camel@macbook> <4ADE5698.3080803@sun.com> <1256138115.21356.21.camel@macbook> Message-ID: <91C2A676-B8F8-4942-AAAD-4381F0CD3470@sun.com> On Oct 21, 2009, at 8:15 AM, Christian Thalinger wrote: > On Tue, 2009-10-20 at 17:32 -0700, Vladimir Kozlov wrote: >> src/cpu/x86/vm/templateInterpreter_x86_64.cpp: >> In TemplateInterpreterGenerator::generate_WrongMethodType_handler() >> what rbx and rax contain and why you need to verify oop? > > I can only tell what the registers contain, John should know why it > needs to be verified. It's a typo: The registers should be c_rarg[12]. Thanks for catching it, Vladimir. >> I don't like outline code in generate_return_entry_for(). >> Why do you need to move it down? > > I guess John wrote it that way because it's not the default case. > John? This x64 code is parallel to what's already in M3 for the x32 code. The usually taken path is the fallthrough path. I think it's slightly faster that way: fewer I-cache lines to touch. (We do that sort of heat-based CFG ordering routinely in the the C2 backend, and I think it's not uncommon in hand-written assembly code also.) >> src/share/vm/classfile/classFileParser.cpp: >> Don't leave commented code. Remove it if you don't need it. > > Yeah, that commented code was just a hack to get it working, the real > fix is to add this field "magically". John and I decided to do that > after M5. But I will remove the commented code. Yes, that's good. The finalized API will remove MethodHandleImpl as a superclass of MethodHandle. When this happens, we'll add a magic field, like the klass field in java.lang.Class. -- John From Christian.Thalinger at Sun.COM Thu Oct 22 09:19:40 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 22 Oct 2009 18:19:40 +0200 Subject: Request for reviews (XL): 6894206: JVM needs a way to traverse method handle structures Message-ID: <1256228380.833.22.camel@macbook> Here is the first part of the method handle walker: http://cr.openjdk.java.net/~twisti/6894206/webrev.01/ The bytecode adapter generation part for the compilers is another webrev, which will be posted later. -- Christian From Christian.Thalinger at Sun.COM Thu Oct 22 09:40:05 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 22 Oct 2009 18:40:05 +0200 Subject: Request for reviews .02 (M): 6829192: JSR 292 needs to support 64-bit x86 In-Reply-To: <91C2A676-B8F8-4942-AAAD-4381F0CD3470@sun.com> References: <1256069092.820.117.camel@macbook> <4ADE5698.3080803@sun.com> <1256138115.21356.21.camel@macbook> <91C2A676-B8F8-4942-AAAD-4381F0CD3470@sun.com> Message-ID: <1256229605.833.24.camel@macbook> Here is the updated webrev: http://cr.openjdk.java.net/~twisti/6829192/webrev.02/ I also added the comment in InterpreterMacroAssembler::get_cache_index_at_bcp() to the 32-bit version. -- Christian From Christian.Thalinger at Sun.COM Fri Oct 23 08:32:01 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Oct 2009 17:32:01 +0200 Subject: Request for review (XS): 6893554: SPECjvm2008 mpegaudio fails with SecurityException Message-ID: <1256311921.833.30.camel@macbook> http://cr.openjdk.java.net/~twisti/6893554/webrev.01/ From Vladimir.Kozlov at Sun.COM Fri Oct 23 09:45:57 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 23 Oct 2009 09:45:57 -0700 Subject: Request for review (XS): 6893554: SPECjvm2008 mpegaudio fails with SecurityException In-Reply-To: <1256311921.833.30.camel@macbook> References: <1256311921.833.30.camel@macbook> Message-ID: <4AE1DDC5.1040703@sun.com> Christian, Thank you for finding the cause so fast. The fix looks good. I am only concern about using #ifdef inside ins_encode and format. Could you verify the generated code for both 32- and 64-bit VM? Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6893554/webrev.01/ > From Christian.Thalinger at Sun.COM Fri Oct 23 10:10:21 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Oct 2009 19:10:21 +0200 Subject: Request for review (XS): 6893554: SPECjvm2008 mpegaudio fails with SecurityException In-Reply-To: <4AE1DDC5.1040703@sun.com> References: <1256311921.833.30.camel@macbook> <4AE1DDC5.1040703@sun.com> Message-ID: <1256317821.833.47.camel@macbook> On Fri, 2009-10-23 at 09:45 -0700, Vladimir Kozlov wrote: > Christian, > > Thank you for finding the cause so fast. > > The fix looks good. I am only concern about > using #ifdef inside ins_encode and format. > Could you verify the generated code for both > 32- and 64-bit VM? I don't like it either. We could use the 64-bit code for 32-bit too, but it's one (useless) instruction more. The generated code with the patch is OK for 32- and 64-bit. I tested that with my initial testcase. That leads me to another question: as I would have noticed the bug when I wouldn't have forgotten to actually run the testcase on 64-bit SPARC, aren't we running the compiler tests somewhere on a nightly basis? -- Christian From Vladimir.Kozlov at Sun.COM Fri Oct 23 10:35:57 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 23 Oct 2009 10:35:57 -0700 Subject: Request for review (XS): 6893554: SPECjvm2008 mpegaudio fails with SecurityException In-Reply-To: <1256317821.833.47.camel@macbook> References: <1256311921.833.30.camel@macbook> <4AE1DDC5.1040703@sun.com> <1256317821.833.47.camel@macbook> Message-ID: <4AE1E97D.8040505@sun.com> Christian Thalinger wrote: > On Fri, 2009-10-23 at 09:45 -0700, Vladimir Kozlov wrote: >> Christian, >> >> Thank you for finding the cause so fast. >> >> The fix looks good. I am only concern about >> using #ifdef inside ins_encode and format. >> Could you verify the generated code for both >> 32- and 64-bit VM? > > I don't like it either. We could use the 64-bit code for 32-bit too, > but it's one (useless) instruction more. > I would just remove #ifdef and use extra shift always. One additional instruction will not affect performance but will guaranty the correctness since in 32-bit VM the upper bit of src register could be set also. > The generated code with the patch is OK for 32- and 64-bit. I tested > that with my initial testcase. > > That leads me to another question: as I would have noticed the bug when > I wouldn't have forgotten to actually run the testcase on 64-bit SPARC, > aren't we running the compiler tests somewhere on a nightly basis? I looked on Nightly and the test passed: Passed: compiler/6823354/Test6823354.java But they running on Niagara 1 machines which does not have popc so this code is not exercised. Vladimir > > -- Christian > From Christian.Thalinger at Sun.COM Fri Oct 23 10:44:31 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Oct 2009 19:44:31 +0200 Subject: Request for review (XS): 6893554: SPECjvm2008 mpegaudio fails with SecurityException In-Reply-To: <4AE1E97D.8040505@sun.com> References: <1256311921.833.30.camel@macbook> <4AE1DDC5.1040703@sun.com> <1256317821.833.47.camel@macbook> <4AE1E97D.8040505@sun.com> Message-ID: <1256319871.833.50.camel@macbook> On Fri, 2009-10-23 at 10:35 -0700, Vladimir Kozlov wrote: > I would just remove #ifdef and use extra shift always. > One additional instruction will not affect performance but > will guaranty the correctness since in 32-bit VM the upper > bit of src register could be set also. Good point. I will remove the #ifdef and post another webrev. > I looked on Nightly and the test passed: > > Passed: compiler/6823354/Test6823354.java > > But they running on Niagara 1 machines which does not have popc > so this code is not exercised. Ahh, that explains it :-/ -- Christian From Christian.Thalinger at Sun.COM Fri Oct 23 11:43:01 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Oct 2009 20:43:01 +0200 Subject: Request for review .02 (XS): 6893554: SPECjvm2008 mpegaudio fails with SecurityException In-Reply-To: <1256319871.833.50.camel@macbook> References: <1256311921.833.30.camel@macbook> <4AE1DDC5.1040703@sun.com> <1256317821.833.47.camel@macbook> <4AE1E97D.8040505@sun.com> <1256319871.833.50.camel@macbook> Message-ID: <1256323381.833.53.camel@macbook> On Fri, 2009-10-23 at 19:44 +0200, Christian Thalinger wrote: > On Fri, 2009-10-23 at 10:35 -0700, Vladimir Kozlov wrote: > > I would just remove #ifdef and use extra shift always. > > One additional instruction will not affect performance but > > will guaranty the correctness since in 32-bit VM the upper > > bit of src register could be set also. > > Good point. I will remove the #ifdef and post another webrev. http://cr.openjdk.java.net/~twisti/6893554/webrev.02/ -- Christian From Vladimir.Kozlov at Sun.COM Fri Oct 23 11:44:35 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 23 Oct 2009 11:44:35 -0700 Subject: Request for review .02 (XS): 6893554: SPECjvm2008 mpegaudio fails with SecurityException In-Reply-To: <1256323381.833.53.camel@macbook> References: <1256311921.833.30.camel@macbook> <4AE1DDC5.1040703@sun.com> <1256317821.833.47.camel@macbook> <4AE1E97D.8040505@sun.com> <1256319871.833.50.camel@macbook> <1256323381.833.53.camel@macbook> Message-ID: <4AE1F993.9030802@sun.com> Looks good. Thanks, Vladimir Christian Thalinger wrote: > On Fri, 2009-10-23 at 19:44 +0200, Christian Thalinger wrote: >> On Fri, 2009-10-23 at 10:35 -0700, Vladimir Kozlov wrote: >>> I would just remove #ifdef and use extra shift always. >>> One additional instruction will not affect performance but >>> will guaranty the correctness since in 32-bit VM the upper >>> bit of src register could be set also. >> Good point. I will remove the #ifdef and post another webrev. > > http://cr.openjdk.java.net/~twisti/6893554/webrev.02/ > > -- Christian > From tom.deneau at amd.com Fri Oct 23 16:07:36 2009 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 23 Oct 2009 18:07:36 -0500 Subject: Starting with jdwp agent should not incur performance penalty Message-ID: <510934C4EB2082479E7D4AA4D06A88827BAB4A98@SAUSEXMBP01.amd.com> I have filed an issue dealing with performance when a jdwp agent is attached. This issue has not yet become publicly visible but I was hoping to start some discussion on it. The internal review ID is 1630014 but if you can't see that, you can view the issue at the end of this post. Problem ------- We can see how the code generation for throws gets affected by the value Returned by jvmti_can_post_exceptions() which depends not on the SetEventNotification state but on the capabilities state and is the OR of the three capabilities, * Can_generate_exception_events * Can_generate_frame_pop_events * Can_generate_method_exit_events and how these capabilities can only be set at agent_onload phase. For example in share/vm/opto/parse2.cpp, case ByteCodes::_athrow: if (env()->jvmti_can_post_exceptions()) { // "Full-speed throwing" is not necessary here, // since we're notifying the VM on every throw. uncommon_trap(Deoptimization::Reason_unhandled, Deoptimization::Action_none); return; } .... //otherwise fastpath add_exception_state(make_exception_state(peek()))); break; And then deep in the uncommon_trap routine, in addition to all the other exception handling, in JvmtiExport::post_exception_throw, the jvmti_thread_state is checked to see if we really need to do a JVMTI Exception event notification (if the debugger has not yet connected, the answer is no). General ways to attack this =========================== General Solution 1) In the _athrow example above..... * if can_post_exceptions is true, generate code for a runtime check of the jvmti_thread_state, and to take the "slow path" only if jvmti_thread_state indicated that event notifications needed to be sent, otherwise branch to the "fast path" code. (this might have to be done in graphKit.cpp as well) General Solution 2) * At compilation time do not compile in the "slow path" (which checks for jvmti notification) at all unless jvmti exception event notification is enabled in some jvmti_thread_state. Thus in the normal situation where the jdwp agent is attached but debugger not attached, we would only compile the "fast path". * At debugger attach time (ie, jvmti exception event notification enabled), all such compiled methods which could throw exceptions would need to get invalidated and possibly recompiled to include the slow path. I'd be interested in the pros and cons of these two general solutions. To me, solution 1 seems less intrusive. Also, since the exception event notification can have different values for different threads, this allows some threads to take the fast path while others take the slow path. ======================================================================= Issue Description ======================================================================= Title: Starting with jdwp agent should not incur performance penalty --------------------------------------------------------------------- Description: A DESCRIPTION OF THE REQUEST : If you start Java with the jdwp agent, for example using -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n you will see that the jdwp agent enables the * can_generate_exception_events capability but does not enable exception event notification until a debugger actually attaches to the socket. (This can be confirmed using the -XX:TraceJVMTI option). Yet just using the jdwp agent and not attaching the debugger still results in a large decrease in performance for applications which throw exceptions, at least for the server compiler. Note that it is not a workaround to just delay the attachment of the jdwp agent using the com.sun.tools.attach API. The jdwp agent does not have the Agent_OnAttach entry point, and even if it did, the capabilities that the jdwp agent adds can only be added at JVM initialization time. JUSTIFICATION : This is important because many applications start the JVM with the jdwp agent in case they might want to attach the debugger at some later time. This happens even in production environments and the expectation is that starting with the jdwp agent does not incur a noticeable performance penalty until the debugger attaches. EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED - The expectation is that starting with the jdwp agent does not incur a noticeable performance penalty until the debugger attaches. ACTUAL - The actual behavior is that starting with the jdwp agent does incur a noticeable performance penalty for apps that throw exceptions even though the debugger has not attached. workaround: From Vladimir.Kozlov at Sun.COM Fri Oct 23 21:50:51 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 23 Oct 2009 21:50:51 -0700 Subject: 6894807: problem with interfaces in C2 type system Message-ID: <4AE287AB.2050006@sun.com> I am investigating 6894807: No ClassCastException for HashAttributeSet constructors if run with -Xcomp Because of Escape Analysis is on by default all constructors are inlined in the test case and object scalar replaced. But due to, I think, the problem in C2 type system the result is incorrect. We should check if interface is exact before replacing it with j.l.O in TypeOopPtr::filter() for the case (exact interface)->filter(j.l.O). Vladimir ---------------------------------------------------------------- Test code expects ClassCastException exception: import javax.print.attribute.Attribute; import javax.print.attribute.AttributeSet; import javax.print.attribute.DocAttribute; import javax.print.attribute.HashAttributeSet; import javax.print.attribute.standard.JobState; try { new MyHashAttributeSet(JobState.CANCELED, DocAttribute.class); System.out.println("No ClassCastException in t2!"); } catch (ClassCastException _) { } EA forces to inline all constructors for MyHashAttributeSet: class MyHashAttributeSet extends HashAttributeSet{ MyHashAttributeSet(Attribute attribute, Class interfaceName){ super(attribute, interfaceName); } then protected HashAttributeSet(Attribute attribute, Class interfaceName) { if (interfaceName == null) { throw new NullPointerException("null interface"); } myInterface = interfaceName; add (attribute); } add() is inlined also: public boolean add(Attribute attribute) { Object oldAttribute = attrMap.put(attribute.getCategory(), AttributeSetUtilities. verifyAttributeValue(attribute, myInterface)); return (!attribute.equals(oldAttribute)); } and verifyAttributeValue(attribute, myInterface) is inlined as well: public static Attribute verifyAttributeValue(Object object, Class interfaceName) { if (object == null) { throw new NullPointerException(); } else if (interfaceName.isInstance (object)) { return (Attribute) object; } else { throw new ClassCastException(); } } object is JobState.CANCELED which is public static final JobState CANCELED = new JobState (7); and interfaceName is DocAttribute.class where public interface DocAttribute extends Attribute {} ---------------------------------------------------------------- So we end up with (DocAttribute.class).isInstance(JobState.CANCELED) We have intrinsic for isInstance() for which we generated // Now load the mirror's klass metaobject, and null-check it. // Side-effects region with the control path if the klass is null. Node* kls = load_klass_from_mirror(mirror, never_see_null, nargs, region, _prim_path); case vmIntrinsics::_isInstance: // nothing is an instance of a primitive type query_value = gen_instanceof(obj, kls); where due to NULL check we have next CastPP for DocAttribute.class: [t at 19 l at 19]: print kls->dump(1) 390 LoadKlass === _ 7 389 [[ 391 396 ]] @rawptr:BotPTR, idx=Raw; # * Klass: * !jvms: AttributeSetUtilities::verifyAttributeValue @ bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 395 IfTrue === 393 [[ 370 396 ]] #1 !jvms: AttributeSetUtilities::verifyAttributeValue @ bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 396 CastPP === 395 390 [[ 409 409 413 432 427 ]] #klass java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: 0x0811c7e0 * !jvms: AttributeSetUtilities::verifyAttributeValue @ bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 During IGVN LoadKlass(390) transformed to constant klass which is interface: 702 ConP === 0 [[ 396 391 ]] #precise klass javax/print/attribute/DocAttribute: 0x08407298:Constant:exact * Interface:precise klass javax/print/attribute/DocAttribute: 0x08407298:Constant:exact * 396 CastPP === 395 702 [[ 409 409 413 432 427 ]] #klass java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: 0x0811c7e0 * !jvms: AttributeSetUtilities::verifyAttributeValue @ bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 ConstraintCastNode::Value() calls TypeOopPtr::filter() method which, I think, returns incorrect result: [t at 19 l at 19]: print ft->dump() precise klass javax/print/attribute/DocAttribute: 0x08407298:Constant:exact * [t at 19 l at 19]: print ftkp->klass()->print() [t at 19 l at 19]: print ktkp->klass()->print() ktkp->klass()->print() = (void) because of this code: // If we have an interface-typed Phi or cast and we narrow to a class type, // the join should report back the class. However, if we have a J/L/Object // class-typed Phi and an interface flows in, it's possible that the meet & // join report an interface back out. This isn't possible but happens // because the type system doesn't interact well with interfaces. if (ftkp != NULL && ktkp != NULL && ftkp->is_loaded() && ftkp->klass()->is_interface() && ktkp->is_loaded() && !ktkp->klass()->is_interface()) { // Happens in a CTW of rt.jar, 320-341, no extra flags return ktkp->cast_to_ptr_type(ftkp->ptr()); } the result is precise klass java/lang/Object: 0x0811c7e0:Constant:exact * which leads to incorrect result from CmpP node: 703 ConP === 0 [[ 704 432 704 ]] #precise klass java/lang/Object: 0x0811c7e0:Constant:exact * Klass:precise klass java/lang/Object: 0x0811c7e0:Constant:exact * 704 CmpP === _ 703 703 [[ 705 ]] !orig=[413] !jvms: AttributeSetUtilities::verifyAttributeValue @ bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 From Vladimir.Kozlov at Sun.COM Mon Oct 26 15:07:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 26 Oct 2009 15:07:20 -0700 Subject: 6894807: problem with interfaces in C2 type system In-Reply-To: <4AE287AB.2050006@sun.com> References: <4AE287AB.2050006@sun.com> Message-ID: <4AE61D98.9050406@sun.com> John, Tom I need your help with this. The original implementation of TypeOopPtr::filter() was done by John and pushed by Ross for: 6467870: Fixes to monotonically narrow or widen types during igvn Ross Knippel wrote: > This change is from John Rose (I'm just the medium.) > It's a piece extracted from his current work. It did not have the bug's problem since an interface could not be exact. Then Tom added the klass part for: 6788347: C2Compiler crash 6u7 Which causes the problem since interface klass could be exact (constant, as in the bug's case) and casting j.l.O klass to interface's ptr returns incorrectly exact j.l.O klass: return ktkp->cast_to_ptr_type(ftkp->ptr()); The fix is either simple return original j.l.o klass: return kills; or cast to ptrs meet: return ktkp->cast_to_ptr_type(ktkp->meet_ptr(ftkp->ptr())); Both of them fixed the problem. But I am not sure since in both cases we loose the precision of interface klass which allows more ideal optimizations (for example, for CmpP). Thanks, Vladimir Vladimir Kozlov wrote: > I am investigating 6894807: No ClassCastException for HashAttributeSet > constructors if run with -Xcomp > > Because of Escape Analysis is on by default all constructors are inlined > in the test case and object scalar replaced. But due to, I think, > the problem in C2 type system the result is incorrect. > > We should check if interface is exact before replacing > it with j.l.O in TypeOopPtr::filter() for the case > (exact interface klass)->filter(j.l.O klass). > > Vladimir > > ---------------------------------------------------------------- > Test code expects ClassCastException exception: > > import javax.print.attribute.Attribute; > import javax.print.attribute.AttributeSet; > import javax.print.attribute.DocAttribute; > import javax.print.attribute.HashAttributeSet; > import javax.print.attribute.standard.JobState; > > try { > new MyHashAttributeSet(JobState.CANCELED, DocAttribute.class); > System.out.println("No ClassCastException in t2!"); > } catch (ClassCastException _) { > } > > EA forces to inline all constructors for MyHashAttributeSet: > > class MyHashAttributeSet extends HashAttributeSet{ > MyHashAttributeSet(Attribute attribute, > Class interfaceName){ > super(attribute, interfaceName); > } > > then > > protected HashAttributeSet(Attribute attribute, Class > interfaceName) { > if (interfaceName == null) { > throw new NullPointerException("null interface"); > } > myInterface = interfaceName; > add (attribute); > } > > add() is inlined also: > > public boolean add(Attribute attribute) { > Object oldAttribute = > attrMap.put(attribute.getCategory(), > AttributeSetUtilities. > verifyAttributeValue(attribute, myInterface)); > return (!attribute.equals(oldAttribute)); > } > > and verifyAttributeValue(attribute, myInterface) is inlined as well: > > public static Attribute > verifyAttributeValue(Object object, Class interfaceName) { > > if (object == null) { > throw new NullPointerException(); > } > else if (interfaceName.isInstance (object)) { > return (Attribute) object; > } else { > throw new ClassCastException(); > } > } > > object is JobState.CANCELED which is > > public static final JobState CANCELED = new JobState (7); > > and interfaceName is DocAttribute.class where > > public interface DocAttribute extends Attribute {} > > ---------------------------------------------------------------- > So we end up with > > (DocAttribute.class).isInstance(JobState.CANCELED) > > We have intrinsic for isInstance() for which we generated > > // Now load the mirror's klass metaobject, and null-check it. > // Side-effects region with the control path if the klass is null. > Node* kls = load_klass_from_mirror(mirror, never_see_null, nargs, > region, _prim_path); > > case vmIntrinsics::_isInstance: > // nothing is an instance of a primitive type > query_value = gen_instanceof(obj, kls); > > where due to NULL check we have next CastPP for DocAttribute.class: > [t at 19 l at 19]: print kls->dump(1) > 390 LoadKlass === _ 7 389 [[ 391 396 ]] @rawptr:BotPTR, > idx=Raw; # * Klass: * !jvms: > AttributeSetUtilities::verifyAttributeValue @ bci:14 > HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 > MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 > 395 IfTrue === 393 [[ 370 396 ]] #1 !jvms: > AttributeSetUtilities::verifyAttributeValue @ bci:14 > HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 > MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 > 396 CastPP === 395 390 [[ 409 409 413 432 427 ]] #klass > java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: 0x0811c7e0 > * !jvms: AttributeSetUtilities::verifyAttributeValue @ bci:14 > HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 > MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 > > During IGVN LoadKlass(390) transformed to constant klass which is > interface: > > 702 ConP === 0 [[ 396 391 ]] #precise klass > javax/print/attribute/DocAttribute: 0x08407298:Constant:exact * > Interface:precise klass javax/print/attribute/DocAttribute: > 0x08407298:Constant:exact * > 396 CastPP === 395 702 [[ 409 409 413 432 427 ]] #klass > java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: 0x0811c7e0 > * !jvms: AttributeSetUtilities::verifyAttributeValue @ bci:14 > HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 > MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 > > ConstraintCastNode::Value() calls TypeOopPtr::filter() method > which, I think, returns incorrect result: > > [t at 19 l at 19]: print ft->dump() > precise klass javax/print/attribute/DocAttribute: > 0x08407298:Constant:exact * > > [t at 19 l at 19]: print ftkp->klass()->print() > loaded=true initialized=false finalized=false subklass=false size=9 > flags=public,interface,abstract mirror=PRESENT ident=655 PERM > address=0x8407298> > > [t at 19 l at 19]: print ktkp->klass()->print() > initialized=true finalized=false subklass=true size=8 flags=public,super > mirror=PRESENT ident=558 PERM address=0x811c7e0>ktkp->klass()->print() = > (void) > > because of this code: > > // If we have an interface-typed Phi or cast and we narrow to a class > type, > // the join should report back the class. However, if we have a > J/L/Object > // class-typed Phi and an interface flows in, it's possible that the > meet & > // join report an interface back out. This isn't possible but happens > // because the type system doesn't interact well with interfaces. > > if (ftkp != NULL && ktkp != NULL && > ftkp->is_loaded() && ftkp->klass()->is_interface() && > ktkp->is_loaded() && !ktkp->klass()->is_interface()) { > // Happens in a CTW of rt.jar, 320-341, no extra flags > return ktkp->cast_to_ptr_type(ftkp->ptr()); > } > > the result is > > precise klass java/lang/Object: 0x0811c7e0:Constant:exact * > > which leads to incorrect result from CmpP node: > > 703 ConP === 0 [[ 704 432 704 ]] #precise klass > java/lang/Object: 0x0811c7e0:Constant:exact * Klass:precise klass > java/lang/Object: 0x0811c7e0:Constant:exact * > 704 CmpP === _ 703 703 [[ 705 ]] !orig=[413] !jvms: > AttributeSetUtilities::verifyAttributeValue @ bci:14 > HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 > MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 > From Thomas.Rodriguez at Sun.COM Mon Oct 26 16:22:16 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 26 Oct 2009 16:22:16 -0700 Subject: 6894807: problem with interfaces in C2 type system In-Reply-To: <4AE61D98.9050406@sun.com> References: <4AE287AB.2050006@sun.com> <4AE61D98.9050406@sun.com> Message-ID: <90A43170-33C5-4719-A342-E89667307530@sun.com> I think it should include an extra test of !ftkp->klass_is_exact(). This will cause it to return ft which is the original precise type. tom On Oct 26, 2009, at 3:07 PM, Vladimir Kozlov wrote: > John, Tom > > I need your help with this. > > The original implementation of TypeOopPtr::filter() was done by John > and pushed by Ross for: > > 6467870: Fixes to monotonically narrow or widen types during igvn > > Ross Knippel wrote: > > This change is from John Rose (I'm just the medium.) > > It's a piece extracted from his current work. > > It did not have the bug's problem since an interface could not be > exact. > > Then Tom added the klass part for: > > 6788347: C2Compiler crash 6u7 > > Which causes the problem since interface klass could be exact > (constant, > as in the bug's case) and casting j.l.O klass to interface's ptr > returns incorrectly exact j.l.O klass: > > return ktkp->cast_to_ptr_type(ftkp->ptr()); > > The fix is either simple return original j.l.o klass: > > return kills; > > or cast to ptrs meet: > > return ktkp->cast_to_ptr_type(ktkp->meet_ptr(ftkp->ptr())); > > Both of them fixed the problem. But I am not sure since in > both cases we loose the precision of interface klass which > allows more ideal optimizations (for example, for CmpP). > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> I am investigating 6894807: No ClassCastException for >> HashAttributeSet constructors if run with -Xcomp >> Because of Escape Analysis is on by default all constructors are >> inlined >> in the test case and object scalar replaced. But due to, I think, >> the problem in C2 type system the result is incorrect. >> We should check if interface is exact before replacing >> it with j.l.O in TypeOopPtr::filter() for the case >> (exact interface klass)->filter(j.l.O klass). >> Vladimir >> ---------------------------------------------------------------- >> Test code expects ClassCastException exception: >> import javax.print.attribute.Attribute; >> import javax.print.attribute.AttributeSet; >> import javax.print.attribute.DocAttribute; >> import javax.print.attribute.HashAttributeSet; >> import javax.print.attribute.standard.JobState; >> try { >> new MyHashAttributeSet(JobState.CANCELED, >> DocAttribute.class); >> System.out.println("No ClassCastException in t2!"); >> } catch (ClassCastException _) { >> } >> EA forces to inline all constructors for MyHashAttributeSet: >> class MyHashAttributeSet extends HashAttributeSet{ >> MyHashAttributeSet(Attribute attribute, >> Class interfaceName){ >> super(attribute, interfaceName); >> } >> then >> protected HashAttributeSet(Attribute attribute, Class >> interfaceName) { >> if (interfaceName == null) { >> throw new NullPointerException("null interface"); >> } >> myInterface = interfaceName; >> add (attribute); >> } >> add() is inlined also: >> public boolean add(Attribute attribute) { >> Object oldAttribute = >> attrMap.put(attribute.getCategory(), >> AttributeSetUtilities. >> verifyAttributeValue(attribute, myInterface)); >> return (!attribute.equals(oldAttribute)); >> } >> and verifyAttributeValue(attribute, myInterface) is inlined as well: >> public static Attribute >> verifyAttributeValue(Object object, Class interfaceName) { >> if (object == null) { >> throw new NullPointerException(); >> } >> else if (interfaceName.isInstance (object)) { >> return (Attribute) object; >> } else { >> throw new ClassCastException(); >> } >> } >> object is JobState.CANCELED which is >> public static final JobState CANCELED = new JobState (7); >> and interfaceName is DocAttribute.class where >> public interface DocAttribute extends Attribute {} >> ---------------------------------------------------------------- >> So we end up with >> (DocAttribute.class).isInstance(JobState.CANCELED) >> We have intrinsic for isInstance() for which we generated >> // Now load the mirror's klass metaobject, and null-check it. >> // Side-effects region with the control path if the klass is null. >> Node* kls = load_klass_from_mirror(mirror, never_see_null, nargs, >> region, _prim_path); >> case vmIntrinsics::_isInstance: >> // nothing is an instance of a primitive type >> query_value = gen_instanceof(obj, kls); >> where due to NULL check we have next CastPP for DocAttribute.class: >> [t at 19 l at 19]: print kls->dump(1) >> 390 LoadKlass === _ 7 389 [[ 391 396 ]] >> @rawptr:BotPTR, idx=Raw; # * Klass: * !jvms: >> AttributeSetUtilities::verifyAttributeValue @ bci:14 >> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >> 395 IfTrue === 393 [[ 370 396 ]] #1 !jvms: >> AttributeSetUtilities::verifyAttributeValue @ bci:14 >> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >> 396 CastPP === 395 390 [[ 409 409 413 432 427 ]] #klass >> java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: >> 0x0811c7e0 * !jvms: AttributeSetUtilities::verifyAttributeValue @ >> bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ >> bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >> During IGVN LoadKlass(390) transformed to constant klass which is >> interface: >> 702 ConP === 0 [[ 396 391 ]] #precise klass javax/print/ >> attribute/DocAttribute: 0x08407298:Constant:exact * >> Interface:precise klass javax/print/attribute/DocAttribute: >> 0x08407298:Constant:exact * >> 396 CastPP === 395 702 [[ 409 409 413 432 427 ]] #klass >> java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: >> 0x0811c7e0 * !jvms: AttributeSetUtilities::verifyAttributeValue @ >> bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ >> bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >> ConstraintCastNode::Value() calls TypeOopPtr::filter() method >> which, I think, returns incorrect result: >> [t at 19 l at 19]: print ft->dump() >> precise klass javax/print/attribute/DocAttribute: >> 0x08407298:Constant:exact * >> [t at 19 l at 19]: print ftkp->klass()->print() >> > loaded=true initialized=false finalized=false subklass=false size=9 >> flags=public,interface,abstract mirror=PRESENT ident=655 PERM >> address=0x8407298> >> [t at 19 l at 19]: print ktkp->klass()->print() >> > initialized=true finalized=false subklass=true size=8 >> flags=public,super mirror=PRESENT ident=558 PERM >> address=0x811c7e0>ktkp->klass()->print() = (void) >> because of this code: >> // If we have an interface-typed Phi or cast and we narrow to a >> class type, >> // the join should report back the class. However, if we have a J/ >> L/Object >> // class-typed Phi and an interface flows in, it's possible that >> the meet & >> // join report an interface back out. This isn't possible but >> happens >> // because the type system doesn't interact well with interfaces. >> if (ftkp != NULL && ktkp != NULL && >> ftkp->is_loaded() && ftkp->klass()->is_interface() && >> ktkp->is_loaded() && !ktkp->klass()->is_interface()) { >> // Happens in a CTW of rt.jar, 320-341, no extra flags >> return ktkp->cast_to_ptr_type(ftkp->ptr()); >> } >> the result is >> precise klass java/lang/Object: 0x0811c7e0:Constant:exact * >> which leads to incorrect result from CmpP node: >> 703 ConP === 0 [[ 704 432 704 ]] #precise klass java/ >> lang/Object: 0x0811c7e0:Constant:exact * Klass:precise klass java/ >> lang/Object: 0x0811c7e0:Constant:exact * >> 704 CmpP === _ 703 703 [[ 705 ]] !orig=[413] !jvms: >> AttributeSetUtilities::verifyAttributeValue @ bci:14 >> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 From Vladimir.Kozlov at Sun.COM Mon Oct 26 17:30:14 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 26 Oct 2009 17:30:14 -0700 Subject: 6894807: problem with interfaces in C2 type system In-Reply-To: <90A43170-33C5-4719-A342-E89667307530@sun.com> References: <4AE287AB.2050006@sun.com> <4AE61D98.9050406@sun.com> <90A43170-33C5-4719-A342-E89667307530@sun.com> Message-ID: <4AE63F16.2090104@sun.com> Thanks, Tom I will do it. Vladimir Tom Rodriguez wrote: > I think it should include an extra test of !ftkp->klass_is_exact(). > This will cause it to return ft which is the original precise type. > > tom > > On Oct 26, 2009, at 3:07 PM, Vladimir Kozlov wrote: > >> John, Tom >> >> I need your help with this. >> >> The original implementation of TypeOopPtr::filter() was done by John >> and pushed by Ross for: >> >> 6467870: Fixes to monotonically narrow or widen types during igvn >> >> Ross Knippel wrote: >> > This change is from John Rose (I'm just the medium.) >> > It's a piece extracted from his current work. >> >> It did not have the bug's problem since an interface could not be exact. >> >> Then Tom added the klass part for: >> >> 6788347: C2Compiler crash 6u7 >> >> Which causes the problem since interface klass could be exact (constant, >> as in the bug's case) and casting j.l.O klass to interface's ptr >> returns incorrectly exact j.l.O klass: >> >> return ktkp->cast_to_ptr_type(ftkp->ptr()); >> >> The fix is either simple return original j.l.o klass: >> >> return kills; >> >> or cast to ptrs meet: >> >> return ktkp->cast_to_ptr_type(ktkp->meet_ptr(ftkp->ptr())); >> >> Both of them fixed the problem. But I am not sure since in >> both cases we loose the precision of interface klass which >> allows more ideal optimizations (for example, for CmpP). >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> I am investigating 6894807: No ClassCastException for >>> HashAttributeSet constructors if run with -Xcomp >>> Because of Escape Analysis is on by default all constructors are inlined >>> in the test case and object scalar replaced. But due to, I think, >>> the problem in C2 type system the result is incorrect. >>> We should check if interface is exact before replacing >>> it with j.l.O in TypeOopPtr::filter() for the case >>> (exact interface klass)->filter(j.l.O klass). >>> Vladimir >>> ---------------------------------------------------------------- >>> Test code expects ClassCastException exception: >>> import javax.print.attribute.Attribute; >>> import javax.print.attribute.AttributeSet; >>> import javax.print.attribute.DocAttribute; >>> import javax.print.attribute.HashAttributeSet; >>> import javax.print.attribute.standard.JobState; >>> try { >>> new MyHashAttributeSet(JobState.CANCELED, >>> DocAttribute.class); >>> System.out.println("No ClassCastException in t2!"); >>> } catch (ClassCastException _) { >>> } >>> EA forces to inline all constructors for MyHashAttributeSet: >>> class MyHashAttributeSet extends HashAttributeSet{ >>> MyHashAttributeSet(Attribute attribute, >>> Class interfaceName){ >>> super(attribute, interfaceName); >>> } >>> then >>> protected HashAttributeSet(Attribute attribute, Class >>> interfaceName) { >>> if (interfaceName == null) { >>> throw new NullPointerException("null interface"); >>> } >>> myInterface = interfaceName; >>> add (attribute); >>> } >>> add() is inlined also: >>> public boolean add(Attribute attribute) { >>> Object oldAttribute = >>> attrMap.put(attribute.getCategory(), >>> AttributeSetUtilities. >>> verifyAttributeValue(attribute, myInterface)); >>> return (!attribute.equals(oldAttribute)); >>> } >>> and verifyAttributeValue(attribute, myInterface) is inlined as well: >>> public static Attribute >>> verifyAttributeValue(Object object, Class interfaceName) { >>> if (object == null) { >>> throw new NullPointerException(); >>> } >>> else if (interfaceName.isInstance (object)) { >>> return (Attribute) object; >>> } else { >>> throw new ClassCastException(); >>> } >>> } >>> object is JobState.CANCELED which is >>> public static final JobState CANCELED = new JobState (7); >>> and interfaceName is DocAttribute.class where >>> public interface DocAttribute extends Attribute {} >>> ---------------------------------------------------------------- >>> So we end up with >>> (DocAttribute.class).isInstance(JobState.CANCELED) >>> We have intrinsic for isInstance() for which we generated >>> // Now load the mirror's klass metaobject, and null-check it. >>> // Side-effects region with the control path if the klass is null. >>> Node* kls = load_klass_from_mirror(mirror, never_see_null, nargs, >>> region, _prim_path); >>> case vmIntrinsics::_isInstance: >>> // nothing is an instance of a primitive type >>> query_value = gen_instanceof(obj, kls); >>> where due to NULL check we have next CastPP for DocAttribute.class: >>> [t at 19 l at 19]: print kls->dump(1) >>> 390 LoadKlass === _ 7 389 [[ 391 396 ]] @rawptr:BotPTR, >>> idx=Raw; # * Klass: * !jvms: >>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>> 395 IfTrue === 393 [[ 370 396 ]] #1 !jvms: >>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>> 396 CastPP === 395 390 [[ 409 409 413 432 427 ]] #klass >>> java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: >>> 0x0811c7e0 * !jvms: AttributeSetUtilities::verifyAttributeValue @ >>> bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ >>> bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>> During IGVN LoadKlass(390) transformed to constant klass which is >>> interface: >>> 702 ConP === 0 [[ 396 391 ]] #precise klass >>> javax/print/attribute/DocAttribute: 0x08407298:Constant:exact * >>> Interface:precise klass javax/print/attribute/DocAttribute: >>> 0x08407298:Constant:exact * >>> 396 CastPP === 395 702 [[ 409 409 413 432 427 ]] #klass >>> java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: >>> 0x0811c7e0 * !jvms: AttributeSetUtilities::verifyAttributeValue @ >>> bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ >>> bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>> ConstraintCastNode::Value() calls TypeOopPtr::filter() method >>> which, I think, returns incorrect result: >>> [t at 19 l at 19]: print ft->dump() >>> precise klass javax/print/attribute/DocAttribute: >>> 0x08407298:Constant:exact * >>> [t at 19 l at 19]: print ftkp->klass()->print() >>> >> loaded=true initialized=false finalized=false subklass=false size=9 >>> flags=public,interface,abstract mirror=PRESENT ident=655 PERM >>> address=0x8407298> >>> [t at 19 l at 19]: print ktkp->klass()->print() >>> >> initialized=true finalized=false subklass=true size=8 >>> flags=public,super mirror=PRESENT ident=558 PERM >>> address=0x811c7e0>ktkp->klass()->print() = (void) >>> because of this code: >>> // If we have an interface-typed Phi or cast and we narrow to a >>> class type, >>> // the join should report back the class. However, if we have a >>> J/L/Object >>> // class-typed Phi and an interface flows in, it's possible that the >>> meet & >>> // join report an interface back out. This isn't possible but happens >>> // because the type system doesn't interact well with interfaces. >>> if (ftkp != NULL && ktkp != NULL && >>> ftkp->is_loaded() && ftkp->klass()->is_interface() && >>> ktkp->is_loaded() && !ktkp->klass()->is_interface()) { >>> // Happens in a CTW of rt.jar, 320-341, no extra flags >>> return ktkp->cast_to_ptr_type(ftkp->ptr()); >>> } >>> the result is >>> precise klass java/lang/Object: 0x0811c7e0:Constant:exact * >>> which leads to incorrect result from CmpP node: >>> 703 ConP === 0 [[ 704 432 704 ]] #precise klass >>> java/lang/Object: 0x0811c7e0:Constant:exact * Klass:precise klass >>> java/lang/Object: 0x0811c7e0:Constant:exact * >>> 704 CmpP === _ 703 703 [[ 705 ]] !orig=[413] !jvms: >>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 > From John.Rose at Sun.COM Mon Oct 26 22:07:07 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 27 Oct 2009 01:07:07 -0400 Subject: 6894807: problem with interfaces in C2 type system In-Reply-To: <4AE63F16.2090104@sun.com> References: <4AE287AB.2050006@sun.com> <4AE61D98.9050406@sun.com> <90A43170-33C5-4719-A342-E89667307530@sun.com> <4AE63F16.2090104@sun.com> Message-ID: <6392CCBB-64DD-49BB-8B21-2F89B6C1208F@sun.com> Ughh. We keep patching this stuff... Two questions: 1. Is the second occurrence of this comment really true, or is it just a copy of the first occurrence (from Tom's fix)? // Happens in a CTW of rt.jar, 320-341, no extra flags 2. Why doesn't the bug happen in the original code? Oh, right: An object cannot have exactly an interface type. It's strange to have a phi with a constant type. Maybe the right answer for a filter() query is, if the phi's type ('kill' arg) is a Type::singleton, return it without further processing. -- John On Oct 26, 2009, at 8:30 PM, Vladimir Kozlov wrote: > Thanks, Tom > > I will do it. > > Vladimir > > Tom Rodriguez wrote: >> I think it should include an extra test of !ftkp->klass_is_exact >> (). This will cause it to return ft which is the original precise >> type. >> tom >> On Oct 26, 2009, at 3:07 PM, Vladimir Kozlov wrote: >>> John, Tom >>> >>> I need your help with this. >>> >>> The original implementation of TypeOopPtr::filter() was done by John >>> and pushed by Ross for: >>> >>> 6467870: Fixes to monotonically narrow or widen types during igvn >>> >>> Ross Knippel wrote: >>> > This change is from John Rose (I'm just the medium.) >>> > It's a piece extracted from his current work. >>> >>> It did not have the bug's problem since an interface could not be >>> exact. >>> >>> Then Tom added the klass part for: >>> >>> 6788347: C2Compiler crash 6u7 >>> >>> Which causes the problem since interface klass could be exact >>> (constant, >>> as in the bug's case) and casting j.l.O klass to interface's ptr >>> returns incorrectly exact j.l.O klass: >>> >>> return ktkp->cast_to_ptr_type(ftkp->ptr()); >>> >>> The fix is either simple return original j.l.o klass: >>> >>> return kills; >>> >>> or cast to ptrs meet: >>> >>> return ktkp->cast_to_ptr_type(ktkp->meet_ptr(ftkp->ptr())); >>> >>> Both of them fixed the problem. But I am not sure since in >>> both cases we loose the precision of interface klass which >>> allows more ideal optimizations (for example, for CmpP). >>> >>> Thanks, >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> I am investigating 6894807: No ClassCastException for >>>> HashAttributeSet constructors if run with -Xcomp >>>> Because of Escape Analysis is on by default all constructors are >>>> inlined >>>> in the test case and object scalar replaced. But due to, I think, >>>> the problem in C2 type system the result is incorrect. >>>> We should check if interface is exact before replacing >>>> it with j.l.O in TypeOopPtr::filter() for the case >>>> (exact interface klass)->filter(j.l.O klass). >>>> Vladimir >>>> ---------------------------------------------------------------- >>>> Test code expects ClassCastException exception: >>>> import javax.print.attribute.Attribute; >>>> import javax.print.attribute.AttributeSet; >>>> import javax.print.attribute.DocAttribute; >>>> import javax.print.attribute.HashAttributeSet; >>>> import javax.print.attribute.standard.JobState; >>>> try { >>>> new MyHashAttributeSet(JobState.CANCELED, >>>> DocAttribute.class); >>>> System.out.println("No ClassCastException in t2!"); >>>> } catch (ClassCastException _) { >>>> } >>>> EA forces to inline all constructors for MyHashAttributeSet: >>>> class MyHashAttributeSet extends HashAttributeSet{ >>>> MyHashAttributeSet(Attribute attribute, >>>> Class interfaceName){ >>>> super(attribute, interfaceName); >>>> } >>>> then >>>> protected HashAttributeSet(Attribute attribute, Class >>>> interfaceName) { >>>> if (interfaceName == null) { >>>> throw new NullPointerException("null interface"); >>>> } >>>> myInterface = interfaceName; >>>> add (attribute); >>>> } >>>> add() is inlined also: >>>> public boolean add(Attribute attribute) { >>>> Object oldAttribute = >>>> attrMap.put(attribute.getCategory(), >>>> AttributeSetUtilities. >>>> verifyAttributeValue(attribute, >>>> myInterface)); >>>> return (!attribute.equals(oldAttribute)); >>>> } >>>> and verifyAttributeValue(attribute, myInterface) is inlined as >>>> well: >>>> public static Attribute >>>> verifyAttributeValue(Object object, Class interfaceName) { >>>> if (object == null) { >>>> throw new NullPointerException(); >>>> } >>>> else if (interfaceName.isInstance (object)) { >>>> return (Attribute) object; >>>> } else { >>>> throw new ClassCastException(); >>>> } >>>> } >>>> object is JobState.CANCELED which is >>>> public static final JobState CANCELED = new JobState (7); >>>> and interfaceName is DocAttribute.class where >>>> public interface DocAttribute extends Attribute {} >>>> ---------------------------------------------------------------- >>>> So we end up with >>>> (DocAttribute.class).isInstance(JobState.CANCELED) >>>> We have intrinsic for isInstance() for which we generated >>>> // Now load the mirror's klass metaobject, and null-check it. >>>> // Side-effects region with the control path if the klass is null. >>>> Node* kls = load_klass_from_mirror(mirror, never_see_null, nargs, >>>> region, _prim_path); >>>> case vmIntrinsics::_isInstance: >>>> // nothing is an instance of a primitive type >>>> query_value = gen_instanceof(obj, kls); >>>> where due to NULL check we have next CastPP for DocAttribute.class: >>>> [t at 19 l at 19]: print kls->dump(1) >>>> 390 LoadKlass === _ 7 389 [[ 391 396 ]] >>>> @rawptr:BotPTR, idx=Raw; # * Klass: * !jvms: >>>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>>> 395 IfTrue === 393 [[ 370 396 ]] #1 !jvms: >>>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>>> 396 CastPP === 395 390 [[ 409 409 413 432 427 ]] >>>> #klass java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/ >>>> Object: 0x0811c7e0 * !jvms: >>>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>>> During IGVN LoadKlass(390) transformed to constant klass which is >>>> interface: >>>> 702 ConP === 0 [[ 396 391 ]] #precise klass javax/print/ >>>> attribute/DocAttribute: 0x08407298:Constant:exact * >>>> Interface:precise klass javax/print/attribute/DocAttribute: >>>> 0x08407298:Constant:exact * >>>> 396 CastPP === 395 702 [[ 409 409 413 432 427 ]] >>>> #klass java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/ >>>> Object: 0x0811c7e0 * !jvms: >>>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>>> ConstraintCastNode::Value() calls TypeOopPtr::filter() method >>>> which, I think, returns incorrect result: >>>> [t at 19 l at 19]: print ft->dump() >>>> precise klass javax/print/attribute/DocAttribute: >>>> 0x08407298:Constant:exact * >>>> [t at 19 l at 19]: print ftkp->klass()->print() >>>> >>> loader=0x0 loaded=true initialized=false finalized=false >>>> subklass=false size=9 flags=public,interface,abstract >>>> mirror=PRESENT ident=655 PERM address=0x8407298> >>>> [t at 19 l at 19]: print ktkp->klass()->print() >>>> >>> initialized=true finalized=false subklass=true size=8 >>>> flags=public,super mirror=PRESENT ident=558 PERM >>>> address=0x811c7e0>ktkp->klass()->print() = (void) >>>> because of this code: >>>> // If we have an interface-typed Phi or cast and we narrow to a >>>> class type, >>>> // the join should report back the class. However, if we have a >>>> J/L/Object >>>> // class-typed Phi and an interface flows in, it's possible that >>>> the meet & >>>> // join report an interface back out. This isn't possible but >>>> happens >>>> // because the type system doesn't interact well with interfaces. >>>> if (ftkp != NULL && ktkp != NULL && >>>> ftkp->is_loaded() && ftkp->klass()->is_interface() && >>>> ktkp->is_loaded() && !ktkp->klass()->is_interface()) { >>>> // Happens in a CTW of rt.jar, 320-341, no extra flags >>>> return ktkp->cast_to_ptr_type(ftkp->ptr()); >>>> } >>>> the result is >>>> precise klass java/lang/Object: 0x0811c7e0:Constant:exact * >>>> which leads to incorrect result from CmpP node: >>>> 703 ConP === 0 [[ 704 432 704 ]] #precise klass java/ >>>> lang/Object: 0x0811c7e0:Constant:exact * Klass:precise klass >>>> java/lang/Object: 0x0811c7e0:Constant:exact * >>>> 704 CmpP === _ 703 703 [[ 705 ]] !orig=[413] !jvms: >>>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 From Vladimir.Kozlov at Sun.COM Mon Oct 26 22:22:55 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 26 Oct 2009 22:22:55 -0700 Subject: 6894807: problem with interfaces in C2 type system In-Reply-To: <6392CCBB-64DD-49BB-8B21-2F89B6C1208F@sun.com> References: <4AE287AB.2050006@sun.com> <4AE61D98.9050406@sun.com> <90A43170-33C5-4719-A342-E89667307530@sun.com> <4AE63F16.2090104@sun.com> <6392CCBB-64DD-49BB-8B21-2F89B6C1208F@sun.com> Message-ID: <4AE683AF.6020501@sun.com> John Rose wrote: > > 1. Is the second occurrence of this comment really true, or is it just a > copy of the first occurrence (from Tom's fix)? > // Happens in a CTW of rt.jar, 320-341, no extra flags I think, Tom just copied it. > > 2. Why doesn't the bug happen in the original code? Oh, right: An > object cannot have exactly an interface type. > > It's strange to have a phi with a constant type. Maybe the right answer > for a filter() query is, if the phi's type ('kill' arg) is a > Type::singleton, return it without further processing. It is not Phi but input ConP (interface.class) of CastPP (which came from null_check_common): 702 ConP === 0 [[ 396 391 ]] #precise klass javax/print/attribute/DocAttribute: 0x08407298:Constant:exact * Interface:precise klass javax/print/attribute/DocAttribute: 0x08407298:Constant:exact * 396 CastPP === 395 702 [[ 409 409 413 432 427 ]] #klass java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: 0x0811c7e0 * !jvms: AttributeSetUtilities::verifyAttributeValue @ bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 Vladimir > > -- John > > On Oct 26, 2009, at 8:30 PM, Vladimir Kozlov wrote: > >> Thanks, Tom >> >> I will do it. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> I think it should include an extra test of !ftkp->klass_is_exact(). >>> This will cause it to return ft which is the original precise type. >>> tom >>> On Oct 26, 2009, at 3:07 PM, Vladimir Kozlov wrote: >>>> John, Tom >>>> >>>> I need your help with this. >>>> >>>> The original implementation of TypeOopPtr::filter() was done by John >>>> and pushed by Ross for: >>>> >>>> 6467870: Fixes to monotonically narrow or widen types during igvn >>>> >>>> Ross Knippel wrote: >>>> > This change is from John Rose (I'm just the medium.) >>>> > It's a piece extracted from his current work. >>>> >>>> It did not have the bug's problem since an interface could not be >>>> exact. >>>> >>>> Then Tom added the klass part for: >>>> >>>> 6788347: C2Compiler crash 6u7 >>>> >>>> Which causes the problem since interface klass could be exact >>>> (constant, >>>> as in the bug's case) and casting j.l.O klass to interface's ptr >>>> returns incorrectly exact j.l.O klass: >>>> >>>> return ktkp->cast_to_ptr_type(ftkp->ptr()); >>>> >>>> The fix is either simple return original j.l.o klass: >>>> >>>> return kills; >>>> >>>> or cast to ptrs meet: >>>> >>>> return ktkp->cast_to_ptr_type(ktkp->meet_ptr(ftkp->ptr())); >>>> >>>> Both of them fixed the problem. But I am not sure since in >>>> both cases we loose the precision of interface klass which >>>> allows more ideal optimizations (for example, for CmpP). >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Vladimir Kozlov wrote: >>>>> I am investigating 6894807: No ClassCastException for >>>>> HashAttributeSet constructors if run with -Xcomp >>>>> Because of Escape Analysis is on by default all constructors are >>>>> inlined >>>>> in the test case and object scalar replaced. But due to, I think, >>>>> the problem in C2 type system the result is incorrect. >>>>> We should check if interface is exact before replacing >>>>> it with j.l.O in TypeOopPtr::filter() for the case >>>>> (exact interface klass)->filter(j.l.O klass). >>>>> Vladimir >>>>> ---------------------------------------------------------------- >>>>> Test code expects ClassCastException exception: >>>>> import javax.print.attribute.Attribute; >>>>> import javax.print.attribute.AttributeSet; >>>>> import javax.print.attribute.DocAttribute; >>>>> import javax.print.attribute.HashAttributeSet; >>>>> import javax.print.attribute.standard.JobState; >>>>> try { >>>>> new MyHashAttributeSet(JobState.CANCELED, >>>>> DocAttribute.class); >>>>> System.out.println("No ClassCastException in t2!"); >>>>> } catch (ClassCastException _) { >>>>> } >>>>> EA forces to inline all constructors for MyHashAttributeSet: >>>>> class MyHashAttributeSet extends HashAttributeSet{ >>>>> MyHashAttributeSet(Attribute attribute, >>>>> Class interfaceName){ >>>>> super(attribute, interfaceName); >>>>> } >>>>> then >>>>> protected HashAttributeSet(Attribute attribute, Class >>>>> interfaceName) { >>>>> if (interfaceName == null) { >>>>> throw new NullPointerException("null interface"); >>>>> } >>>>> myInterface = interfaceName; >>>>> add (attribute); >>>>> } >>>>> add() is inlined also: >>>>> public boolean add(Attribute attribute) { >>>>> Object oldAttribute = >>>>> attrMap.put(attribute.getCategory(), >>>>> AttributeSetUtilities. >>>>> verifyAttributeValue(attribute, myInterface)); >>>>> return (!attribute.equals(oldAttribute)); >>>>> } >>>>> and verifyAttributeValue(attribute, myInterface) is inlined as well: >>>>> public static Attribute >>>>> verifyAttributeValue(Object object, Class interfaceName) { >>>>> if (object == null) { >>>>> throw new NullPointerException(); >>>>> } >>>>> else if (interfaceName.isInstance (object)) { >>>>> return (Attribute) object; >>>>> } else { >>>>> throw new ClassCastException(); >>>>> } >>>>> } >>>>> object is JobState.CANCELED which is >>>>> public static final JobState CANCELED = new JobState (7); >>>>> and interfaceName is DocAttribute.class where >>>>> public interface DocAttribute extends Attribute {} >>>>> ---------------------------------------------------------------- >>>>> So we end up with >>>>> (DocAttribute.class).isInstance(JobState.CANCELED) >>>>> We have intrinsic for isInstance() for which we generated >>>>> // Now load the mirror's klass metaobject, and null-check it. >>>>> // Side-effects region with the control path if the klass is null. >>>>> Node* kls = load_klass_from_mirror(mirror, never_see_null, nargs, >>>>> region, _prim_path); >>>>> case vmIntrinsics::_isInstance: >>>>> // nothing is an instance of a primitive type >>>>> query_value = gen_instanceof(obj, kls); >>>>> where due to NULL check we have next CastPP for DocAttribute.class: >>>>> [t at 19 l at 19]: print kls->dump(1) >>>>> 390 LoadKlass === _ 7 389 [[ 391 396 ]] >>>>> @rawptr:BotPTR, idx=Raw; # * Klass: * !jvms: >>>>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>>>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>>>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>>>> 395 IfTrue === 393 [[ 370 396 ]] #1 !jvms: >>>>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>>>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>>>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>>>> 396 CastPP === 395 390 [[ 409 409 413 432 427 ]] #klass >>>>> java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: >>>>> 0x0811c7e0 * !jvms: AttributeSetUtilities::verifyAttributeValue @ >>>>> bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ >>>>> bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>>>> During IGVN LoadKlass(390) transformed to constant klass which is >>>>> interface: >>>>> 702 ConP === 0 [[ 396 391 ]] #precise klass >>>>> javax/print/attribute/DocAttribute: 0x08407298:Constant:exact * >>>>> Interface:precise klass javax/print/attribute/DocAttribute: >>>>> 0x08407298:Constant:exact * >>>>> 396 CastPP === 395 702 [[ 409 409 413 432 427 ]] #klass >>>>> java/lang/Object: 0x0811c7e0 * Klass:klass java/lang/Object: >>>>> 0x0811c7e0 * !jvms: AttributeSetUtilities::verifyAttributeValue @ >>>>> bci:14 HashAttributeSet::add @ bci:15 HashAttributeSet:: @ >>>>> bci:36 MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 >>>>> ConstraintCastNode::Value() calls TypeOopPtr::filter() method >>>>> which, I think, returns incorrect result: >>>>> [t at 19 l at 19]: print ft->dump() >>>>> precise klass javax/print/attribute/DocAttribute: >>>>> 0x08407298:Constant:exact * >>>>> [t at 19 l at 19]: print ftkp->klass()->print() >>>>> >>>> loaded=true initialized=false finalized=false subklass=false size=9 >>>>> flags=public,interface,abstract mirror=PRESENT ident=655 PERM >>>>> address=0x8407298> >>>>> [t at 19 l at 19]: print ktkp->klass()->print() >>>>> >>>> initialized=true finalized=false subklass=true size=8 >>>>> flags=public,super mirror=PRESENT ident=558 PERM >>>>> address=0x811c7e0>ktkp->klass()->print() = (void) >>>>> because of this code: >>>>> // If we have an interface-typed Phi or cast and we narrow to a >>>>> class type, >>>>> // the join should report back the class. However, if we have a >>>>> J/L/Object >>>>> // class-typed Phi and an interface flows in, it's possible that >>>>> the meet & >>>>> // join report an interface back out. This isn't possible but happens >>>>> // because the type system doesn't interact well with interfaces. >>>>> if (ftkp != NULL && ktkp != NULL && >>>>> ftkp->is_loaded() && ftkp->klass()->is_interface() && >>>>> ktkp->is_loaded() && !ktkp->klass()->is_interface()) { >>>>> // Happens in a CTW of rt.jar, 320-341, no extra flags >>>>> return ktkp->cast_to_ptr_type(ftkp->ptr()); >>>>> } >>>>> the result is >>>>> precise klass java/lang/Object: 0x0811c7e0:Constant:exact * >>>>> which leads to incorrect result from CmpP node: >>>>> 703 ConP === 0 [[ 704 432 704 ]] #precise klass >>>>> java/lang/Object: 0x0811c7e0:Constant:exact * Klass:precise klass >>>>> java/lang/Object: 0x0811c7e0:Constant:exact * >>>>> 704 CmpP === _ 703 703 [[ 705 ]] !orig=[413] !jvms: >>>>> AttributeSetUtilities::verifyAttributeValue @ bci:14 >>>>> HashAttributeSet::add @ bci:15 HashAttributeSet:: @ bci:36 >>>>> MyHashAttributeSet:: @ bci:3 InstanceCheck::t2 @ bci:10 > From John.Rose at Sun.COM Mon Oct 26 22:32:07 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 27 Oct 2009 01:32:07 -0400 Subject: 6894807: problem with interfaces in C2 type system In-Reply-To: <4AE683AF.6020501@sun.com> References: <4AE287AB.2050006@sun.com> <4AE61D98.9050406@sun.com> <90A43170-33C5-4719-A342-E89667307530@sun.com> <4AE63F16.2090104@sun.com> <6392CCBB-64DD-49BB-8B21-2F89B6C1208F@sun.com> <4AE683AF.6020501@sun.com> Message-ID: <0E680FFF-9C40-4E3F-B5B4-2215E8A3FA0C@Sun.COM> On Oct 27, 2009, at 1:22 AM, Vladimir Kozlov wrote: > It is not Phi but input ConP (interface.class) of CastPP (which came > from null_check_common): Same point for CastPP, but I had the roles of Object and exact interface types backwards. Thanks. -- John From Vladimir.Kozlov at Sun.COM Mon Oct 26 22:39:41 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 26 Oct 2009 22:39:41 -0700 Subject: 6894807: problem with interfaces in C2 type system In-Reply-To: <0E680FFF-9C40-4E3F-B5B4-2215E8A3FA0C@Sun.COM> References: <4AE287AB.2050006@sun.com> <4AE61D98.9050406@sun.com> <90A43170-33C5-4719-A342-E89667307530@sun.com> <4AE63F16.2090104@sun.com> <6392CCBB-64DD-49BB-8B21-2F89B6C1208F@sun.com> <4AE683AF.6020501@sun.com> <0E680FFF-9C40-4E3F-B5B4-2215E8A3FA0C@Sun.COM> Message-ID: <4AE6879D.5060404@sun.com> John, So do you agree with Tom suggestion?: return ft if ftkp->klass_is_exact(). Vladimir John Rose wrote: > On Oct 27, 2009, at 1:22 AM, Vladimir Kozlov wrote: > >> It is not Phi but input ConP (interface.class) of CastPP (which came >> from null_check_common): > > Same point for CastPP, but I had the roles of Object and exact interface > types backwards. Thanks. -- John From John.Rose at Sun.COM Mon Oct 26 23:23:33 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 27 Oct 2009 02:23:33 -0400 Subject: 6894807: problem with interfaces in C2 type system In-Reply-To: <4AE6879D.5060404@sun.com> References: <4AE287AB.2050006@sun.com> <4AE61D98.9050406@sun.com> <90A43170-33C5-4719-A342-E89667307530@sun.com> <4AE63F16.2090104@sun.com> <6392CCBB-64DD-49BB-8B21-2F89B6C1208F@sun.com> <4AE683AF.6020501@sun.com> <0E680FFF-9C40-4E3F-B5B4-2215E8A3FA0C@Sun.COM> <4AE6879D.5060404@sun.com> Message-ID: <2D3A4D9D-47C6-4E2C-9A61-4D2CB3138714@Sun.COM> On Oct 27, 2009, at 1:39 AM, Vladimir Kozlov wrote: > So do you agree with Tom suggestion?: return ft if ftkp- > >klass_is_exact(). If it fixes the bug, I guess it's OK. Letting the interface through the CastPP (or Phi) can cause other bugs to happen. (All of these bugs come from a flimsy representation of interfaces in Type.) Some of those CastPP guys are standing there to prevent interfaces and classes from mixing. But, in the case of a constant interface TypeKlassPtr, I don't see the harm in it. (Just watch the nightlies!) It bothers me to break the symmetry between the two cases (inst/ klass). The following change is equivalent (I think) to Tom's suggestion, and reads better to me: if (ft->empty()) { ... } + if (ft->singleton()) return ft; // If we have an interface-typed Phi ... In any case, leave a comment behind with the bug number. The next reader of the code will need lots of help. -- John P.S. My mental picture of Type is that it represents a set of assertions. Type Integer asserts {isa Integer, isa Number, isa Object, isa Serializable, isa Comparable}. Meet is set intersection, while join is set union. The following sets cannot be represented, but should be IMO: {isa Serializable, isa Comparable}, {isa Serializable}, {isa Comparable} (Some assertions can be negated also. An exact type C:exact asserts {! isa D} for every subclass D of C.) If TypeInstPtr could represent one class plus zero or more interfaces, we could (I think) get rid of a lot of this dancing around the snakepit. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20091027/748e1810/attachment.html From Christian.Thalinger at Sun.COM Tue Oct 27 11:02:20 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 27 Oct 2009 18:02:20 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6893554: SPECjvm2008 mpegaudio fails with SecurityException Message-ID: <20091027180227.6C0924141D@hg.openjdk.java.net> Changeset: f875b4f472f7 Author: twisti Date: 2009-10-27 03:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f875b4f472f7 6893554: SPECjvm2008 mpegaudio fails with SecurityException Summary: The problem occurs with negative numbers, as the 32-bit input values are sign extended into the 64-bit registers. Reviewed-by: kvn ! src/cpu/sparc/vm/sparc.ad From John.Cuthbertson at Sun.COM Tue Oct 27 15:10:23 2009 From: John.Cuthbertson at Sun.COM (john cuthbertson - Sun Microsystems) Date: Tue, 27 Oct 2009 15:10:23 -0700 Subject: [Fwd: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code"] Message-ID: <4AE76FCF.1000307@sun.com> Hi Everyone, I should have included the compiler alias on the attached review request. Can someone look over the changes? Thanks, JohnC -------- Original Message -------- Subject: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code" Date: Tue, 27 Oct 2009 14:51:46 -0700 From: john cuthbertson - Sun Microsystems To: hotspot-gc-dev at openjdk.java.net Hi Everyone, Can I have a couple of volunteers to review the proposed fix for this bug? The webrev can be found at http://cr.openjdk.java.net/~johnc/6889740/webrev.0/. The issue is that bad code was being generated for the store operation in the null case of the aastore bytecode template. The bad code was caused by there being only one version of the store_heap_oop routine that took a Register as the second argument. When the calling code passed in NULL_WORD (0) to this routine the value was used as a Register encoding and converted to Register(0), which is rax. Thus the generated store was "mov (dst), $rax" instead of "mov (dst), $0x0". This is normally not a problem as the preceding code in the template fetches the value to be stored into rax. When the G1 pre-barrier code calls the runtime, however, the value in rax can be overwritten and the heap can become corrupted. Testing: OpenDS, jprt, refworkload, and the GC test suite. Thanks, JohnC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20091027/d49d2c38/attachment.html From Vladimir.Kozlov at Sun.COM Tue Oct 27 17:19:23 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 27 Oct 2009 17:19:23 -0700 Subject: [Fwd: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code"] In-Reply-To: <4AE76FCF.1000307@sun.com> References: <4AE76FCF.1000307@sun.com> Message-ID: <4AE78E0B.8050503@sun.com> Thank you, John, for hunting down this difficult to find problem. Changes looks good. Did you thought to use int32_t imm32 instead of intptr_t src? I wonder if we have other places like this. For example, the next code in generate_exception_handler_common() uses NULL_WORD without casting to (int32_t): __ movptr(c_rarg2, NULL_WORD); but there is no void* dummy declaration for movptr(): void movptr(Register dst, intptr_t src); void movptr(Register dst, Register src); #ifdef _LP64 void movptr(Register dst, int32_t imm32); #endif // _LP64 Vladimir john cuthbertson - Sun Microsystems wrote: > Hi Everyone, > > I should have included the compiler alias on the attached review > request. Can someone look over the changes? > > Thanks, > > JohnC > > -------- Original Message -------- > Subject: Request for review (S): CR 6889740 - G1: OpenDS fails with > "unhandled exception in compiled code" > Date: Tue, 27 Oct 2009 14:51:46 -0700 > From: john cuthbertson - Sun Microsystems > To: hotspot-gc-dev at openjdk.java.net > > > > Hi Everyone, > > Can I have a couple of volunteers to review the proposed fix for this > bug? The webrev can be found at > http://cr.openjdk.java.net/~johnc/6889740/webrev.0/. > > The issue is that bad code was being generated for the store operation > in the null case of the aastore bytecode template. The bad code was > caused by there being only one version of the store_heap_oop routine > that took a Register as the second argument. When the calling code > passed in NULL_WORD (0) to this routine the value was used as a Register > encoding and converted to Register(0), which is rax. Thus the generated > store was "mov (dst), $rax" instead of "mov (dst), $0x0". This is > normally not a problem as the preceding code in the template fetches the > value to be stored into rax. When the G1 pre-barrier code calls the > runtime, however, the value in rax can be overwritten and the heap can > become corrupted. > > Testing: OpenDS, jprt, refworkload, and the GC test suite. > > Thanks, > > JohnC > From Christian.Thalinger at Sun.COM Wed Oct 28 01:36:12 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 28 Oct 2009 09:36:12 +0100 Subject: [Fwd: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code"] In-Reply-To: <4AE76FCF.1000307@sun.com> References: <4AE76FCF.1000307@sun.com> Message-ID: <1256718972.1703.14.camel@macbook> On Tue, 2009-10-27 at 15:10 -0700, john cuthbertson - Sun Microsystems wrote: > Can I have a couple of volunteers to review the proposed fix for this > bug? The webrev can be found at > http://cr.openjdk.java.net/~johnc/6889740/webrev.0/. > > The issue is that bad code was being generated for the store operation > in the null case of the aastore bytecode template. The bad code was > caused by there being only one version of the store_heap_oop routine > that took a Register as the second argument. When the calling code > passed in NULL_WORD (0) to this routine the value was used as a Register > encoding and converted to Register(0), which is rax. Thus the generated > store was "mov (dst), $rax" instead of "mov (dst), $0x0". This is > normally not a problem as the preceding code in the template fetches the > value to be stored into rax. When the G1 pre-barrier code calls the > runtime, however, the value in rax can be overwritten and the heap can > become corrupted. Why do you actually pass in a src and then assert on it's value? +void MacroAssembler::store_heap_oop(Address dst, intptr_t src) { + assert(src == NULL_WORD, "use something else otherwise"); It seems it must be null anyway and we could use something like: void MacroAssembler::store_heap_oop_null(Address dst) { -- Christian From John.Cuthbertson at Sun.COM Wed Oct 28 09:35:19 2009 From: John.Cuthbertson at Sun.COM (john cuthbertson - Sun Microsystems) Date: Wed, 28 Oct 2009 09:35:19 -0700 Subject: [Fwd: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code"] In-Reply-To: <1256718972.1703.14.camel@macbook> References: <4AE76FCF.1000307@sun.com> <1256718972.1703.14.camel@macbook> Message-ID: <4AE872C7.4000607@sun.com> Hi Christian, The main reason was just to avoid changing the call-sites and make it consistent with the other generator routines. I don't have a strong preference either way. Thanks for looking at the code, JohnC On 10/28/09 01:36, Christian Thalinger wrote: > On Tue, 2009-10-27 at 15:10 -0700, john cuthbertson - Sun Microsystems > wrote: > >> Can I have a couple of volunteers to review the proposed fix for this >> bug? The webrev can be found at >> http://cr.openjdk.java.net/~johnc/6889740/webrev.0/. >> >> The issue is that bad code was being generated for the store operation >> in the null case of the aastore bytecode template. The bad code was >> caused by there being only one version of the store_heap_oop routine >> that took a Register as the second argument. When the calling code >> passed in NULL_WORD (0) to this routine the value was used as a Register >> encoding and converted to Register(0), which is rax. Thus the generated >> store was "mov (dst), $rax" instead of "mov (dst), $0x0". This is >> normally not a problem as the preceding code in the template fetches the >> value to be stored into rax. When the G1 pre-barrier code calls the >> runtime, however, the value in rax can be overwritten and the heap can >> become corrupted. >> > > Why do you actually pass in a src and then assert on it's value? > > +void MacroAssembler::store_heap_oop(Address dst, intptr_t src) { > + assert(src == NULL_WORD, "use something else otherwise"); > > It seems it must be null anyway and we could use something like: > > void MacroAssembler::store_heap_oop_null(Address dst) { > > -- Christian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20091028/7c2946ea/attachment.html From Thomas.Rodriguez at Sun.COM Wed Oct 28 10:35:34 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 28 Oct 2009 10:35:34 -0700 Subject: [Fwd: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code"] In-Reply-To: <4AE872C7.4000607@sun.com> References: <4AE76FCF.1000307@sun.com> <1256718972.1703.14.camel@macbook> <4AE872C7.4000607@sun.com> Message-ID: But don't you need all three variants to turn this into a compile time problem? I'm ok with what you've done. You should note that the new variant is only there to deal with the use of NULL since all other oop constants should be using jobject. tom On Oct 28, 2009, at 9:35 AM, john cuthbertson - Sun Microsystems wrote: > Hi Christian, > > The main reason was just to avoid changing the call-sites and make > it consistent with the other generator routines. I don't have a > strong preference either way. > > Thanks for looking at the code, > > JohnC > > On 10/28/09 01:36, Christian Thalinger wrote: >> On Tue, 2009-10-27 at 15:10 -0700, john cuthbertson - Sun >> Microsystems >> wrote: >> >> >>> Can I have a couple of volunteers to review the proposed fix for >>> this >>> bug? The webrev can be found at >>> >>> http://cr.openjdk.java.net/~johnc/6889740/webrev.0/ >>> . >>> >>> The issue is that bad code was being generated for the store >>> operation >>> in the null case of the aastore bytecode template. The bad code was >>> caused by there being only one version of the store_heap_oop routine >>> that took a Register as the second argument. When the calling code >>> passed in NULL_WORD (0) to this routine the value was used as a >>> Register >>> encoding and converted to Register(0), which is rax. Thus the >>> generated >>> store was "mov (dst), $rax" instead of "mov (dst), $0x0". This is >>> normally not a problem as the preceding code in the template >>> fetches the >>> value to be stored into rax. When the G1 pre-barrier code calls the >>> runtime, however, the value in rax can be overwritten and the heap >>> can >>> become corrupted. >>> >>> >> >> Why do you actually pass in a src and then assert on it's value? >> >> +void MacroAssembler::store_heap_oop(Address dst, intptr_t src) { >> + assert(src == NULL_WORD, "use something else otherwise"); >> >> It seems it must be null anyway and we could use something like: >> >> void MacroAssembler::store_heap_oop_null(Address dst) { >> >> -- Christian >> >> >> > From John.Cuthbertson at Sun.COM Wed Oct 28 11:01:38 2009 From: John.Cuthbertson at Sun.COM (john cuthbertson - Sun Microsystems) Date: Wed, 28 Oct 2009 11:01:38 -0700 Subject: [Fwd: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code"] In-Reply-To: References: <4AE76FCF.1000307@sun.com> <1256718972.1703.14.camel@macbook> <4AE872C7.4000607@sun.com> Message-ID: <4AE88702.40605@sun.com> Hi Tom, I think you only need the additional variant that takes the void* in order to make this a compile time problem. Adding that prototype first flagged the other calls in do_oop_store as compile time errors. As long as we have that then any call to store_heap_oop added in the future would be caught. JohnC On 10/28/09 10:35, Tom Rodriguez wrote: > But don't you need all three variants to turn this into a compile time > problem? I'm ok with what you've done. You should note that the new > variant is only there to deal with the use of NULL since all other oop > constants should be using jobject. > > tom > > On Oct 28, 2009, at 9:35 AM, john cuthbertson - Sun Microsystems wrote: > >> Hi Christian, >> >> The main reason was just to avoid changing the call-sites and make it >> consistent with the other generator routines. I don't have a strong >> preference either way. >> >> Thanks for looking at the code, >> >> JohnC >> >> On 10/28/09 01:36, Christian Thalinger wrote: >>> On Tue, 2009-10-27 at 15:10 -0700, john cuthbertson - Sun Microsystems >>> wrote: >>> >>> >>>> Can I have a couple of volunteers to review the proposed fix for this >>>> bug? The webrev can be found at >>>> >>>> http://cr.openjdk.java.net/~johnc/6889740/webrev.0/ >>>> . >>>> >>>> The issue is that bad code was being generated for the store operation >>>> in the null case of the aastore bytecode template. The bad code was >>>> caused by there being only one version of the store_heap_oop routine >>>> that took a Register as the second argument. When the calling code >>>> passed in NULL_WORD (0) to this routine the value was used as a >>>> Register >>>> encoding and converted to Register(0), which is rax. Thus the >>>> generated >>>> store was "mov (dst), $rax" instead of "mov (dst), $0x0". This is >>>> normally not a problem as the preceding code in the template >>>> fetches the >>>> value to be stored into rax. When the G1 pre-barrier code calls the >>>> runtime, however, the value in rax can be overwritten and the heap can >>>> become corrupted. >>>> >>>> >>> >>> Why do you actually pass in a src and then assert on it's value? >>> >>> +void MacroAssembler::store_heap_oop(Address dst, intptr_t src) { >>> + assert(src == NULL_WORD, "use something else otherwise"); >>> >>> It seems it must be null anyway and we could use something like: >>> >>> void MacroAssembler::store_heap_oop_null(Address dst) { >>> >>> -- Christian >>> >>> >>> >> > From Christian.Thalinger at Sun.COM Wed Oct 28 11:48:17 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 28 Oct 2009 19:48:17 +0100 Subject: Request for reviews (L): 6893081: method handle & invokedynamic code needs additional cleanup (post 6815692, 6858164) In-Reply-To: <1256069437.820.123.camel@macbook> References: <1256069437.820.123.camel@macbook> Message-ID: <1256755697.3638.18.camel@macbook> On Tue, 2009-10-20 at 22:10 +0200, Christian Thalinger wrote: > This patch is one of the first ones: > > http://cr.openjdk.java.net/~twisti/6893081/webrev.01/ I fixed a small bug. Here is the updated webrev: http://cr.openjdk.java.net/~twisti/6893081/webrev.02/ -- Christian From Christian.Thalinger at Sun.COM Wed Oct 28 12:00:57 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 28 Oct 2009 20:00:57 +0100 Subject: Request for reviews (XL): 6829187: compiler optimizations required for JSR 292 Message-ID: <1256756457.3638.21.camel@macbook> This is the JSR 292 C2 compiler support: http://cr.openjdk.java.net/~twisti/6829187/webrev.01/ -- Christian From Christian.Thalinger at Sun.COM Wed Oct 28 12:06:25 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 28 Oct 2009 20:06:25 +0100 Subject: Request for reviews (XXL): 6893268: additional dynamic language related optimizations in C2 Message-ID: <1256756785.3638.23.camel@macbook> And this one adds C2 inlining support: http://cr.openjdk.java.net/~twisti/6893268/webrev.01/ -- Christian From John.Cuthbertson at Sun.COM Wed Oct 28 13:58:04 2009 From: John.Cuthbertson at Sun.COM (john cuthbertson - Sun Microsystems) Date: Wed, 28 Oct 2009 13:58:04 -0700 Subject: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code" In-Reply-To: <4AE76B72.1030002@sun.com> References: <4AE76B72.1030002@sun.com> Message-ID: <4AE8B05C.4040700@sun.com> Hi Everyone, I've tweaked the change based on feedback from Christian and Tom. The new webrev can be found here: http://cr.openjdk.java.net/~johnc/6889740/webrev.1/ Regards, JohnC On 10/27/09 14:51, john cuthbertson - Sun Microsystems wrote: > Hi Everyone, > > Can I have a couple of volunteers to review the proposed fix for this > bug? The webrev can be found at > http://cr.openjdk.java.net/~johnc/6889740/webrev.0/. > > The issue is that bad code was being generated for the store operation > in the null case of the aastore bytecode template. The bad code was > caused by there being only one version of the store_heap_oop routine > that took a Register as the second argument. When the calling code > passed in NULL_WORD (0) to this routine the value was used as a > Register encoding and converted to Register(0), which is rax. Thus the > generated store was "mov (dst), $rax" instead of "mov (dst), $0x0". > This is normally not a problem as the preceding code in the template > fetches the value to be stored into rax. When the G1 pre-barrier code > calls the runtime, however, the value in rax can be overwritten and > the heap can become corrupted. > > Testing: OpenDS, jprt, refworkload, and the GC test suite. > > Thanks, > > JohnC From Vladimir.Kozlov at Sun.COM Wed Oct 28 14:03:27 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 28 Oct 2009 14:03:27 -0700 Subject: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code" In-Reply-To: <4AE8B05C.4040700@sun.com> References: <4AE76B72.1030002@sun.com> <4AE8B05C.4040700@sun.com> Message-ID: <4AE8B19F.9040409@sun.com> Looks good. Vladimir john cuthbertson - Sun Microsystems wrote: > Hi Everyone, > > I've tweaked the change based on feedback from Christian and Tom. The > new webrev can be found here: > > http://cr.openjdk.java.net/~johnc/6889740/webrev.1/ > > Regards, > > JohnC > > On 10/27/09 14:51, john cuthbertson - Sun Microsystems wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers to review the proposed fix for this >> bug? The webrev can be found at >> http://cr.openjdk.java.net/~johnc/6889740/webrev.0/. >> >> The issue is that bad code was being generated for the store operation >> in the null case of the aastore bytecode template. The bad code was >> caused by there being only one version of the store_heap_oop routine >> that took a Register as the second argument. When the calling code >> passed in NULL_WORD (0) to this routine the value was used as a >> Register encoding and converted to Register(0), which is rax. Thus the >> generated store was "mov (dst), $rax" instead of "mov (dst), $0x0". >> This is normally not a problem as the preceding code in the template >> fetches the value to be stored into rax. When the G1 pre-barrier code >> calls the runtime, however, the value in rax can be overwritten and >> the heap can become corrupted. >> >> Testing: OpenDS, jprt, refworkload, and the GC test suite. >> >> Thanks, >> >> JohnC > From Ulf.Zibis at gmx.de Wed Oct 28 14:44:53 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 28 Oct 2009 22:44:53 +0100 Subject: Character.java methods are slower than Surrogate.java's Message-ID: <4AE8BB55.30506@gmx.de> Hi Christian, for a benchmark test I have replaced all sun.nio.cs.Surrogate methods in sun.nio.cs.ext.EUC_TW with corresponding ones from java.lang.Character. As result, the overall encoding performance was 10 % worse, so java.lang.Character's methods must be much worser. Can you have a look, if there is a chance to better optimize java.lang.Character methods from HotSpot compiler side. The interesting classes to compare are here: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/all-in-charsets/test/sun/nio/cs/ext/EUC_TW_xueming.java?rev=805&view=markup https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/all-in-charsets/test/sun/nio/cs/ext/EUC_TW_CharSurrogate.java?rev=805&view=markup https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/all-in-charsets/test/sun/nio/cs/ext/EUC_TWBenchmark.java?rev=805&view=markup https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/all-in-charsets/src/sun/nio/cs/ext/EUC_TW.java?rev=805&view=markup If you like to build the project, follow the instructions on https://java-nio-charset-enhanced.dev.java.net/ My Results (EUC_TW_xueming is current JDK-algorithm, compare to EUC_TW_CharSurrogate): EUC_TW 65536 ASCII chars in 315 ms encoded to 65536 bytes EUC_TW_CharSurrogate 65536 ASCII chars in 346 ms encoded to 65536 bytes EUC_TW_xueming 65536 ASCII chars in 290 ms encoded to 65536 bytes EUC_TW 65536 UniCodeBMP chars in 805 ms encoded to 231782 bytes EUC_TW_CharSurrogate 65536 UniCodeBMP chars in 810 ms encoded to 231782 bytes EUC_TW_xueming 65536 UniCodeBMP chars in 717 ms encoded to 231782 bytes EUC_TW 65536 UniCodeCJK chars in 580 ms encoded to 131072 bytes EUC_TW_CharSurrogate 65536 UniCodeCJK chars in 592 ms encoded to 131072 bytes EUC_TW_xueming 65536 UniCodeCJK chars in 473 ms encoded to 131072 bytes -Ulf From Vladimir.Kozlov at Sun.COM Wed Oct 28 16:13:21 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 28 Oct 2009 16:13:21 -0700 Subject: Request for reviews (S): 6892186: 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks Message-ID: <4AE8D011.1020503@sun.com> http://cr.openjdk.java.net/~kvn/6896084/webrev.00 Fixed 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks Problem: VM should reserve protected page below heap for compressed oops implicit null checks in compiled code (see 6716785). After zero based compressed oops changes (6791178) the page is not reserved because undefined narrow_oop_base (NULL by default) is used in ReservedHeapSpace() to determine if the page is needed. Solution: Set narrow_oop_base and narrow_oop_use_implicit_null_checks values according to compressed oops encoding mode in Universe::preferred_heap_base() which is called before ReservedHeapSpace() constructors. Reviewed by: Fix verified (y/n): y, test output Other testing: JPRT From Vladimir.Kozlov at Sun.COM Wed Oct 28 21:57:34 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 28 Oct 2009 21:57:34 -0700 Subject: Request for reviews .02 (M): 6829192: JSR 292 needs to support 64-bit x86 In-Reply-To: <1256229605.833.24.camel@macbook> References: <1256069092.820.117.camel@macbook> <4ADE5698.3080803@sun.com> <1256138115.21356.21.camel@macbook> <91C2A676-B8F8-4942-AAAD-4381F0CD3470@sun.com> <1256229605.833.24.camel@macbook> Message-ID: <4AE920BE.5010007@sun.com> Good. Vladimir Christian Thalinger wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~twisti/6829192/webrev.02/ > > I also added the comment in > InterpreterMacroAssembler::get_cache_index_at_bcp() to the 32-bit > version. > > -- Christian > From Christian.Thalinger at Sun.COM Thu Oct 29 01:50:14 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 29 Oct 2009 09:50:14 +0100 Subject: Request for reviews (S): 6892186: 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks In-Reply-To: <4AE8D011.1020503@sun.com> References: <4AE8D011.1020503@sun.com> Message-ID: <1256806214.3638.25.camel@macbook> On Wed, 2009-10-28 at 16:13 -0700, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6896084/webrev.00 > > Fixed 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks > > Problem: > VM should reserve protected page below heap for compressed oops > implicit null checks in compiled code (see 6716785). > After zero based compressed oops changes (6791178) the page is > not reserved because undefined narrow_oop_base (NULL by default) > is used in ReservedHeapSpace() to determine if the page is needed. > > Solution: > Set narrow_oop_base and narrow_oop_use_implicit_null_checks > values according to compressed oops encoding mode in > Universe::preferred_heap_base() which is called before > ReservedHeapSpace() constructors. Using size_t for base (which is an address) feels a little strange but otherwise looks good. -- Christian From Christian.Thalinger at Sun.COM Thu Oct 29 02:32:06 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 29 Oct 2009 10:32:06 +0100 Subject: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code" In-Reply-To: <4AE8B05C.4040700@sun.com> References: <4AE76B72.1030002@sun.com> <4AE8B05C.4040700@sun.com> Message-ID: <1256808726.3638.31.camel@macbook> On Wed, 2009-10-28 at 13:58 -0700, john cuthbertson - Sun Microsystems wrote: > Hi Everyone, > > I've tweaked the change based on feedback from Christian and Tom. The > new webrev can be found here: > > http://cr.openjdk.java.net/~johnc/6889740/webrev.1/ Looks good. -- Christian From Roland.Westrelin at Sun.COM Thu Oct 29 03:22:44 2009 From: Roland.Westrelin at Sun.COM (Roland Westrelin) Date: Thu, 29 Oct 2009 11:22:44 +0100 Subject: Request for reviews (M): 6769124 various 64-bit fixes for c1 Message-ID: http://cr.openjdk.java.net/~roland/6769124/webrev.00/ These are 64-bit fixes to c1 that were first performed as part of the RTS development. The problems are listed in the CR (linked from the webrev). Each fix is relatively simple but there are 10 or so in the webrev. Tests are included for the bugs that can't be reproduced with existing tests. Roland. From Vladimir.Kozlov at Sun.COM Thu Oct 29 10:09:27 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 29 Oct 2009 10:09:27 -0700 Subject: Request for reviews (S): 6892186: 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks In-Reply-To: <1256806214.3638.25.camel@macbook> References: <4AE8D011.1020503@sun.com> <1256806214.3638.25.camel@macbook> Message-ID: <4AE9CC47.7050602@sun.com> Thank you, Christian I will change the type to address. Vladimir Christian Thalinger wrote: > On Wed, 2009-10-28 at 16:13 -0700, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6896084/webrev.00 >> >> Fixed 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks >> >> Problem: >> VM should reserve protected page below heap for compressed oops >> implicit null checks in compiled code (see 6716785). >> After zero based compressed oops changes (6791178) the page is >> not reserved because undefined narrow_oop_base (NULL by default) >> is used in ReservedHeapSpace() to determine if the page is needed. >> >> Solution: >> Set narrow_oop_base and narrow_oop_use_implicit_null_checks >> values according to compressed oops encoding mode in >> Universe::preferred_heap_base() which is called before >> ReservedHeapSpace() constructors. > > Using size_t for base (which is an address) feels a little strange but > otherwise looks good. > > -- Christian > From Vladimir.Kozlov at Sun.COM Thu Oct 29 10:20:11 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 29 Oct 2009 10:20:11 -0700 Subject: Request for reviews (S): 6892186: 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks In-Reply-To: <4AE9CC47.7050602@sun.com> References: <4AE8D011.1020503@sun.com> <1256806214.3638.25.camel@macbook> <4AE9CC47.7050602@sun.com> Message-ID: <4AE9CECB.9040605@sun.com> I am taking this back. It will require adding the cast in all expressions with this variable. I will keep it as it was. Vladimir Vladimir Kozlov wrote: > Thank you, Christian > > I will change the type to address. > > Vladimir > > Christian Thalinger wrote: >> On Wed, 2009-10-28 at 16:13 -0700, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6896084/webrev.00 >>> >>> Fixed 6896084: VM does not reserve protected page below heap for >>> compressed oops implicit null checks >>> >>> Problem: >>> VM should reserve protected page below heap for compressed oops >>> implicit null checks in compiled code (see 6716785). >>> After zero based compressed oops changes (6791178) the page is >>> not reserved because undefined narrow_oop_base (NULL by default) >>> is used in ReservedHeapSpace() to determine if the page is needed. >>> >>> Solution: >>> Set narrow_oop_base and narrow_oop_use_implicit_null_checks >>> values according to compressed oops encoding mode in >>> Universe::preferred_heap_base() which is called before >>> ReservedHeapSpace() constructors. >> >> Using size_t for base (which is an address) feels a little strange but >> otherwise looks good. >> >> -- Christian >> From Christian.Thalinger at Sun.COM Thu Oct 29 12:02:11 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 29 Oct 2009 20:02:11 +0100 Subject: Request for reviews (S): 6892186: 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks In-Reply-To: <4AE9CECB.9040605@sun.com> References: <4AE8D011.1020503@sun.com> <1256806214.3638.25.camel@macbook> <4AE9CC47.7050602@sun.com> <4AE9CECB.9040605@sun.com> Message-ID: <1256842931.912.0.camel@macbook> On Thu, 2009-10-29 at 10:20 -0700, Vladimir Kozlov wrote: > I am taking this back. It will require adding > the cast in all expressions with this variable. > I will keep it as it was. OK. Maybe uintptr_t? ;-) Nevermind. -- Christian From Thomas.Rodriguez at Sun.COM Thu Oct 29 13:52:42 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 29 Oct 2009 13:52:42 -0700 Subject: Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code" In-Reply-To: <4AE8B05C.4040700@sun.com> References: <4AE76B72.1030002@sun.com> <4AE8B05C.4040700@sun.com> Message-ID: <57030A29-818D-48FB-8AD2-977A34C6F8A0@sun.com> looks good. tom On Oct 28, 2009, at 1:58 PM, john cuthbertson - Sun Microsystems wrote: > Hi Everyone, > > I've tweaked the change based on feedback from Christian and Tom. > The new webrev can be found here: > > http://cr.openjdk.java.net/~johnc/6889740/webrev.1/ > > Regards, > > JohnC > > On 10/27/09 14:51, john cuthbertson - Sun Microsystems wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers to review the proposed fix for >> this bug? The webrev can be found at http://cr.openjdk.java.net/~johnc/6889740/webrev.0/ >> . >> >> The issue is that bad code was being generated for the store >> operation in the null case of the aastore bytecode template. The >> bad code was caused by there being only one version of the >> store_heap_oop routine that took a Register as the second argument. >> When the calling code passed in NULL_WORD (0) to this routine the >> value was used as a Register encoding and converted to Register(0), >> which is rax. Thus the generated store was "mov (dst), $rax" >> instead of "mov (dst), $0x0". This is normally not a problem as the >> preceding code in the template fetches the value to be stored into >> rax. When the G1 pre-barrier code calls the runtime, however, the >> value in rax can be overwritten and the heap can become corrupted. >> >> Testing: OpenDS, jprt, refworkload, and the GC test suite. >> >> Thanks, >> >> JohnC > From Changpeng.Fang at Sun.COM Thu Oct 29 17:04:57 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Thu, 29 Oct 2009 17:04:57 -0700 Subject: Request for Review (S) 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck tests crashes or make tnameserv crash In-Reply-To: <4AEA1E1B.6020302@sun.com> References: <494140A6.2070703@sun.com> <49A59C83.5030406@Sun.COM> <894501F8-FA27-42C9-9BBD-EFAC7166B4A4@Sun.COM> <49A5A963.6020701@Sun.COM> <3ADCAF44-7AC1-4F59-9B60-0FAE71184D8C@Sun.COM> <49A82387.4060902@Sun.COM> <49A82929.2070305@Sun.COM> <546A5F65-EA0D-4752-B4B3-2F745866C1A1@Sun.COM> <49CC1575.6020505@Sun.COM> <4AE6380F.6000308@sun.com> <4AEA1E1B.6020302@sun.com> Message-ID: <4AEA2DA9.7020204@sun.com> Was sent to the gc mailing list. Resend to the correct compiler list. Thanks, > http://cr.openjdk.java.net/~cfang/6852078/webrev.00/ > > Note that I am requesting for change to the current jdk source (For > the SubCR) > > 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck > tests crashes or make tnameserv crash > > Problem: Current implementation of superword optimization does not > check for unsafe memory accesses. Since > unsafe memory accesses could not be aligned appropriately without > runtime checking, a un-aligned superword > read/write could cause runtime failure. > > Solution: Simply disable superword for unsafe memory access whose base > is top. > > Tests: Test case in 6852078 > > Thanks, > > Changpeng > > From Vladimir.Kozlov at Sun.COM Thu Oct 29 17:18:29 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 29 Oct 2009 17:18:29 -0700 Subject: Request for Review (S) 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck tests crashes or make tnameserv crash In-Reply-To: <4AEA2DA9.7020204@sun.com> References: <494140A6.2070703@sun.com> <49A59C83.5030406@Sun.COM> <894501F8-FA27-42C9-9BBD-EFAC7166B4A4@Sun.COM> <49A5A963.6020701@Sun.COM> <3ADCAF44-7AC1-4F59-9B60-0FAE71184D8C@Sun.COM> <49A82387.4060902@Sun.COM> <49A82929.2070305@Sun.COM> <546A5F65-EA0D-4752-B4B3-2F745866C1A1@Sun.COM> <49CC1575.6020505@Sun.COM> <4AE6380F.6000308@sun.com> <4AEA1E1B.6020302@sun.com> <4AEA2DA9.7020204@sun.com> Message-ID: <4AEA30D5.30202@sun.com> I don't think having assert there is correct since there is nothing wrong with ideal graph. Vladimir Changpeng Fang wrote: > Was sent to the gc mailing list. Resend to the correct compiler list. > Thanks, > >> http://cr.openjdk.java.net/~cfang/6852078/webrev.00/ >> >> Note that I am requesting for change to the current jdk source (For >> the SubCR) >> >> 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck >> tests crashes or make tnameserv crash >> >> Problem: Current implementation of superword optimization does not >> check for unsafe memory accesses. Since >> unsafe memory accesses could not be aligned appropriately without >> runtime checking, a un-aligned superword >> read/write could cause runtime failure. >> >> Solution: Simply disable superword for unsafe memory access whose base >> is top. >> >> Tests: Test case in 6852078 >> >> Thanks, >> >> Changpeng >> >> > From Changpeng.Fang at Sun.COM Thu Oct 29 17:36:43 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Thu, 29 Oct 2009 17:36:43 -0700 Subject: Request for Review (S) 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck tests crashes or make tnameserv crash In-Reply-To: <4AEA30D5.30202@sun.com> References: <494140A6.2070703@sun.com> <49A59C83.5030406@Sun.COM> <894501F8-FA27-42C9-9BBD-EFAC7166B4A4@Sun.COM> <49A5A963.6020701@Sun.COM> <3ADCAF44-7AC1-4F59-9B60-0FAE71184D8C@Sun.COM> <49A82387.4060902@Sun.COM> <49A82929.2070305@Sun.COM> <546A5F65-EA0D-4752-B4B3-2F745866C1A1@Sun.COM> <49CC1575.6020505@Sun.COM> <4AE6380F.6000308@sun.com> <4AEA1E1B.6020302@sun.com> <4AEA2DA9.7020204@sun.com> <4AEA30D5.30202@sun.com> Message-ID: <4AEA351B.9010002@sun.com> On 10/29/09 17:18, Vladimir Kozlov wrote: > I don't think having assert there is correct > since there is nothing wrong with ideal graph. > 1924 //unsafe reference could not be aligned appropriately without runtime checking 1925 if (base == NULL || base->bottom_type() == Type::TOP) { 1926 assert(!valid(), "unsafe access"); 1927 return; 1928 } The assert is nothing related to ideal graph. It just makes sure that the SWPointer returned from here is not useable. You may see many places that use SWPointer::valid() checking before doing actual thing (alignment, for example). Thanks, Changpeng > Vladimir > > Changpeng Fang wrote: >> Was sent to the gc mailing list. Resend to the correct compiler >> list. Thanks, >> >>> http://cr.openjdk.java.net/~cfang/6852078/webrev.00/ >>> >>> Note that I am requesting for change to the current jdk source (For >>> the SubCR) >>> >>> 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck >>> tests crashes or make tnameserv crash >>> >>> Problem: Current implementation of superword optimization does not >>> check for unsafe memory accesses. Since >>> unsafe memory accesses could not be aligned appropriately without >>> runtime checking, a un-aligned superword >>> read/write could cause runtime failure. >>> >>> Solution: Simply disable superword for unsafe memory access whose >>> base is top. >>> >>> Tests: Test case in 6852078 >>> >>> Thanks, >>> >>> Changpeng >>> >>> >> From Vladimir.Kozlov at Sun.COM Thu Oct 29 17:40:59 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 29 Oct 2009 17:40:59 -0700 Subject: Request for Review (S) 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck tests crashes or make tnameserv crash In-Reply-To: <4AEA351B.9010002@sun.com> References: <494140A6.2070703@sun.com> <49A59C83.5030406@Sun.COM> <894501F8-FA27-42C9-9BBD-EFAC7166B4A4@Sun.COM> <49A5A963.6020701@Sun.COM> <3ADCAF44-7AC1-4F59-9B60-0FAE71184D8C@Sun.COM> <49A82387.4060902@Sun.COM> <49A82929.2070305@Sun.COM> <546A5F65-EA0D-4752-B4B3-2F745866C1A1@Sun.COM> <49CC1575.6020505@Sun.COM> <4AE6380F.6000308@sun.com> <4AEA1E1B.6020302@sun.com> <4AEA2DA9.7020204@sun.com> <4AEA30D5.30202@sun.com> <4AEA351B.9010002@sun.com> Message-ID: <4AEA361B.1040703@sun.com> OK. Vladimir Changpeng Fang wrote: > On 10/29/09 17:18, Vladimir Kozlov wrote: >> I don't think having assert there is correct >> since there is nothing wrong with ideal graph. >> > 1924 //unsafe reference could not be aligned appropriately without > runtime checking > 1925 if (base == NULL || base->bottom_type() == Type::TOP) { > 1926 assert(!valid(), "unsafe access"); > 1927 return; > 1928 } > > > The assert is nothing related to ideal graph. It just makes sure that > the SWPointer returned from > here is not useable. You may see many places that use SWPointer::valid() > checking before doing > actual thing (alignment, for example). > > Thanks, > > Changpeng > > >> Vladimir >> >> Changpeng Fang wrote: >>> Was sent to the gc mailing list. Resend to the correct compiler >>> list. Thanks, >>> >>>> http://cr.openjdk.java.net/~cfang/6852078/webrev.00/ >>>> >>>> Note that I am requesting for change to the current jdk source (For >>>> the SubCR) >>>> >>>> 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck >>>> tests crashes or make tnameserv crash >>>> >>>> Problem: Current implementation of superword optimization does not >>>> check for unsafe memory accesses. Since >>>> unsafe memory accesses could not be aligned appropriately without >>>> runtime checking, a un-aligned superword >>>> read/write could cause runtime failure. >>>> >>>> Solution: Simply disable superword for unsafe memory access whose >>>> base is top. >>>> >>>> Tests: Test case in 6852078 >>>> >>>> Thanks, >>>> >>>> Changpeng >>>> >>>> >>> > From Changpeng.Fang at Sun.COM Thu Oct 29 18:41:53 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Thu, 29 Oct 2009 18:41:53 -0700 Subject: Request for Review (S) 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck tests crashes or make tnameserv crash In-Reply-To: <4AEA2DA9.7020204@sun.com> References: <494140A6.2070703@sun.com> <49A59C83.5030406@Sun.COM> <894501F8-FA27-42C9-9BBD-EFAC7166B4A4@Sun.COM> <49A5A963.6020701@Sun.COM> <3ADCAF44-7AC1-4F59-9B60-0FAE71184D8C@Sun.COM> <49A82387.4060902@Sun.COM> <49A82929.2070305@Sun.COM> <546A5F65-EA0D-4752-B4B3-2F745866C1A1@Sun.COM> <49CC1575.6020505@Sun.COM> <4AE6380F.6000308@sun.com> <4AEA1E1B.6020302@sun.com> <4AEA2DA9.7020204@sun.com> Message-ID: <4AEA4461.5040008@sun.com> http://cr.openjdk.java.net/~cfang/6852078/webrev.01/ Kevin developed a very nice small test case to expose the problem (many Thanks!! -- it makes life much easier). I included it in the regression test (webrev.01 is the update). Thanks, Changpeng On 10/29/09 17:04, Changpeng Fang wrote: > Was sent to the gc mailing list. Resend to the correct compiler list. > Thanks, > >> http://cr.openjdk.java.net/~cfang/6852078/webrev.00/ >> >> Note that I am requesting for change to the current jdk source (For >> the SubCR) >> >> 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck >> tests crashes or make tnameserv crash >> >> Problem: Current implementation of superword optimization does not >> check for unsafe memory accesses. Since >> unsafe memory accesses could not be aligned appropriately without >> runtime checking, a un-aligned superword >> read/write could cause runtime failure. >> >> Solution: Simply disable superword for unsafe memory access whose >> base is top. >> >> Tests: Test case in 6852078 >> >> Thanks, >> >> Changpeng >> >> > From changpeng.fang at sun.com Thu Oct 29 19:08:00 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Fri, 30 Oct 2009 02:08:00 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 20 new changesets Message-ID: <20091030020841.D6D3341809@hg.openjdk.java.net> Changeset: 8afee153274a Author: jcoomes Date: 2009-10-05 05:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8afee153274a 6887948: test/gc/6845368/bigobj.java fails due to timeout Reviewed-by: iveresov ! test/gc/6845368/bigobj.java Changeset: 035d2e036a9b Author: tonyp Date: 2009-10-02 16:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/035d2e036a9b 6885041: G1: inconsistent thread dump Summary: When G1 is enabled, thread dumps are inconsistent as the info for some of the G1 threads is not formatted properly. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: ff2402f6a50b Author: tonyp Date: 2009-10-02 16:20 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ff2402f6a50b 6882730: G1: parallel heap verification messes up region dump Summary: It tidies up the G1 heap verification a bit. In particular, when the verification is done in parallel and there is a failure, this is propagated to the top level and the heap is dumped at the end, not by every thread that encounters a failure. Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 1f19207eefc2 Author: tonyp Date: 2009-10-05 12:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1f19207eefc2 6847956: G1: crash in oopDesc*G1ParCopyHelper::copy_to_survivor_space(oopDesc*) Summary: When we copy objects to survivors during marking, we incorrectly set NTAMS to bottom, which causes marking to miss visiting some of those objects. Reviewed-by: apetrusenko, iveresov ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 4c3458a31e17 Author: tonyp Date: 2009-10-07 09:42 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4c3458a31e17 6888316: G1: has_aborted() || _cm->region_stack_empty() fails Summary: Remove incorrect guarantee. Reviewed-by: apetrusenko, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 11d4857fe5e1 Author: tonyp Date: 2009-10-07 10:09 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/11d4857fe5e1 6888619: G1: too many guarantees in concurrent marking Summary: change more guarantees in concurrent marking into asserts. Reviewed-by: apetrusenko, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 2c03ce058f55 Author: bobv Date: 2009-10-07 09:48 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2c03ce058f55 6888847: TaskQueue needs release_store() for correctness on RMO machines Summary: See title. Reviewed-by: jmasa, ysr, jcoomes, iveresov, tonyp ! src/share/vm/utilities/taskqueue.hpp Changeset: 1ee412f7fec9 Author: tonyp Date: 2009-10-07 19:01 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1ee412f7fec9 6866190: Remove SIMPLE_STACK code from TaskQueue Summary: What the title says. We don't use SIMPLE_STACK any more. Reviewed-by: ysr ! src/share/vm/utilities/taskqueue.hpp Changeset: f99f695bb8ef Author: tonyp Date: 2009-10-19 17:02 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f99f695bb8ef Merge ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp Changeset: 39b01ab7035a Author: ysr Date: 2009-10-16 02:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/39b01ab7035a 6888898: CMS: ReduceInitialCardMarks unsafe in the presence of cms precleaning 6889757: G1: enable card mark elision for initializing writes from compiled code (ReduceInitialCardMarks) Summary: Defer the (compiler-elided) card-mark upon a slow-path allocation until after the store and before the next subsequent safepoint; G1 now answers yes to can_elide_tlab_write_barriers(). Reviewed-by: jcoomes, kvn, never ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 052a899eec3e Author: ysr Date: 2009-10-20 00:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/052a899eec3e 6892749: assert(UseParNewGC || UseSerialGC || UseConcMarkSweepGC, "...") fails Summary: Removed the assert: UseSerialGC is not necessarily always set when serial gc is being used. Reviewed-by: jcoomes, jmasa, tonyp ! src/share/vm/memory/genCollectedHeap.hpp Changeset: b0b36f0de97e Author: tonyp Date: 2009-10-20 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b0b36f0de97e Merge Changeset: dfdaf65c3423 Author: apetrusenko Date: 2009-10-22 07:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dfdaf65c3423 6858886: G1: guarantee(_next_marked_bytes <= used(),"invariant") at heapRegion.hpp:359 Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 67a9176de85c Author: trims Date: 2009-10-23 14:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/67a9176de85c 6894844: Bump the HS17 build number to 04 Summary: Update the HS17 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 411c9c4ca96a Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/411c9c4ca96a Added tag jdk7-b74 for changeset f4b900403d6e ! .hgtags Changeset: d8dd291a362a Author: trims Date: 2009-10-23 14:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d8dd291a362a Merge Changeset: 08780c8a9f04 Author: kamg Date: 2009-10-20 16:34 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/08780c8a9f04 6893483: DTrace probe return values for a couple JNI methods are wrong Summary: Fix the shadowing and incorrect macro usages Reviewed-by: coleenp ! src/share/vm/prims/jni.cpp Changeset: a3b9e96881fe Author: xlu Date: 2009-10-23 18:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a3b9e96881fe Merge Changeset: d912f17c1ae4 Author: xlu Date: 2009-10-28 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d912f17c1ae4 Merge Changeset: 4926bf2d292f Author: cfang Date: 2009-10-29 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4926bf2d292f Merge From vladimir.kozlov at sun.com Thu Oct 29 21:42:43 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 30 Oct 2009 04:42:43 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks Message-ID: <20091030044246.852BC41835@hg.openjdk.java.net> Changeset: f334aec453a1 Author: kvn Date: 2009-10-29 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f334aec453a1 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks Summary: Set narrow_oop_base and narrow_oop_use_implicit_null_checks in Universe::preferred_heap_base(). Reviewed-by: twisti, jcoomes ! src/share/vm/memory/universe.cpp From Paul.Hohensee at Sun.COM Fri Oct 30 07:48:32 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 30 Oct 2009 10:48:32 -0400 Subject: Request for Review (S) 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck tests crashes or make tnameserv crash In-Reply-To: <4AEA361B.1040703@sun.com> References: <494140A6.2070703@sun.com> <49A59C83.5030406@Sun.COM> <894501F8-FA27-42C9-9BBD-EFAC7166B4A4@Sun.COM> <49A5A963.6020701@Sun.COM> <3ADCAF44-7AC1-4F59-9B60-0FAE71184D8C@Sun.COM> <49A82387.4060902@Sun.COM> <49A82929.2070305@Sun.COM> <546A5F65-EA0D-4752-B4B3-2F745866C1A1@Sun.COM> <49CC1575.6020505@Sun.COM> <4AE6380F.6000308@sun.com> <4AEA1E1B.6020302@sun.com> <4AEA2DA9.7020204@sun.com> <4AEA30D5.30202@sun.com> <4AEA351B.9010002@sun.com> <4AEA361B.1040703@sun.com> Message-ID: <4AEAFCC0.20208@sun.com> Looks ok to me also. Paul Vladimir Kozlov wrote: > OK. > > Vladimir > > Changpeng Fang wrote: >> On 10/29/09 17:18, Vladimir Kozlov wrote: >>> I don't think having assert there is correct >>> since there is nothing wrong with ideal graph. >>> >> 1924 //unsafe reference could not be aligned appropriately without >> runtime checking >> 1925 if (base == NULL || base->bottom_type() == Type::TOP) { >> 1926 assert(!valid(), "unsafe access"); >> 1927 return; >> 1928 } >> >> >> The assert is nothing related to ideal graph. It just makes sure that >> the SWPointer returned from >> here is not useable. You may see many places that use >> SWPointer::valid() checking before doing >> actual thing (alignment, for example). >> >> Thanks, >> >> Changpeng >> >> >>> Vladimir >>> >>> Changpeng Fang wrote: >>>> Was sent to the gc mailing list. Resend to the correct compiler >>>> list. Thanks, >>>> >>>>> http://cr.openjdk.java.net/~cfang/6852078/webrev.00/ >>>>> >>>>> Note that I am requesting for change to the current jdk source >>>>> (For the SubCR) >>>>> >>>>> 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg >>>>> jck tests crashes or make tnameserv crash >>>>> >>>>> Problem: Current implementation of superword optimization does not >>>>> check for unsafe memory accesses. Since >>>>> unsafe memory accesses could not be aligned appropriately without >>>>> runtime checking, a un-aligned superword >>>>> read/write could cause runtime failure. >>>>> >>>>> Solution: Simply disable superword for unsafe memory access whose >>>>> base is top. >>>>> >>>>> Tests: Test case in 6852078 >>>>> >>>>> Thanks, >>>>> >>>>> Changpeng >>>>> >>>>> >>>> >> From changpeng.fang at sun.com Fri Oct 30 12:36:18 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Fri, 30 Oct 2009 19:36:18 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck tests crashes or make tnameserv crash Message-ID: <20091030193623.B1DDC4192D@hg.openjdk.java.net> Changeset: 73a726751507 Author: cfang Date: 2009-10-30 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/73a726751507 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck tests crashes or make tnameserv crash Summary: Disable SuperWord optimization for unsafe read/write Reviewed-by: kvn, phh ! src/share/vm/opto/superword.cpp + test/compiler/6852078/Test6852078.java From Thomas.Rodriguez at Sun.COM Fri Oct 30 12:44:03 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 30 Oct 2009 12:44:03 -0700 Subject: Request for reviews (M): 6769124 various 64-bit fixes for c1 In-Reply-To: References: Message-ID: <3391688B-022D-432F-8CF2-028D35C83FD4@sun.com> Looks good. Thanks from bringing these over. tom On Oct 29, 2009, at 3:22 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/6769124/webrev.00/ > > These are 64-bit fixes to c1 that were first performed as part of > the RTS development. The problems are listed in the CR (linked from > the webrev). Each fix is relatively simple but there are 10 or so in > the webrev. Tests are included for the bugs that can't be reproduced > with existing tests. > > Roland. > From john.rose at sun.com Fri Oct 30 15:59:11 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 30 Oct 2009 22:59:11 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 6891770: JSR 292 API needs initial unit tests Message-ID: <20091030225945.7749341969@hg.openjdk.java.net> Changeset: 9c352f7ed4a3 Author: jrose Date: 2009-10-21 23:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9c352f7ed4a3 6891770: JSR 292 API needs initial unit tests Summary: backport working mlvm regression test to M3 implementation of JSR 292; requires jtreg 4.1 Reviewed-by: twisti + test/java/dyn/MethodHandlesTest.java From john.rose at sun.com Fri Oct 30 21:27:24 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 31 Oct 2009 04:27:24 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6858164: invokedynamic code needs some cleanup (post-6655638) Message-ID: <20091031042726.4B128419D4@hg.openjdk.java.net> Changeset: 389049f3f393 Author: jrose Date: 2009-10-30 16:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/389049f3f393 6858164: invokedynamic code needs some cleanup (post-6655638) Summary: Fix several crashers, remove needless paths for boxed-style bootstrap method call, refactor & simplify APIs for rewriter constantPoolOop, remove sun.dyn.CallSiteImpl Reviewed-by: kvn ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp