From volker.simonis at gmail.com Tue Sep 1 01:54:53 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 1 Sep 2009 10:54:53 +0200 Subject: Change 6420645 causes SIGBUS during deoptimisation at a safepoint on 64bit-SPARC In-Reply-To: <4A9C502E.1070205@sun.com> References: <4A9C502E.1070205@sun.com> Message-ID: Intuitively I would prefer the new implementation and would rather fix the problem by changing the VMReg numbering in sparc.ad if this doesn't hurt otherwise. If the new implementation is not necessary for compressed oops, I think it may be at least necessary if one would implement 'float_in_double' on Sparc eventually. Could you please send me the Bug-ID of this issue once you found/created it? Thank you and best regards, Volker On 9/1/09, Coleen Phillimore wrote: > > Hi, > > The code that is causing this crash was changed during development of > compressed oops and I erroneously thought it was equivalent to the original > code, and I found it easier to understand, so I checked it in. > So no, there was no rationale behind this change to make compressed oops > work. It should be backed out (and your test added to our test system). I > will file a new bug if there isn't one already. > As far as the strange encoding of floating point registers on sparc, I > don't know the rationale behind it. Maybe someone on the compiler mailing > list can answer that. > > Thank you for finding this. > Coleen > > > Volker Simonis wrote: > > > Hi Coleen, > > > > I discovered a problem during deoptimisation at a safepoint which > > leads to a SIGBUS on 64bit-SPARC. The problem was introduced by the > > change "6420645: Create a vm that uses compressed oops for up to 32gb > > heapsizes" which has been submitted by you. The problem is easily > > reproducible with the attached test program. Just run: > > > > java -d64 -server -showversion -Xcomp -Xbatch > > "-XX:CompileCommand=compileonly DeoptTest > > deopt_compiledframe_at_safepoint" -XX:+PrintCompilation > DeoptTest > > > > and you will get a VM crash like: > > > > CompilerOracle: compileonly > DeoptTest.deopt_compiledframe_at_safepoint > > java version "1.6.0_14" > > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > > Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, compiled mode) > > > > 1 b DeoptTest::deopt_compiledframe_at_safepoint (220 > bytes) > > 1 made not entrant > DeoptTest::deopt_compiledframe_at_safepoint (220 bytes) > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGBUS (0xa) at pc=0xffffffff7e37514c, pid=9314, tid=15 > > # > > # JRE version: 6.0_14-b08 > > # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.0-b16 compiled mode > > solaris-sparc ) > > # Problematic frame: > > # V [libjvm.so+0x77514c] > > > > As noticed before, the error is a regression of change 6420645. It > > doesn't happen with earlier versions of the HotSpot. For example 6u13 > > with HS 11 runs the test just fine: > > > > CompilerOracle: compileonly > DeoptTest.deopt_compiledframe_at_safepoint > > java version "1.6.0_13" > > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > > Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, compiled mode) > > > > 1 b DeoptTest::deopt_compiledframe_at_safepoint (220 > bytes) > > 1 made not entrant > DeoptTest::deopt_compiledframe_at_safepoint (220 bytes) > > OK > > > > > > Notice that the problem is still present in the HS head revsion. I've > > tried with 7-ea b70: > > > > java version "1.7.0-ea" > > Java(TM) SE Runtime Environment (build 1.7.0-ea-b70) > > Java HotSpot(TM) 64-Bit Server VM (build 16.0-b07, compiled mode) > > > > 1 b DeoptTest::deopt_compiledframe_at_safepoint (220 > bytes) > > 1 made not entrant > DeoptTest::deopt_compiledframe_at_safepoint (220 bytes) > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGBUS (0xa) at pc=0xffffffff7e38c7fc, pid=10714, tid=15 > > # > > # JRE version: 7.0-b70 > > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.0-b07 compiled mode > > solaris-sparc ) > > # Problematic frame: > > # V [libjvm.so+0x78c7fc] > > > > > > The problem is caused be the following changes in frame.cpp: > > > > > > --- a/src/share/vm/runtime/frame.cpp Sat Dec 01 00:00:00 > 2007 +0000 > > +++ b/src/share/vm/runtime/frame.cpp Sun Apr 13 17:43:42 > 2008 -0400 > > @@ -1153,9 +1153,8 @@ oop* > frame::oopmapreg_to_location(VMReg > > // If it is passed in a register, it got spilled in the stub frame. > > return (oop *)reg_map->location(reg); > > } else { > > - int sp_offset_in_stack_slots = reg->reg2stack(); > > - int sp_offset = sp_offset_in_stack_slots >> (LogBytesPerWord - > > LogBytesPerInt); > > - return (oop *)&unextended_sp()[sp_offset]; > > + int sp_offset_in_bytes = reg->reg2stack() * > VMRegImpl::stack_slot_size; > > + return (oop*)(((address)unextended_sp()) + > sp_offset_in_bytes); > > } > > } > > > > and 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(). In the old > implementation, this was > > hidden by the right shift in frame::oopmapreg_to_location() which > > mapped F32 and F33 to the same stack offset. > > > > 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()); > > > > This 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 undesired behaviour in the new > > implementation of frame::oopmapreg_to_location() as described before. > > > > 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 > > > > 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); > > } > > > > 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 Changpeng.Fang at Sun.COM Tue Sep 1 11:07:38 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Tue, 01 Sep 2009 11:07:38 -0700 Subject: Request for reviews (S): 6877254: Server vm crashes with "no branches off of store slice" when run with CMS and UseSuperWord (default) In-Reply-To: <4A972188.5050905@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A972188.5050905@sun.com> Message-ID: <4A9D62EA.6000909@sun.com> http://cr.openjdk.java.net/~cfang/6877254/webrev.00/ Thanks, Changpeng From Thomas.Rodriguez at Sun.COM Tue Sep 1 13:55:30 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 01 Sep 2009 13:55:30 -0700 Subject: Change 6420645 causes SIGBUS during deoptimisation at a safepoint on 64bit-SPARC In-Reply-To: References: Message-ID: <6DBF4B78-515D-423E-BBED-DA492C6FD3BA@sun.com> > 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 guanxiaohua at gmail.com Thu Sep 3 12:04:49 2009 From: guanxiaohua at gmail.com (Tony Guan) Date: Thu, 3 Sep 2009 14:04:49 -0500 Subject: capturing method entry/exit for the compiled method Message-ID: <2fcb552b0909031204i59ca31d8yaa9155cdefd05973@mail.gmail.com> Hi all, Is there any way to monitor the method entry/exit for the compiled methods? I am using Openjdk 1.7 b59, and only found that functionality for interpreted codes. Thanks! Tony From john.coomes at sun.com Thu Sep 3 21:46:37 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 04:46:37 +0000 Subject: hg: jdk7/hotspot-comp: 3 new changesets Message-ID: <20090904044638.2A1EE12B81@hg.openjdk.java.net> Changeset: d8b49b53d8cf Author: wetmore Date: 2009-08-14 17:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/d8b49b53d8cf 6872177: JCE framework and provider builds broken following -target 7 changes Reviewed-by: ohair ! make/Defs-internal.gmk Changeset: 4c36e9853dda Author: tbell Date: 2009-08-24 22:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/4c36e9853dda Merge Changeset: 378f57273f09 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/378f57273f09 Added tag jdk7-b71 for changeset 4c36e9853dda ! .hgtags From john.coomes at sun.com Thu Sep 3 21:52:54 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 04:52:54 +0000 Subject: hg: jdk7/hotspot-comp/corba: 4 new changesets Message-ID: <20090904045258.96C9412B86@hg.openjdk.java.net> Changeset: 8001ba2bf10d Author: andrew Date: 2009-08-20 01:28 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/8001ba2bf10d 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk javac Summary: The bootstrap javac currently uses the default source and targets of the boot javac Reviewed-by: jjg, ohair ! make/common/shared/Defs-java.gmk Changeset: 04414f276160 Author: xdono Date: 2009-08-24 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/04414f276160 Merge Changeset: 3f1ef7f899ea Author: andrew Date: 2009-09-01 23:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/3f1ef7f899ea 6878106: Synchronize CORBA and JDK makefiles where possible Summary: Add recent changes to the JDK makefile to the CORBA makefile Reviewed-by: jjg, never ! make/common/shared/Defs-java.gmk Changeset: c793a3120926 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/c793a3120926 Added tag jdk7-b71 for changeset 3f1ef7f899ea ! .hgtags From john.coomes at sun.com Thu Sep 3 22:04:14 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 05:04:14 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b71 for changeset ff94d8ce0dad Message-ID: <20090904050417.6750212B8B@hg.openjdk.java.net> Changeset: 37c805b6156f Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/37c805b6156f Added tag jdk7-b71 for changeset ff94d8ce0dad ! .hgtags From john.coomes at sun.com Thu Sep 3 22:10:59 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 05:10:59 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b71 for changeset 03314cf56a72 Message-ID: <20090904051102.09D9B12B90@hg.openjdk.java.net> Changeset: 4c990aa99bc0 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/4c990aa99bc0 Added tag jdk7-b71 for changeset 03314cf56a72 ! .hgtags From john.coomes at sun.com Thu Sep 3 22:19:41 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 05:19:41 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 27 new changesets Message-ID: <20090904052729.7478B12B95@hg.openjdk.java.net> Changeset: 1ff977b938e5 Author: sherman Date: 2009-08-13 10:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1ff977b938e5 6840246: Lightweight implementation of String.split for simple use case Summary: Added a fastpath for simple use case Reviewed-by: alanb, martin ! src/share/classes/java/lang/String.java ! test/java/lang/String/Split.java Changeset: 8c0c96a3f9f6 Author: wetmore Date: 2009-08-13 12:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8c0c96a3f9f6 6870335: Provider numbers need to be bumped to 1.7 Reviewed-by: mullan ! src/share/classes/com/sun/security/sasl/Provider.java ! src/share/classes/sun/security/jgss/SunProvider.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/smartcardio/SunPCSC.java ! src/share/classes/sun/security/ssl/SunJSSE.java Changeset: 6797a2407a50 Author: wetmore Date: 2009-08-13 12:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6797a2407a50 Merge Changeset: 35f32639ee20 Author: sherman Date: 2009-08-13 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/35f32639ee20 6676423: (prefs) Opensource unit/regression tests for java.util.prefs Summary: Moved the existing test cases for prefs to open area Reviewed-by: martin, alanb + test/java/util/prefs/CommentsInXml.java + test/java/util/prefs/ConflictInFlush.java + test/java/util/prefs/ExportNode.java + test/java/util/prefs/ExportSubtree.java + test/java/util/prefs/PrefsSpi.java + test/java/util/prefs/PrefsSpi.sh + test/java/util/prefs/RemoveReadOnlyNode.java + test/java/util/prefs/RemoveUnregedListener.java + test/java/util/prefs/SerializeExceptions.java Changeset: f094eb92a6e0 Author: sherman Date: 2009-08-13 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f094eb92a6e0 Merge Changeset: 7fcdefc99dc4 Author: sherman Date: 2009-08-14 11:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7fcdefc99dc4 6866397: (file) PathMatcher with regex syntax doesn't match as expected (win) Summary: Use unicode_case_insensitive for windows path matcher for now. Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! test/java/nio/file/PathMatcher/Basic.java Changeset: 77a1c2056565 Author: sherman Date: 2009-08-14 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/77a1c2056565 6730652: CharsetEncoder.canEncode(char) returns incorrect values for some charsets Summary: override the canEncode() in ISO2022_CN_CNS Reviewed-by: martin ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/ISO2022_CN_CNS.java ! test/sun/nio/cs/FindCanEncodeBugs.java Changeset: 8414927b41d8 Author: weijun Date: 2009-08-18 10:20 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8414927b41d8 6829785: TextCallbackHandler does not honor PasswordCallback.isEchoOn() Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java ! src/share/classes/sun/security/util/Password.java + test/com/sun/security/auth/callback/TextCallbackHandler/Password.java Changeset: 74029d1cf4e4 Author: tbell Date: 2009-08-18 17:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/74029d1cf4e4 Merge Changeset: 5e8986cabdd8 Author: weijun Date: 2009-08-20 11:24 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5e8986cabdd8 6867665: Problem with keytabs with multiple kvno's (key versions) Reviewed-by: valeriep, ohair ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/ktab/HighestKvno.java Changeset: dfece53c600f Author: alanb Date: 2009-08-20 08:39 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dfece53c600f 6595866: File does work with symbolic links (win,vista) Reviewed-by: sherman ! src/windows/native/java/io/WinNTFileSystem_md.c + test/java/io/File/SymLinks.java Changeset: 70c03e494a68 Author: alanb Date: 2009-08-20 08:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/70c03e494a68 6870926: (file) Path.toRealPath performance can be improved (win) Reviewed-by: sherman ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java ! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c Changeset: 5cd12b68d09b Author: alanb Date: 2009-08-20 08:48 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5cd12b68d09b 6866804: (file) Path calls checkPermission insteadof checkXXX (sol) Reviewed-by: sherman ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java + test/java/nio/file/Path/CheckPermissions.java ! test/java/nio/file/Path/Misc.java Changeset: 3992a43bb0a5 Author: darcy Date: 2009-08-21 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3992a43bb0a5 6378701: (enum) Unclear purpose of EnumConstantNotPresentException Reviewed-by: lancea, andrew, alanb ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/TypeNotPresentException.java ! src/share/classes/java/lang/annotation/AnnotationFormatError.java ! src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java Changeset: 99a55f6f1cef Author: alanb Date: 2009-08-22 17:40 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/99a55f6f1cef 6874521: Remove @note tags Reviewed-by: andrew, darcy ! src/share/classes/java/nio/channels/Channels.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/file/FileRef.java ! src/share/classes/java/util/Scanner.java Changeset: cef30252932a Author: alanb Date: 2009-08-23 12:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cef30252932a 6842687: New I/O: Update Asynchronous I/O API to jsr203/nio2-b101 Reviewed-by: sherman ! make/java/nio/FILES_java.gmk ! src/share/classes/java/nio/channels/AsynchronousByteChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannel.java ! src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/CompletionHandler.java ! src/share/classes/java/nio/channels/exceptions - src/share/classes/sun/nio/ch/AbstractFuture.java ! src/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java ! src/share/classes/sun/nio/ch/AsynchronousFileChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/CompletedFuture.java ! src/share/classes/sun/nio/ch/Invoker.java ! src/share/classes/sun/nio/ch/PendingFuture.java ! src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java ! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/Port.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/Iocp.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/native/sun/nio/ch/Iocp.c ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Identity.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java ! test/java/nio/channels/AsynchronousDatagramChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/CustomThreadPool.java ! test/java/nio/channels/AsynchronousFileChannel/Lock.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java + test/java/nio/channels/AsynchronousSocketChannel/DieBeforeComplete.java ! test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java ! test/java/nio/channels/FileChannel/ReleaseOnCloseDeadlock.java Changeset: fca3e1a178fd Author: alanb Date: 2009-08-23 17:20 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fca3e1a178fd Merge Changeset: dbcc1f13e4fd Author: weijun Date: 2009-08-24 18:37 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dbcc1f13e4fd 6875033: regression: test of 6867665 fail Reviewed-by: xuelei ! test/sun/security/krb5/ktab/HighestKvno.java Changeset: d954cd279188 Author: ohair Date: 2009-08-24 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d954cd279188 6853636: Fix warnings in jdwpgen, add jdwpgen NetBeans project Reviewed-by: andrew, alanb, tbell, swamyv ! .hgignore + make/netbeans/jdwpgen/build.xml + make/netbeans/jdwpgen/nbproject/build-impl.xml + make/netbeans/jdwpgen/nbproject/findbugs.settings + make/netbeans/jdwpgen/nbproject/genfiles.properties + make/netbeans/jdwpgen/nbproject/project.properties + make/netbeans/jdwpgen/nbproject/project.xml + make/netbeans/jdwpgen/nbproject/sqe.properties ! make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java ! make/tools/src/build/tools/jdwpgen/AltNode.java ! make/tools/src/build/tools/jdwpgen/ConstantSetNode.java ! make/tools/src/build/tools/jdwpgen/Main.java ! make/tools/src/build/tools/jdwpgen/Node.java ! make/tools/src/build/tools/jdwpgen/Parse.java ! make/tools/src/build/tools/jdwpgen/RepeatNode.java ! make/tools/src/build/tools/jdwpgen/SelectNode.java Changeset: dd997cc0c823 Author: vinnie Date: 2009-08-24 18:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dd997cc0c823 6872048: bad private keys are generated for 2 specific ECC curves Reviewed-by: wetmore ! src/share/native/sun/security/ec/ec.c ! test/sun/security/ec/TestEC.java Changeset: b71a03c75515 Author: tbell Date: 2009-08-24 22:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b71a03c75515 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java Changeset: 80368890a2a0 Author: andrew Date: 2009-08-18 19:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/80368890a2a0 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk javac Summary: The bootstrap javac currently uses the default source and targets of the boot javac Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: 43465920bf47 Author: xdono Date: 2009-08-18 19:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/43465920bf47 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: b3aac0db5586 Author: tbell Date: 2009-08-21 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b3aac0db5586 6705913: freetype_versioncheck.exe - Unable To Locate Component Summary: Update freetype_versioncheck to deal with newer Visual Studio releases Reviewed-by: ohair ! make/tools/freetypecheck/Makefile ! make/tools/freetypecheck/freetypecheck.c Changeset: e0b26d347302 Author: xdono Date: 2009-08-24 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e0b26d347302 Merge Changeset: b3f3240135f0 Author: xdono Date: 2009-09-01 13:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b3f3240135f0 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java Changeset: ce3fde68c495 Author: xdono Date: 2009-09-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ce3fde68c495 Added tag jdk7-b71 for changeset b3f3240135f0 ! .hgtags From john.coomes at sun.com Thu Sep 3 22:42:37 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 05:42:37 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 11 new changesets Message-ID: <20090904054258.019CC12B9A@hg.openjdk.java.net> Changeset: 8a03f3c7d160 Author: jjg Date: 2009-08-12 07:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/8a03f3c7d160 6870706: langtools launcher issues Reviewed-by: mcimadamore ! make/build.xml ! src/share/bin/launcher.sh-template Changeset: 71680973d8ec Author: jjg Date: 2009-08-12 07:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/71680973d8ec 6758471: should be able to set jtreg options in langtools build Reviewed-by: mcimadamore ! make/build.properties ! make/build.xml Changeset: 7dbb79875a63 Author: jjg Date: 2009-08-12 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7dbb79875a63 6558476: com/sun/tools/javac/Main.compile don't release file handles on return Reviewed-by: darcy + src/share/classes/com/sun/tools/javac/file/CloseableURLClassLoader.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/T6558476.java Changeset: b055a5ea0dad Author: tbell Date: 2009-08-18 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b055a5ea0dad Merge Changeset: 2aa3a1cdb094 Author: andrew Date: 2009-08-19 20:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2aa3a1cdb094 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk Summary: Set source and target explicitly in pcompile task Reviewed-by: jjg ! make/build.xml Changeset: 2ce3597237f0 Author: darcy Date: 2009-08-19 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2ce3597237f0 6871291: Please clarify javax.tools.JavaCompiler.getTask() "classes" parameter Reviewed-by: jjg ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 61c1f735df67 Author: jjg Date: 2009-08-21 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/61c1f735df67 6873849: suppress notes generated by javac Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/T6873849.java Changeset: d9febdd5ae21 Author: jjg Date: 2009-08-21 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d9febdd5ae21 6873845: refine access to symbol file Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/T6873845.java Changeset: c863e90091ee Author: jjg Date: 2009-08-24 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c863e90091ee 6869216: testgetallmembers should consistently use correct filemanager Reviewed-by: darcy ! test/tools/javac/processing/model/testgetallmembers/Main.java Changeset: 33c8c38e1757 Author: tbell Date: 2009-08-24 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/33c8c38e1757 Merge Changeset: d434aa041b52 Author: xdono Date: 2009-09-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d434aa041b52 Added tag jdk7-b71 for changeset 33c8c38e1757 ! .hgtags From John.Cuthbertson at Sun.COM Fri Sep 4 00:24:48 2009 From: John.Cuthbertson at Sun.COM (John Cuthbertson) Date: Fri, 04 Sep 2009 00:24:48 -0700 Subject: capturing method entry/exit for the compiled method In-Reply-To: <2fcb552b0909031204i59ca31d8yaa9155cdefd05973@mail.gmail.com> References: <2fcb552b0909031204i59ca31d8yaa9155cdefd05973@mail.gmail.com> Message-ID: <7450cd1d728c.4aa05e50@sun.com> Hi Tony, What platform are you running on? If it is Solaris have you tried enabling the Dtrace method probes? If not then you could investigate instrumenting the runtime routines that get invoked by both interpreted and compiled code: SharedRuntime::dtrace_method_entry() and SharedRuntime::dtrace_method_exit(). Regards, JohnC ----- Original Message ----- From: Tony Guan Date: Thursday, September 3, 2009 6:00 pm Subject: capturing method entry/exit for the compiled method To: hotspot-compiler-dev at openjdk.java.net > Hi all, > > Is there any way to monitor the method entry/exit for the compiled methods? > > I am using Openjdk 1.7 b59, and only found that functionality for > interpreted codes. > > > Thanks! > > Tony From mark at klomp.org Fri Sep 4 00:35:27 2009 From: mark at klomp.org (Mark Wielaard) Date: Fri, 04 Sep 2009 09:35:27 +0200 Subject: capturing method entry/exit for the compiled method In-Reply-To: <7450cd1d728c.4aa05e50@sun.com> References: <2fcb552b0909031204i59ca31d8yaa9155cdefd05973@mail.gmail.com> <7450cd1d728c.4aa05e50@sun.com> Message-ID: <1252049727.28653.36.camel@springer.wildebeest.org> On Fri, 2009-09-04 at 00:24 -0700, John Cuthbertson wrote: > What platform are you running on? If it is Solaris have you tried > enabling the Dtrace method probes? If not then you could investigate > instrumenting the runtime routines that get invoked by both > interpreted and compiled code: SharedRuntime::dtrace_method_entry() > and SharedRuntime::dtrace_method_exit(). BTW. This now also works on GNU/Linux systems through Systemtap: http://gnu.wildebeest.org/diary/2009/08/06/i-love-it-when-a-plan-comes-together-systemtap-meets-java/ Patches are in IcedTea atm, I am working on some issue to get JNI tracing also fully supported and will then push the cleanups to OpenJDK. Cheers, Mark From guanxiaohua at gmail.com Fri Sep 4 07:53:35 2009 From: guanxiaohua at gmail.com (Tony Guan) Date: Fri, 4 Sep 2009 09:53:35 -0500 Subject: capturing method entry/exit for the compiled method In-Reply-To: <1252049727.28653.36.camel@springer.wildebeest.org> References: <2fcb552b0909031204i59ca31d8yaa9155cdefd05973@mail.gmail.com> <7450cd1d728c.4aa05e50@sun.com> <1252049727.28653.36.camel@springer.wildebeest.org> Message-ID: <2fcb552b0909040753i186848a4n68705e3e7cc6ba68@mail.gmail.com> Hi Mark, Thank you for reply! Sadly I am using linux (Fedora Core 8). :-( And Dtrace is not supported. But I'll look into the OpenJDK code to find some clue starting from the dtrace. And of course, the Systemtap. Thanks again! Tony On Fri, Sep 4, 2009 at 2:35 AM, Mark Wielaard wrote: > On Fri, 2009-09-04 at 00:24 -0700, John Cuthbertson wrote: >> What platform are you running on? If it is Solaris have you tried >> enabling the Dtrace method probes? If not then you could investigate >> instrumenting the runtime routines that get invoked by both >> interpreted and compiled code: SharedRuntime::dtrace_method_entry() >> and SharedRuntime::dtrace_method_exit(). > > BTW. This now also works on GNU/Linux systems through Systemtap: > http://gnu.wildebeest.org/diary/2009/08/06/i-love-it-when-a-plan-comes-together-systemtap-meets-java/ > Patches are in IcedTea atm, I am working on some issue to get JNI > tracing also fully supported and will then push the cleanups to OpenJDK. > > Cheers, > > Mark > > From Christian.Thalinger at Sun.COM Sat Sep 5 02:20:22 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 05 Sep 2009 11:20:22 +0200 Subject: Question: "backwards" adressing In-Reply-To: <4A954EE7.9060708@gmx.de> References: <4A926E02.5050909@gmx.de> <4A928A3D.8020103@Sun.COM> <4A928CF9.40909@gmx.de> <4A929040.4040601@Sun.COM> <4A929F4E.5020307@gmx.de> <4A92A718.5040704@Sun.COM> <4A92B3B0.4060509@gmx.de> <4A92B778.5090006@Sun.COM> <4A954EE7.9060708@gmx.de> Message-ID: <4AA22D56.3020509@Sun.COM> Ulf Zibis wrote: > Do you know any reason for this ? Let's see what code is generated (on 32-bit x86)... > static void loop1(int off, char in1, char in2, char[] out) { > out[off+3] = in1; > out[off+5] = in2; > out[off+0] = in1; > out[off+4] = in2; > out[off+9] = in1; > out[off+8] = in2; > out[off+6] = in1; > out[off+1] = in2; > out[off+7] = in1; > out[off+2] = in2; > } 030 MOV16 [EDI + #22 + ECX << #1],EBP 035 MOV16 [EDI + #12 + ECX << #1],EDX 03a MOV16 [EDI + #20 + ECX << #1],EBP 03f MOV16 [EDI + #30 + ECX << #1],EDX 044 MOV16 [EDI + #28 + ECX << #1],EBP 049 MOV16 [EDI + #24 + ECX << #1],EDX 04e MOV16 [EDI + #14 + ECX << #1],EBP 053 MOV16 [EDI + #26 + ECX << #1],EDX 058 MOV16 [EDI + #16 + ECX << #1],EBP > > static void loop2(int off, char in1, char in2, char[] out) { > out[off++] = in1; > out[off++] = in2; > out[off++] = in1; > out[off++] = in2; > out[off++] = in1; > out[off++] = in2; > out[off++] = in1; > out[off++] = in2; > out[off++] = in1; > out[off++] = in2; > } 02e MOV16 [EBX + #14 + ECX << #1],EDI 033 MOV16 [EBX + #16 + ECX << #1],EDX 038 MOV16 [EBX + #18 + ECX << #1],EDI 03d MOV16 [EBX + #20 + ECX << #1],EDX 042 MOV16 [EBX + #22 + ECX << #1],EDI 047 MOV16 [EBX + #24 + ECX << #1],EDX 04c MOV16 [EBX + #26 + ECX << #1],EDI 051 MOV16 [EBX + #28 + ECX << #1],EDX 056 MOV16 [EBX + #30 + ECX << #1],EDI As you can see the instruction sequence is almost the same, except the ordering. Theoretically the second one should be faster as continuous writes should perform better. Additionally in the final compiled version of main, where both loop1 and loop2 are inlined, the loops are unrolled a couple of times (4x). > Hm, that's what I thought as first, so in forward case cpu should do: > 1. base+index -> index register > 2. move highSurrogate(accumulator), [index register] > 3. increment index register > 4. move lowSurrogate(accumulator), [index register] > > Backward case cpu should do: > 1. base+index -> index register > 2. move -> temp > 3. increment index register > 4. move lowSurrogate(accumulator), [index register] > 5. load temp -> index register > 6. move highSurrogate(accumulator), [index register] > > Please excuse, that I'm insisting, but I really don't understand why > both should run in same time. > Can you explain once more? >From the assembly above you can see that x86 instructions have complex addressing modes, and that's why there is no need for an index increment between the writes. -- Christian From volker.simonis at gmail.com Mon Sep 7 06:21:32 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 7 Sep 2009 15:21:32 +0200 Subject: Change 6420645 causes SIGBUS during deoptimisation at a safepoint on 64bit-SPARC In-Reply-To: <6DBF4B78-515D-423E-BBED-DA492C6FD3BA@sun.com> References: <6DBF4B78-515D-423E-BBED-DA492C6FD3BA@sun.com> Message-ID: Hi Coleen, did you filed/found a bug report for this issue. I can volunteer to open a bug for this and once there's a bug ID I could also submit a patch to fix it if that would help. I just would like to keep this issue tracked. Regards, Volker On 9/1/09, 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 Sep 7 09:31:53 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 07 Sep 2009 18:31:53 +0200 Subject: gen_i2c_adapter problem on x86_64 Message-ID: <4AA53579.10609@Sun.COM> Hi! Today I was hunting down a bug in the JSR 292 compiler port for x86_64. After stepping through the call path I found out that the arguments for the target call are read from the wrong address (relative to r13, while the arguments are stored relative to rsp). The attached patch is a port of what x86_32 does. Is the attached patch the correct fix? And if yes, why did this ever work before? -- Christian diff --git a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp --- a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp +++ b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp @@ -638,6 +638,10 @@ __ movptr(rax, Address(rsp, 0)); + // Must preserve original SP for loading incoming arguments because + // we need to align the outgoing SP for compiled code. + __ movptr(r11, rsp); + // Cut-out for having no stack args. Since up to 2 int/oop args are passed // in registers, we will occasionally have no stack args. int comp_words_on_stack = 0; @@ -661,6 +665,10 @@ // as far as the placement of the call instruction __ push(rax); + // Put saved SP in another register + const Register saved_sp = rax; + __ movptr(saved_sp, r11); + // Will jump to the compiled code just as if compiled code was doing it. // Pre-load the register-jump target early, to schedule it better. __ movptr(r11, Address(rbx, in_bytes(methodOopDesc::from_compiled_offset()))); @@ -680,11 +688,7 @@ assert(!regs[i].second()->is_valid() || regs[i].first()->next() == regs[i].second(), "scrambled load targets?"); // Load in argument order going down. - // int ld_off = (total_args_passed + comp_words_on_stack -i)*wordSize; - // base ld_off on r13 (sender_sp) as the stack alignment makes offsets from rsp - // unpredictable - int ld_off = ((total_args_passed - 1) - i)*Interpreter::stackElementSize(); - + int ld_off = (total_args_passed - i)*Interpreter::stackElementSize() + Interpreter::value_offset_in_bytes(); // Point to interpreter value (vs. tag) int next_off = ld_off - Interpreter::stackElementSize(); // @@ -699,10 +703,14 @@ if (r_1->is_stack()) { // Convert stack slot to an SP offset (+ wordSize to account for return address ) int st_off = regs[i].first()->reg2stack()*VMRegImpl::stack_slot_size + wordSize; + + // We can use r13 as a temp here because compiled code doesn't need r13 as an input + // and if we end up going thru a c2i because of a miss a reasonable value of r13 + // we be generated. if (!r_2->is_valid()) { // sign extend??? - __ movl(rax, Address(r13, ld_off)); - __ movptr(Address(rsp, st_off), rax); + __ movl(r13, Address(saved_sp, ld_off)); + __ movptr(Address(rsp, st_off), r13); } else { // // We are using two optoregs. This can be either T_OBJECT, T_ADDRESS, T_LONG, or T_DOUBLE @@ -715,9 +723,9 @@ // ld_off is MSW so get LSW const int offset = (sig_bt[i]==T_LONG||sig_bt[i]==T_DOUBLE)? next_off : ld_off; - __ movq(rax, Address(r13, offset)); + __ movq(r13, Address(saved_sp, offset)); // st_off is LSW (i.e. reg.first()) - __ movq(Address(rsp, st_off), rax); + __ movq(Address(rsp, st_off), r13); } } else if (r_1->is_Register()) { // Register argument Register r = r_1->as_Register(); @@ -732,16 +740,16 @@ next_off : ld_off; // this can be a misaligned move - __ movq(r, Address(r13, offset)); + __ movq(r, Address(saved_sp, offset)); } else { // sign extend and use a full word? - __ movl(r, Address(r13, ld_off)); + __ movl(r, Address(saved_sp, ld_off)); } } else { if (!r_2->is_valid()) { - __ movflt(r_1->as_XMMRegister(), Address(r13, ld_off)); + __ movflt(r_1->as_XMMRegister(), Address(saved_sp, ld_off)); } else { - __ movdbl(r_1->as_XMMRegister(), Address(r13, next_off)); + __ movdbl(r_1->as_XMMRegister(), Address(saved_sp, next_off)); } } } From John.Rose at Sun.COM Tue Sep 8 00:39:57 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 08 Sep 2009 00:39:57 -0700 Subject: gen_i2c_adapter problem on x86_64 In-Reply-To: <4AA53579.10609@Sun.COM> References: <4AA53579.10609@Sun.COM> Message-ID: <59790C84-1530-4250-A872-4470806863E0@sun.com> Probably it already works because r13 is part of the interpreter calling convention, like rsi is on 32-bit. See InterpreterMacroAssembler::prepare_to_jump_from_interpreted on both platforms. -- John On Sep 7, 2009, at 9:31 AM, Christian Thalinger wrote: > Hi! > > Today I was hunting down a bug in the JSR 292 compiler port for > x86_64. > After stepping through the call path I found out that the arguments > for > the target call are read from the wrong address (relative to r13, > while > the arguments are stored relative to rsp). The attached patch is a > port > of what x86_32 does. > > Is the attached patch the correct fix? And if yes, why did this ever > work before? From Christian.Thalinger at Sun.COM Tue Sep 8 01:36:47 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 08 Sep 2009 10:36:47 +0200 Subject: gen_i2c_adapter problem on x86_64 In-Reply-To: <59790C84-1530-4250-A872-4470806863E0@sun.com> References: <4AA53579.10609@Sun.COM> <59790C84-1530-4250-A872-4470806863E0@sun.com> Message-ID: <4AA6179F.3070505@Sun.COM> John Rose wrote: > Probably it already works because r13 is part of the interpreter > calling convention, like rsi is on 32-bit. > > See InterpreterMacroAssembler::prepare_to_jump_from_interpreted on > both platforms. The problem is that in gen_c2i_adapter we save the SP before extra space is allocated on the stack to hold the arguments: int extraspace = (total_args_passed * Interpreter::stackElementSize()) + wordSize; // stack is aligned, keep it that way extraspace = round_to(extraspace, 2*wordSize); // Get return address __ pop(rax); // set senderSP value __ mov(r13, rsp); __ subptr(rsp, extraspace); and in gen_i2c_adapter we load the arguments relative to r13 (with positive offsets). This cannot work. At least when we have a C2I-I2C call path. -- Christian From John.Rose at Sun.COM Tue Sep 8 01:58:17 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 08 Sep 2009 01:58:17 -0700 Subject: gen_i2c_adapter problem on x86_64 In-Reply-To: <4AA6179F.3070505@Sun.COM> References: <4AA53579.10609@Sun.COM> <59790C84-1530-4250-A872-4470806863E0@sun.com> <4AA6179F.3070505@Sun.COM> Message-ID: <0CBC13F7-FBF2-4900-B270-97DBCD027E9D@Sun.COM> On Sep 8, 2009, at 1:36 AM, Christian Thalinger wrote: > At least when we have a C2I-I2C call path. OK, that's the new part. In order to do some of the argument shuffling, adapter method handles can go through a C2I-I2C transition pair. This is why we need the extra support for preserving SP in compiled calls to method handles, and why MH.invoke calls must (on x86/32) stash the outgoing SP in BP. We need a similar convention on x86/64. -- John From Christian.Thalinger at Sun.COM Tue Sep 8 02:17:18 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 08 Sep 2009 11:17:18 +0200 Subject: gen_i2c_adapter problem on x86_64 In-Reply-To: <0CBC13F7-FBF2-4900-B270-97DBCD027E9D@Sun.COM> References: <4AA53579.10609@Sun.COM> <59790C84-1530-4250-A872-4470806863E0@sun.com> <4AA6179F.3070505@Sun.COM> <0CBC13F7-FBF2-4900-B270-97DBCD027E9D@Sun.COM> Message-ID: <4AA6211E.1010601@Sun.COM> John Rose wrote: > On Sep 8, 2009, at 1:36 AM, Christian Thalinger wrote: > >> At least when we have a C2I-I2C call path. > > OK, that's the new part. In order to do some of the argument > shuffling, adapter method handles can go through a C2I-I2C transition > pair. > > This is why we need the extra support for preserving SP in compiled > calls to method handles, and why MH.invoke calls must (on x86/32) > stash the outgoing SP in BP. We need a similar convention on x86/64. I already store SP in BP for MH.invoke calls in x86_64, otherwise it wouldn't work at all. But I don't see the connection between these two. Can you explain? -- Christian From Ulf.Zibis at gmx.de Tue Sep 8 05:59:05 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 08 Sep 2009 14:59:05 +0200 Subject: Question: "backwards" adressing In-Reply-To: <4AA22D56.3020509@Sun.COM> References: <4A926E02.5050909@gmx.de> <4A928A3D.8020103@Sun.COM> <4A928CF9.40909@gmx.de> <4A929040.4040601@Sun.COM> <4A929F4E.5020307@gmx.de> <4A92A718.5040704@Sun.COM> <4A92B3B0.4060509@gmx.de> <4A92B778.5090006@Sun.COM> <4A954EE7.9060708@gmx.de> <4AA22D56.3020509@Sun.COM> Message-ID: <4AA65519.1070502@gmx.de> Christian, thanks for remembering my question. Am 05.09.2009 11:20, Christian Thalinger schrieb: > Ulf Zibis wrote: > >> Do you know any reason for this ? >> > > Let's see what code is generated (on 32-bit x86)... > > >> static void loop1(int off, char in1, char in2, char[] out) { >> out[off+3] = in1; >> out[off+5] = in2; >> out[off+0] = in1; >> out[off+4] = in2; >> out[off+9] = in1; >> out[off+8] = in2; >> out[off+6] = in1; >> out[off+1] = in2; >> out[off+7] = in1; >> out[off+2] = in2; >> } >> > > 030 MOV16 [EDI + #22 + ECX << #1],EBP > 035 MOV16 [EDI + #12 + ECX << #1],EDX > 03a MOV16 [EDI + #20 + ECX << #1],EBP > 03f MOV16 [EDI + #30 + ECX << #1],EDX > 044 MOV16 [EDI + #28 + ECX << #1],EBP > 049 MOV16 [EDI + #24 + ECX << #1],EDX > 04e MOV16 [EDI + #14 + ECX << #1],EBP > 053 MOV16 [EDI + #26 + ECX << #1],EDX > 058 MOV16 [EDI + #16 + ECX << #1],EBP > > >> static void loop2(int off, char in1, char in2, char[] out) { >> out[off++] = in1; >> out[off++] = in2; >> out[off++] = in1; >> out[off++] = in2; >> out[off++] = in1; >> out[off++] = in2; >> out[off++] = in1; >> out[off++] = in2; >> out[off++] = in1; >> out[off++] = in2; >> } >> > > 02e MOV16 [EBX + #14 + ECX << #1],EDI > 033 MOV16 [EBX + #16 + ECX << #1],EDX > 038 MOV16 [EBX + #18 + ECX << #1],EDI > 03d MOV16 [EBX + #20 + ECX << #1],EDX > 042 MOV16 [EBX + #22 + ECX << #1],EDI > 047 MOV16 [EBX + #24 + ECX << #1],EDX > 04c MOV16 [EBX + #26 + ECX << #1],EDI > 051 MOV16 [EBX + #28 + ECX << #1],EDX > 056 MOV16 [EBX + #30 + ECX << #1],EDI > > As you can see the instruction sequence is almost the same, except the > ordering. Theoretically the second one should be faster as continuous > writes should perform better. > Yes, that's what I'm wondering too, because it's even contrariwise in my test. Additionally I don't understand: - the additional shift by #1, so the address in loop2 would be incremented by 4 (or is there a parenthesis missing around (ECX << #1) ?), but we are in a char[] not int[] - Why doesn't hotspot compile to INC opcodes? I think, CPU's won't have INC, if they wouldn't have advantages. ??? - This complex addressing moded MOV opcode needs 5 bytes to be loaded each, I guess, INC should be shorter. - Doesn't x86 have a combined MOV_&_INC opcode ? Stupid questions? OK, it's long time ago, I was programming in assembler, and modern x86 didn't exist that time. -Ulf From Paul.Hohensee at Sun.COM Tue Sep 8 08:06:35 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 08 Sep 2009 11:06:35 -0400 Subject: Question: "backwards" adressing In-Reply-To: <4AA65519.1070502@gmx.de> References: <4A926E02.5050909@gmx.de> <4A928A3D.8020103@Sun.COM> <4A928CF9.40909@gmx.de> <4A929040.4040601@Sun.COM> <4A929F4E.5020307@gmx.de> <4A92A718.5040704@Sun.COM> <4A92B3B0.4060509@gmx.de> <4A92B778.5090006@Sun.COM> <4A954EE7.9060708@gmx.de> <4AA22D56.3020509@Sun.COM> <4AA65519.1070502@gmx.de> Message-ID: <4AA672FB.5090207@sun.com> The unit of memory access for current x86 designs is larger than a single 2-byte word, being usually at least 8 bytes. The processors have store combining buffers that merge stores to the same line if they happen close enough together in time, so a small number of store instructions such as in your example will all merge up into at most 3 store buffer entries, regardless of instruction ordering. Paul Ulf Zibis wrote: > Christian, thanks for remembering my question. > > > Am 05.09.2009 11:20, Christian Thalinger schrieb: >> Ulf Zibis wrote: >> >>> Do you know any reason for this ? >>> >> >> Let's see what code is generated (on 32-bit x86)... >> >> >>> static void loop1(int off, char in1, char in2, char[] out) { >>> out[off+3] = in1; >>> out[off+5] = in2; >>> out[off+0] = in1; >>> out[off+4] = in2; >>> out[off+9] = in1; >>> out[off+8] = in2; >>> out[off+6] = in1; >>> out[off+1] = in2; >>> out[off+7] = in1; >>> out[off+2] = in2; >>> } >>> >> >> 030 MOV16 [EDI + #22 + ECX << #1],EBP >> 035 MOV16 [EDI + #12 + ECX << #1],EDX >> 03a MOV16 [EDI + #20 + ECX << #1],EBP >> 03f MOV16 [EDI + #30 + ECX << #1],EDX >> 044 MOV16 [EDI + #28 + ECX << #1],EBP >> 049 MOV16 [EDI + #24 + ECX << #1],EDX >> 04e MOV16 [EDI + #14 + ECX << #1],EBP >> 053 MOV16 [EDI + #26 + ECX << #1],EDX >> 058 MOV16 [EDI + #16 + ECX << #1],EBP >> >> >>> static void loop2(int off, char in1, char in2, char[] out) { >>> out[off++] = in1; >>> out[off++] = in2; >>> out[off++] = in1; >>> out[off++] = in2; >>> out[off++] = in1; >>> out[off++] = in2; >>> out[off++] = in1; >>> out[off++] = in2; >>> out[off++] = in1; >>> out[off++] = in2; >>> } >>> >> >> 02e MOV16 [EBX + #14 + ECX << #1],EDI >> 033 MOV16 [EBX + #16 + ECX << #1],EDX >> 038 MOV16 [EBX + #18 + ECX << #1],EDI >> 03d MOV16 [EBX + #20 + ECX << #1],EDX >> 042 MOV16 [EBX + #22 + ECX << #1],EDI >> 047 MOV16 [EBX + #24 + ECX << #1],EDX >> 04c MOV16 [EBX + #26 + ECX << #1],EDI >> 051 MOV16 [EBX + #28 + ECX << #1],EDX >> 056 MOV16 [EBX + #30 + ECX << #1],EDI >> >> As you can see the instruction sequence is almost the same, except the >> ordering. Theoretically the second one should be faster as continuous >> writes should perform better. >> > > Yes, that's what I'm wondering too, because it's even contrariwise in > my test. > Additionally I don't understand: > - the additional shift by #1, so the address in loop2 would be > incremented by 4 (or is there a parenthesis missing around (ECX << #1) > ?), but we are in a char[] not int[] > - Why doesn't hotspot compile to INC opcodes? I think, CPU's won't > have INC, if they wouldn't have advantages. ??? > - This complex addressing moded MOV opcode needs 5 bytes to be loaded > each, I guess, INC should be shorter. > - Doesn't x86 have a combined MOV_&_INC opcode ? > > Stupid questions? OK, it's long time ago, I was programming in > assembler, and modern x86 didn't exist that time. > > -Ulf > > > > From Vladimir.Kozlov at Sun.COM Tue Sep 8 13:57:24 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 08 Sep 2009 13:57:24 -0700 Subject: Change 6420645 causes SIGBUS during deoptimisation at a safepoint on 64bit-SPARC In-Reply-To: References: <6DBF4B78-515D-423E-BBED-DA492C6FD3BA@sun.com> Message-ID: <4AA6C534.107@sun.com> Thank you, Volker I filed C2 bug since the fix is for .ad file and is not related to COOP: 6880034: SIGBUS during deoptimisation at a safepoint on 64bit-SPARC Vladimir Volker Simonis wrote: > Hi Coleen, > > did you filed/found a bug report for this issue. I can volunteer to > open a bug for this and once there's a bug ID I could also submit a > patch to fix it if that would help. I just would like to keep this > issue tracked. > > Regards, > Volker > > On 9/1/09, 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 Coleen.Phillimore at Sun.COM Tue Sep 8 14:48:31 2009 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Tue, 08 Sep 2009 17:48:31 -0400 Subject: Change 6420645 causes SIGBUS during deoptimisation at a safepoint on 64bit-SPARC In-Reply-To: <4AA6C534.107@sun.com> References: <6DBF4B78-515D-423E-BBED-DA492C6FD3BA@sun.com> <4AA6C534.107@sun.com> Message-ID: <4AA6D12F.2040606@sun.com> I filed one this morning too, but didn't put hotspot-compiler-dev on the interest list 'cause I thought it'd bounce. CR 6879831 Created, P2 hotspot/runtime_syst Change for compressed oops causes SIGBUS during deoptimisation at a safepoint on 64bit-SPARC but I just closed it as a duplicate of yours since you've added more information to yours, and it should be in the c2 category. Thanks, Coleen On 09/08/09 16:57, Vladimir Kozlov wrote: > Thank you, Volker > > I filed C2 bug since the fix is for .ad file and is not related to COOP: > > 6880034: SIGBUS during deoptimisation at a safepoint on 64bit-SPARC > > Vladimir > > Volker Simonis wrote: >> Hi Coleen, >> >> did you filed/found a bug report for this issue. I can volunteer to >> open a bug for this and once there's a bug ID I could also submit a >> patch to fix it if that would help. I just would like to keep this >> issue tracked. >> >> Regards, >> Volker >> >> On 9/1/09, 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 vladimir.kozlov at sun.com Tue Sep 8 15:12:45 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 08 Sep 2009 22:12:45 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6875619: CTW fails with /hotspot/src/share/vm/opto/type.hpp Message-ID: <20090908221252.93AE5E2F2@hg.openjdk.java.net> Changeset: 0f1c19b7a52d Author: kvn Date: 2009-09-08 10:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0f1c19b7a52d 6875619: CTW fails with /hotspot/src/share/vm/opto/type.hpp Summary: In load_array_length() cast array's type to TypeOopPtr when calling make_ideal_length() method. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp From Vladimir.Kozlov at Sun.COM Tue Sep 8 16:15:35 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 08 Sep 2009 16:15:35 -0700 Subject: Request for reviews (XS): 6880052 Message-ID: <4AA6E597.1020102@sun.com> http://cr.openjdk.java.net/~kvn/6880052/webrev.00 Fixed 6880052: SIGSEGV in GraphKit::null_check_common() Problem: After 6875577 fix the method do_null_check() checks for unloaded klass also for arrays. But array type may not have klass, for example, when element type is Bottom. The bug case has Phi node which merges several CheckCastPP with different types so its type is bottom[int:>=0]. Solution: Check that a klass is not NULL before the unloaded check. Reviewed by: Fix verified (y/n): y, test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Tue Sep 8 16:33:51 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 08 Sep 2009 16:33:51 -0700 Subject: Request for reviews (XS): 6880052 In-Reply-To: <4AA6E597.1020102@sun.com> References: <4AA6E597.1020102@sun.com> Message-ID: <20305AC0-9C89-434F-B0C7-53E0348303AB@sun.com> looks good. tom On Sep 8, 2009, at 4:15 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6880052/webrev.00 > > Fixed 6880052: SIGSEGV in GraphKit::null_check_common() > > Problem: > After 6875577 fix the method do_null_check() checks for > unloaded klass also for arrays. But array type may not > have klass, for example, when element type is Bottom. > The bug case has Phi node which merges several CheckCastPP > with different types so its type is bottom[int:>=0]. > > Solution: > Check that a klass is not NULL before the unloaded check. > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Tue Sep 8 16:53:25 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 08 Sep 2009 16:53:25 -0700 Subject: Request for reviews (XS): 6880052 In-Reply-To: <20305AC0-9C89-434F-B0C7-53E0348303AB@sun.com> References: <4AA6E597.1020102@sun.com> <20305AC0-9C89-434F-B0C7-53E0348303AB@sun.com> Message-ID: <4AA6EE75.2080901@sun.com> Thanks Tom Vladimir Tom Rodriguez wrote: > looks good. > > tom > > On Sep 8, 2009, at 4:15 PM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6880052/webrev.00 >> >> Fixed 6880052: SIGSEGV in GraphKit::null_check_common() >> >> Problem: >> After 6875577 fix the method do_null_check() checks for >> unloaded klass also for arrays. But array type may not >> have klass, for example, when element type is Bottom. >> The bug case has Phi node which merges several CheckCastPP >> with different types so its type is bottom[int:>=0]. >> >> Solution: >> Check that a klass is not NULL before the unloaded check. >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > From Changpeng.Fang at Sun.COM Tue Sep 8 17:23:34 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Tue, 08 Sep 2009 17:23:34 -0700 Subject: Request for reviews (S): 6877254: Server vm crashes with "no branches off of store slice" when run with CMS and UseSuperWord (default) In-Reply-To: <4A9D62EA.6000909@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A972188.5050905@sun.com> <4A9D62EA.6000909@sun.com> Message-ID: <4AA6F586.4090302@sun.com> Need additional reviews (Tom (never) proposed the implementation, so I assume he is oked )! Comments are in the webrev. On 09/01/09 11:07, Changpeng Fang wrote: > http://cr.openjdk.java.net/~cfang/6877254/webrev.00/ > > Thanks, > > Changpeng Thanks, Changpeng From Vladimir.Kozlov at Sun.COM Tue Sep 8 18:30:41 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 08 Sep 2009 18:30:41 -0700 Subject: Request for reviews (S): 6877254: Server vm crashes with "no branches off of store slice" when run with CMS and UseSuperWord (default) In-Reply-To: <4AA6F586.4090302@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A972188.5050905@sun.com> <4A9D62EA.6000909@sun.com> <4AA6F586.4090302@sun.com> Message-ID: <4AA70541.2050702@sun.com> I have concerns about StoreCMNode::Ideal(aidx) implementation. The result of memory_at() is never the same mergemem node. I either mergemem->base_memory() or mergemem->in(aidx) so your check will be always true. Also mergemem nodes could be chained when the result of memory_at() is also mergemem. You can look on methods in memnode.cpp which search through mergemem for stores: step_through_mergemem(), find_previous_store(). Thanks, Vladimir Changpeng Fang wrote: > Need additional reviews (Tom (never) proposed the implementation, so I > assume he is oked )! > Comments are in the webrev. > > > On 09/01/09 11:07, Changpeng Fang wrote: >> http://cr.openjdk.java.net/~cfang/6877254/webrev.00/ >> >> Thanks, >> >> Changpeng > > > Thanks, > > Changpeng From Thomas.Rodriguez at Sun.COM Tue Sep 8 21:34:17 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 08 Sep 2009 21:34:17 -0700 Subject: Request for reviews (S): 6877254: Server vm crashes with "no branches off of store slice" when run with CMS and UseSuperWord (default) In-Reply-To: <4AA70541.2050702@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A972188.5050905@sun.com> <4A9D62EA.6000909@sun.com> <4AA6F586.4090302@sun.com> <4AA70541.2050702@sun.com> Message-ID: <3BADB634-F23C-4DB2-8040-0FC55B8FD7ED@sun.com> On Sep 8, 2009, at 6:30 PM, Vladimir Kozlov wrote: > I have concerns about StoreCMNode::Ideal(aidx) implementation. > > The result of memory_at() is never the same mergemem node. > I either mergemem->base_memory() or mergemem->in(aidx) > so your check will be always true. You're right but i think that just means we can drop that test. > > Also mergemem nodes could be chained when the result of memory_at() > is also mergemem. I figured Ideal would be called again if there was more work to do and it should be a rare case anyway. The mem of a StoreCM should only be something besides a Store if the StoreCM is dead or if something weird has gone on with cloning. These changes are pretty conservative since we don't have a clear set of rules for when a StoreCM is dead though I think we could if we wanted to. tom > > You can look on methods in memnode.cpp which search through > mergemem for stores: step_through_mergemem(), find_previous_store(). > > Thanks, > Vladimir > > Changpeng Fang wrote: >> Need additional reviews (Tom (never) proposed the implementation, >> so I assume he is oked )! >> Comments are in the webrev. >> On 09/01/09 11:07, Changpeng Fang wrote: >>> http://cr.openjdk.java.net/~cfang/6877254/webrev.00/ >>> >>> Thanks, >>> >>> Changpeng >> Thanks, >> Changpeng From vladimir.kozlov at sun.com Tue Sep 8 21:38:31 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 09 Sep 2009 04:38:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6880052: SIGSEGV in GraphKit::null_check_common() Message-ID: <20090909043840.EAF23E319@hg.openjdk.java.net> Changeset: 26fbe81d30cf Author: kvn Date: 2009-09-08 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/26fbe81d30cf 6880052: SIGSEGV in GraphKit::null_check_common() Summary: Check that a klass is not NULL before the is_loaded() call. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp From Vladimir.Kozlov at Sun.COM Tue Sep 8 22:04:27 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 08 Sep 2009 22:04:27 -0700 Subject: Request for reviews (S): 6877254: Server vm crashes with "no branches off of store slice" when run with CMS and UseSuperWord (default) In-Reply-To: <3BADB634-F23C-4DB2-8040-0FC55B8FD7ED@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A972188.5050905@sun.com> <4A9D62EA.6000909@sun.com> <4AA6F586.4090302@sun.com> <4AA70541.2050702@sun.com> <3BADB634-F23C-4DB2-8040-0FC55B8FD7ED@sun.com> Message-ID: <4AA7375B.6080607@sun.com> You are right, we don't need loop inside Ideal. Vladimir Tom Rodriguez wrote: > > On Sep 8, 2009, at 6:30 PM, Vladimir Kozlov wrote: > >> I have concerns about StoreCMNode::Ideal(aidx) implementation. >> >> The result of memory_at() is never the same mergemem node. >> I either mergemem->base_memory() or mergemem->in(aidx) >> so your check will be always true. > > You're right but i think that just means we can drop that test. > >> >> Also mergemem nodes could be chained when the result of memory_at() >> is also mergemem. > > I figured Ideal would be called again if there was more work to do and > it should be a rare case anyway. The mem of a StoreCM should only be > something besides a Store if the StoreCM is dead or if something weird > has gone on with cloning. These changes are pretty conservative since > we don't have a clear set of rules for when a StoreCM is dead though I > think we could if we wanted to. > > tom > >> >> You can look on methods in memnode.cpp which search through >> mergemem for stores: step_through_mergemem(), find_previous_store(). >> >> Thanks, >> Vladimir >> >> Changpeng Fang wrote: >>> Need additional reviews (Tom (never) proposed the implementation, so >>> I assume he is oked )! >>> Comments are in the webrev. >>> On 09/01/09 11:07, Changpeng Fang wrote: >>>> http://cr.openjdk.java.net/~cfang/6877254/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Changpeng >>> Thanks, >>> Changpeng > From Vladimir.Kozlov at Sun.COM Wed Sep 9 15:35:35 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 09 Sep 2009 15:35:35 -0700 Subject: Request for reviews (S): 6880053 Message-ID: <4AA82DB7.6060200@sun.com> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Problem: I added this assert in 6875577 fix to catch cases when the type of the cloned object is TypeInstPtr::NOTNULL since it will produce incorrect graph. And Nightly testing found such case: the method sun.reflect.GeneratedMethodAccessor4.invoke(Object o, Object[] ao) returns the clone of the Object o argument. Solution: Use more general oop type TypeOopPtr::NOTNULL for additional CheckCastPP node in clone() instrinsic and arraycopy. Also fix instance_id meet for TypeOopPtr. Reviewed by: Fix verified (y/n): y, test Other testing: JPRT From Vladimir.Kozlov at Sun.COM Wed Sep 9 16:11:30 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 09 Sep 2009 16:11:30 -0700 Subject: Request for reviews (XS): 6880533 Message-ID: <4AA83622.1050400@sun.com> http://cr.openjdk.java.net/~kvn/6880533/webrev.00 Fixed 6880533: test/compiler/6865031/Test.java miss -XX:+IgnoreUnrecognizedVMOptions Problem: The test failed with 32-bit VM since UseCompressedOops is not defined. Solution: Add missing test option -XX:+IgnoreUnrecognizedVMOptions. Reviewed by: Fix verified (y/n): y, test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Wed Sep 9 16:16:46 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 09 Sep 2009 16:16:46 -0700 Subject: Request for reviews (XS): 6880533 In-Reply-To: <4AA83622.1050400@sun.com> References: <4AA83622.1050400@sun.com> Message-ID: <62BDC303-F7DF-4008-94AD-54E6B7822F8A@sun.com> Looks good. tom On Sep 9, 2009, at 4:11 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6880533/webrev.00 > > Fixed 6880533: test/compiler/6865031/Test.java miss -XX: > +IgnoreUnrecognizedVMOptions > > Problem: > The test failed with 32-bit VM since UseCompressedOops is not defined. > > Solution: > Add missing test option -XX:+IgnoreUnrecognizedVMOptions. > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Wed Sep 9 16:24:55 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 09 Sep 2009 16:24:55 -0700 Subject: Request for reviews (XS): 6880533 In-Reply-To: <62BDC303-F7DF-4008-94AD-54E6B7822F8A@sun.com> References: <4AA83622.1050400@sun.com> <62BDC303-F7DF-4008-94AD-54E6B7822F8A@sun.com> Message-ID: <4AA83947.6050205@sun.com> Thanks Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 9, 2009, at 4:11 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6880533/webrev.00 >> >> Fixed 6880533: test/compiler/6865031/Test.java miss >> -XX:+IgnoreUnrecognizedVMOptions >> >> Problem: >> The test failed with 32-bit VM since UseCompressedOops is not defined. >> >> Solution: >> Add missing test option -XX:+IgnoreUnrecognizedVMOptions. >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > From Thomas.Rodriguez at Sun.COM Wed Sep 9 16:27:33 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 09 Sep 2009 16:27:33 -0700 Subject: uncommon trap for athrow Message-ID: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> We got in a report, 6877221, complaining about the use of the uncommon trap below for handling of an athrow. Anyone understand why we use an uncommon trap here to dispatch an exception? if (can_rerun_bytecode()) { // Do not push_ex_oop here! // Re-executing the bytecode will reproduce the throwing condition. bool must_throw = true; uncommon_trap(Deoptimization::Reason_unhandled, Deoptimization::Action_none, (ciKlass*)NULL, (const char*)NULL, // default args must_throw); return; } // Oops, need to call into the VM to resolve the klasses at runtime. // Note: This call must not deoptimize, since it is not a real at this bci! kill_dead_locals(); make_runtime_call(RC_NO_LEAF | RC_MUST_THROW, OptoRuntime::rethrow_Type(), OptoRuntime::rethrow_stub(), NULL, NULL, ex_node); We should just jump into rethrow since that's where we'll end up anyway right? All the work of an uncommon trap is useless for the dispatch and also drops the code back into the interpreter. tom From Thomas.Rodriguez at Sun.COM Wed Sep 9 16:31:03 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 09 Sep 2009 16:31:03 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <4AA82DB7.6060200@sun.com> References: <4AA82DB7.6060200@sun.com> Message-ID: <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> I'm don't understand this. What is TypeOopPtr::NOTNULL supposed to represent? That doesn't seem like a valid type in the lattice since it would have to correspond to Object:NotNull which is already represented by TypeInstPtr::NOTNULL. Why will the graph be incorrect if the type is TypeInstPtr::NOTNULL? tom On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6880053/webrev.00 > > Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != > TypeInstPtr::NOTNULL) > > Problem: > I added this assert in 6875577 fix to catch cases when > the type of the cloned object is TypeInstPtr::NOTNULL > since it will produce incorrect graph. > And Nightly testing found such case: the method > sun.reflect.GeneratedMethodAccessor4.invoke(Object o, Object[] ao) > returns the clone of the Object o argument. > > Solution: > Use more general oop type TypeOopPtr::NOTNULL for > additional CheckCastPP node in clone() instrinsic and arraycopy. > Also fix instance_id meet for TypeOopPtr. > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Wed Sep 9 16:43:16 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 09 Sep 2009 16:43:16 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> Message-ID: <4AA83D94.4000708@sun.com> As you remember we have 2 CheckCastPP nodes in clone() intrinsic. One is original which we move and pin below arraycopy call to guaranty that all memory accesses to the cloned object are placed below arraycopy. And the second is used to have a live oop across arraycopy call. If both have the same type (bug's case) the CheckCastPPNode::identity() will eliminate the original CheckCastPP since it references the second: // Replace raw memory edge with new CheckCastPP to have a live oop // at safepoints instead of raw value. assert(new_obj->is_CheckCastPP() && new_obj->in(1) == alloc_obj->in(1), "sanity"); alloc_obj->set_req(1, new_obj); Vladimir Tom Rodriguez wrote: > I'm don't understand this. What is TypeOopPtr::NOTNULL supposed to > represent? That doesn't seem like a valid type in the lattice since it > would have to correspond to Object:NotNull which is already represented > by TypeInstPtr::NOTNULL. Why will the graph be incorrect if the type is > TypeInstPtr::NOTNULL? > > tom > > On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >> >> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >> TypeInstPtr::NOTNULL) >> >> Problem: >> I added this assert in 6875577 fix to catch cases when >> the type of the cloned object is TypeInstPtr::NOTNULL >> since it will produce incorrect graph. >> And Nightly testing found such case: the method >> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, Object[] ao) >> returns the clone of the Object o argument. >> >> Solution: >> Use more general oop type TypeOopPtr::NOTNULL for >> additional CheckCastPP node in clone() instrinsic and arraycopy. >> Also fix instance_id meet for TypeOopPtr. >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > From Thomas.Rodriguez at Sun.COM Wed Sep 9 16:59:36 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 09 Sep 2009 16:59:36 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <4AA83D94.4000708@sun.com> References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> Message-ID: <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> I suspected that was the purpose but TypeOopPtr::NOTNULL seems nonsensical to me. Is that really a valid type? tom On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: > As you remember we have 2 CheckCastPP nodes in clone() intrinsic. > One is original which we move and pin below arraycopy call > to guaranty that all memory accesses to the cloned object > are placed below arraycopy. > And the second is used to have a live oop across arraycopy call. > If both have the same type (bug's case) the > CheckCastPPNode::identity() > will eliminate the original CheckCastPP since it references the > second: > > // Replace raw memory edge with new CheckCastPP to have a live oop > // at safepoints instead of raw value. > assert(new_obj->is_CheckCastPP() && new_obj->in(1) == alloc_obj- > >in(1), "sanity"); > alloc_obj->set_req(1, new_obj); > > Vladimir > > Tom Rodriguez wrote: >> I'm don't understand this. What is TypeOopPtr::NOTNULL supposed to >> represent? That doesn't seem like a valid type in the lattice >> since it would have to correspond to Object:NotNull which is >> already represented by TypeInstPtr::NOTNULL. Why will the graph be >> incorrect if the type is TypeInstPtr::NOTNULL? >> tom >> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>> >>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >>> TypeInstPtr::NOTNULL) >>> >>> Problem: >>> I added this assert in 6875577 fix to catch cases when >>> the type of the cloned object is TypeInstPtr::NOTNULL >>> since it will produce incorrect graph. >>> And Nightly testing found such case: the method >>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, Object[] ao) >>> returns the clone of the Object o argument. >>> >>> Solution: >>> Use more general oop type TypeOopPtr::NOTNULL for >>> additional CheckCastPP node in clone() instrinsic and arraycopy. >>> Also fix instance_id meet for TypeOopPtr. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, test >>> >>> Other testing: >>> JPRT >>> From Vladimir.Kozlov at Sun.COM Wed Sep 9 17:32:13 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 09 Sep 2009 17:32:13 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> Message-ID: <4AA8490D.6050200@sun.com> It is valid C2 type since all type methods (xmeet) process it but it should not exist from java point of view. And I'm using it with assumption that none java programs use such type. I am also not fully comfortable with it but I can't find other type which could be used (I tried). I talked with John and he agreed with this change. I ran CTW and it did not find problems with this change. But we may still hit some problems where we would expect a real java type and will get this one. But such cases should be caught by asserts we have. The other solution (which we rejected before) is to modify oop map build to list raw pointers which have CheckCastPP users. Then we will not need the second CheckCastPP. Vladimir Tom Rodriguez wrote: > I suspected that was the purpose but TypeOopPtr::NOTNULL seems > nonsensical to me. Is that really a valid type? > > tom > > On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: > >> As you remember we have 2 CheckCastPP nodes in clone() intrinsic. >> One is original which we move and pin below arraycopy call >> to guaranty that all memory accesses to the cloned object >> are placed below arraycopy. >> And the second is used to have a live oop across arraycopy call. >> If both have the same type (bug's case) the CheckCastPPNode::identity() >> will eliminate the original CheckCastPP since it references the second: >> >> // Replace raw memory edge with new CheckCastPP to have a live oop >> // at safepoints instead of raw value. >> assert(new_obj->is_CheckCastPP() && new_obj->in(1) == >> alloc_obj->in(1), "sanity"); >> alloc_obj->set_req(1, new_obj); >> >> Vladimir >> >> Tom Rodriguez wrote: >>> I'm don't understand this. What is TypeOopPtr::NOTNULL supposed to >>> represent? That doesn't seem like a valid type in the lattice since >>> it would have to correspond to Object:NotNull which is already >>> represented by TypeInstPtr::NOTNULL. Why will the graph be incorrect >>> if the type is TypeInstPtr::NOTNULL? >>> tom >>> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>>> >>>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >>>> TypeInstPtr::NOTNULL) >>>> >>>> Problem: >>>> I added this assert in 6875577 fix to catch cases when >>>> the type of the cloned object is TypeInstPtr::NOTNULL >>>> since it will produce incorrect graph. >>>> And Nightly testing found such case: the method >>>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, Object[] ao) >>>> returns the clone of the Object o argument. >>>> >>>> Solution: >>>> Use more general oop type TypeOopPtr::NOTNULL for >>>> additional CheckCastPP node in clone() instrinsic and arraycopy. >>>> Also fix instance_id meet for TypeOopPtr. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y, test >>>> >>>> Other testing: >>>> JPRT >>>> > From Thomas.Rodriguez at Sun.COM Wed Sep 9 18:21:12 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 09 Sep 2009 18:21:12 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <4AA8490D.6050200@sun.com> References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> <4AA8490D.6050200@sun.com> Message-ID: <7542F21E-4FE4-4FB4-B809-0F209F66A32D@Sun.COM> At one point in the original discussion you suggested using MembarCPUOrder to enforce the ordering which allows us to leave the CheckCastPP in it's original location without adding another CheckCastPP. I'd prefer that to playing weird games with the types. Is that a viable fix? tom On Sep 9, 2009, at 5:32 PM, Vladimir Kozlov wrote: > It is valid C2 type since all type methods (xmeet) process it > but it should not exist from java point of view. And I'm using it > with assumption that none java programs use such type. > > I am also not fully comfortable with it but I can't find > other type which could be used (I tried). > I talked with John and he agreed with this change. > > I ran CTW and it did not find problems with this change. > But we may still hit some problems where we would expect > a real java type and will get this one. But such cases > should be caught by asserts we have. > > The other solution (which we rejected before) is to modify > oop map build to list raw pointers which have CheckCastPP > users. Then we will not need the second CheckCastPP. > > Vladimir > > Tom Rodriguez wrote: >> I suspected that was the purpose but TypeOopPtr::NOTNULL seems >> nonsensical to me. Is that really a valid type? >> tom >> On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: >>> As you remember we have 2 CheckCastPP nodes in clone() intrinsic. >>> One is original which we move and pin below arraycopy call >>> to guaranty that all memory accesses to the cloned object >>> are placed below arraycopy. >>> And the second is used to have a live oop across arraycopy call. >>> If both have the same type (bug's case) the >>> CheckCastPPNode::identity() >>> will eliminate the original CheckCastPP since it references the >>> second: >>> >>> // Replace raw memory edge with new CheckCastPP to have a live oop >>> // at safepoints instead of raw value. >>> assert(new_obj->is_CheckCastPP() && new_obj->in(1) == alloc_obj- >>> >in(1), "sanity"); >>> alloc_obj->set_req(1, new_obj); >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> I'm don't understand this. What is TypeOopPtr::NOTNULL supposed >>>> to represent? That doesn't seem like a valid type in the lattice >>>> since it would have to correspond to Object:NotNull which is >>>> already represented by TypeInstPtr::NOTNULL. Why will the graph >>>> be incorrect if the type is TypeInstPtr::NOTNULL? >>>> tom >>>> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>>>> >>>>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >>>>> TypeInstPtr::NOTNULL) >>>>> >>>>> Problem: >>>>> I added this assert in 6875577 fix to catch cases when >>>>> the type of the cloned object is TypeInstPtr::NOTNULL >>>>> since it will produce incorrect graph. >>>>> And Nightly testing found such case: the method >>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, Object[] ao) >>>>> returns the clone of the Object o argument. >>>>> >>>>> Solution: >>>>> Use more general oop type TypeOopPtr::NOTNULL for >>>>> additional CheckCastPP node in clone() instrinsic and arraycopy. >>>>> Also fix instance_id meet for TypeOopPtr. >>>>> >>>>> Reviewed by: >>>>> >>>>> Fix verified (y/n): y, test >>>>> >>>>> Other testing: >>>>> JPRT >>>>> From Vladimir.Kozlov at Sun.COM Wed Sep 9 18:35:22 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 09 Sep 2009 18:35:22 -0700 Subject: Request for reviews (XS): 6880574 Message-ID: <4AA857DA.2070608@sun.com> http://cr.openjdk.java.net/~kvn/6880574/webrev.00 Fixed 6880574: C2 assert in escape.cpp:445 on linux-amd64 Problem: Unsafe access may have several chained AddP nodes but get_addp_base() method expects incorrectly only one. Solution: Look through chained AddP nodes in get_addp_base(). Reviewed by: Fix verified (y/n): y, test Other testing: JPRT From John.Rose at Sun.COM Wed Sep 9 18:56:47 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 09 Sep 2009 18:56:47 -0700 Subject: Request for reviews (XS): 6880574 In-Reply-To: <4AA857DA.2070608@sun.com> References: <4AA857DA.2070608@sun.com> Message-ID: Looks good. Nice comment before the subroutine. -- John On Sep 9, 2009, at 6:35 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6880574/webrev.00 From Vladimir.Kozlov at Sun.COM Wed Sep 9 18:57:58 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 09 Sep 2009 18:57:58 -0700 Subject: Request for reviews (XS): 6880574 In-Reply-To: References: <4AA857DA.2070608@sun.com> Message-ID: <4AA85D26.70801@sun.com> Thanks John Vladimir John Rose wrote: > Looks good. Nice comment before the subroutine. -- John > On Sep 9, 2009, at 6:35 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6880574/webrev.00 > From Vladimir.Kozlov at Sun.COM Wed Sep 9 19:28:02 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 09 Sep 2009 19:28:02 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <7542F21E-4FE4-4FB4-B809-0F209F66A32D@Sun.COM> References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> <4AA8490D.6050200@sun.com> <7542F21E-4FE4-4FB4-B809-0F209F66A32D@Sun.COM> Message-ID: <4AA86432.8000607@sun.com> The problem with membar is that it is barrier for all memory, we can't set it to slices corresponding only to this object. It will prevent memory optimizations for other objects. I don't remember other problems then this performance concern. Vladimir Tom Rodriguez wrote: > At one point in the original discussion you suggested using > MembarCPUOrder to enforce the ordering which allows us to leave the > CheckCastPP in it's original location without adding another > CheckCastPP. I'd prefer that to playing weird games with the types. Is > that a viable fix? > > tom > > On Sep 9, 2009, at 5:32 PM, Vladimir Kozlov wrote: > >> It is valid C2 type since all type methods (xmeet) process it >> but it should not exist from java point of view. And I'm using it >> with assumption that none java programs use such type. >> >> I am also not fully comfortable with it but I can't find >> other type which could be used (I tried). >> I talked with John and he agreed with this change. >> >> I ran CTW and it did not find problems with this change. >> But we may still hit some problems where we would expect >> a real java type and will get this one. But such cases >> should be caught by asserts we have. >> >> The other solution (which we rejected before) is to modify >> oop map build to list raw pointers which have CheckCastPP >> users. Then we will not need the second CheckCastPP. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> I suspected that was the purpose but TypeOopPtr::NOTNULL seems >>> nonsensical to me. Is that really a valid type? >>> tom >>> On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: >>>> As you remember we have 2 CheckCastPP nodes in clone() intrinsic. >>>> One is original which we move and pin below arraycopy call >>>> to guaranty that all memory accesses to the cloned object >>>> are placed below arraycopy. >>>> And the second is used to have a live oop across arraycopy call. >>>> If both have the same type (bug's case) the CheckCastPPNode::identity() >>>> will eliminate the original CheckCastPP since it references the second: >>>> >>>> // Replace raw memory edge with new CheckCastPP to have a live oop >>>> // at safepoints instead of raw value. >>>> assert(new_obj->is_CheckCastPP() && new_obj->in(1) == >>>> alloc_obj->in(1), "sanity"); >>>> alloc_obj->set_req(1, new_obj); >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> I'm don't understand this. What is TypeOopPtr::NOTNULL supposed to >>>>> represent? That doesn't seem like a valid type in the lattice >>>>> since it would have to correspond to Object:NotNull which is >>>>> already represented by TypeInstPtr::NOTNULL. Why will the graph be >>>>> incorrect if the type is TypeInstPtr::NOTNULL? >>>>> tom >>>>> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>>>>> >>>>>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >>>>>> TypeInstPtr::NOTNULL) >>>>>> >>>>>> Problem: >>>>>> I added this assert in 6875577 fix to catch cases when >>>>>> the type of the cloned object is TypeInstPtr::NOTNULL >>>>>> since it will produce incorrect graph. >>>>>> And Nightly testing found such case: the method >>>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, Object[] ao) >>>>>> returns the clone of the Object o argument. >>>>>> >>>>>> Solution: >>>>>> Use more general oop type TypeOopPtr::NOTNULL for >>>>>> additional CheckCastPP node in clone() instrinsic and arraycopy. >>>>>> Also fix instance_id meet for TypeOopPtr. >>>>>> >>>>>> Reviewed by: >>>>>> >>>>>> Fix verified (y/n): y, test >>>>>> >>>>>> Other testing: >>>>>> JPRT >>>>>> > From John.Rose at Sun.COM Wed Sep 9 19:31:45 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 09 Sep 2009 19:31:45 -0700 Subject: uncommon trap for athrow In-Reply-To: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> References: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> Message-ID: <72599AF7-126F-413A-A7C9-3E76F40BCE3E@sun.com> On Sep 9, 2009, at 4:27 PM, Tom Rodriguez wrote: > We got in a report, 6877221, complaining about the use of the > uncommon trap below for handling of an athrow. Anyone understand > why we use an uncommon trap here to dispatch an exception? That was a long time ago... That code gets used when a non-call bytecode needs to raise an exception, and also the method itself has local exception handlers. So in that case the compiler needs to wire up the potential local transfers of control between N non-call sites and M handlers. The wire-up is done by calling rethrow and then processing its result with catch_call_exceptions, which will eventually set up PC-to-PC mapping tables. (Confusingly, the rethrow stub jumps to the nmethod's sole exception handler area, which itself is always just a call to the exception blob, which after lots of waste movement calls SharedRuntime::compute_compiled_exc_handler. The PC returned by that guy is either an unwinder routine, or else a local PC prepared by catch_call_exceptions.) I suppose it would work to remove the code the customer is complaining about, but it might cause catch_call_exceptions to create a large number of a control flow edges. This in turn could degrade code quality and/or slow down compile times. Remember that an uncommon trap is cheaper than a branch, because the state along the trapping edge goes away, and does not affect downstream optimization or register allocation. It's maybe worth an experiment to remove that trap. It would be easy to put the uncommon trap under a switch. -- John From Vladimir.Kozlov at Sun.COM Wed Sep 9 19:47:29 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 09 Sep 2009 19:47:29 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <4AA86432.8000607@sun.com> References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> <4AA8490D.6050200@sun.com> <7542F21E-4FE4-4FB4-B809-0F209F66A32D@Sun.COM> <4AA86432.8000607@sun.com> Message-ID: <4AA868C1.7030302@sun.com> I am taking my previous statement back. We are already generating MembarCPUOrder after generic arraycopy under flag InsertMemBarAfterArraycopy which is true by default. The only place where we miss it is in clone() intrinsic. I will check the performance with it. Also we may need to generate it always (not under flag) when it is used for zeroing reduction. Vladimir Vladimir Kozlov wrote: > The problem with membar is that it is barrier for all memory, > we can't set it to slices corresponding only to this object. > It will prevent memory optimizations for other objects. > I don't remember other problems then this performance concern. > > Vladimir > > Tom Rodriguez wrote: >> At one point in the original discussion you suggested using >> MembarCPUOrder to enforce the ordering which allows us to leave the >> CheckCastPP in it's original location without adding another >> CheckCastPP. I'd prefer that to playing weird games with the types. >> Is that a viable fix? >> >> tom >> >> On Sep 9, 2009, at 5:32 PM, Vladimir Kozlov wrote: >> >>> It is valid C2 type since all type methods (xmeet) process it >>> but it should not exist from java point of view. And I'm using it >>> with assumption that none java programs use such type. >>> >>> I am also not fully comfortable with it but I can't find >>> other type which could be used (I tried). >>> I talked with John and he agreed with this change. >>> >>> I ran CTW and it did not find problems with this change. >>> But we may still hit some problems where we would expect >>> a real java type and will get this one. But such cases >>> should be caught by asserts we have. >>> >>> The other solution (which we rejected before) is to modify >>> oop map build to list raw pointers which have CheckCastPP >>> users. Then we will not need the second CheckCastPP. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> I suspected that was the purpose but TypeOopPtr::NOTNULL seems >>>> nonsensical to me. Is that really a valid type? >>>> tom >>>> On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: >>>>> As you remember we have 2 CheckCastPP nodes in clone() intrinsic. >>>>> One is original which we move and pin below arraycopy call >>>>> to guaranty that all memory accesses to the cloned object >>>>> are placed below arraycopy. >>>>> And the second is used to have a live oop across arraycopy call. >>>>> If both have the same type (bug's case) the >>>>> CheckCastPPNode::identity() >>>>> will eliminate the original CheckCastPP since it references the >>>>> second: >>>>> >>>>> // Replace raw memory edge with new CheckCastPP to have a live oop >>>>> // at safepoints instead of raw value. >>>>> assert(new_obj->is_CheckCastPP() && new_obj->in(1) == >>>>> alloc_obj->in(1), "sanity"); >>>>> alloc_obj->set_req(1, new_obj); >>>>> >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> I'm don't understand this. What is TypeOopPtr::NOTNULL supposed >>>>>> to represent? That doesn't seem like a valid type in the lattice >>>>>> since it would have to correspond to Object:NotNull which is >>>>>> already represented by TypeInstPtr::NOTNULL. Why will the graph >>>>>> be incorrect if the type is TypeInstPtr::NOTNULL? >>>>>> tom >>>>>> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>>>>>> >>>>>>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >>>>>>> TypeInstPtr::NOTNULL) >>>>>>> >>>>>>> Problem: >>>>>>> I added this assert in 6875577 fix to catch cases when >>>>>>> the type of the cloned object is TypeInstPtr::NOTNULL >>>>>>> since it will produce incorrect graph. >>>>>>> And Nightly testing found such case: the method >>>>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, Object[] ao) >>>>>>> returns the clone of the Object o argument. >>>>>>> >>>>>>> Solution: >>>>>>> Use more general oop type TypeOopPtr::NOTNULL for >>>>>>> additional CheckCastPP node in clone() instrinsic and arraycopy. >>>>>>> Also fix instance_id meet for TypeOopPtr. >>>>>>> >>>>>>> Reviewed by: >>>>>>> >>>>>>> Fix verified (y/n): y, test >>>>>>> >>>>>>> Other testing: >>>>>>> JPRT >>>>>>> >> From vladimir.kozlov at sun.com Wed Sep 9 20:13:38 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 10 Sep 2009 03:13:38 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6880533: test/compiler/6865031/Test.java miss -XX:+IgnoreUnrecognizedVMOptions Message-ID: <20090910031347.E33D0E3C6@hg.openjdk.java.net> Changeset: 9a4e87ba1a90 Author: kvn Date: 2009-09-09 16:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9a4e87ba1a90 6880533: test/compiler/6865031/Test.java miss -XX:+IgnoreUnrecognizedVMOptions Summary: Add missing test option -XX:+IgnoreUnrecognizedVMOptions. Reviewed-by: never ! test/compiler/6865031/Test.java From Thomas.Rodriguez at Sun.COM Thu Sep 10 11:11:49 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 10 Sep 2009 11:11:49 -0700 Subject: Request for reviews (XS): 6880574 In-Reply-To: <4AA857DA.2070608@sun.com> References: <4AA857DA.2070608@sun.com> Message-ID: <5DF775EF-64B2-4E3C-88C3-C19BD864E03A@sun.com> looks good. tom On Sep 9, 2009, at 6:35 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6880574/webrev.00 > > Fixed 6880574: C2 assert in escape.cpp:445 on linux-amd64 > > Problem: > Unsafe access may have several chained AddP nodes but > get_addp_base() method expects incorrectly only one. > > Solution: > Look through chained AddP nodes in get_addp_base(). > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Thu Sep 10 11:12:46 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 10 Sep 2009 11:12:46 -0700 Subject: Request for reviews (XS): 6880574 In-Reply-To: <5DF775EF-64B2-4E3C-88C3-C19BD864E03A@sun.com> References: <4AA857DA.2070608@sun.com> <5DF775EF-64B2-4E3C-88C3-C19BD864E03A@sun.com> Message-ID: <4AA9419E.8010804@sun.com> Thanks Tom, Vladimir Tom Rodriguez wrote: > looks good. > > tom > > On Sep 9, 2009, at 6:35 PM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6880574/webrev.00 >> >> Fixed 6880574: C2 assert in escape.cpp:445 on linux-amd64 >> >> Problem: >> Unsafe access may have several chained AddP nodes but >> get_addp_base() method expects incorrectly only one. >> >> Solution: >> Look through chained AddP nodes in get_addp_base(). >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > From Thomas.Rodriguez at Sun.COM Thu Sep 10 11:30:21 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 10 Sep 2009 11:30:21 -0700 Subject: uncommon trap for athrow In-Reply-To: <72599AF7-126F-413A-A7C9-3E76F40BCE3E@sun.com> References: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> <72599AF7-126F-413A-A7C9-3E76F40BCE3E@sun.com> Message-ID: <91677D2A-FF8C-4E76-B680-2C66588F53B9@Sun.COM> > That code gets used when a non-call bytecode needs to raise an > exception, and also the method itself has local exception handlers. > So in that case the compiler needs to wire up the potential local > transfers of control between N non-call sites and M handlers. The > wire-up is done by calling rethrow and then processing its result > with catch_call_exceptions, which will eventually set up PC-to-PC > mapping tables. > > (Confusingly, the rethrow stub jumps to the nmethod's sole exception > handler area, which itself is always just a call to the exception > blob, which after lots of waste movement calls > SharedRuntime::compute_compiled_exc_handler. The PC returned by > that guy is either an unwinder routine, or else a local PC prepared > by catch_call_exceptions.) > > I suppose it would work to remove the code the customer is > complaining about, but it might cause catch_call_exceptions to > create a large number of a control flow edges. This in turn could > degrade code quality and/or slow down compile times. Remember that > an uncommon trap is cheaper than a branch, because the state along > the trapping edge goes away, and does not affect downstream > optimization or register allocation. That makes some sense. I hadn't considered the extra edges that would be produced. It does mean that the exception path is much slower than it needs to be. In the test case it's explicitly throwing an exception which is going to be caught elsewhere in the method. It's clearly been boiled down from something larger which is why it looks so silly. while (true) { try { try { work(); throw new Exception(); } finally { } } catch (Exception e) { } } The throw causes an uncommon trap and then we spend time in the interpeter until we re-osr. The finally block acts as a funnel for all possible exceptions which keeps us from optimizing the throw into a direct transfer of control in the original compile. Disabling can_rerun_bytecode seems risky. For this case disallowing athrow from rerunning would probably fix it without expanding the number of edges too much though it seems like kind of a hack. Alternatively maybe the uncommon trap needs to have a proper trap count like other kinds of uncommon traps so that we could avoid it if it's hot. That might be better. Thanks! tom > > It's maybe worth an experiment to remove that trap. It would be > easy to put the uncommon trap under a switch. > > -- John From John.Rose at Sun.COM Thu Sep 10 12:02:14 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 10 Sep 2009 12:02:14 -0700 Subject: uncommon trap for athrow In-Reply-To: <91677D2A-FF8C-4E76-B680-2C66588F53B9@Sun.COM> References: <8AAABBB5-2E7E-4617-A199-4B3BA9468C75@sun.com> <72599AF7-126F-413A-A7C9-3E76F40BCE3E@sun.com> <91677D2A-FF8C-4E76-B680-2C66588F53B9@Sun.COM> Message-ID: On Sep 10, 2009, at 11:30 AM, Tom Rodriguez wrote: > maybe the uncommon trap needs to have a proper trap count like other > kinds of uncommon traps so that we could avoid it if it's hot. That > might be better. I agree; if it gets hot we should make the extra paths. -- John From vladimir.kozlov at sun.com Thu Sep 10 13:20:25 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 10 Sep 2009 20:20:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6880574: C2 assert in escape.cpp:445 on linux-amd64 Message-ID: <20090910202039.45DACE5D9@hg.openjdk.java.net> Changeset: 159d56b94894 Author: kvn Date: 2009-09-10 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/159d56b94894 6880574: C2 assert in escape.cpp:445 on linux-amd64 Summary: Look through chained AddP nodes in get_addp_base(). Reviewed-by: jrose ! src/share/vm/opto/escape.cpp From Vladimir.Kozlov at Sun.COM Thu Sep 10 14:35:47 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 10 Sep 2009 14:35:47 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <4AA868C1.7030302@sun.com> References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> <4AA8490D.6050200@sun.com> <7542F21E-4FE4-4FB4-B809-0F209F66A32D@Sun.COM> <4AA86432.8000607@sun.com> <4AA868C1.7030302@sun.com> Message-ID: <4AA97133.5080305@sun.com> I used MembarCPUOrder, removed second CheckCastPP and ran through CTW, JPRT and refworkload. I don't see performance difference. http://cr.openjdk.java.net/~kvn/6880053/webrev.01 Vladimir Vladimir Kozlov wrote: > I am taking my previous statement back. > > We are already generating MembarCPUOrder after generic arraycopy > under flag InsertMemBarAfterArraycopy which is true by default. > The only place where we miss it is in clone() intrinsic. > I will check the performance with it. Also we may need to > generate it always (not under flag) when it is used for > zeroing reduction. > > Vladimir > > Vladimir Kozlov wrote: >> The problem with membar is that it is barrier for all memory, >> we can't set it to slices corresponding only to this object. >> It will prevent memory optimizations for other objects. >> I don't remember other problems then this performance concern. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> At one point in the original discussion you suggested using >>> MembarCPUOrder to enforce the ordering which allows us to leave the >>> CheckCastPP in it's original location without adding another >>> CheckCastPP. I'd prefer that to playing weird games with the types. >>> Is that a viable fix? >>> >>> tom >>> >>> On Sep 9, 2009, at 5:32 PM, Vladimir Kozlov wrote: >>> >>>> It is valid C2 type since all type methods (xmeet) process it >>>> but it should not exist from java point of view. And I'm using it >>>> with assumption that none java programs use such type. >>>> >>>> I am also not fully comfortable with it but I can't find >>>> other type which could be used (I tried). >>>> I talked with John and he agreed with this change. >>>> >>>> I ran CTW and it did not find problems with this change. >>>> But we may still hit some problems where we would expect >>>> a real java type and will get this one. But such cases >>>> should be caught by asserts we have. >>>> >>>> The other solution (which we rejected before) is to modify >>>> oop map build to list raw pointers which have CheckCastPP >>>> users. Then we will not need the second CheckCastPP. >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> I suspected that was the purpose but TypeOopPtr::NOTNULL seems >>>>> nonsensical to me. Is that really a valid type? >>>>> tom >>>>> On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: >>>>>> As you remember we have 2 CheckCastPP nodes in clone() intrinsic. >>>>>> One is original which we move and pin below arraycopy call >>>>>> to guaranty that all memory accesses to the cloned object >>>>>> are placed below arraycopy. >>>>>> And the second is used to have a live oop across arraycopy call. >>>>>> If both have the same type (bug's case) the >>>>>> CheckCastPPNode::identity() >>>>>> will eliminate the original CheckCastPP since it references the >>>>>> second: >>>>>> >>>>>> // Replace raw memory edge with new CheckCastPP to have a live oop >>>>>> // at safepoints instead of raw value. >>>>>> assert(new_obj->is_CheckCastPP() && new_obj->in(1) == >>>>>> alloc_obj->in(1), "sanity"); >>>>>> alloc_obj->set_req(1, new_obj); >>>>>> >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> I'm don't understand this. What is TypeOopPtr::NOTNULL supposed >>>>>>> to represent? That doesn't seem like a valid type in the lattice >>>>>>> since it would have to correspond to Object:NotNull which is >>>>>>> already represented by TypeInstPtr::NOTNULL. Why will the graph >>>>>>> be incorrect if the type is TypeInstPtr::NOTNULL? >>>>>>> tom >>>>>>> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>>>>>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>>>>>>> >>>>>>>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >>>>>>>> TypeInstPtr::NOTNULL) >>>>>>>> >>>>>>>> Problem: >>>>>>>> I added this assert in 6875577 fix to catch cases when >>>>>>>> the type of the cloned object is TypeInstPtr::NOTNULL >>>>>>>> since it will produce incorrect graph. >>>>>>>> And Nightly testing found such case: the method >>>>>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, Object[] ao) >>>>>>>> returns the clone of the Object o argument. >>>>>>>> >>>>>>>> Solution: >>>>>>>> Use more general oop type TypeOopPtr::NOTNULL for >>>>>>>> additional CheckCastPP node in clone() instrinsic and arraycopy. >>>>>>>> Also fix instance_id meet for TypeOopPtr. >>>>>>>> >>>>>>>> Reviewed by: >>>>>>>> >>>>>>>> Fix verified (y/n): y, test >>>>>>>> >>>>>>>> Other testing: >>>>>>>> JPRT >>>>>>>> >>> From Thomas.Rodriguez at Sun.COM Thu Sep 10 15:11:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 10 Sep 2009 15:11:15 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <4AA97133.5080305@sun.com> References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> <4AA8490D.6050200@sun.com> <7542F21E-4FE4-4FB4-B809-0F209F66A32D@Sun.COM> <4AA86432.8000607@sun.com> <4AA868C1.7030302@sun.com> <4AA97133.5080305@sun.com> Message-ID: I like that much better. tom On Sep 10, 2009, at 2:35 PM, Vladimir Kozlov wrote: > I used MembarCPUOrder, removed second CheckCastPP and > ran through CTW, JPRT and refworkload. > I don't see performance difference. > > http://cr.openjdk.java.net/~kvn/6880053/webrev.01 > > Vladimir > > Vladimir Kozlov wrote: >> I am taking my previous statement back. >> We are already generating MembarCPUOrder after generic arraycopy >> under flag InsertMemBarAfterArraycopy which is true by default. >> The only place where we miss it is in clone() intrinsic. >> I will check the performance with it. Also we may need to >> generate it always (not under flag) when it is used for >> zeroing reduction. >> Vladimir >> Vladimir Kozlov wrote: >>> The problem with membar is that it is barrier for all memory, >>> we can't set it to slices corresponding only to this object. >>> It will prevent memory optimizations for other objects. >>> I don't remember other problems then this performance concern. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> At one point in the original discussion you suggested using >>>> MembarCPUOrder to enforce the ordering which allows us to leave >>>> the CheckCastPP in it's original location without adding another >>>> CheckCastPP. I'd prefer that to playing weird games with the >>>> types. Is that a viable fix? >>>> >>>> tom >>>> >>>> On Sep 9, 2009, at 5:32 PM, Vladimir Kozlov wrote: >>>> >>>>> It is valid C2 type since all type methods (xmeet) process it >>>>> but it should not exist from java point of view. And I'm using it >>>>> with assumption that none java programs use such type. >>>>> >>>>> I am also not fully comfortable with it but I can't find >>>>> other type which could be used (I tried). >>>>> I talked with John and he agreed with this change. >>>>> >>>>> I ran CTW and it did not find problems with this change. >>>>> But we may still hit some problems where we would expect >>>>> a real java type and will get this one. But such cases >>>>> should be caught by asserts we have. >>>>> >>>>> The other solution (which we rejected before) is to modify >>>>> oop map build to list raw pointers which have CheckCastPP >>>>> users. Then we will not need the second CheckCastPP. >>>>> >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> I suspected that was the purpose but TypeOopPtr::NOTNULL seems >>>>>> nonsensical to me. Is that really a valid type? >>>>>> tom >>>>>> On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: >>>>>>> As you remember we have 2 CheckCastPP nodes in clone() >>>>>>> intrinsic. >>>>>>> One is original which we move and pin below arraycopy call >>>>>>> to guaranty that all memory accesses to the cloned object >>>>>>> are placed below arraycopy. >>>>>>> And the second is used to have a live oop across arraycopy call. >>>>>>> If both have the same type (bug's case) the >>>>>>> CheckCastPPNode::identity() >>>>>>> will eliminate the original CheckCastPP since it references >>>>>>> the second: >>>>>>> >>>>>>> // Replace raw memory edge with new CheckCastPP to have a live >>>>>>> oop >>>>>>> // at safepoints instead of raw value. >>>>>>> assert(new_obj->is_CheckCastPP() && new_obj->in(1) == >>>>>>> alloc_obj->in(1), "sanity"); >>>>>>> alloc_obj->set_req(1, new_obj); >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> I'm don't understand this. What is TypeOopPtr::NOTNULL >>>>>>>> supposed to represent? That doesn't seem like a valid type >>>>>>>> in the lattice since it would have to correspond to >>>>>>>> Object:NotNull which is already represented by >>>>>>>> TypeInstPtr::NOTNULL. Why will the graph be incorrect if the >>>>>>>> type is TypeInstPtr::NOTNULL? >>>>>>>> tom >>>>>>>> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>>>>>>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>>>>>>>> >>>>>>>>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >>>>>>>>> TypeInstPtr::NOTNULL) >>>>>>>>> >>>>>>>>> Problem: >>>>>>>>> I added this assert in 6875577 fix to catch cases when >>>>>>>>> the type of the cloned object is TypeInstPtr::NOTNULL >>>>>>>>> since it will produce incorrect graph. >>>>>>>>> And Nightly testing found such case: the method >>>>>>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, >>>>>>>>> Object[] ao) >>>>>>>>> returns the clone of the Object o argument. >>>>>>>>> >>>>>>>>> Solution: >>>>>>>>> Use more general oop type TypeOopPtr::NOTNULL for >>>>>>>>> additional CheckCastPP node in clone() instrinsic and >>>>>>>>> arraycopy. >>>>>>>>> Also fix instance_id meet for TypeOopPtr. >>>>>>>>> >>>>>>>>> Reviewed by: >>>>>>>>> >>>>>>>>> Fix verified (y/n): y, test >>>>>>>>> >>>>>>>>> Other testing: >>>>>>>>> JPRT >>>>>>>>> >>>> From Changpeng.Fang at Sun.COM Thu Sep 10 15:13:58 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Thu, 10 Sep 2009 15:13:58 -0700 Subject: Request for reviews (S): 6877254: Server vm crashes with "no branches off of store slice" when run with CMS and UseSuperWord (default) In-Reply-To: <3BADB634-F23C-4DB2-8040-0FC55B8FD7ED@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A972188.5050905@sun.com> <4A9D62EA.6000909@sun.com> <4AA6F586.4090302@sun.com> <4AA70541.2050702@sun.com> <3BADB634-F23C-4DB2-8040-0FC55B8FD7ED@sun.com> Message-ID: <4AA97A26.5040002@sun.com> http://cr.openjdk.java.net/~cfang/6877254/webrev.01/ Updated with the test removed! * if (mem != my_store) {* Thanks, Changpeng On 09/08/09 21:34, Tom Rodriguez wrote: > > On Sep 8, 2009, at 6:30 PM, Vladimir Kozlov wrote: > >> I have concerns about StoreCMNode::Ideal(aidx) implementation. >> >> The result of memory_at() is never the same mergemem node. >> I either mergemem->base_memory() or mergemem->in(aidx) >> so your check will be always true. > > You're right but i think that just means we can drop that test. > >> >> Also mergemem nodes could be chained when the result of memory_at() >> is also mergemem. > > I figured Ideal would be called again if there was more work to do and > it should be a rare case anyway. The mem of a StoreCM should only be > something besides a Store if the StoreCM is dead or if something weird > has gone on with cloning. These changes are pretty conservative since > we don't have a clear set of rules for when a StoreCM is dead though I > think we could if we wanted to. > > tom > >> >> You can look on methods in memnode.cpp which search through >> mergemem for stores: step_through_mergemem(), find_previous_store(). >> >> Thanks, >> Vladimir >> >> Changpeng Fang wrote: >>> Need additional reviews (Tom (never) proposed the implementation, so >>> I assume he is oked )! >>> Comments are in the webrev. >>> On 09/01/09 11:07, Changpeng Fang wrote: >>>> http://cr.openjdk.java.net/~cfang/6877254/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Changpeng >>> Thanks, >>> Changpeng > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090910/4f9d9da9/attachment.html From Vladimir.Kozlov at Sun.COM Thu Sep 10 15:20:04 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 10 Sep 2009 15:20:04 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> <4AA8490D.6050200@sun.com> <7542F21E-4FE4-4FB4-B809-0F209F66A32D@Sun.COM> <4AA86432.8000607@sun.com> <4AA868C1.7030302@sun.com> <4AA97133.5080305@sun.com> Message-ID: <4AA97B94.4070005@sun.com> Thanks Tom Vladimir Tom Rodriguez wrote: > I like that much better. > > tom > > On Sep 10, 2009, at 2:35 PM, Vladimir Kozlov wrote: > >> I used MembarCPUOrder, removed second CheckCastPP and >> ran through CTW, JPRT and refworkload. >> I don't see performance difference. >> >> http://cr.openjdk.java.net/~kvn/6880053/webrev.01 >> >> Vladimir >> >> Vladimir Kozlov wrote: >>> I am taking my previous statement back. >>> We are already generating MembarCPUOrder after generic arraycopy >>> under flag InsertMemBarAfterArraycopy which is true by default. >>> The only place where we miss it is in clone() intrinsic. >>> I will check the performance with it. Also we may need to >>> generate it always (not under flag) when it is used for >>> zeroing reduction. >>> Vladimir >>> Vladimir Kozlov wrote: >>>> The problem with membar is that it is barrier for all memory, >>>> we can't set it to slices corresponding only to this object. >>>> It will prevent memory optimizations for other objects. >>>> I don't remember other problems then this performance concern. >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> At one point in the original discussion you suggested using >>>>> MembarCPUOrder to enforce the ordering which allows us to leave the >>>>> CheckCastPP in it's original location without adding another >>>>> CheckCastPP. I'd prefer that to playing weird games with the >>>>> types. Is that a viable fix? >>>>> >>>>> tom >>>>> >>>>> On Sep 9, 2009, at 5:32 PM, Vladimir Kozlov wrote: >>>>> >>>>>> It is valid C2 type since all type methods (xmeet) process it >>>>>> but it should not exist from java point of view. And I'm using it >>>>>> with assumption that none java programs use such type. >>>>>> >>>>>> I am also not fully comfortable with it but I can't find >>>>>> other type which could be used (I tried). >>>>>> I talked with John and he agreed with this change. >>>>>> >>>>>> I ran CTW and it did not find problems with this change. >>>>>> But we may still hit some problems where we would expect >>>>>> a real java type and will get this one. But such cases >>>>>> should be caught by asserts we have. >>>>>> >>>>>> The other solution (which we rejected before) is to modify >>>>>> oop map build to list raw pointers which have CheckCastPP >>>>>> users. Then we will not need the second CheckCastPP. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> I suspected that was the purpose but TypeOopPtr::NOTNULL seems >>>>>>> nonsensical to me. Is that really a valid type? >>>>>>> tom >>>>>>> On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: >>>>>>>> As you remember we have 2 CheckCastPP nodes in clone() intrinsic. >>>>>>>> One is original which we move and pin below arraycopy call >>>>>>>> to guaranty that all memory accesses to the cloned object >>>>>>>> are placed below arraycopy. >>>>>>>> And the second is used to have a live oop across arraycopy call. >>>>>>>> If both have the same type (bug's case) the >>>>>>>> CheckCastPPNode::identity() >>>>>>>> will eliminate the original CheckCastPP since it references the >>>>>>>> second: >>>>>>>> >>>>>>>> // Replace raw memory edge with new CheckCastPP to have a live oop >>>>>>>> // at safepoints instead of raw value. >>>>>>>> assert(new_obj->is_CheckCastPP() && new_obj->in(1) == >>>>>>>> alloc_obj->in(1), "sanity"); >>>>>>>> alloc_obj->set_req(1, new_obj); >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> I'm don't understand this. What is TypeOopPtr::NOTNULL >>>>>>>>> supposed to represent? That doesn't seem like a valid type in >>>>>>>>> the lattice since it would have to correspond to Object:NotNull >>>>>>>>> which is already represented by TypeInstPtr::NOTNULL. Why will >>>>>>>>> the graph be incorrect if the type is TypeInstPtr::NOTNULL? >>>>>>>>> tom >>>>>>>>> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>>>>>>>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>>>>>>>>> >>>>>>>>>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >>>>>>>>>> TypeInstPtr::NOTNULL) >>>>>>>>>> >>>>>>>>>> Problem: >>>>>>>>>> I added this assert in 6875577 fix to catch cases when >>>>>>>>>> the type of the cloned object is TypeInstPtr::NOTNULL >>>>>>>>>> since it will produce incorrect graph. >>>>>>>>>> And Nightly testing found such case: the method >>>>>>>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, Object[] >>>>>>>>>> ao) >>>>>>>>>> returns the clone of the Object o argument. >>>>>>>>>> >>>>>>>>>> Solution: >>>>>>>>>> Use more general oop type TypeOopPtr::NOTNULL for >>>>>>>>>> additional CheckCastPP node in clone() instrinsic and arraycopy. >>>>>>>>>> Also fix instance_id meet for TypeOopPtr. >>>>>>>>>> >>>>>>>>>> Reviewed by: >>>>>>>>>> >>>>>>>>>> Fix verified (y/n): y, test >>>>>>>>>> >>>>>>>>>> Other testing: >>>>>>>>>> JPRT >>>>>>>>>> >>>>> > From Vladimir.Kozlov at Sun.COM Thu Sep 10 15:23:39 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 10 Sep 2009 15:23:39 -0700 Subject: Request for reviews (S): 6877254: Server vm crashes with "no branches off of store slice" when run with CMS and UseSuperWord (default) In-Reply-To: <4AA97A26.5040002@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A972188.5050905@sun.com> <4A9D62EA.6000909@sun.com> <4AA6F586.4090302@sun.com> <4AA70541.2050702@sun.com> <3BADB634-F23C-4DB2-8040-0FC55B8FD7ED@sun.com> <4AA97A26.5040002@sun.com> Message-ID: <4AA97C6B.1000900@sun.com> Looks good. Vladimir Changpeng Fang wrote: > http://cr.openjdk.java.net/~cfang/6877254/webrev.01/ > > Updated with the test removed! > > * if (mem != my_store) {* > > > Thanks, > > Changpeng > > > On 09/08/09 21:34, Tom Rodriguez wrote: >> >> On Sep 8, 2009, at 6:30 PM, Vladimir Kozlov wrote: >> >>> I have concerns about StoreCMNode::Ideal(aidx) implementation. >>> >>> The result of memory_at() is never the same mergemem node. >>> I either mergemem->base_memory() or mergemem->in(aidx) >>> so your check will be always true. >> >> You're right but i think that just means we can drop that test. >> >>> >>> Also mergemem nodes could be chained when the result of memory_at() >>> is also mergemem. >> >> I figured Ideal would be called again if there was more work to do and >> it should be a rare case anyway. The mem of a StoreCM should only be >> something besides a Store if the StoreCM is dead or if something weird >> has gone on with cloning. These changes are pretty conservative since >> we don't have a clear set of rules for when a StoreCM is dead though I >> think we could if we wanted to. >> >> tom >> >>> >>> You can look on methods in memnode.cpp which search through >>> mergemem for stores: step_through_mergemem(), find_previous_store(). >>> >>> Thanks, >>> Vladimir >>> >>> Changpeng Fang wrote: >>>> Need additional reviews (Tom (never) proposed the implementation, so >>>> I assume he is oked )! >>>> Comments are in the webrev. >>>> On 09/01/09 11:07, Changpeng Fang wrote: >>>>> http://cr.openjdk.java.net/~cfang/6877254/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Changpeng >>>> Thanks, >>>> Changpeng >> > From Thomas.Rodriguez at Sun.COM Thu Sep 10 16:11:30 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 10 Sep 2009 16:11:30 -0700 Subject: review (S) for 6854812: 6.0_14-b08 crashes with a SIGSEGV Message-ID: <3EB379F3-2333-48FC-8539-987FC58C6AD5@Sun.COM> http://cr.openjdk.java.net/~never/6854812 From Vladimir.Kozlov at Sun.COM Thu Sep 10 18:08:40 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 10 Sep 2009 18:08:40 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <4AA97B94.4070005@sun.com> References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> <4AA8490D.6050200@sun.com> <7542F21E-4FE4-4FB4-B809-0F209F66A32D@Sun.COM> <4AA86432.8000607@sun.com> <4AA868C1.7030302@sun.com> <4AA97133.5080305@sun.com> <4AA97B94.4070005@sun.com> Message-ID: <4AA9A318.50305@sun.com> Tom, I forgot to add instance_id meet changes for TypeOopPtr in the last webrev. I added it: http://cr.openjdk.java.net/~kvn/6880053/webrev.01 Thanks, Vladimir Vladimir Kozlov wrote: > Thanks Tom > > Vladimir > > Tom Rodriguez wrote: >> I like that much better. >> >> tom >> >> On Sep 10, 2009, at 2:35 PM, Vladimir Kozlov wrote: >> >>> I used MembarCPUOrder, removed second CheckCastPP and >>> ran through CTW, JPRT and refworkload. >>> I don't see performance difference. >>> >>> http://cr.openjdk.java.net/~kvn/6880053/webrev.01 >>> >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> I am taking my previous statement back. >>>> We are already generating MembarCPUOrder after generic arraycopy >>>> under flag InsertMemBarAfterArraycopy which is true by default. >>>> The only place where we miss it is in clone() intrinsic. >>>> I will check the performance with it. Also we may need to >>>> generate it always (not under flag) when it is used for >>>> zeroing reduction. >>>> Vladimir >>>> Vladimir Kozlov wrote: >>>>> The problem with membar is that it is barrier for all memory, >>>>> we can't set it to slices corresponding only to this object. >>>>> It will prevent memory optimizations for other objects. >>>>> I don't remember other problems then this performance concern. >>>>> >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> At one point in the original discussion you suggested using >>>>>> MembarCPUOrder to enforce the ordering which allows us to leave >>>>>> the CheckCastPP in it's original location without adding another >>>>>> CheckCastPP. I'd prefer that to playing weird games with the >>>>>> types. Is that a viable fix? >>>>>> >>>>>> tom >>>>>> >>>>>> On Sep 9, 2009, at 5:32 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> It is valid C2 type since all type methods (xmeet) process it >>>>>>> but it should not exist from java point of view. And I'm using it >>>>>>> with assumption that none java programs use such type. >>>>>>> >>>>>>> I am also not fully comfortable with it but I can't find >>>>>>> other type which could be used (I tried). >>>>>>> I talked with John and he agreed with this change. >>>>>>> >>>>>>> I ran CTW and it did not find problems with this change. >>>>>>> But we may still hit some problems where we would expect >>>>>>> a real java type and will get this one. But such cases >>>>>>> should be caught by asserts we have. >>>>>>> >>>>>>> The other solution (which we rejected before) is to modify >>>>>>> oop map build to list raw pointers which have CheckCastPP >>>>>>> users. Then we will not need the second CheckCastPP. >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> I suspected that was the purpose but TypeOopPtr::NOTNULL seems >>>>>>>> nonsensical to me. Is that really a valid type? >>>>>>>> tom >>>>>>>> On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: >>>>>>>>> As you remember we have 2 CheckCastPP nodes in clone() intrinsic. >>>>>>>>> One is original which we move and pin below arraycopy call >>>>>>>>> to guaranty that all memory accesses to the cloned object >>>>>>>>> are placed below arraycopy. >>>>>>>>> And the second is used to have a live oop across arraycopy call. >>>>>>>>> If both have the same type (bug's case) the >>>>>>>>> CheckCastPPNode::identity() >>>>>>>>> will eliminate the original CheckCastPP since it references the >>>>>>>>> second: >>>>>>>>> >>>>>>>>> // Replace raw memory edge with new CheckCastPP to have a live oop >>>>>>>>> // at safepoints instead of raw value. >>>>>>>>> assert(new_obj->is_CheckCastPP() && new_obj->in(1) == >>>>>>>>> alloc_obj->in(1), "sanity"); >>>>>>>>> alloc_obj->set_req(1, new_obj); >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>> I'm don't understand this. What is TypeOopPtr::NOTNULL >>>>>>>>>> supposed to represent? That doesn't seem like a valid type in >>>>>>>>>> the lattice since it would have to correspond to >>>>>>>>>> Object:NotNull which is already represented by >>>>>>>>>> TypeInstPtr::NOTNULL. Why will the graph be incorrect if the >>>>>>>>>> type is TypeInstPtr::NOTNULL? >>>>>>>>>> tom >>>>>>>>>> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>>>>>>>>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>>>>>>>>>> >>>>>>>>>>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >>>>>>>>>>> TypeInstPtr::NOTNULL) >>>>>>>>>>> >>>>>>>>>>> Problem: >>>>>>>>>>> I added this assert in 6875577 fix to catch cases when >>>>>>>>>>> the type of the cloned object is TypeInstPtr::NOTNULL >>>>>>>>>>> since it will produce incorrect graph. >>>>>>>>>>> And Nightly testing found such case: the method >>>>>>>>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, >>>>>>>>>>> Object[] ao) >>>>>>>>>>> returns the clone of the Object o argument. >>>>>>>>>>> >>>>>>>>>>> Solution: >>>>>>>>>>> Use more general oop type TypeOopPtr::NOTNULL for >>>>>>>>>>> additional CheckCastPP node in clone() instrinsic and arraycopy. >>>>>>>>>>> Also fix instance_id meet for TypeOopPtr. >>>>>>>>>>> >>>>>>>>>>> Reviewed by: >>>>>>>>>>> >>>>>>>>>>> Fix verified (y/n): y, test >>>>>>>>>>> >>>>>>>>>>> Other testing: >>>>>>>>>>> JPRT >>>>>>>>>>> >>>>>> >> From vladimir.kozlov at sun.com Fri Sep 11 00:49:12 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 11 Sep 2009 07:49:12 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Message-ID: <20090911074922.AA3E4EF26@hg.openjdk.java.net> Changeset: c7e94e8fff43 Author: kvn Date: 2009-09-10 18:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c7e94e8fff43 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Summary: Removed second CheckCastPP and use MembarCPUOrder after arraycopy to cloned object. Reviewed-by: never ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp From Vladimir.Kozlov at Sun.COM Fri Sep 11 10:10:16 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 11 Sep 2009 10:10:16 -0700 Subject: Request for reviews (L) (resending): 6827605 and 6875866 for HS17 Message-ID: <4AAA8478.6030006@sun.com> I still need reviews for this (and I merged it with latest sources). http://cr.openjdk.java.net/~kvn/6827605/webrev.02 Fixed 6827605: new String intrinsics may prevent EA scalar replacement Fixed 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 Problem: New String.indexOf SSE4.2 intrinsic prevents EA scalar replacement of String object clone in the famous hot jbb code in Orderline.process: stockData.indexOf("ORIGINAL") (6827605). Also String.indexOf SSE4.2 code starts string rescanning from a wrong place after failing to match a part of substring (6875866). Solution: Modify String intrinsic methods to pass char[] pointers and counters instead of string oops to allow EA eliminate non-escaping string objects. Move some checks from mach nodes encoding into ideal graph. Move common assembler code into MacroAssembler. Add memory edge to AryEqNode. Fix 6875866. Reviewed by: Fix verified (y/n): y, refworkload Other testing: JPRT, CTW From Christian.Thalinger at Sun.COM Mon Sep 14 04:31:03 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 14 Sep 2009 13:31:03 +0200 Subject: review (S) for 6854812: 6.0_14-b08 crashes with a SIGSEGV In-Reply-To: <3EB379F3-2333-48FC-8539-987FC58C6AD5@Sun.COM> References: <3EB379F3-2333-48FC-8539-987FC58C6AD5@Sun.COM> Message-ID: <4AAE2977.8040706@Sun.COM> Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6854812 src/share/vm/ci/ciMethod.hpp: + // maintained as live for deopt. raw_liveness is always the direct Could you change that saying "raw_liveness_bci_at"? Just to be in sync. Otherwise looks good. -- Christian From Thomas.Rodriguez at Sun.COM Mon Sep 14 08:57:04 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 14 Sep 2009 08:57:04 -0700 Subject: review (S) for 6854812: 6.0_14-b08 crashes with a SIGSEGV In-Reply-To: <4AAE2977.8040706@Sun.COM> References: <3EB379F3-2333-48FC-8539-987FC58C6AD5@Sun.COM> <4AAE2977.8040706@Sun.COM> Message-ID: <620FC334-0433-4FE6-8E96-66B9784C4A57@Sun.COM> Fixed. Thanks! tom On Sep 14, 2009, at 4:31 AM, Christian Thalinger wrote: > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6854812 > > src/share/vm/ci/ciMethod.hpp: > > + // maintained as live for deopt. raw_liveness is always the > direct > > Could you change that saying "raw_liveness_bci_at"? Just to be in > sync. > > Otherwise looks good. > > -- Christian From Thomas.Rodriguez at Sun.COM Mon Sep 14 11:40:58 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 14 Sep 2009 11:40:58 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: <4AA9A318.50305@sun.com> References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> <4AA8490D.6050200@sun.com> <7542F21E-4FE4-4FB4-B809-0F209F66A32D@Sun.COM> <4AA86432.8000607@sun.com> <4AA868C1.7030302@sun.com> <4AA97133.5080305@sun.com> <4AA97B94.4070005@sun.com> <4AA9A318.50305@sun.com> Message-ID: Why not require instance_id to be specified instead of it being optional? tom On Sep 10, 2009, at 6:08 PM, Vladimir Kozlov wrote: > Tom, > > I forgot to add instance_id meet changes for TypeOopPtr > in the last webrev. I added it: > > http://cr.openjdk.java.net/~kvn/6880053/webrev.01 > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> Thanks Tom >> Vladimir >> Tom Rodriguez wrote: >>> I like that much better. >>> >>> tom >>> >>> On Sep 10, 2009, at 2:35 PM, Vladimir Kozlov wrote: >>> >>>> I used MembarCPUOrder, removed second CheckCastPP and >>>> ran through CTW, JPRT and refworkload. >>>> I don't see performance difference. >>>> >>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.01 >>>> >>>> Vladimir >>>> >>>> Vladimir Kozlov wrote: >>>>> I am taking my previous statement back. >>>>> We are already generating MembarCPUOrder after generic arraycopy >>>>> under flag InsertMemBarAfterArraycopy which is true by default. >>>>> The only place where we miss it is in clone() intrinsic. >>>>> I will check the performance with it. Also we may need to >>>>> generate it always (not under flag) when it is used for >>>>> zeroing reduction. >>>>> Vladimir >>>>> Vladimir Kozlov wrote: >>>>>> The problem with membar is that it is barrier for all memory, >>>>>> we can't set it to slices corresponding only to this object. >>>>>> It will prevent memory optimizations for other objects. >>>>>> I don't remember other problems then this performance concern. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> At one point in the original discussion you suggested using >>>>>>> MembarCPUOrder to enforce the ordering which allows us to >>>>>>> leave the CheckCastPP in it's original location without adding >>>>>>> another CheckCastPP. I'd prefer that to playing weird games >>>>>>> with the types. Is that a viable fix? >>>>>>> >>>>>>> tom >>>>>>> >>>>>>> On Sep 9, 2009, at 5:32 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> It is valid C2 type since all type methods (xmeet) process it >>>>>>>> but it should not exist from java point of view. And I'm >>>>>>>> using it >>>>>>>> with assumption that none java programs use such type. >>>>>>>> >>>>>>>> I am also not fully comfortable with it but I can't find >>>>>>>> other type which could be used (I tried). >>>>>>>> I talked with John and he agreed with this change. >>>>>>>> >>>>>>>> I ran CTW and it did not find problems with this change. >>>>>>>> But we may still hit some problems where we would expect >>>>>>>> a real java type and will get this one. But such cases >>>>>>>> should be caught by asserts we have. >>>>>>>> >>>>>>>> The other solution (which we rejected before) is to modify >>>>>>>> oop map build to list raw pointers which have CheckCastPP >>>>>>>> users. Then we will not need the second CheckCastPP. >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> I suspected that was the purpose but TypeOopPtr::NOTNULL >>>>>>>>> seems nonsensical to me. Is that really a valid type? >>>>>>>>> tom >>>>>>>>> On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: >>>>>>>>>> As you remember we have 2 CheckCastPP nodes in clone() >>>>>>>>>> intrinsic. >>>>>>>>>> One is original which we move and pin below arraycopy call >>>>>>>>>> to guaranty that all memory accesses to the cloned object >>>>>>>>>> are placed below arraycopy. >>>>>>>>>> And the second is used to have a live oop across arraycopy >>>>>>>>>> call. >>>>>>>>>> If both have the same type (bug's case) the >>>>>>>>>> CheckCastPPNode::identity() >>>>>>>>>> will eliminate the original CheckCastPP since it references >>>>>>>>>> the second: >>>>>>>>>> >>>>>>>>>> // Replace raw memory edge with new CheckCastPP to have a >>>>>>>>>> live oop >>>>>>>>>> // at safepoints instead of raw value. >>>>>>>>>> assert(new_obj->is_CheckCastPP() && new_obj->in(1) == >>>>>>>>>> alloc_obj->in(1), "sanity"); >>>>>>>>>> alloc_obj->set_req(1, new_obj); >>>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>> I'm don't understand this. What is TypeOopPtr::NOTNULL >>>>>>>>>>> supposed to represent? That doesn't seem like a valid >>>>>>>>>>> type in the lattice since it would have to correspond to >>>>>>>>>>> Object:NotNull which is already represented by >>>>>>>>>>> TypeInstPtr::NOTNULL. Why will the graph be incorrect if >>>>>>>>>>> the type is TypeInstPtr::NOTNULL? >>>>>>>>>>> tom >>>>>>>>>>> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>>>>>>>>>>> >>>>>>>>>>>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()- >>>>>>>>>>>> >type() != TypeInstPtr::NOTNULL) >>>>>>>>>>>> >>>>>>>>>>>> Problem: >>>>>>>>>>>> I added this assert in 6875577 fix to catch cases when >>>>>>>>>>>> the type of the cloned object is TypeInstPtr::NOTNULL >>>>>>>>>>>> since it will produce incorrect graph. >>>>>>>>>>>> And Nightly testing found such case: the method >>>>>>>>>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, >>>>>>>>>>>> Object[] ao) >>>>>>>>>>>> returns the clone of the Object o argument. >>>>>>>>>>>> >>>>>>>>>>>> Solution: >>>>>>>>>>>> Use more general oop type TypeOopPtr::NOTNULL for >>>>>>>>>>>> additional CheckCastPP node in clone() instrinsic and >>>>>>>>>>>> arraycopy. >>>>>>>>>>>> Also fix instance_id meet for TypeOopPtr. >>>>>>>>>>>> >>>>>>>>>>>> Reviewed by: >>>>>>>>>>>> >>>>>>>>>>>> Fix verified (y/n): y, test >>>>>>>>>>>> >>>>>>>>>>>> Other testing: >>>>>>>>>>>> JPRT >>>>>>>>>>>> >>>>>>> >>> From Thomas.Rodriguez at Sun.COM Mon Sep 14 11:46:49 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 14 Sep 2009 11:46:49 -0700 Subject: Request for reviews (L) (resending): 6827605 and 6875866 for HS17 In-Reply-To: <4AAA8478.6030006@sun.com> References: <4AAA8478.6030006@sun.com> Message-ID: looks good. tom On Sep 11, 2009, at 10:10 AM, Vladimir Kozlov wrote: > I still need reviews for this (and I merged it with latest sources). > > http://cr.openjdk.java.net/~kvn/6827605/webrev.02 > > Fixed 6827605: new String intrinsics may prevent EA scalar replacement > Fixed 6875866: Intrinsic for String.indexOf() is broken on x86 with > SSE4.2 > > Problem: > New String.indexOf SSE4.2 intrinsic prevents EA scalar replacement > of String object clone in the famous hot jbb code in > Orderline.process: > stockData.indexOf("ORIGINAL") (6827605). > Also String.indexOf SSE4.2 code starts string rescanning from > a wrong place after failing to match a part of substring (6875866). > > Solution: > Modify String intrinsic methods to pass char[] pointers and > counters instead of string oops to allow EA eliminate > non-escaping string objects. Move some checks from > mach nodes encoding into ideal graph. > Move common assembler code into MacroAssembler. > Add memory edge to AryEqNode. > Fix 6875866. > > Reviewed by: > > Fix verified (y/n): y, refworkload > > Other testing: > JPRT, CTW > From Vladimir.Kozlov at Sun.COM Mon Sep 14 11:56:03 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 14 Sep 2009 11:56:03 -0700 Subject: Request for reviews (S): 6880053 In-Reply-To: References: <4AA82DB7.6060200@sun.com> <4B28135F-8C64-4FFD-B0A6-0BBF8E284905@sun.com> <4AA83D94.4000708@sun.com> <08ECA159-67E3-4C3E-96DE-EDDC176A7FF9@Sun.COM> <4AA8490D.6050200@sun.com> <7542F21E-4FE4-4FB4-B809-0F209F66A32D@Sun.COM> <4AA86432.8000607@sun.com> <4AA868C1.7030302@sun.com> <4AA97133.5080305@sun.com> <4AA97B94.4070005@sun.com> <4AA9A318.50305@sun.com> Message-ID: <4AAE91C3.3000401@sun.com> You are right. It doesn't need to be optional. The code is in repository already, I pushed it on Friday for testing over weekend. So I will change it next time. Thanks, Vladimir Tom Rodriguez wrote: > Why not require instance_id to be specified instead of it being optional? > > tom > > On Sep 10, 2009, at 6:08 PM, Vladimir Kozlov wrote: > >> Tom, >> >> I forgot to add instance_id meet changes for TypeOopPtr >> in the last webrev. I added it: >> >> http://cr.openjdk.java.net/~kvn/6880053/webrev.01 >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> Thanks Tom >>> Vladimir >>> Tom Rodriguez wrote: >>>> I like that much better. >>>> >>>> tom >>>> >>>> On Sep 10, 2009, at 2:35 PM, Vladimir Kozlov wrote: >>>> >>>>> I used MembarCPUOrder, removed second CheckCastPP and >>>>> ran through CTW, JPRT and refworkload. >>>>> I don't see performance difference. >>>>> >>>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.01 >>>>> >>>>> Vladimir >>>>> >>>>> Vladimir Kozlov wrote: >>>>>> I am taking my previous statement back. >>>>>> We are already generating MembarCPUOrder after generic arraycopy >>>>>> under flag InsertMemBarAfterArraycopy which is true by default. >>>>>> The only place where we miss it is in clone() intrinsic. >>>>>> I will check the performance with it. Also we may need to >>>>>> generate it always (not under flag) when it is used for >>>>>> zeroing reduction. >>>>>> Vladimir >>>>>> Vladimir Kozlov wrote: >>>>>>> The problem with membar is that it is barrier for all memory, >>>>>>> we can't set it to slices corresponding only to this object. >>>>>>> It will prevent memory optimizations for other objects. >>>>>>> I don't remember other problems then this performance concern. >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> At one point in the original discussion you suggested using >>>>>>>> MembarCPUOrder to enforce the ordering which allows us to leave >>>>>>>> the CheckCastPP in it's original location without adding another >>>>>>>> CheckCastPP. I'd prefer that to playing weird games with the >>>>>>>> types. Is that a viable fix? >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>> On Sep 9, 2009, at 5:32 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> It is valid C2 type since all type methods (xmeet) process it >>>>>>>>> but it should not exist from java point of view. And I'm using it >>>>>>>>> with assumption that none java programs use such type. >>>>>>>>> >>>>>>>>> I am also not fully comfortable with it but I can't find >>>>>>>>> other type which could be used (I tried). >>>>>>>>> I talked with John and he agreed with this change. >>>>>>>>> >>>>>>>>> I ran CTW and it did not find problems with this change. >>>>>>>>> But we may still hit some problems where we would expect >>>>>>>>> a real java type and will get this one. But such cases >>>>>>>>> should be caught by asserts we have. >>>>>>>>> >>>>>>>>> The other solution (which we rejected before) is to modify >>>>>>>>> oop map build to list raw pointers which have CheckCastPP >>>>>>>>> users. Then we will not need the second CheckCastPP. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>> I suspected that was the purpose but TypeOopPtr::NOTNULL seems >>>>>>>>>> nonsensical to me. Is that really a valid type? >>>>>>>>>> tom >>>>>>>>>> On Sep 9, 2009, at 4:43 PM, Vladimir Kozlov wrote: >>>>>>>>>>> As you remember we have 2 CheckCastPP nodes in clone() >>>>>>>>>>> intrinsic. >>>>>>>>>>> One is original which we move and pin below arraycopy call >>>>>>>>>>> to guaranty that all memory accesses to the cloned object >>>>>>>>>>> are placed below arraycopy. >>>>>>>>>>> And the second is used to have a live oop across arraycopy call. >>>>>>>>>>> If both have the same type (bug's case) the >>>>>>>>>>> CheckCastPPNode::identity() >>>>>>>>>>> will eliminate the original CheckCastPP since it references >>>>>>>>>>> the second: >>>>>>>>>>> >>>>>>>>>>> // Replace raw memory edge with new CheckCastPP to have a >>>>>>>>>>> live oop >>>>>>>>>>> // at safepoints instead of raw value. >>>>>>>>>>> assert(new_obj->is_CheckCastPP() && new_obj->in(1) == >>>>>>>>>>> alloc_obj->in(1), "sanity"); >>>>>>>>>>> alloc_obj->set_req(1, new_obj); >>>>>>>>>>> >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>> I'm don't understand this. What is TypeOopPtr::NOTNULL >>>>>>>>>>>> supposed to represent? That doesn't seem like a valid type >>>>>>>>>>>> in the lattice since it would have to correspond to >>>>>>>>>>>> Object:NotNull which is already represented by >>>>>>>>>>>> TypeInstPtr::NOTNULL. Why will the graph be incorrect if >>>>>>>>>>>> the type is TypeInstPtr::NOTNULL? >>>>>>>>>>>> tom >>>>>>>>>>>> On Sep 9, 2009, at 3:35 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/6880053/webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() >>>>>>>>>>>>> != TypeInstPtr::NOTNULL) >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: >>>>>>>>>>>>> I added this assert in 6875577 fix to catch cases when >>>>>>>>>>>>> the type of the cloned object is TypeInstPtr::NOTNULL >>>>>>>>>>>>> since it will produce incorrect graph. >>>>>>>>>>>>> And Nightly testing found such case: the method >>>>>>>>>>>>> sun.reflect.GeneratedMethodAccessor4.invoke(Object o, >>>>>>>>>>>>> Object[] ao) >>>>>>>>>>>>> returns the clone of the Object o argument. >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: >>>>>>>>>>>>> Use more general oop type TypeOopPtr::NOTNULL for >>>>>>>>>>>>> additional CheckCastPP node in clone() instrinsic and >>>>>>>>>>>>> arraycopy. >>>>>>>>>>>>> Also fix instance_id meet for TypeOopPtr. >>>>>>>>>>>>> >>>>>>>>>>>>> Reviewed by: >>>>>>>>>>>>> >>>>>>>>>>>>> Fix verified (y/n): y, test >>>>>>>>>>>>> >>>>>>>>>>>>> Other testing: >>>>>>>>>>>>> JPRT >>>>>>>>>>>>> >>>>>>>> >>>> > From Vladimir.Kozlov at Sun.COM Mon Sep 14 11:57:07 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 14 Sep 2009 11:57:07 -0700 Subject: Request for reviews (L) (resending): 6827605 and 6875866 for HS17 In-Reply-To: References: <4AAA8478.6030006@sun.com> Message-ID: <4AAE9203.3060606@sun.com> Thanks, Tom Vladimir Tom Rodriguez wrote: > looks good. > > tom > > On Sep 11, 2009, at 10:10 AM, Vladimir Kozlov wrote: > >> I still need reviews for this (and I merged it with latest sources). >> >> http://cr.openjdk.java.net/~kvn/6827605/webrev.02 >> >> Fixed 6827605: new String intrinsics may prevent EA scalar replacement >> Fixed 6875866: Intrinsic for String.indexOf() is broken on x86 with >> SSE4.2 >> >> Problem: >> New String.indexOf SSE4.2 intrinsic prevents EA scalar replacement >> of String object clone in the famous hot jbb code in Orderline.process: >> stockData.indexOf("ORIGINAL") (6827605). >> Also String.indexOf SSE4.2 code starts string rescanning from >> a wrong place after failing to match a part of substring (6875866). >> >> Solution: >> Modify String intrinsic methods to pass char[] pointers and >> counters instead of string oops to allow EA eliminate >> non-escaping string objects. Move some checks from >> mach nodes encoding into ideal graph. >> Move common assembler code into MacroAssembler. >> Add memory edge to AryEqNode. >> Fix 6875866. >> >> Reviewed by: >> >> Fix verified (y/n): y, refworkload >> >> Other testing: >> JPRT, CTW >> > From changpeng.fang at sun.com Mon Sep 14 12:00:58 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Mon, 14 Sep 2009 19:00:58 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6877254: Server vm crashes with no branches off of store slice" when run with CMS and UseSuperWord(default) Message-ID: <20090914190111.831AB12157@hg.openjdk.java.net> Changeset: 685e959d09ea Author: cfang Date: 2009-09-14 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/685e959d09ea 6877254: Server vm crashes with no branches off of store slice" when run with CMS and UseSuperWord(default) Summary: design StoreCMNode::Ideal to promote its oopStore input if the input is a MergeMem node Reviewed-by: kvn, never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/superword.cpp + test/compiler/6877254/Test.java From vladimir.kozlov at sun.com Mon Sep 14 18:21:56 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 15 Sep 2009 01:21:56 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6827605: new String intrinsics may prevent EA scalar replacement; ... Message-ID: <20090915012207.23DFD121B3@hg.openjdk.java.net> Changeset: 62001a362ce9 Author: kvn Date: 2009-09-14 12:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/62001a362ce9 6827605: new String intrinsics may prevent EA scalar replacement 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 Summary: Modify String intrinsic methods to pass char[] pointers instead of string oops. Reviewed-by: never ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6875866/Test.java From Changpeng.Fang at Sun.COM Tue Sep 15 10:07:46 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Tue, 15 Sep 2009 10:07:46 -0700 Subject: Request for reviews (S): 6879921: CTW failure jdk6_18/hotspot/src/share/vm/utilities/globalDefinitions.cpp:268 In-Reply-To: <4A972188.5050905@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A972188.5050905@sun.com> Message-ID: <4AAFC9E2.7030400@sun.com> http://cr.openjdk.java.net/~cfang/6879921/webrev.00/ Problem: We do not intend to apply superword to non-primitive types. Current SuperWord implementation filters out non-primitives when it creates the initial set of packs through "find_adjacent_refs". However, when it extends the packlists using the def-use or use-def chains, non-primitives may still be put into consideration, and this leads to the assertion failure when we compute the data size of a T_ADDRESS type (bug 6879921). Solution: Filter out non-primitives when we extend the initial packlists (i.e. don't consider packing non-primitive defs and uses). Fixes 6879921: CTW failure jdk6_18/hotspot/src/share/vm/utilities/globalDefinitions.cpp:268 Tests: JPRT and CTW Thanks, Changpeng From Thomas.Rodriguez at Sun.COM Tue Sep 15 10:34:56 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 15 Sep 2009 10:34:56 -0700 Subject: Request for reviews (S): 6879921: CTW failure jdk6_18/hotspot/src/share/vm/utilities/globalDefinitions.cpp:268 In-Reply-To: <4AAFC9E2.7030400@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A972188.5050905@sun.com> <4AAFC9E2.7030400@sun.com> Message-ID: Looks good. tom On Sep 15, 2009, at 10:07 AM, Changpeng Fang wrote: > http://cr.openjdk.java.net/~cfang/6879921/webrev.00/ > > Problem: > We do not intend to apply superword to non-primitive types. Current > SuperWord > implementation filters out non-primitives when it creates the > initial set of > packs through "find_adjacent_refs". However, when it extends the > packlists > using the def-use or use-def chains, non-primitives may still be put > into > consideration, and this leads to the assertion failure when we > compute the > data size of a T_ADDRESS type (bug 6879921). > > Solution: > Filter out non-primitives when we extend the initial packlists (i.e. > don't consider > packing non-primitive defs and uses). > > Fixes 6879921: CTW failure jdk6_18/hotspot/src/share/vm/utilities/ > globalDefinitions.cpp:268 > > Tests: > JPRT and CTW > > Thanks, > > Changpeng From Vladimir.Kozlov at Sun.COM Tue Sep 15 11:03:31 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 15 Sep 2009 11:03:31 -0700 Subject: Request for reviews (S): 6879921: CTW failure jdk6_18/hotspot/src/share/vm/utilities/globalDefinitions.cpp:268 In-Reply-To: <4AAFC9E2.7030400@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A972188.5050905@sun.com> <4AAFC9E2.7030400@sun.com> Message-ID: <4AAFD6F3.4040505@sun.com> Good. Vladimir Changpeng Fang wrote: > http://cr.openjdk.java.net/~cfang/6879921/webrev.00/ > > Problem: > We do not intend to apply superword to non-primitive types. Current > SuperWord > implementation filters out non-primitives when it creates the initial > set of > packs through "find_adjacent_refs". However, when it extends the packlists > using the def-use or use-def chains, non-primitives may still be put into > consideration, and this leads to the assertion failure when we compute the > data size of a T_ADDRESS type (bug 6879921). > > Solution: > Filter out non-primitives when we extend the initial packlists (i.e. > don't consider > packing non-primitive defs and uses). > > Fixes 6879921: CTW failure > jdk6_18/hotspot/src/share/vm/utilities/globalDefinitions.cpp:268 > > Tests: > JPRT and CTW > > Thanks, > > Changpeng From changpeng.fang at sun.com Tue Sep 15 13:21:03 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Tue, 15 Sep 2009 20:21:03 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6879921: CTW failure jdk6_18/hotspot/src/share/vm/utilities/globalDefinitions.cpp:268 Message-ID: <20090915202111.D440812229@hg.openjdk.java.net> Changeset: 00977607da34 Author: cfang Date: 2009-09-15 11:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/00977607da34 6879921: CTW failure jdk6_18/hotspot/src/share/vm/utilities/globalDefinitions.cpp:268 Summary: filter out non-primitives before deciding whether two ops can be packed Reviewed-by: kvn, never ! src/share/vm/opto/superword.cpp From Vladimir.Kozlov at Sun.COM Tue Sep 15 17:44:56 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 15 Sep 2009 17:44:56 -0700 Subject: Request for reviews (XS): 6879362 Message-ID: <4AB03508.7030608@sun.com> http://cr.openjdk.java.net/~kvn/6879362/webrev.00 Fixed 6879362: assert(!klass_is_exact(),"only non-exact klass") Problem: The AddP type could be not related to the type of allocated object when CHA type is different from MDO type on a dead path (for example, from instanceof check) which is not collapsed during parsing. Solution: Do nothing for such AddP node and don't process its users during escape analysis since this code branch will go away. Reviewed by: Fix verified (y/n): y, test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Tue Sep 15 17:58:39 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 15 Sep 2009 17:58:39 -0700 Subject: Request for reviews (XS): 6879362 In-Reply-To: <4AB03508.7030608@sun.com> References: <4AB03508.7030608@sun.com> Message-ID: <3177F632-2792-4920-B4F7-00AFF189C298@sun.com> Doesn't !is_subtype_of imply !equals? tom On Sep 15, 2009, at 5:44 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6879362/webrev.00 > > Fixed 6879362: assert(!klass_is_exact(),"only non-exact klass") > > Problem: > The AddP type could be not related to the type of > allocated object when CHA type is different from MDO type > on a dead path (for example, from instanceof check) > which is not collapsed during parsing. > > Solution: > Do nothing for such AddP node and don't process its users > during escape analysis since this code branch will go away. > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Tue Sep 15 18:04:33 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 15 Sep 2009 18:04:33 -0700 Subject: Request for reviews (XS): 6879362 In-Reply-To: <3177F632-2792-4920-B4F7-00AFF189C298@sun.com> References: <4AB03508.7030608@sun.com> <3177F632-2792-4920-B4F7-00AFF189C298@sun.com> Message-ID: <4AB039A1.9070804@sun.com> Yes, the equals check could be removed now. Thanks, Vladimir Tom Rodriguez wrote: > Doesn't !is_subtype_of imply !equals? > > tom > > On Sep 15, 2009, at 5:44 PM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6879362/webrev.00 >> >> Fixed 6879362: assert(!klass_is_exact(),"only non-exact klass") >> >> Problem: >> The AddP type could be not related to the type of >> allocated object when CHA type is different from MDO type >> on a dead path (for example, from instanceof check) >> which is not collapsed during parsing. >> >> Solution: >> Do nothing for such AddP node and don't process its users >> during escape analysis since this code branch will go away. >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > From Vladimir.Kozlov at Sun.COM Tue Sep 15 18:52:45 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 15 Sep 2009 18:52:45 -0700 Subject: Request for reviews (XS): 6879362 In-Reply-To: <4AB039A1.9070804@sun.com> References: <4AB03508.7030608@sun.com> <3177F632-2792-4920-B4F7-00AFF189C298@sun.com> <4AB039A1.9070804@sun.com> Message-ID: <4AB044ED.6030605@sun.com> I updated webrev and ran jbb and microbenchmarks to verify that this change does not have regression in allocation elimination. Vladimir Vladimir Kozlov wrote: > Yes, the equals check could be removed now. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> Doesn't !is_subtype_of imply !equals? >> >> tom >> >> On Sep 15, 2009, at 5:44 PM, Vladimir Kozlov wrote: >> >>> >>> http://cr.openjdk.java.net/~kvn/6879362/webrev.00 >>> >>> Fixed 6879362: assert(!klass_is_exact(),"only non-exact klass") >>> >>> Problem: >>> The AddP type could be not related to the type of >>> allocated object when CHA type is different from MDO type >>> on a dead path (for example, from instanceof check) >>> which is not collapsed during parsing. >>> >>> Solution: >>> Do nothing for such AddP node and don't process its users >>> during escape analysis since this code branch will go away. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, test >>> >>> Other testing: >>> JPRT >>> >> From vladimir.kozlov at sun.com Tue Sep 15 22:48:21 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 16 Sep 2009 05:48:21 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6879362: assert(!klass_is_exact(), "only non-exact klass") Message-ID: <20090916054823.34B5812273@hg.openjdk.java.net> Changeset: 7e309ecb83ce Author: kvn Date: 2009-09-15 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7e309ecb83ce 6879362: assert(!klass_is_exact(),"only non-exact klass") Summary: Do nothing for AddP node which has type not related to the type of allocated object. Reviewed-by: never ! src/share/vm/opto/escape.cpp From john.rose at sun.com Wed Sep 16 00:57:16 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Wed, 16 Sep 2009 07:57:16 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090916075720.93ECC12282@hg.openjdk.java.net> Changeset: 148e5441d916 Author: jrose Date: 2009-09-15 21:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/148e5441d916 6863023: need non-perm oops in code cache for JSR 292 Summary: Make a special root-list for those few nmethods which might contain non-perm oops. Reviewed-by: twisti, kvn, never, jmasa, ysr ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline2.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/utilities/debug.cpp Changeset: be094e0c089a Author: jrose Date: 2009-09-15 22:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/be094e0c089a Merge From thomas.rodriguez at sun.com Wed Sep 16 13:13:57 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 16 Sep 2009 20:13:57 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6854812: 6.0_14-b08 crashes with a SIGSEGV Message-ID: <20090916201405.022AD122F9@hg.openjdk.java.net> Changeset: 3a2aa26bdc58 Author: never Date: 2009-09-16 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3a2aa26bdc58 6854812: 6.0_14-b08 crashes with a SIGSEGV Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/opto/parse1.cpp From Thomas.Rodriguez at Sun.COM Thu Sep 17 16:17:01 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 17 Sep 2009 16:17:01 -0700 Subject: review (M) for 6879063: SA should use hsdis for disassembly Message-ID: <024A7C18-7306-41E4-919A-CCB70D33C691@sun.com> http://javaweb.sfbay.sun.com/~never/webrev/6879063/ The SA has Java based disassemblers for x86 and sparc but not for amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This required a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and the SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. I also updated the disassembly printing code to more closely match the JVM though we still don't print out a lot things like oops and relocs in the SA. I deleted all the old disassembler logic since it's incompatible with the new disassembly interface. I also blew away the moribund dbx based SA interface and few other dead files. In the end I deleted around 22000 lines of source. Tested by dumping full assembly from core files. From Vladimir.Kozlov at Sun.COM Thu Sep 17 16:22:37 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 17 Sep 2009 16:22:37 -0700 Subject: Request for reviews (S): 6820514: meet not symmetric failure in ctw Message-ID: <4AB2C4BD.7030908@sun.com> http://cr.openjdk.java.net/~kvn/6820514/webrev.01 Fixed 6820514: meet not symmetric failure in ctw Problem: Missing instance_id meet for the case j.l.Object:NotNull meets unloaded instance klass. Solution: Add instance_id meet in TypeInstPtr::xmeet_unloaded(). Fix Type::interface_vs_oop() for narrow oops (cases regression test 6837094 failure). Remove optional instance_id in TypeOopPtr::make() as I promised before. Reviewed by: Fix verified (y/n): y, ctw test from bug and 6837094 test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Thu Sep 17 16:24:30 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 17 Sep 2009 16:24:30 -0700 Subject: review (M) for 6879063: SA should use hsdis for disassembly In-Reply-To: <024A7C18-7306-41E4-919A-CCB70D33C691@sun.com> References: <024A7C18-7306-41E4-919A-CCB70D33C691@sun.com> Message-ID: <7483182D-A8FC-4C4D-82B4-4ADAFCA310E7@sun.com> That should be http://cr.openjdk.java.net/~never/6879063/ tom On Sep 17, 2009, at 4:17 PM, Tom Rodriguez wrote: > http://javaweb.sfbay.sun.com/~never/webrev/6879063/ > > The SA has Java based disassemblers for x86 and sparc but not for > amd64. Instead of porting to amd64 we should switch over to using > hsdis for it like the JVM does. This required a new entry point into > hsdis, decode_instructions_virtual, which separates the address of the > code being disassembled from the buffer containing the code. The > existing uses of decode_instructions have been updated to use the new > interface and the SA Disassembler has Java native methods that call > into hsdis and call back up to Java to perform the disassembly. I > also updated the disassembly printing code to more closely match the > JVM though we still don't print out a lot things like oops and relocs > in the SA. > > I deleted all the old disassembler logic since it's incompatible with > the new disassembly interface. I also blew away the moribund dbx > based SA interface and few other dead files. In the end I deleted > around 22000 lines of source. > > Tested by dumping full assembly from core files. From Thomas.Rodriguez at Sun.COM Thu Sep 17 16:35:49 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 17 Sep 2009 16:35:49 -0700 Subject: Request for reviews (S): 6820514: meet not symmetric failure in ctw In-Reply-To: <4AB2C4BD.7030908@sun.com> References: <4AB2C4BD.7030908@sun.com> Message-ID: <9D452FFE-0C0C-48FE-82D8-9591817883B1@sun.com> I think this looks ok. It might deserve a full CTW run. tom On Sep 17, 2009, at 4:22 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6820514/webrev.01 > > Fixed 6820514: meet not symmetric failure in ctw > > Problem: > Missing instance_id meet for the case j.l.Object:NotNull > meets unloaded instance klass. > > Solution: > Add instance_id meet in TypeInstPtr::xmeet_unloaded(). > Fix Type::interface_vs_oop() for narrow oops (cases > regression test 6837094 failure). > Remove optional instance_id in TypeOopPtr::make() > as I promised before. > > Reviewed by: > > Fix verified (y/n): y, ctw test from bug and 6837094 test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Thu Sep 17 16:45:35 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 17 Sep 2009 16:45:35 -0700 Subject: Request for reviews (S): 6820514: meet not symmetric failure in ctw In-Reply-To: <9D452FFE-0C0C-48FE-82D8-9591817883B1@sun.com> References: <4AB2C4BD.7030908@sun.com> <9D452FFE-0C0C-48FE-82D8-9591817883B1@sun.com> Message-ID: <4AB2CA1F.1050502@sun.com> Thanks, Tom CTW is running. I will do push after it finish. Vladimir Tom Rodriguez wrote: > I think this looks ok. It might deserve a full CTW run. > > tom > > On Sep 17, 2009, at 4:22 PM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6820514/webrev.01 >> >> Fixed 6820514: meet not symmetric failure in ctw >> >> Problem: >> Missing instance_id meet for the case j.l.Object:NotNull >> meets unloaded instance klass. >> >> Solution: >> Add instance_id meet in TypeInstPtr::xmeet_unloaded(). >> Fix Type::interface_vs_oop() for narrow oops (cases >> regression test 6837094 failure). >> Remove optional instance_id in TypeOopPtr::make() >> as I promised before. >> >> Reviewed by: >> >> Fix verified (y/n): y, ctw test from bug and 6837094 test >> >> Other testing: >> JPRT >> > From Vladimir.Kozlov at Sun.COM Thu Sep 17 18:07:47 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 17 Sep 2009 18:07:47 -0700 Subject: review (M) for 6879063: SA should use hsdis for disassembly In-Reply-To: <024A7C18-7306-41E4-919A-CCB70D33C691@sun.com> References: <024A7C18-7306-41E4-919A-CCB70D33C691@sun.com> Message-ID: <4AB2DD63.3010804@sun.com> Looks good. In agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java You use libname = "hsdis-sparc" for 64 bit VM also. Why you don't use hsdis-sparcv9.so ? In agent/src/os/solaris/proc/Makefile missing amd64 in .PHONY: You did not remove sun/jvm/hotspot/asm/sparc directory since you still need SPARCArgument.java. Right? Thanks, Vladimir Tom Rodriguez wrote: > http://javaweb.sfbay.sun.com/~never/webrev/6879063/ > > The SA has Java based disassemblers for x86 and sparc but not for > amd64. Instead of porting to amd64 we should switch over to using > hsdis for it like the JVM does. This required a new entry point into > hsdis, decode_instructions_virtual, which separates the address of the > code being disassembled from the buffer containing the code. The > existing uses of decode_instructions have been updated to use the new > interface and the SA Disassembler has Java native methods that call > into hsdis and call back up to Java to perform the disassembly. I > also updated the disassembly printing code to more closely match the > JVM though we still don't print out a lot things like oops and relocs > in the SA. > > I deleted all the old disassembler logic since it's incompatible with > the new disassembly interface. I also blew away the moribund dbx > based SA interface and few other dead files. In the end I deleted > around 22000 lines of source. > > Tested by dumping full assembly from core files. From Vladimir.Kozlov at Sun.COM Thu Sep 17 18:51:06 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 17 Sep 2009 18:51:06 -0700 Subject: Request for reviews (S): 6880053 backport to HS16 Message-ID: <4AB2E78A.4060509@sun.com> This is backport of the fix in HS17. http://cr.openjdk.java.net/~kvn/6880053_hs16/webrev.00 Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Problem: Nightly testing found a case when the type of the cloned object is TypeInstPtr::NOTNULL the same as tyoe of second CheckCastPP node in clone() intrinsic and arraycopy. It produces incorrect graph. Solution: Removed second CheckCastPP and instead use MembarCPUOrder to not let reads from the cloned object float above the arraycopy. Reviewed by: Fix verified (y/n): y, test Other testing: JPRT From john.coomes at sun.com Thu Sep 17 21:07:19 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:07:19 +0000 Subject: hg: jdk7/hotspot-comp: 3 new changesets Message-ID: <20090918040719.77F81123F6@hg.openjdk.java.net> Changeset: 4079d923a501 Author: peterz Date: 2009-08-31 14:10 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/4079d923a501 6844267: Nimbus generator depends on JIBX Summary: Nimbus generator now uses JAXB instead of JIBX Reviewed-by: jasper ! README-builds.html Changeset: 0d7e03b426df Author: yan Date: 2009-09-09 00:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/0d7e03b426df Merge Changeset: 4c4fe09fb670 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/4c4fe09fb670 Added tag jdk7-b72 for changeset 0d7e03b426df ! .hgtags From john.coomes at sun.com Thu Sep 17 21:07:46 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:07:46 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b72 for changeset c793a3120926 Message-ID: <20090918040747.87645123FB@hg.openjdk.java.net> Changeset: 12991b453239 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/12991b453239 Added tag jdk7-b72 for changeset c793a3120926 ! .hgtags From john.coomes at sun.com Thu Sep 17 21:10:12 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:10:12 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b72 for changeset 37c805b6156f Message-ID: <20090918041014.E41B612400@hg.openjdk.java.net> Changeset: 93dfa6e0fe76 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/93dfa6e0fe76 Added tag jdk7-b72 for changeset 37c805b6156f ! .hgtags From john.coomes at sun.com Thu Sep 17 21:10:43 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:10:43 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b72 for changeset 4c990aa99bc0 Message-ID: <20090918041044.2A1F612405@hg.openjdk.java.net> Changeset: d79f0d601c2b Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/d79f0d601c2b Added tag jdk7-b72 for changeset 4c990aa99bc0 ! .hgtags From john.coomes at sun.com Thu Sep 17 21:12:14 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:12:14 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 52 new changesets Message-ID: <20090918042322.BF6261240A@hg.openjdk.java.net> Changeset: b115cf946852 Author: sherman Date: 2009-08-25 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b115cf946852 4963968: zlib should be upgraded to current version of zlib Summary: upgrade zlib to the latest ver 1.2.3 Reviewed-by: martin, alanb, ksrini ! make/com/sun/java/pack/Makefile ! make/common/Defs.gmk ! make/java/jli/Makefile ! make/java/zip/FILES_c.gmk ! make/java/zip/Makefile ! make/java/zip/reorder-i586 ! make/java/zip/reorder-sparc ! make/java/zip/reorder-sparcv9 ! make/sun/splashscreen/FILES_c.gmk ! make/sun/splashscreen/Makefile - 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/share/native/java/util/zip/zlib-1.2.3/ChangeLog + src/share/native/java/util/zip/zlib-1.2.3/README + src/share/native/java/util/zip/zlib-1.2.3/compress.c + src/share/native/java/util/zip/zlib-1.2.3/crc32.h + src/share/native/java/util/zip/zlib-1.2.3/deflate.c + src/share/native/java/util/zip/zlib-1.2.3/deflate.h + src/share/native/java/util/zip/zlib-1.2.3/gzio.c + src/share/native/java/util/zip/zlib-1.2.3/infback.c + src/share/native/java/util/zip/zlib-1.2.3/inffast.c + src/share/native/java/util/zip/zlib-1.2.3/inffast.h + src/share/native/java/util/zip/zlib-1.2.3/inffixed.h + src/share/native/java/util/zip/zlib-1.2.3/inflate.c + src/share/native/java/util/zip/zlib-1.2.3/inflate.h + src/share/native/java/util/zip/zlib-1.2.3/inftrees.c + src/share/native/java/util/zip/zlib-1.2.3/inftrees.h + src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java + src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff + src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff + src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff + src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff + src/share/native/java/util/zip/zlib-1.2.3/trees.c + src/share/native/java/util/zip/zlib-1.2.3/trees.h + src/share/native/java/util/zip/zlib-1.2.3/uncompr.c + src/share/native/java/util/zip/zlib-1.2.3/zadler32.c + src/share/native/java/util/zip/zlib-1.2.3/zconf.h + src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c + src/share/native/java/util/zip/zlib-1.2.3/zlib.h + src/share/native/java/util/zip/zlib-1.2.3/zutil.c + src/share/native/java/util/zip/zlib-1.2.3/zutil.h Changeset: 196c7bb551e7 Author: darcy Date: 2009-08-25 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/196c7bb551e7 6875861: javadoc build warning on java.util.Properites from unconventional @see ordering Reviewed-by: martin ! src/share/classes/java/util/Properties.java Changeset: 2607e571a6d5 Author: weijun Date: 2009-08-26 12:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2607e571a6d5 6868864: Kerberos tests fail under windows/cygwin Reviewed-by: wetmore ! test/sun/security/krb5/auto/basic.sh Changeset: 69396f593772 Author: dl Date: 2009-08-25 19:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/69396f593772 6871697: LinkedBlockingQueue Iterator/remove/poll race Summary: More checks for node.next == node Reviewed-by: martin, dholmes, chegar ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java Changeset: aeaf7b138d90 Author: dl Date: 2009-08-25 19:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aeaf7b138d90 6868712: Improve concurrent queue tests Summary: Fix all known flaky tests, plus minor maintenance Reviewed-by: martin, chegar ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collection/IteratorAtEnd.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/RacingCollections.java ! test/java/util/PriorityQueue/RemoveContains.java ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/Interrupt.java + test/java/util/concurrent/BlockingQueue/LastElement.java ! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java ! test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java ! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java ! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java ! test/java/util/concurrent/ConcurrentQueues/GCRetention.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java + test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java ! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 25371bf31658 Author: darcy Date: 2009-08-27 11:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/25371bf31658 6876628: @throw instead of @throws in two ParagraphView classes Reviewed-by: peterz ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/html/ParagraphView.java Changeset: 5342b0cdbf95 Author: xlu Date: 2009-08-27 18:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5342b0cdbf95 6876282: BigDecimal's divide(BigDecimal bd, RoundingFormat r) produces incorrect result Reviewed-by: darcy ! src/share/classes/java/math/BigDecimal.java ! test/java/math/BigDecimal/DivideTests.java Changeset: 4a5f2147f953 Author: darcy Date: 2009-08-28 11:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4a5f2147f953 6877122: Many javadoc warnings from java.awt.Window, other awt classes Reviewed-by: anthony ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/dnd/DragSourceContext.java Changeset: e0f79982edd2 Author: darcy Date: 2009-08-28 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e0f79982edd2 6261502: (reflect) Add the functionality to screen out the "inappropriate" modifier bits Reviewed-by: alanb ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java Changeset: 225aa5ee10da Author: tbell Date: 2009-08-28 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/225aa5ee10da Merge ! src/share/classes/javax/swing/text/ParagraphView.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: db5d6b4cbc11 Author: martin Date: 2009-08-31 15:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/db5d6b4cbc11 6860431: Character.isSurrogate(char ch) Summary: Add new method Character.isSurrogate(char ch) Reviewed-by: sherman, darcy, okutsu ! src/share/classes/java/lang/Character.java ! src/share/classes/sun/io/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java ! src/share/classes/sun/nio/cs/ISO_8859_1.java ! src/share/classes/sun/nio/cs/SingleByte.java ! src/share/classes/sun/nio/cs/SingleByteEncoder.java ! src/share/classes/sun/nio/cs/Surrogate.java ! src/share/classes/sun/nio/cs/US_ASCII.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/UnicodeDecoder.java ! src/share/classes/sun/nio/cs/UnicodeEncoder.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/DoubleByteEncoder.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/ISCII91.java ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java Changeset: ed0863629d28 Author: tbell Date: 2009-09-03 18:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ed0863629d28 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: ee5300e1835a Author: weijun Date: 2009-09-04 14:58 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ee5300e1835a 6876328: different names for the same digest algorithms breaks jarsigner Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java + test/sun/security/tools/jarsigner/nameclash.sh Changeset: 98ad1322051e Author: weijun Date: 2009-09-04 14:59 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/98ad1322051e 6871847: AlgorithmId.get("SHA256withECDSA") not available Reviewed-by: vinnie ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/SHA256withECDSA.java Changeset: c34f92a47245 Author: darcy Date: 2009-09-04 13:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c34f92a47245 6873951: test/java/lang/reflect/Generics/Probe.java fails. Reviewed-by: alanb ! test/java/lang/reflect/Generics/Probe.java Changeset: 704296144175 Author: martin Date: 2009-09-04 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/704296144175 6879368: Remove stray quote in Character javadoc Summary: Remove stray quote in Character.valueOf javadoc, using Ulf's \u005CuXXXX technique Reviewed-by: darcy ! src/share/classes/java/lang/Character.java Changeset: 658a4255c797 Author: tbell Date: 2009-09-04 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/658a4255c797 Merge Changeset: 3f87b755b1c8 Author: alanb Date: 2009-09-04 18:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3f87b755b1c8 6873621: (file) FileStore.supportsFileAttributeView(Class type) returns wrong result Reviewed-by: andrew ! src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/SolarisFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! test/java/nio/file/FileStore/Basic.java Changeset: 05ea733a7ae2 Author: alanb Date: 2009-09-04 18:17 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/05ea733a7ae2 6868627: (spec) Files.walkFileTree doesn't make it clear that uncaught errors and exceptions are propagated Reviewed-by: sherman ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java Changeset: 87a2ef2439bc Author: alanb Date: 2009-09-04 22:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/87a2ef2439bc 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to java.net.ConnectException Reviewed-by: tbell, ohair, dcubed, andrew ! src/share/transport/socket/socketTransport.c ! test/com/sun/jdi/BadHandshakeTest.java Changeset: 7afdf9d0bc2c Author: alanb Date: 2009-09-05 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7afdf9d0bc2c Merge Changeset: abb69e8b1774 Author: tbell Date: 2009-09-06 23:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/abb69e8b1774 Merge Changeset: 559fb14d0ae9 Author: anthony Date: 2009-08-27 16:42 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/559fb14d0ae9 6780496: Javaw process taking up 80-90 percent of CPU time! Summary: The transparency effects get enabled on showing, and disabled on hiding a window Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h Changeset: 7599cca4fe5e Author: dcherepanov Date: 2009-08-27 17:04 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7599cca4fe5e 6852051: Getting Null Pointer Exception when displaying message for TrayIcon on Opensolaris Reviewed-by: anthony ! src/share/classes/java/awt/Component.java Changeset: 911a82b4901f Author: dcherepanov Date: 2009-08-27 17:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/911a82b4901f 6854898: Frame is located at the negative coordinates instead of origin for Solaris 10 CDE Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XErrorHandler.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: d5ac8fb96d13 Author: anthony Date: 2009-08-28 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d5ac8fb96d13 6689468: test/closed/java/awt/Component/VisibleHwInLwContTest/VisibleHwInLwContTest.html fails Summary: The addNotify() checks whether the component is actually hidden, and hides the peer appropriately if needed Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java Changeset: d755ace580b2 Author: yan Date: 2009-09-04 14:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d755ace580b2 6871299: Shift+Tab no longer generates a KEY_TYPED event; used to with JRE 1.5 Summary: Add XK_ISO_Left_Tab -> VK_TAB rule Reviewed-by: dcherepanov ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 5a584fbcc712 Author: yan Date: 2009-09-09 00:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5a584fbcc712 Merge Changeset: a48c15bcf64f Author: rupashka Date: 2009-08-14 13:18 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a48c15bcf64f 6824600: OOM occurs when setLookAndFeel() is executed in Windows L&F(XP style) Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/windows/DesktopProperty.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalFontDesktopProperty.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java + test/com/sun/java/swing/plaf/windows/Test6824600.java Changeset: fa334ff12794 Author: alexp Date: 2009-08-19 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fa334ff12794 6872492: JLayer sources contain wrong header Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java Changeset: 3e36c9abb569 Author: yan Date: 2009-08-20 23:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3e36c9abb569 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: e8d93257cf7e Author: rupashka Date: 2009-08-21 16:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e8d93257cf7e 6579827: vista : JSlider on JColorchooser is not properly render or can't be seen completely. Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6579827/bug6579827.java Changeset: d07bd8fa89e4 Author: rupashka Date: 2009-08-24 18:21 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d07bd8fa89e4 6849266: closed/javax/swing/JFileChooser/6484091/bug6484091.java fails on solaris 10 sparc Reviewed-by: peterz + test/javax/swing/JFileChooser/6484091/bug6484091.java Changeset: 799439873bf9 Author: alexp Date: 2009-08-24 19:22 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/799439873bf9 6824395: Several Swing core components prevent using them in wrapper classes Reviewed-by: peterz ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JLayer/6824395/bug6824395.java ! test/javax/swing/JLayer/SerializationTest/SerializationTest.java Changeset: 4914723317b9 Author: peytoia Date: 2009-08-31 12:55 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4914723317b9 6851214: (tz) New Jordan rule creates a failure for SimpleTimeZone parsing post tzdata2009h Reviewed-by: okutsu ! src/share/classes/java/util/SimpleTimeZone.java + test/java/util/TimeZone/ListTimeZones.java Changeset: 7aa6cb832991 Author: peytoia Date: 2009-08-31 14:50 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7aa6cb832991 6872467: (tz) Support tzdata2009l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab Changeset: 92b6482e7719 Author: peytoia Date: 2009-08-31 14:53 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/92b6482e7719 6456628: (tz) Default timezone is incorrectly set occasionally on Linux Reviewed-by: okutsu ! src/solaris/native/java/util/TimeZone_md.c Changeset: f7d606ca25a9 Author: peterz Date: 2009-08-31 13:46 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f7d606ca25a9 6802944: Nimbus initialization is too slow Reviewed-by: jasper ! make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/plaf/nimbus/DerivedColor.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Changeset: 7e7153da24ef Author: peterz Date: 2009-08-31 13:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7e7153da24ef 6844267: Nimbus generator depends on JIBX Summary: Nimbus generator now uses JAXB instead of JIBX Reviewed-by: jasper ! README ! make/common/Sanity.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/javax/swing/plaf/Makefile - make/javax/swing/plaf/nimbus/Makefile ! make/tools/Makefile + make/tools/generate_nimbus/Makefile + make/tools/src/build/tools/generatenimbus/Generator.java + make/tools/src/build/tools/generatenimbus/ObjectFactory.java + make/tools/src/build/tools/generatenimbus/Paint.java + make/tools/src/build/tools/generatenimbus/PainterGenerator.java + make/tools/src/build/tools/generatenimbus/Shape.java + make/tools/src/build/tools/generatenimbus/SynthModel.java + make/tools/src/build/tools/generatenimbus/UIDefault.java + make/tools/src/build/tools/generatenimbus/UIStyle.java + make/tools/src/build/tools/generatenimbus/Utils.java - 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 Changeset: e7d311b4ae94 Author: alexp Date: 2009-08-31 18:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e7d311b4ae94 6872503: JLayer event handling should be rewritten Reviewed-by: art ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6872503/bug6872503.java Changeset: 9d8f551780d5 Author: peytoia Date: 2009-09-01 15:39 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9d8f551780d5 6830423: Unified Ext B character not displayed with Dialog font Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 37c33432e98a Author: peytoia Date: 2009-09-01 15:42 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/37c33432e98a 6838887: (tz) Add UTC and Yerevan to tzmappings Reviewed-by: okutsu ! src/windows/lib/tzmappings Changeset: 5780cff2763c Author: peytoia Date: 2009-09-01 16:15 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5780cff2763c 6856390: RFE : sequence.allfonts.UTF-8.ja for Windows fontconfig.properties Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 4f819e2e0bfc Author: peterz Date: 2009-09-01 15:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4f819e2e0bfc 6387579: Usage of package-private class as parameter of a method (javax.swing.tree.DefaultTreeSelectionModel) Reviewed-by: rupashka ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java Changeset: 935814bd43a6 Author: alexp Date: 2009-09-01 18:51 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/935814bd43a6 6875153: JLayer.isOptimizedDrawingEnabled() throws NPE for null glass pane set Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java + test/javax/swing/JLayer/6875153/bug6875153.java Changeset: 281fbd82a971 Author: alexp Date: 2009-09-02 17:47 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/281fbd82a971 6797139: JButton title is truncating for some strings irrespective of preferred size. Reviewed-by: peterz ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java ! src/share/classes/sun/swing/MenuItemLayoutHelper.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/SwingUtilities/6797139/bug6797139.java Changeset: ff468ef27959 Author: gsm Date: 2009-09-07 12:27 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ff468ef27959 6699856: Creating text in a JTextPane using Chinese text causes undesired behavior Reviewed-by: peterz ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 01c46cb72eb7 Author: rupashka Date: 2009-09-07 15:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/01c46cb72eb7 6589634: Unable to view focus on "Up one level", "create new folder" etc. of JFileChooser Dialog Reviewed-by: peterz, loneid ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java Changeset: d73a741a7ea1 Author: malenkov Date: 2009-09-08 14:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d73a741a7ea1 6868185: 2 JCK api/java_beans/Introspector/ tests fails starting from jdk7 b66 Reviewed-by: peterz ! src/share/classes/com/sun/beans/finder/BeanInfoFinder.java Changeset: e289c06b6d36 Author: yan Date: 2009-09-09 00:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e289c06b6d36 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 Changeset: 460639b036f3 Author: yan Date: 2009-09-15 23:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/460639b036f3 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 Changeset: f09a2bfba691 Author: xdono Date: 2009-09-17 13:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f09a2bfba691 Added tag jdk7-b72 for changeset 460639b036f3 ! .hgtags From john.coomes at sun.com Thu Sep 17 21:30:26 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:30:26 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 23 new changesets Message-ID: <20090918043104.DFEF312411@hg.openjdk.java.net> Changeset: 40aca381dcaf Author: darcy Date: 2009-08-25 16:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/40aca381dcaf 6872011: Update printing processor to support JSR 308 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java Changeset: 25f15fdd168a Author: darcy Date: 2009-08-26 19:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/25f15fdd168a 6548708: Annotation processing should free service loader if there are no processors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 8109aa93b212 Author: mcimadamore Date: 2009-08-27 13:40 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/8109aa93b212 6840638: Project Coin: Improved Type Inference for Generic Instance Creation (aka 'diamond') Summary: diamond operator implementation (simple approach) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/generics/diamond/neg/Neg01.java + test/tools/javac/generics/diamond/neg/Neg01.out + test/tools/javac/generics/diamond/neg/Neg02.java + test/tools/javac/generics/diamond/neg/Neg02.out + test/tools/javac/generics/diamond/neg/Neg03.java + test/tools/javac/generics/diamond/neg/Neg03.out + test/tools/javac/generics/diamond/neg/Neg04.java + test/tools/javac/generics/diamond/neg/Neg04.out + test/tools/javac/generics/diamond/neg/Neg05.java + test/tools/javac/generics/diamond/neg/Neg05.out + test/tools/javac/generics/diamond/pos/Pos01.java + test/tools/javac/generics/diamond/pos/Pos02.java + test/tools/javac/generics/diamond/pos/Pos03.java + test/tools/javac/generics/diamond/pos/Pos04.java Changeset: ed31953ca025 Author: jjg Date: 2009-08-27 11:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ed31953ca025 6875336: some tests should use /nodynamiccopyright/ Reviewed-by: darcy ! test/tools/javac/6521805/T6521805a.java ! test/tools/javac/6521805/T6521805a_1.out ! test/tools/javac/6521805/T6521805a_2.out ! test/tools/javac/6521805/T6521805d.java ! test/tools/javac/6521805/T6521805d.out ! test/tools/javac/6717241/T6717241a.java ! test/tools/javac/6717241/T6717241a.out ! test/tools/javac/6717241/T6717241b.java ! test/tools/javac/6717241/T6717241b.out ! test/tools/javac/6734819/T6734819c.java ! test/tools/javac/6734819/T6734819c.out ! test/tools/javac/6758789/T6758789a.java ! test/tools/javac/6758789/T6758789a.out ! test/tools/javac/6758789/T6758789b.java ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/6840059/T6840059.java ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/Diagnostics/6722234/T6722234a.java ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234b.java ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.java ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d.java ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.java ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6860795/T6860795.java ! test/tools/javac/Diagnostics/6860795/T6860795.out ! test/tools/javac/Diagnostics/6862608/T6862608a.java ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.java ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/Diagnostics/6864382/T6864382.java ! test/tools/javac/Diagnostics/6864382/T6864382.out ! test/tools/javac/OverrideChecks/6199153/T6199153.java ! test/tools/javac/OverrideChecks/6199153/T6199153.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.java ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.java ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/cast/6467183/T6467183a.java ! test/tools/javac/cast/6467183/T6467183a.out ! test/tools/javac/cast/6557182/T6557182.java ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.java ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.java ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/generics/5009937/T5009937.java ! test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/6182950/T6182950a.java ! test/tools/javac/generics/6182950/T6182950a.out ! test/tools/javac/generics/6182950/T6182950b.java ! test/tools/javac/generics/6182950/T6182950b.out ! test/tools/javac/generics/6677785/T6677785.java ! test/tools/javac/generics/6677785/T6677785.out ! test/tools/javac/generics/6711619/T6711619a.java ! test/tools/javac/generics/6711619/T6711619a.out ! test/tools/javac/generics/6711619/T6711619b.java ! test/tools/javac/generics/6711619/T6711619b.out ! test/tools/javac/generics/6723444/T6723444.java ! test/tools/javac/generics/6723444/T6723444.out ! test/tools/javac/generics/inference/6315770/T6315770.java ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.java ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.java ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.java ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.java ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6638712/T6638712e.java ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6718364/T6718364.java ! test/tools/javac/generics/inference/6718364/T6718364.out ! test/tools/javac/generics/rare/6665356/T6665356.java ! test/tools/javac/generics/rare/6665356/T6665356.out ! test/tools/javac/generics/typevars/6569404/T6569404b.java ! test/tools/javac/generics/typevars/6569404/T6569404b.out ! test/tools/javac/generics/typevars/6680106/T6680106.java ! test/tools/javac/generics/typevars/6680106/T6680106.out ! test/tools/javac/generics/typevars/6804733/T6804733.java ! test/tools/javac/generics/typevars/6804733/T6804733.out ! test/tools/javac/typeAnnotations/failures/AnnotationVersion.java ! test/tools/javac/typeAnnotations/failures/AnnotationVersion.out ! test/tools/javac/typeAnnotations/failures/IncompleteArray.java ! test/tools/javac/typeAnnotations/failures/IncompleteArray.out ! test/tools/javac/typeAnnotations/failures/IncompleteVararg.java ! test/tools/javac/typeAnnotations/failures/IncompleteVararg.out ! test/tools/javac/typeAnnotations/failures/IndexArray.java ! test/tools/javac/typeAnnotations/failures/IndexArray.out ! test/tools/javac/typeAnnotations/failures/LintCast.java ! test/tools/javac/typeAnnotations/failures/LintCast.out ! test/tools/javac/typeAnnotations/failures/Scopes.java ! test/tools/javac/typeAnnotations/failures/Scopes.out ! test/tools/javac/typeAnnotations/failures/StaticFields.java ! test/tools/javac/typeAnnotations/failures/StaticFields.out ! test/tools/javac/typeAnnotations/failures/StaticMethods.java ! test/tools/javac/typeAnnotations/failures/StaticMethods.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/target/Constructor.java ! test/tools/javac/typeAnnotations/failures/target/Constructor.out ! test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java ! test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out ! test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java ! test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out ! test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java ! test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out ! test/tools/javac/typeAnnotations/failures/target/VoidMethod.java ! test/tools/javac/typeAnnotations/failures/target/VoidMethod.out ! test/tools/javac/varargs/6806876/T6806876.java ! test/tools/javac/varargs/6806876/T6806876.out ! test/tools/javac/warnings/6747671/T6747671.java ! test/tools/javac/warnings/6747671/T6747671.out Changeset: 74760fd5197f Author: jjg Date: 2009-08-27 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/74760fd5197f 6843707: bad tests generate files in the test/ directory 6876699: generated files in repository Reviewed-by: darcy - test/tools/javac/meth/InvokeMH_BAD68.java - test/tools/javac/meth/InvokeMH_BAD72.java ! test/tools/javac/meth/MakeNegTests.sh ! test/tools/javac/quid/MakeNegTests.sh - test/tools/javac/quid/QuotedIdent_BAD61.java - test/tools/javac/quid/QuotedIdent_BAD62.java - test/tools/javac/quid/QuotedIdent_BAD63.java Changeset: 2c20f17c429c Author: jjg Date: 2009-08-27 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2c20f17c429c 6876753: javap tests fail on Windows Reviewed-by: darcy ! test/tools/javap/T4975569.java ! test/tools/javap/T6729471.java ! test/tools/javap/pathsep.sh ! test/tools/javap/stackmap/T6271292.sh Changeset: f29068bfeaed Author: jjg Date: 2009-08-27 17:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f29068bfeaed 6876755: apt tests fail on Windows Reviewed-by: darcy ! test/tools/apt/Basics/apt.sh ! test/tools/apt/Basics/print.sh ! test/tools/apt/Compile/compile.sh Changeset: 477c5bf1149c Author: jjg Date: 2009-08-27 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/477c5bf1149c 6876765: javah tests fail on Windows Reviewed-by: darcy ! test/tools/javah/6257087/foo.sh ! test/tools/javah/ConstMacroTest.sh ! test/tools/javah/MissingParamClassTest.sh ! test/tools/javah/ReadOldClass.sh Changeset: 0ba956343648 Author: jjg Date: 2009-08-28 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0ba956343648 6876782: two javadoc tests fail on Windows Reviewed-by: darcy ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java Changeset: f0c9fc46990b Author: jjg Date: 2009-08-28 14:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f0c9fc46990b 6877188: some javac shell tests do not work on Windows Reviewed-by: darcy ! test/tools/javac/4846262/Test.sh ! test/tools/javac/6302184/T6302184.sh ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/unicode/SupplementaryJavaID6.sh Changeset: ce5be4c09f2a Author: tbell Date: 2009-08-28 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ce5be4c09f2a Merge - test/tools/javac/meth/InvokeMH_BAD68.java - test/tools/javac/meth/InvokeMH_BAD72.java - test/tools/javac/quid/QuotedIdent_BAD61.java - test/tools/javac/quid/QuotedIdent_BAD62.java - test/tools/javac/quid/QuotedIdent_BAD63.java Changeset: d5e76d422509 Author: jjg Date: 2009-08-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d5e76d422509 6877229: more javac tests fail on Windows Reviewed-by: darcy ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/MissingInclude.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/innerClassFile/Driver.sh ! test/tools/javac/quid/QuotedIdent.java ! test/tools/javac/quid/QuotedIdent2.java ! test/tools/javac/stackmap/T4955930.sh Changeset: 4fa458c945ac Author: jjg Date: 2009-08-31 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4fa458c945ac 6877744: delete extraneous file Reviewed-by: darcy - test/tools/javac/innerClassFile/Driver.java Changeset: 45301370bc5a Author: jjg Date: 2009-08-31 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/45301370bc5a 6877751: test/tools/javac/6627362/T6627362.java fails Reviewed-by: darcy ! test/tools/javac/6627362/T6627362.java Changeset: 5a72ba18c471 Author: jjg Date: 2009-08-31 19:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/5a72ba18c471 6877759: test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java leaves open file Reviewed-by: darcy ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java Changeset: dda7e13f09fb Author: mcimadamore Date: 2009-09-01 14:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/dda7e13f09fb 6650759: Inference of formal type parameter (unused in formal parameters) is not performed Summary: propagate inference constraints from 15.12.2.7 to 15.12.2.8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/generics/inference/6302954/T6476073.java ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712e.out + test/tools/javac/generics/inference/6650759/T6650759a.java + test/tools/javac/generics/inference/6650759/T6650759b.java + test/tools/javac/generics/inference/6650759/T6650759c.java + test/tools/javac/generics/inference/6650759/T6650759d.java + test/tools/javac/generics/inference/6650759/T6650759e.java + test/tools/javac/generics/inference/6650759/T6650759f.java + test/tools/javac/generics/inference/6650759/T6650759g.java + test/tools/javac/generics/inference/6650759/T6650759h.java + test/tools/javac/generics/inference/6650759/T6650759i.java + test/tools/javac/generics/inference/6650759/T6650759j.java + test/tools/javac/generics/inference/6650759/T6650759k.java + test/tools/javac/generics/inference/6650759/T6650759l.java + test/tools/javac/generics/inference/6650759/T6650759m.java + test/tools/javac/generics/inference/6650759/T6650759m.out Changeset: 40a1327a5283 Author: jjg Date: 2009-09-01 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/40a1327a5283 6877763: update langtools/test/Makefile for JPRT Reviewed-by: ohair ! test/Makefile Changeset: 8d999cb7ec09 Author: jjg Date: 2009-09-02 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/8d999cb7ec09 6874249: Check has duplicate local variable and field for "source" Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: 90c28923e449 Author: tbell Date: 2009-09-03 18:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/90c28923e449 Merge - test/tools/javac/innerClassFile/Driver.java - test/tools/javac/meth/InvokeMH_BAD68.java - test/tools/javac/meth/InvokeMH_BAD72.java - test/tools/javac/quid/QuotedIdent_BAD61.java - test/tools/javac/quid/QuotedIdent_BAD62.java - test/tools/javac/quid/QuotedIdent_BAD63.java Changeset: 35e29f51a7c3 Author: jjg Date: 2009-09-08 11:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/35e29f51a7c3 6419701: DefaultFileManager clean up: URI.create 6483788: DefaultFileManager.ZipFileObject.toUri() fails to escape space characters 6501502: JSR 199: FileObject.toUri should return file:///c:/ or file:/c:/ not file://c:/ 6877206: JavaFileObject.toUri returns bogus URI (win) 6877223: tests @ignored because of issues with File.toURI on Windows Reviewed-by: mcimadamore, alanb ! 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/javadoc/ClassDocImpl.java ! test/tools/javac/Diagnostics/6769027/tester.properties ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/Sibling.java + test/tools/javac/api/T6483788.java + test/tools/javac/api/T6501502.java + test/tools/javac/api/T6877206.java Changeset: dd98acd9f717 Author: jjg Date: 2009-09-08 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/dd98acd9f717 6879346: files have Windows newlines Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java ! test/com/sun/javadoc/testCRLineSeparator/pkg/MyClass.java ! test/com/sun/javadoc/testHref/package-list ! test/com/sun/javadoc/testLinkOption/testNewLineInLink/package.html ! test/com/sun/javadoc/testNoPackagesFile/TestNoPackagesFile.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testRelativeLinks/pkg/package.html ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testWarnings/pkg/package.html ! test/tools/javah/SubClassConsts.win Changeset: 261c54b2312e Author: jjg Date: 2009-09-08 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/261c54b2312e 6879371: javap does not close internal default file manager Reviewed-by: darcy ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/T6879371.java Changeset: bfad32768345 Author: xdono Date: 2009-09-17 13:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/bfad32768345 Added tag jdk7-b72 for changeset 261c54b2312e ! .hgtags From Thomas.Rodriguez at Sun.COM Fri Sep 18 09:06:05 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 18 Sep 2009 09:06:05 -0700 Subject: Request for reviews (S): 6880053 backport to HS16 In-Reply-To: <4AB2E78A.4060509@sun.com> References: <4AB2E78A.4060509@sun.com> Message-ID: <05113A0E-554A-4BF9-94DD-ADC3325F19BD@sun.com> Looks good. tom On Sep 17, 2009, at 6:51 PM, Vladimir Kozlov wrote: > This is backport of the fix in HS17. > > http://cr.openjdk.java.net/~kvn/6880053_hs16/webrev.00 > > Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != > TypeInstPtr::NOTNULL) > > Problem: > Nightly testing found a case when the type > of the cloned object is TypeInstPtr::NOTNULL > the same as tyoe of second CheckCastPP node in clone() > intrinsic and arraycopy. It produces incorrect graph. > > Solution: > Removed second CheckCastPP and instead use MembarCPUOrder > to not let reads from the cloned object float above the arraycopy. > > Reviewed by: > > Fix verified (y/n): y, test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Fri Sep 18 09:44:27 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 18 Sep 2009 09:44:27 -0700 Subject: Request for reviews (S): 6880053 backport to HS16 In-Reply-To: <05113A0E-554A-4BF9-94DD-ADC3325F19BD@sun.com> References: <4AB2E78A.4060509@sun.com> <05113A0E-554A-4BF9-94DD-ADC3325F19BD@sun.com> Message-ID: <4AB3B8EB.4010504@sun.com> Than you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 17, 2009, at 6:51 PM, Vladimir Kozlov wrote: > >> This is backport of the fix in HS17. >> >> http://cr.openjdk.java.net/~kvn/6880053_hs16/webrev.00 >> >> Fixed 6880053: assert(alloc_obj->as_CheckCastPP()->type() != >> TypeInstPtr::NOTNULL) >> >> Problem: >> Nightly testing found a case when the type >> of the cloned object is TypeInstPtr::NOTNULL >> the same as tyoe of second CheckCastPP node in clone() >> intrinsic and arraycopy. It produces incorrect graph. >> >> Solution: >> Removed second CheckCastPP and instead use MembarCPUOrder >> to not let reads from the cloned object float above the arraycopy. >> >> Reviewed by: >> >> Fix verified (y/n): y, test >> >> Other testing: >> JPRT >> > From volker.simonis at gmail.com Fri Sep 18 10:33:39 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 18 Sep 2009 19:33:39 +0200 Subject: review (M) for 6879063: SA should use hsdis for disassembly In-Reply-To: <024A7C18-7306-41E4-919A-CCB70D33C691@sun.com> References: <024A7C18-7306-41E4-919A-CCB70D33C691@sun.com> Message-ID: Hi, sorry, I was still preparing an answer to the previous mail thread... So here some comments for this concrete change: hsdis-demo.c ----------------- - newer versions of gcc/ld may reorder the location of functions within the executable. As far as I know there's no easy (and portable) way of getting the size of a function in C and before we start reading the elf information of the executable I would suggest the following simple hack to make hsdis-demo work in any case even if the function 'end_of_file()' is optimized out or relocated before main(): void *start = (void*) &main; void *end = (void*) &end_of_file; #if defined(__ia64) || defined(__powerpc__) /* On IA64 and PPC function pointers are pointers to function descriptors */ start = *((void**)start); end = *((void**)end); #endif disassemble(start, (end > start) ? end : start + 256); Of course 256 instructions is just a vague estimation and could be replaced by something more appropriate... hsdis.c --------- - add the following to native_arch_name() for ppc64, ia64 and s390 support: #ifdef LIBARCH_ia64 res = "ia64"; #endif #ifdef LIBARCH_ppc64 res = "powerpc:common64"; #endif #ifdef LIBARCH_s390x res = "s390:64-bit"; #endif - I'm still not happy with decode_instructions_virtual() since it's still not possible to decode a single instruction. When I first read you previous answer I thought you mention the "number of instructions to decode" with the new 'length' argument. But now that it is the length of the underlying buffer, it's still not easy to decode a single instructions on non-RISC architectures. So what about yet another argument which specifies the number of instructions to decode? Or do you have a better idea? Makefile ----------- - add: CFLAGS/ppc64 += -m64 for ppc64 support (Notice that I only have access to and tested on 64-bit ppc linux!). - 'make both' doesn't work on a 64-bit Linux (it only builds the 64-bit library!). To make it work you have to change the ARCH definition to something like: CPU = $(shell uname -m) ARCH1=$(CPU:x86_64=amd64) ARCH2=$(ARCH1:i686=i386) ifndef LP64 ARCH=$(ARCH2:amd64=i386) else ARCH=$(ARCH2) endif Notice that with this change "make demo" will build the 32-bit demo even an a 64-bit Linux. You have to use 'LP64=1 make demo' to build the 64-bit demo. This should be documented in the README file. (The same is true for Solaris anyway - 'make demo' will build the 32-bit demo by default and 'LP64=1 make demo' will build the 64-bit one. - I didn't build for Windows, but emacs syntax higlighting gives me an error because of an unbalanced " in: CFLAGS += LIBARCH=\"$(LIBARCH)\"" I just wondered if the last " is really needed? Regards, Volker On 9/18/09, Tom Rodriguez wrote: > http://javaweb.sfbay.sun.com/~never/webrev/6879063/ > > The SA has Java based disassemblers for x86 and sparc but not for > amd64. Instead of porting to amd64 we should switch over to using > hsdis for it like the JVM does. This required a new entry point into > hsdis, decode_instructions_virtual, which separates the address of the > code being disassembled from the buffer containing the code. The > existing uses of decode_instructions have been updated to use the new > interface and the SA Disassembler has Java native methods that call > into hsdis and call back up to Java to perform the disassembly. I > also updated the disassembly printing code to more closely match the > JVM though we still don't print out a lot things like oops and relocs > in the SA. > > I deleted all the old disassembler logic since it's incompatible with > the new disassembly interface. I also blew away the moribund dbx > based SA interface and few other dead files. In the end I deleted > around 22000 lines of source. > > Tested by dumping full assembly from core files. > From John.Rose at Sun.COM Fri Sep 18 10:50:14 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 18 Sep 2009 10:50:14 -0700 Subject: Summit comment on interference between hot vs. cold code Message-ID: This just came up during Q&A on Christian Wimmer's talk http://wiki.jvmlangsummit.com/Trace-based_JIT , and I want to capture it in this forum. Library writers (like Martin Buchholz) do not want to be burdened with factoring (sequestering) cold from hot code in order to get good optimization. Trace-based compilation sifts input code naturally. A root cause in Hotspot of the interference between cold and hot code (besides whole-method compilation per se) is the poor metrics we use for inlining. In particular, we fail to inline a method if it look too large (in absolute bytecode count) even if most of its bytecodes are never executed. Now that we have a bytecode summarization mechanism (for escape analysis) perhaps we could measure inline candidates more accurately, by counting their "weight" only according to actually executed (or frequently executed) bytecodes. Also, once a whole method is being compiled, we should be corresponding more eager to inline from hot call sites than from cold ones. -- John From rasbold at google.com Fri Sep 18 11:37:33 2009 From: rasbold at google.com (Chuck Rasbold) Date: Fri, 18 Sep 2009 11:37:33 -0700 Subject: Summit comment on interference between hot vs. cold code In-Reply-To: References: Message-ID: <4149a0430909181137j25154a25y992eadfa5b20dda5@mail.gmail.com> On Fri, Sep 18, 2009 at 10:50 AM, John Rose wrote: > This just came up during Q&A on Christian Wimmer's talk > http://wiki.jvmlangsummit.com/Trace-based_JIT , and I want to capture it > in this forum. > > Library writers (like Martin Buchholz) do not want to be burdened with > factoring (sequestering) cold from hot code in order to get good > optimization. Trace-based compilation sifts input code naturally. > > A root cause in Hotspot of the interference between cold and hot code > (besides whole-method compilation per se) is the poor metrics we use for > inlining. In particular, we fail to inline a method if it look too large > (in absolute bytecode count) even if most of its bytecodes are never > executed. > > Now that we have a bytecode summarization mechanism (for escape analysis) > perhaps we could measure inline candidates more accurately, by counting > their "weight" only according to actually executed (or frequently executed) > bytecodes. > > Also, once a whole method is being compiled, we should be corresponding > more eager to inline from hot call sites than from cold ones. > > Can you elaborate on the last statement a little bit? I don't think I understand what you mean.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090918/bb7af40d/attachment.html From vladimir.kozlov at sun.com Fri Sep 18 12:23:39 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 18 Sep 2009 19:23:39 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6820514: meet not symmetric failure in ctw Message-ID: <20090918192348.ECF0812515@hg.openjdk.java.net> Changeset: 6a8ccac44f41 Author: kvn Date: 2009-09-18 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6a8ccac44f41 6820514: meet not symmetric failure in ctw Summary: Add missing instance_id meet. Reviewed-by: never ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp From John.Rose at Sun.COM Fri Sep 18 13:56:21 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 18 Sep 2009 13:56:21 -0700 Subject: Summit comment on interference between hot vs. cold code In-Reply-To: <4149a0430909181137j25154a25y992eadfa5b20dda5@mail.gmail.com> References: <4149a0430909181137j25154a25y992eadfa5b20dda5@mail.gmail.com> Message-ID: On Sep 18, 2009, at 11:37 AM, Chuck Rasbold wrote: > Also, once a whole method is being compiled, we should be > corresponding more eager to inline from hot call sites than from > cold ones. You and Paul are teasing me! This (= heat-based inlining) was on my project list for years. We're slowly getting there. -- John From Christian.Thalinger at Sun.COM Mon Sep 21 06:29:58 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 21 Sep 2009 15:29:58 +0200 Subject: src/dst register for andI_rReg_imm255 and andI_rReg_imm65535 Message-ID: <4AB77FD6.70107@Sun.COM> Hi! Is there a reason why both andI_rReg_imm255 and andI_rReg_imm65535 only operate on a src register and not on src and dst? Because of that we almost always need a spill right before which we don't need. -- Christian From Christian.Thalinger at Sun.COM Mon Sep 21 06:34:59 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 21 Sep 2009 15:34:59 +0200 Subject: src/dst register for andI_rReg_imm255 and andI_rReg_imm65535 In-Reply-To: <4AB77FD6.70107@Sun.COM> References: <4AB77FD6.70107@Sun.COM> Message-ID: <4AB78103.6000104@Sun.COM> Christian Thalinger wrote: > Hi! > > Is there a reason why both andI_rReg_imm255 and andI_rReg_imm65535 only > operate on a src register and not on src and dst? Because of that we > almost always need a spill right before which we don't need. Sorry... on x86_64. -- Christian From Christian.Thalinger at Sun.COM Mon Sep 21 07:35:30 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 21 Sep 2009 16:35:30 +0200 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 Message-ID: <4AB78F32.5000105@Sun.COM> http://cr.openjdk.java.net/~twisti/6879902/webrev.01/ From volker.simonis at gmail.com Mon Sep 21 10:10:47 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 21 Sep 2009 19:10:47 +0200 Subject: review (M) for 6879063: SA should use hsdis for disassembly In-Reply-To: <7483182D-A8FC-4C4D-82B4-4ADAFCA310E7@sun.com> References: <024A7C18-7306-41E4-919A-CCB70D33C691@sun.com> <7483182D-A8FC-4C4D-82B4-4ADAFCA310E7@sun.com> Message-ID: And here just another small addition to the README file: Binutils don't build with Sun Studio 11 because SS11 doesn't understand the __FUNCTION__ macros which are used there. Either replace them with __func__ or use GCC or SS 12 for compilation. You'd probably better submit this change before I come up with some more hairsplitting:) On 9/18/09, Tom Rodriguez wrote: > That should be http://cr.openjdk.java.net/~never/6879063/ > > tom > > > On Sep 17, 2009, at 4:17 PM, Tom Rodriguez wrote: > > > > http://javaweb.sfbay.sun.com/~never/webrev/6879063/ > > > > The SA has Java based disassemblers for x86 and sparc but not for > > amd64. Instead of porting to amd64 we should switch over to using > > hsdis for it like the JVM does. This required a new entry point into > > hsdis, decode_instructions_virtual, which separates the address of the > > code being disassembled from the buffer containing the code. The > > existing uses of decode_instructions have been updated to use the new > > interface and the SA Disassembler has Java native methods that call > > into hsdis and call back up to Java to perform the disassembly. I > > also updated the disassembly printing code to more closely match the > > JVM though we still don't print out a lot things like oops and relocs > > in the SA. > > > > I deleted all the old disassembler logic since it's incompatible with > > the new disassembly interface. I also blew away the moribund dbx > > based SA interface and few other dead files. In the end I deleted > > around 22000 lines of source. > > > > Tested by dumping full assembly from core files. > > > > From Vladimir.Kozlov at Sun.COM Mon Sep 21 10:54:24 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 21 Sep 2009 10:54:24 -0700 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 In-Reply-To: <4AB78F32.5000105@Sun.COM> References: <4AB78F32.5000105@Sun.COM> Message-ID: <4AB7BDD0.2010104@sun.com> Christian, Why you did not use arg_slot(st_off)? Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6879902/webrev.01/ From Vladimir.Kozlov at Sun.COM Mon Sep 21 11:10:34 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 21 Sep 2009 11:10:34 -0700 Subject: src/dst register for andI_rReg_imm255 and andI_rReg_imm65535 In-Reply-To: <4AB78103.6000104@Sun.COM> References: <4AB77FD6.70107@Sun.COM> <4AB78103.6000104@Sun.COM> Message-ID: <4AB7C19A.3030209@sun.com> Christian, Can you tell more about the problem you see? The instructions you pointing use dst register only: "movzbl $dst, $dst\t# int & 0xFF" Vladimir Christian Thalinger wrote: > Christian Thalinger wrote: >> Hi! >> >> Is there a reason why both andI_rReg_imm255 and andI_rReg_imm65535 only >> operate on a src register and not on src and dst? Because of that we >> almost always need a spill right before which we don't need. > > Sorry... on x86_64. -- Christian From Christian.Thalinger at Sun.COM Mon Sep 21 12:06:19 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 21 Sep 2009 21:06:19 +0200 Subject: src/dst register for andI_rReg_imm255 and andI_rReg_imm65535 In-Reply-To: <4AB7C19A.3030209@sun.com> References: <4AB77FD6.70107@Sun.COM> <4AB78103.6000104@Sun.COM> <4AB7C19A.3030209@sun.com> Message-ID: <4AB7CEAB.6060906@Sun.COM> Vladimir Kozlov wrote: > Christian, > > Can you tell more about the problem you see? > The instructions you pointing use dst register only: > > "movzbl $dst, $dst\t# int & 0xFF" Right. Well, it's not a problem, I just wonder why it does not use the src register: "movzbl $dst, $src\t# int & 0xFF" but instead we have to emit a spill instruction to move src to dst. -- Christian From Christian.Thalinger at Sun.COM Mon Sep 21 12:09:59 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 21 Sep 2009 21:09:59 +0200 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 In-Reply-To: <4AB7BDD0.2010104@sun.com> References: <4AB78F32.5000105@Sun.COM> <4AB7BDD0.2010104@sun.com> Message-ID: <4AB7CF87.5040800@Sun.COM> Vladimir Kozlov wrote: > Christian, > > Why you did not use arg_slot(st_off)? I also talked with Tom about this issue and the problem with arg_slot() is that it's for interpreter frames. Looking at arg_slot() it uses arg_offset() to calculate the offset: // base+st_off points to top of argument int arg_offset(const int st_off) { return st_off + Interpreter::value_offset_in_bytes(); } And this seems wrong when storing the arguments for the compiled frame. -- Christian From Thomas.Rodriguez at Sun.COM Mon Sep 21 12:25:18 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 21 Sep 2009 12:25:18 -0700 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 In-Reply-To: <4AB7BDD0.2010104@sun.com> References: <4AB78F32.5000105@Sun.COM> <4AB7BDD0.2010104@sun.com> Message-ID: <2E9EE0A1-3B14-4C02-B0EC-2D8EB0D6EF5F@sun.com> I actually told him not to since using arg_slot in i2c adapters seemed dubious to me since it adds in Interpreter::value_offset_in_bytes(). I guess since the rest of the i2c code uses it we should use it but I'd like an assert that value_offset_in_bytes() == 0 in arg_slot. I don't really like that i2c always forces constants into Rdisp instead of using the simm13 variants. I think all of these should be using RegisterOrConstant and ensure_rs2 to deal with this issue. tom On Sep 21, 2009, at 10:54 AM, Vladimir Kozlov wrote: > Christian, > > Why you did not use arg_slot(st_off)? > > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6879902/webrev.01/ From Thomas.Rodriguez at Sun.COM Mon Sep 21 12:26:06 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 21 Sep 2009 12:26:06 -0700 Subject: src/dst register for andI_rReg_imm255 and andI_rReg_imm65535 In-Reply-To: <4AB7CEAB.6060906@Sun.COM> References: <4AB77FD6.70107@Sun.COM> <4AB78103.6000104@Sun.COM> <4AB7C19A.3030209@sun.com> <4AB7CEAB.6060906@Sun.COM> Message-ID: On Sep 21, 2009, at 12:06 PM, Christian Thalinger wrote: > Vladimir Kozlov wrote: >> Christian, >> >> Can you tell more about the problem you see? >> The instructions you pointing use dst register only: >> >> "movzbl $dst, $dst\t# int & 0xFF" > > Right. Well, it's not a problem, I just wonder why it does not use > the > src register: > > "movzbl $dst, $src\t# int & 0xFF" > > but instead we have to emit a spill instruction to move src to dst. That will occur if there are other users of src. If it's the last use then we shouldn't emit the spill. tom > > -- Christian From Vladimir.Kozlov at Sun.COM Mon Sep 21 12:35:08 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 21 Sep 2009 12:35:08 -0700 Subject: src/dst register for andI_rReg_imm255 and andI_rReg_imm65535 In-Reply-To: <4AB7CEAB.6060906@Sun.COM> References: <4AB77FD6.70107@Sun.COM> <4AB78103.6000104@Sun.COM> <4AB7C19A.3030209@sun.com> <4AB7CEAB.6060906@Sun.COM> Message-ID: <4AB7D56C.8010809@sun.com> The src is not register, it is Int constant which could be immediate value. We use "movzbl $dst, $dst" to avoid immediate value and reduce the instruction size. instruct andI_rReg_imm255(rRegI dst, immI_255 src) %{ match(Set dst (AndI dst src)); The spill you see is to preserve the original value (which should be used later again) since the dst will be modified. The spill should not be related to int constant value "src". Could you show assembler? Vladimir Christian Thalinger wrote: > Vladimir Kozlov wrote: >> Christian, >> >> Can you tell more about the problem you see? >> The instructions you pointing use dst register only: >> >> "movzbl $dst, $dst\t# int & 0xFF" > > Right. Well, it's not a problem, I just wonder why it does not use the > src register: > > "movzbl $dst, $src\t# int & 0xFF" > > but instead we have to emit a spill instruction to move src to dst. > > -- Christian From Vladimir.Kozlov at Sun.COM Mon Sep 21 12:36:47 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 21 Sep 2009 12:36:47 -0700 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 In-Reply-To: <4AB7CF87.5040800@Sun.COM> References: <4AB78F32.5000105@Sun.COM> <4AB7BDD0.2010104@sun.com> <4AB7CF87.5040800@Sun.COM> Message-ID: <4AB7D5CF.3000906@sun.com> OK. That explains it. Changes looks good. Vladimir Christian Thalinger wrote: > Vladimir Kozlov wrote: >> Christian, >> >> Why you did not use arg_slot(st_off)? > > I also talked with Tom about this issue and the problem with arg_slot() > is that it's for interpreter frames. Looking at arg_slot() it uses > arg_offset() to calculate the offset: > > // base+st_off points to top of argument > int arg_offset(const int st_off) { return st_off + > Interpreter::value_offset_in_bytes(); } > > And this seems wrong when storing the arguments for the compiled frame. > > -- Christian From Christian.Thalinger at Sun.COM Tue Sep 22 01:34:52 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 22 Sep 2009 10:34:52 +0200 Subject: src/dst register for andI_rReg_imm255 and andI_rReg_imm65535 In-Reply-To: References: <4AB77FD6.70107@Sun.COM> <4AB78103.6000104@Sun.COM> <4AB7C19A.3030209@sun.com> <4AB7CEAB.6060906@Sun.COM> Message-ID: <4AB88C2C.8030600@Sun.COM> Tom Rodriguez wrote: > On Sep 21, 2009, at 12:06 PM, Christian Thalinger wrote: > >> Vladimir Kozlov wrote: >>> Christian, >>> >>> Can you tell more about the problem you see? >>> The instructions you pointing use dst register only: >>> >>> "movzbl $dst, $dst\t# int & 0xFF" >> Right. Well, it's not a problem, I just wonder why it does not use >> the >> src register: >> >> "movzbl $dst, $src\t# int & 0xFF" >> >> but instead we have to emit a spill instruction to move src to dst. > > That will occur if there are other users of src. If it's the last use > then we shouldn't emit the spill. I was looking at some assembly output while testing something else and I noticed that it's not the case. Maybe LoopUnrollLimit=1 changes the way code is emitted, but in this small loop there is no other use of src and we have a spill: 042 B2: # B2 B3 <- B1 B2 Loop: B2-B2 inner stride: not constant Freq: 1e+06 042 movl R11, RBP # spill 045 movzbl R11, R11 # int & 0xFF 049 addl RBX, R11 # int 04c incl RBP # int 04e cmpl RBP, #2147483647 054 jl,s B2 # loop end P=1.000000 C=809121.000000 -- Christian From Christian.Thalinger at Sun.COM Tue Sep 22 01:38:30 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 22 Sep 2009 10:38:30 +0200 Subject: src/dst register for andI_rReg_imm255 and andI_rReg_imm65535 In-Reply-To: <4AB7D56C.8010809@sun.com> References: <4AB77FD6.70107@Sun.COM> <4AB78103.6000104@Sun.COM> <4AB7C19A.3030209@sun.com> <4AB7CEAB.6060906@Sun.COM> <4AB7D56C.8010809@sun.com> Message-ID: <4AB88D06.3080006@Sun.COM> Vladimir Kozlov wrote: > The src is not register, it is Int constant which could be immediate > value. We use "movzbl $dst, $dst" to avoid immediate value and reduce > the instruction size. > > instruct andI_rReg_imm255(rRegI dst, immI_255 src) > %{ > match(Set dst (AndI dst src)); Sorry, I really should be more verbose when explaining my problems :-/ What I actually meant was, why it's not defined this way: instruct andI_rReg_imm255(rRegI dst, rRegI src, immI_255 mask) %{ match(Set dst (AndI src mask)); format %{ "movzbl $dst, $src\t# int & 0xFF" %} ins_encode %{ __ movzbl($dst$$Register, $src$$Register); %} ins_pipe(ialu_reg); %} This way src and dst still can be the same register and produce the same code as before (if required). > > The spill you see is to preserve the original value (which should be > used later again) since the dst will be modified. The spill > should not be related to int constant value "src". > > Could you show assembler? I just sent one in reply to Tom's message. -- Christian From Christian.Thalinger at Sun.COM Tue Sep 22 01:56:07 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 22 Sep 2009 10:56:07 +0200 Subject: src/dst register for andI_rReg_imm255 and andI_rReg_imm65535 In-Reply-To: <4AB88C2C.8030600@Sun.COM> References: <4AB77FD6.70107@Sun.COM> <4AB78103.6000104@Sun.COM> <4AB7C19A.3030209@sun.com> <4AB7CEAB.6060906@Sun.COM> <4AB88C2C.8030600@Sun.COM> Message-ID: <4AB89127.2010600@Sun.COM> Christian Thalinger wrote: > Tom Rodriguez wrote: >> On Sep 21, 2009, at 12:06 PM, Christian Thalinger wrote: >> >>> Vladimir Kozlov wrote: >>>> Christian, >>>> >>>> Can you tell more about the problem you see? >>>> The instructions you pointing use dst register only: >>>> >>>> "movzbl $dst, $dst\t# int & 0xFF" >>> Right. Well, it's not a problem, I just wonder why it does not use >>> the >>> src register: >>> >>> "movzbl $dst, $src\t# int & 0xFF" >>> >>> but instead we have to emit a spill instruction to move src to dst. >> That will occur if there are other users of src. If it's the last use >> then we shouldn't emit the spill. > > I was looking at some assembly output while testing something else and I > noticed that it's not the case. Maybe LoopUnrollLimit=1 changes the way > code is emitted, but in this small loop there is no other use of src and > we have a spill: > > 042 B2: # B2 B3 <- B1 B2 Loop: B2-B2 inner stride: not constant > Freq: 1e+06 > 042 movl R11, RBP # spill > 045 movzbl R11, R11 # int & 0xFF > 049 addl RBX, R11 # int > 04c incl RBP # int > 04e cmpl RBP, #2147483647 > 054 jl,s B2 # loop end P=1.000000 C=809121.000000 Seems I'm a bit confused today... of course there is another use of src. But what is the reason we need a spill here? src doesn't get changed in the movzbl instruction. -- Christian From Vladimir.Kozlov at Sun.COM Tue Sep 22 08:57:14 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 22 Sep 2009 08:57:14 -0700 Subject: src/dst register for andI_rReg_imm255 and andI_rReg_imm65535 In-Reply-To: <4AB89127.2010600@Sun.COM> References: <4AB77FD6.70107@Sun.COM> <4AB78103.6000104@Sun.COM> <4AB7C19A.3030209@sun.com> <4AB7CEAB.6060906@Sun.COM> <4AB88C2C.8030600@Sun.COM> <4AB89127.2010600@Sun.COM> Message-ID: <4AB8F3DA.7020200@sun.com> movzbl will change the value since it will move only lowest byte. The src is loop variable and its value will be > 255. But you are right - we don't need the spill here: instead of movl R11, RBP # spill movzbl R11, R11 # int & 0xFF it could be movzbl R11, RBP # int & 0xFF And your suggested change will work. Vladimir Christian Thalinger wrote: > Christian Thalinger wrote: >> Tom Rodriguez wrote: >>> On Sep 21, 2009, at 12:06 PM, Christian Thalinger wrote: >>> >>>> Vladimir Kozlov wrote: >>>>> Christian, >>>>> >>>>> Can you tell more about the problem you see? >>>>> The instructions you pointing use dst register only: >>>>> >>>>> "movzbl $dst, $dst\t# int & 0xFF" >>>> Right. Well, it's not a problem, I just wonder why it does not use >>>> the >>>> src register: >>>> >>>> "movzbl $dst, $src\t# int & 0xFF" >>>> >>>> but instead we have to emit a spill instruction to move src to dst. >>> That will occur if there are other users of src. If it's the last use >>> then we shouldn't emit the spill. >> I was looking at some assembly output while testing something else and I >> noticed that it's not the case. Maybe LoopUnrollLimit=1 changes the way >> code is emitted, but in this small loop there is no other use of src and >> we have a spill: >> >> 042 B2: # B2 B3 <- B1 B2 Loop: B2-B2 inner stride: not constant >> Freq: 1e+06 >> 042 movl R11, RBP # spill >> 045 movzbl R11, R11 # int & 0xFF >> 049 addl RBX, R11 # int >> 04c incl RBP # int >> 04e cmpl RBP, #2147483647 >> 054 jl,s B2 # loop end P=1.000000 C=809121.000000 > > Seems I'm a bit confused today... of course there is another use of src. > But what is the reason we need a spill here? src doesn't get changed > in the movzbl instruction. > > -- Christian From Christian.Thalinger at Sun.COM Tue Sep 22 09:57:09 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 22 Sep 2009 18:57:09 +0200 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 In-Reply-To: <2E9EE0A1-3B14-4C02-B0EC-2D8EB0D6EF5F@sun.com> References: <4AB78F32.5000105@Sun.COM> <4AB7BDD0.2010104@sun.com> <2E9EE0A1-3B14-4C02-B0EC-2D8EB0D6EF5F@sun.com> Message-ID: <4AB901E5.20509@Sun.COM> Tom Rodriguez wrote: > I actually told him not to since using arg_slot in i2c adapters seemed > dubious to me since it adds in Interpreter::value_offset_in_bytes(). > I guess since the rest of the i2c code uses it we should use it but > I'd like an assert that value_offset_in_bytes() == 0 in arg_slot. I > don't really like that i2c always forces constants into Rdisp instead > of using the simm13 variants. I think all of these should be using > RegisterOrConstant and ensure_rs2 to deal with this issue. Should I roll that into my change? -- Christian From Thomas.Rodriguez at Sun.COM Tue Sep 22 10:10:26 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 22 Sep 2009 10:10:26 -0700 Subject: Request for reviews (XS): 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 In-Reply-To: <4AB901E5.20509@Sun.COM> References: <4AB78F32.5000105@Sun.COM> <4AB7BDD0.2010104@sun.com> <2E9EE0A1-3B14-4C02-B0EC-2D8EB0D6EF5F@sun.com> <4AB901E5.20509@Sun.COM> Message-ID: <09FB22A5-36C4-4CA2-8806-41AF0D6FA3DA@Sun.COM> 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. tom On Sep 22, 2009, at 9:57 AM, Christian Thalinger wrote: > Tom Rodriguez wrote: >> I actually told him not to since using arg_slot in i2c adapters >> seemed >> dubious to me since it adds in Interpreter::value_offset_in_bytes(). >> I guess since the rest of the i2c code uses it we should use it but >> I'd like an assert that value_offset_in_bytes() == 0 in arg_slot. I >> don't really like that i2c always forces constants into Rdisp instead >> of using the simm13 variants. I think all of these should be using >> RegisterOrConstant and ensure_rs2 to deal with this issue. > > Should I roll that into my change? -- Christian From martinrb at google.com Thu Sep 24 15:11:56 2009 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Sep 2009 15:11:56 -0700 Subject: Summit comment on interference between hot vs. cold code In-Reply-To: References: <4149a0430909181137j25154a25y992eadfa5b20dda5@mail.gmail.com> Message-ID: <1ccfd1c10909241511y46347962v2106352b1e725c09@mail.gmail.com> Years ago, I filed Sun bug: Eliminate remaining performance penalty for using assert http://bugs.sun.com/view_bug.do?bug_id=6445664 The synopsis doesn't make clear that it is really asking for heat-based inlining (and secondarily for reduction in assert startup costs). Martin On Fri, Sep 18, 2009 at 13:56, John Rose wrote: > On Sep 18, 2009, at 11:37 AM, Chuck Rasbold wrote: > >> Also, once a whole method is being compiled, we should be corresponding >> more eager to inline from hot call sites than from cold ones. > > You and Paul are teasing me! ?This (= heat-based inlining) was on my project > list for years. ?We're slowly ?getting there. > > -- John > From john.rose at sun.com Thu Sep 24 23:32:47 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 25 Sep 2009 06:32:47 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 31 new changesets Message-ID: <20090925063351.03551128D9@hg.openjdk.java.net> Changeset: 05f89f00a864 Author: jmasa Date: 2009-08-24 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/05f89f00a864 6798898: CMS: bugs related to class unloading Summary: Override should_remember_klasses() and remember_klass() as needed. Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/referenceProcessor.cpp Changeset: e1fdf4fd34dc Author: tonyp Date: 2009-08-19 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e1fdf4fd34dc 6871111: G1: remove the concurrent overhead tracker Summary: Removing the concurrent overhead tracker from G1, along with the GC overhead reporter and the G1AccountConcurrentOverhead (both of which rely on the the concurrent overhead tracker). Reviewed-by: iveresov, johnc ! 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/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_shared - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp Changeset: ead53f6b615d Author: tonyp Date: 2009-08-24 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ead53f6b615d Merge - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp Changeset: b37c246bf7ce Author: jcoomes Date: 2009-08-11 15:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b37c246bf7ce 6861660: OopMapBlock count/size confusion Reviewed-by: tonyp, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp Changeset: 9eebd3ac74cf Author: jcoomes Date: 2009-08-13 16:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9eebd3ac74cf 6845368: large objects cause a crash or unexpected exception Reviewed-by: jmasa, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp + test/gc/6845368/bigobj.java Changeset: 8624da129f0b Author: apetrusenko Date: 2009-08-31 05:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8624da129f0b 6841313: G1: dirty cards of survivor regions in parallel Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 8b46c4d82093 Author: ysr Date: 2009-09-02 00:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8b46c4d82093 4957990: Perm heap bloat in JVM Summary: Treat ProfileData in MDO's as a source of weak, not strong, roots. Fixes the bug for stop-world collection -- the case of concurrent collection will be fixed separately. Reviewed-by: jcoomes, jmasa, kvn, never ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! 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/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: 2c79770d1f6e Author: tonyp Date: 2009-07-30 16:22 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2c79770d1f6e 6819085: G1: use larger and/or user settable region size Summary: Instead of the region size being hard-coded, allow the user to set it. Reviewed-by: jmasa, johnc, apetrusenko ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: b1606b3c0a8a Author: apetrusenko Date: 2009-09-04 05:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b1606b3c0a8a Merge ! src/share/vm/code/nmethod.cpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp Changeset: b1f5ced5da21 Author: jcoomes Date: 2009-09-03 19:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b1f5ced5da21 6879076: disable jprt sync after builds are done Reviewed-by: kamg, dholmes ! make/jprt.properties Changeset: 68ef3fdcdb76 Author: ysr Date: 2009-09-10 16:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/68ef3fdcdb76 6872136: CMS: confusing message may be printed when a collector is switched off implicitly Summary: Fix CDS/CMS option overrides related to iCMS option CMSIncrementalMode; explicate overrides to error stream. Reviewed-by: coleenp ! src/share/vm/runtime/arguments.cpp Changeset: a6f533fc33e0 Author: kvn Date: 2009-09-14 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a6f533fc33e0 Merge Changeset: eb058abd0562 Author: ysr Date: 2009-09-15 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/eb058abd0562 6861557: G1: assert(top() == bottom() || zfs == Allocated,"Region must be empty, or ...") Summary: Druing heap shrinking, check for emptiness of a region before modifying its ZF status. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: d7c9544cc141 Author: apetrusenko Date: 2009-09-18 06:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d7c9544cc141 Merge Changeset: aafa4232dfd7 Author: asaha Date: 2009-08-28 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/aafa4232dfd7 6821003: Update hotspot windows os_win32 for windows 7 Reviewed-by: xlu ! src/os/windows/vm/os_windows.cpp Changeset: 9601152ccfc1 Author: dcubed Date: 2009-08-28 12:25 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9601152ccfc1 6875393: 2/3 JNI itable index cache is broken Summary: Add missing initialization of cache size. Reviewed-by: tbell ! src/share/vm/oops/instanceKlass.cpp Changeset: 75e30968ebe1 Author: dcubed Date: 2009-08-28 12:32 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/75e30968ebe1 Merge ! src/share/vm/oops/instanceKlass.cpp Changeset: df97b1cf46d8 Author: dcubed Date: 2009-08-28 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/df97b1cf46d8 Merge Changeset: bb287c042e99 Author: apangin Date: 2009-08-30 15:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bb287c042e99 Merge Changeset: 6918603297f7 Author: poonam Date: 2009-09-01 23:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6918603297f7 6858208: jvm crash when specifying TypeProfileWidth=0 on jdk 6.0 Summary: Add an explicit check for TypeProfileWidth == 0 in record_klass_in_profile_helper() functions. Reviewed-by: never, coleenp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp Changeset: 5fdbe2cdf565 Author: andrew Date: 2009-09-08 09:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5fdbe2cdf565 6879689: Fix warning about ignored return value when compiling with -O2 Summary: Store the return value of fwrite and check it matches the size of the array. Reviewed-by: twisti, dholmes ! src/share/vm/adlc/archDesc.cpp Changeset: 0804a88ed4f5 Author: andrew Date: 2009-09-08 09:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0804a88ed4f5 Merge Changeset: 682194ca1d8d Author: acorn Date: 2009-09-10 09:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/682194ca1d8d Merge - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 0fc81f0a8ca8 Author: andrew Date: 2009-09-12 12:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0fc81f0a8ca8 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk Summary: The build fails if the bootstrap JDK defaults to <1.5 Reviewed-by: jcoomes ! make/linux/makefiles/jvmti.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/jvmti.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/sa.make ! make/solaris/makefiles/top.make ! make/windows/makefiles/generated.make ! make/windows/makefiles/jvmti.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/projectfiles/common/Makefile Changeset: e5b31fd85b72 Author: acorn Date: 2009-09-15 16:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e5b31fd85b72 Merge Changeset: ad6585fd4087 Author: acorn Date: 2009-09-04 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ad6585fd4087 6830542: Performance: JVM_DefineClass already verified. Reviewed-by: kamg, phh ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 26b774d693aa Author: acorn Date: 2009-09-16 09:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/26b774d693aa Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp Changeset: 83c29a26f67c Author: acorn Date: 2009-09-16 15:42 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/83c29a26f67c 6879572: SA fails _is_marked_dependent not found Reviewed-by: kamg, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 723131383de6 Author: acorn Date: 2009-09-18 15:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/723131383de6 Merge Changeset: 54b3b351d6f9 Author: jrose Date: 2009-09-23 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/54b3b351d6f9 Merge ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 753cf9794df9 Author: jrose Date: 2009-09-23 23:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/753cf9794df9 6885169: merge of 4957990 and 6863023 causes conflict on do_nmethods Summary: After mechanically merging changes, some by-hand adjustments are needed. Reviewed-by: ysr ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp From Vladimir.Kozlov at Sun.COM Fri Sep 25 09:23:19 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 25 Sep 2009 09:23:19 -0700 Subject: Request for reviews (XS): 6883468 for HS16 and HS17 Message-ID: <4ABCEE77.1070208@sun.com> http://cr.openjdk.java.net/~kvn/6883468/webrev.00 Fixed 6883468: C2 compiler enters infinite loop in PhaseIterGVN::transform Problem: There is ideal transformation ping-pong between AddPNode::Ideal() for raw pointer and CastX2PNode::Ideal() transformation which reconstruct raw AddP node again with the same input SubI(#0, Phi). Solution: Avoid transformation in CastX2PNode::Ideal() if input is SubI node and its in(1) is ConI(#0). Reviewed by: Fix verified (y/n): y, by customer Other testing: JPRT From Changpeng.Fang at Sun.COM Fri Sep 25 13:12:59 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Fri, 25 Sep 2009 13:12:59 -0700 Subject: Request for reviews (XS): 6883468 for HS16 and HS17 In-Reply-To: <4ABCEE77.1070208@sun.com> References: <4ABCEE77.1070208@sun.com> Message-ID: <4ABD244B.1010705@sun.com> Look Good! Changpeng On 09/25/09 09:23, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6883468/webrev.00 > > Fixed 6883468: C2 compiler enters infinite loop in > PhaseIterGVN::transform > > Problem: > There is ideal transformation ping-pong between AddPNode::Ideal() > for raw pointer and CastX2PNode::Ideal() transformation which > reconstruct raw AddP node again with the same input SubI(#0, Phi). > > Solution: > Avoid transformation in CastX2PNode::Ideal() if input is SubI node > and its in(1) is ConI(#0). > > Reviewed by: > > Fix verified (y/n): y, by customer > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Fri Sep 25 13:14:53 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 25 Sep 2009 13:14:53 -0700 Subject: Request for reviews (XS): 6883468 for HS16 and HS17 In-Reply-To: <4ABD244B.1010705@sun.com> References: <4ABCEE77.1070208@sun.com> <4ABD244B.1010705@sun.com> Message-ID: <4ABD24BD.3070708@sun.com> Thanks Vladimir Changpeng Fang wrote: > Look Good! > > Changpeng > > > On 09/25/09 09:23, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/6883468/webrev.00 >> >> Fixed 6883468: C2 compiler enters infinite loop in >> PhaseIterGVN::transform >> >> Problem: >> There is ideal transformation ping-pong between AddPNode::Ideal() >> for raw pointer and CastX2PNode::Ideal() transformation which >> reconstruct raw AddP node again with the same input SubI(#0, Phi). >> >> Solution: >> Avoid transformation in CastX2PNode::Ideal() if input is SubI node >> and its in(1) is ConI(#0). >> >> Reviewed by: >> >> Fix verified (y/n): y, by customer >> >> Other testing: >> JPRT >> > From vladimir.kozlov at sun.com Fri Sep 25 18:07:39 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Sat, 26 Sep 2009 01:07:39 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6883468: C2 compiler enters infinite loop in PhaseIterGVN::transform Message-ID: <20090926010749.74D791298F@hg.openjdk.java.net> Changeset: ddd6f1182ae3 Author: kvn Date: 2009-09-25 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ddd6f1182ae3 6883468: C2 compiler enters infinite loop in PhaseIterGVN::transform Summary: Avoid ideal transformation ping-pong between AddPNode::Ideal() and CastX2PNode::Ideal(). Reviewed-by: cfang ! src/share/vm/opto/connode.cpp From Changpeng.Fang at Sun.COM Mon Sep 28 16:38:23 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Mon, 28 Sep 2009 16:38:23 -0700 Subject: Request for reviews (XS): 6886353: For DeoptimizeALot, JTreg tests should "IgnoreUnrecognizedVMOptions on a product build In-Reply-To: <4A8C3CAF.9070703@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> Message-ID: <4AC148EF.7080803@sun.com> http://cr.openjdk.java.net/~cfang/6886353/webrev.00/ Problem: JTreg tests on a product build will fail if the regression tests use DeoptimizeALot ( a debug option) Solution: Add -XX:+IgnoreUnrecognizedVMOptions so that the product build tests can ignore DeoptimizeALot Thanks, Changpeng From Vladimir.Kozlov at Sun.COM Mon Sep 28 16:56:18 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 28 Sep 2009 16:56:18 -0700 Subject: Request for reviews (XS): 6886353: For DeoptimizeALot, JTreg tests should "IgnoreUnrecognizedVMOptions on a product build In-Reply-To: <4AC148EF.7080803@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4AC148EF.7080803@sun.com> Message-ID: <4AC14D22.9020300@sun.com> Looks good. Vladimir Changpeng Fang wrote: > http://cr.openjdk.java.net/~cfang/6886353/webrev.00/ > > Problem: > JTreg tests on a product build will fail if the regression tests use > DeoptimizeALot ( a debug option) > > Solution: > Add -XX:+IgnoreUnrecognizedVMOptions so that the product build tests > can ignore DeoptimizeALot > > > Thanks, > > Changpeng From changpeng.fang at sun.com Mon Sep 28 19:40:47 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Tue, 29 Sep 2009 02:40:47 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6886353: For DeoptimizeALot, JTreg tests should "IgnoreUnrecognizedVMOptions on a product build Message-ID: <20090929024055.A4C5112A31@hg.openjdk.java.net> Changeset: d6b9fd78f389 Author: cfang Date: 2009-09-28 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d6b9fd78f389 6886353: For DeoptimizeALot, JTreg tests should "IgnoreUnrecognizedVMOptions on a product build Summary: Add IgnoreUnrecognizedVMOptions for JTreg tests (on a product build) to pass with DeoptimizeALot Reviewed-by: kvn ! test/compiler/6823453/Test.java ! test/compiler/6833129/Test.java From Vladimir.Kozlov at Sun.COM Wed Sep 30 09:45:32 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 30 Sep 2009 09:45:32 -0700 Subject: Request for reviews (S): 6875959 Message-ID: <4AC38B2C.2030306@sun.com> http://cr.openjdk.java.net/~kvn/6875959/webrev.01 Fixed 6875959: CTW fails hotspot/src/share/vm/opto/reg_split.cpp:1087 Problem: When choosing a candidate for spilling ties may happen when live ranges defined and used only inside one block. In which case area is 0 and score set to max for all such live ranges. As result coloring is done in the order of live ranges numbers. In the bug's case the spill copy was added to break long (64 bit on 32-bit x86) mem-mem move and because of the above it processed after bound live ranges and there are no registers pair left for it. And when we try to spill it we got the assert. Solution: To break spill ties choose bound live range over unbound (to free register) or one with smaller cost to spill. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT, refworkload From Vladimir.Kozlov at Sun.COM Wed Sep 30 12:18:40 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 30 Sep 2009 12:18:40 -0700 Subject: 6880034: Change 6420645 causes SIGBUS during deoptimisation at a safepoint on 64bit-SPARC In-Reply-To: <6DBF4B78-515D-423E-BBED-DA492C6FD3BA@sun.com> References: <6DBF4B78-515D-423E-BBED-DA492C6FD3BA@sun.com> Message-ID: <4AC3AF10.1030209@sun.com> 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 john.rose at sun.com Wed Sep 30 18:52:19 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Thu, 01 Oct 2009 01:52:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6 new changesets Message-ID: <20091001015238.9C19241660@hg.openjdk.java.net> Changeset: 74a5db69c1fe Author: dcubed Date: 2009-09-21 09:30 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/74a5db69c1fe 6419370: 4/4 new jmethodID code has tiny holes in synchronization Summary: Fix races in jmethodID cache and JNI itable index cache. Reviewed-by: ikrylov, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.hpp Changeset: d72ba3205918 Author: acorn Date: 2009-09-21 18:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d72ba3205918 Merge Changeset: 87770dcf831b Author: dcubed Date: 2009-09-22 21:12 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87770dcf831b 6876794: 4/4 sp07t002 hangs very intermittently Summary: remove over locking by VMThread on "is thread suspended?" check Reviewed-by: dholmes, acorn, andrew ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: c3c4a1d3801a Author: andrew Date: 2009-09-23 11:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c3c4a1d3801a 6884552: remove some unnecessary #ifdef's introduced in the fix for 4957990 Summary: Removed the unnecessary #ifdef's which were interfering with the build of the Zero-assembler port Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: 1af62b6ca0f9 Author: apetrusenko Date: 2009-09-25 04:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1af62b6ca0f9 Merge Changeset: 46b819ba120b Author: jrose Date: 2009-09-30 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/46b819ba120b Merge ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp