From john.r.rose at oracle.com Sat May 1 06:36:38 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 01 May 2010 13:36:38 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6939134: JSR 292 adjustments to method handle invocation Message-ID: <20100501133640.8937444724@hg.openjdk.java.net> Changeset: cd5dbf694d45 Author: jrose Date: 2010-05-01 02:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cd5dbf694d45 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric; also clean up JVM-to-Java interfaces Reviewed-by: twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp From john.r.rose at oracle.com Sat May 1 19:07:43 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 02 May 2010 02:07:43 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 6939134: JSR 292 adjustments to method handle invocation Message-ID: <20100502020756.0D48A4482D@hg.openjdk.java.net> Changeset: 0cd764a1c809 Author: jrose Date: 2010-04-30 23:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0cd764a1c809 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric; also clean up JVM-to-Java interfaces Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/JavaMethodHandle.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/NoAccessException.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/MethodTypeImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/package-info.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! test/java/dyn/MethodHandlesTest.java From john.r.rose at oracle.com Sat May 1 19:08:03 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 02 May 2010 02:08:03 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 6939134: JSR 292 adjustments to method handle invocation Message-ID: <20100502020805.6360C4482E@hg.openjdk.java.net> Changeset: f0e3ec1f9d9f Author: jrose Date: 2010-05-01 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f0e3ec1f9d9f 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric Reviewed-by: twisti ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! test/tools/javac/meth/InvokeDyn.java ! test/tools/javac/meth/InvokeMH.java From john.r.rose at oracle.com Sat May 1 23:28:57 2010 From: john.r.rose at oracle.com (John Rose) Date: Sat, 1 May 2010 23:28:57 -0700 Subject: Request for reviews (L): 6939207: refactor constant pool index processing In-Reply-To: <1272446638.19839.330.camel@macbook> References: <1270631795.2639.207.camel@macbook> <2C343FD4-0DDD-4E23-8D36-BC0822237586@oracle.com> <1272031594.15338.957.camel@macbook> <347FD1C4-6BED-42E6-A3C0-7C9FD1EE8AD5@oracle.com> <1272446638.19839.330.camel@macbook> Message-ID: <2408D46F-E6EE-4685-8E79-B3ACA5A09621@oracle.com> On Apr 28, 2010, at 2:23 AM, Christian Thalinger wrote: > On Fri, 2010-04-23 at 15:52 -0700, John Rose wrote: >> On Apr 23, 2010, at 7:06 AM, Christian Thalinger wrote: >> >>> I have to say I was a little confused about the get_index1, >>> get_index2, ... naming as it looks like you were running out of method >>> names and just append 1, 2, ... ;-) >> >> You are right, it could look that way at first. Can you suggest some >> comments that would short-circuit that impression quickly? > > Well, you could rename it to get_index_u{1,2,4} which would correspond > to the other Bytes::get* functions. Thanks, I like this idea. I changed it to be this way. One wrinkle: get_offset2 changes to get_offset_s2 (since it's signed). I think it is good to advertise the signed-ness of the accessors. > If you want to keep them maybe add a simple comment like: > > // get_{index,offset,constant}{1,2,4} methods return an > // index/offset/constant of the size of the appended number in bytes > //(1, 2, or 4 bytes). > > You may rephrase for better English. > > I just see that ciStreams.hpp has comments on most of these methods. > >> >>> The change is very big. I take a look at it again later. >> >> That will be just fine. > > src/share/vm/prims/jvmtiClassFileReconstituter.cpp: > > Copyright year update missing. Fixed. > src/share/vm/prims/methodComparator.cpp: > > - if (_s_old->get_index_big() != _s_new->get_index_big()) > + if (Bytes::get_Java_u2(_s_old->bcp() + 1) != Bytes::get_Java_u2(_s_new->bcp() + 1)) > > Why can't you use get_index2() here? It's a pre-existing hack. I added comments. I thought about splitting up the comparisons, but didn't want to risk a bug. if (! _s_old->is_wide()) { // We could use get_index_u1 and get_constant_u1, but it's simpler to grab both bytes at once: if (Bytes::get_Java_u2(_s_old->bcp() + 1) != Bytes::get_Java_u2(_s_new->bcp() + 1)) return false; } else { // We could use get_index_u2 and get_constant_u2, but it's simpler to grab all four bytes at once: if (Bytes::get_Java_u4(_s_old->bcp() + 1) != Bytes::get_Java_u4(_s_new->bcp() + 1)) return false; } > Otherwise looks good. Thanks! -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100501/5e02811f/attachment.html From john.r.rose at oracle.com Sun May 2 04:52:40 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 02 May 2010 11:52:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6939196: method handle signatures off the boot class path get linkage errors Message-ID: <20100502115242.AEE6D44928@hg.openjdk.java.net> Changeset: 2ffde6cfe049 Author: jrose Date: 2010-05-01 21:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2ffde6cfe049 6939196: method handle signatures off the boot class path get linkage errors Summary: Adjust MethodType lookup logic to search off the BCP, but not to cache those results Reviewed-by: twisti ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp From Christian.Thalinger at Sun.COM Mon May 3 01:39:47 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 03 May 2010 10:39:47 +0200 Subject: Request for reviews (L): 6939207: refactor constant pool index processing In-Reply-To: <2408D46F-E6EE-4685-8E79-B3ACA5A09621@oracle.com> References: <1270631795.2639.207.camel@macbook> <2C343FD4-0DDD-4E23-8D36-BC0822237586@oracle.com> <1272031594.15338.957.camel@macbook> <347FD1C4-6BED-42E6-A3C0-7C9FD1EE8AD5@oracle.com> <1272446638.19839.330.camel@macbook> <2408D46F-E6EE-4685-8E79-B3ACA5A09621@oracle.com> Message-ID: <1272875987.4703.9.camel@macbook> On Sat, 2010-05-01 at 23:28 -0700, John Rose wrote: > On Apr 28, 2010, at 2:23 AM, Christian Thalinger wrote: > > > On Fri, 2010-04-23 at 15:52 -0700, John Rose wrote: > > > On Apr 23, 2010, at 7:06 AM, Christian Thalinger wrote: > > > > > > > I have to say I was a little confused about the get_index1, > > > > get_index2, ... naming as it looks like you were running out of > > > > method > > > > names and just append 1, 2, ... ;-) > > > > > > You are right, it could look that way at first. Can you suggest > > > some > > > comments that would short-circuit that impression quickly? > > > > Well, you could rename it to get_index_u{1,2,4} which would > > correspond > > to the other Bytes::get* functions. > > > Thanks, I like this idea. I changed it to be this way. > > > One wrinkle: get_offset2 changes to get_offset_s2 (since it's signed). > I think it is good to advertise the signed-ness of the accessors. I agree. > It's a pre-existing hack. I added comments. I thought about > splitting up the comparisons, but didn't want to risk a bug. > > > if (! _s_old->is_wide()) { > // We could use get_index_u1 and get_constant_u1, but it's simpler to grab both bytes at once: > if (Bytes::get_Java_u2(_s_old->bcp() + 1) != Bytes::get_Java_u2(_s_new->bcp() + 1)) > return false; > } else { > // We could use get_index_u2 and get_constant_u2, but it's simpler to grab all four bytes at once: > if (Bytes::get_Java_u4(_s_old->bcp() + 1) != Bytes::get_Java_u4(_s_new->bcp() + 1)) > return false; > } The comments are good. -- Christian From goetz.lindenmaier at sap.com Mon May 3 04:49:09 2010 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 3 May 2010 13:49:09 +0200 Subject: Potential scheduling problem with compressed Oops. Message-ID: <140FA3E3585AD840A3316D2853F974DC0764C9EFC2@DEWDFECCR03.wdf.sap.corp> Hi, we are working on a port of HotSpot for ia64. Currently, we enable this port to support compressed Oops. I ran into an issue where a Decode node was moved above a safepoint by the scheduler. A precedence edge was missing to force the node behind the safepoint. This edge can easily be added if ComputeRegisterAntidependencies() not only considers AddP in this code: 2627 if( n->jvms() ) { // Precedence edge from derived to safept 2628 // Check if last_safept_node was moved by pinch-point insertion in anti_do_use() 2629 if( b->_nodes[last_safept] != last_safept_node ) { 2630 last_safept = b->find_node(last_safept_node); 2631 } 2632 for( uint j=last_safept; j > i; j-- ) { 2633 Node *mach = b->_nodes[j]; 2634 if( mach->is_Mach() && mach->as_Mach()->ideal_Opcode() == Op_AddP ) 2635 mach->add_prec( n ); 2636 } 2637 last_safept = i; 2638 last_safept_node = m; 2639 } So I changed the code here to test for Op_DecodeN and our problem disappeared. I want to share this information as I think this can happen on other platforms, too. And it was pretty hard to track down. We extended the scheduler to consider several blocks, increasing the situations where nodes can be moved past Safepoints. But I assume, a suiting dataflow graph can appear on other platforms, too. Or is there a constraint I missed? Regards, Goetz. From Christian.Thalinger at Sun.COM Mon May 3 08:33:58 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 03 May 2010 17:33:58 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> Message-ID: <1272900838.4703.17.camel@macbook> On Wed, 2010-04-28 at 12:23 -0700, John Rose wrote: > Suggestion: Grep for is_method_handle_adapter in this file, and adapt any relevant changes: > > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-ing-6939134.patch > > (My bad that it's not pushed yet.) Now it is. Is it OK that 3 tests of MethodHandlesTest are failing now? Additionally I found a bug in SPARC C1 with one of the tests (I think it's testCastFailure). Obviously I have to fix that before pushing. -- Christian From tom.rodriguez at oracle.com Mon May 3 10:30:18 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 3 May 2010 10:30:18 -0700 Subject: Potential scheduling problem with compressed Oops. In-Reply-To: <140FA3E3585AD840A3316D2853F974DC0764C9EFC2@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC0764C9EFC2@DEWDFECCR03.wdf.sap.corp> Message-ID: On May 3, 2010, at 4:49 AM, Lindenmaier, Goetz wrote: > Hi, > > we are working on a port of HotSpot for ia64. Currently, we > enable this port to support compressed Oops. > > I ran into an issue where a Decode node was moved above a safepoint > by the scheduler. A precedence edge was missing to force the node > behind the safepoint. Can you describe in more detail why this causes a problem? In general DecodeN and EncodeP can safely span safepoints as long as the anti-deps of their inputs are respected. tom > This edge can easily be added if ComputeRegisterAntidependencies() > not only considers AddP in this code: > > 2627 if( n->jvms() ) { // Precedence edge from derived to safept > 2628 // Check if last_safept_node was moved by pinch-point insertion in anti_do_use() > 2629 if( b->_nodes[last_safept] != last_safept_node ) { > 2630 last_safept = b->find_node(last_safept_node); > 2631 } > 2632 for( uint j=last_safept; j > i; j-- ) { > 2633 Node *mach = b->_nodes[j]; > 2634 if( mach->is_Mach() && mach->as_Mach()->ideal_Opcode() == Op_AddP ) > 2635 mach->add_prec( n ); > 2636 } > 2637 last_safept = i; > 2638 last_safept_node = m; > 2639 } > > So I changed the code here to test for Op_DecodeN and our problem > disappeared. > I want to share this information as I think this can happen on other > platforms, too. And it was pretty hard to track down. > We extended the scheduler to consider several blocks, increasing the > situations where nodes can be moved past Safepoints. But I assume, > a suiting dataflow graph can appear on other platforms, too. Or is > there a constraint I missed? > > Regards, > Goetz. > > > > > > > > > From john.r.rose at oracle.com Mon May 3 11:11:41 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 3 May 2010 11:11:41 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1272900838.4703.17.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> Message-ID: On May 3, 2010, at 8:33 AM, Christian Thalinger wrote: > On Wed, 2010-04-28 at 12:23 -0700, John Rose wrote: >> Suggestion: Grep for is_method_handle_adapter in this file, and adapt any relevant changes: >> >> http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-ing-6939134.patch >> >> (My bad that it's not pushed yet.) > > Now it is. Is it OK that 3 tests of MethodHandlesTest are failing > now? No, that's not OK; I always (?!?) test MHT before pushing. Which patches (or is it the JDK7 push), which version of MHT, and which 3 tests? Possible explanation: The tests change (improve) with both meth-ing and meth-bcp. It's likely there's a temporary version skew somewhere. > Additionally I found a bug in SPARC C1 with one of the tests (I think > it's testCastFailure). Obviously I have to fix that before pushing. Foo. Let me know if I can help. BTW, did the cpindex changes for sparc break anything on your end? -- John From Christian.Thalinger at Sun.COM Mon May 3 11:44:20 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 03 May 2010 20:44:20 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> Message-ID: <1272912260.4703.22.camel@macbook> On Mon, 2010-05-03 at 11:11 -0700, John Rose wrote: > On May 3, 2010, at 8:33 AM, Christian Thalinger wrote: > > > On Wed, 2010-04-28 at 12:23 -0700, John Rose wrote: > >> Suggestion: Grep for is_method_handle_adapter in this file, and adapt any relevant changes: > >> > >> http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-ing-6939134.patch > >> > >> (My bad that it's not pushed yet.) > > > > Now it is. Is it OK that 3 tests of MethodHandlesTest are failing > > now? > > No, that's not OK; I always (?!?) test MHT before pushing. Which > patches (or is it the JDK7 push), which version of MHT, and which 3 > tests? I built the hotspot-comp forest to really test what is then in the repository. > > Possible explanation: The tests change (improve) with both meth-ing > and meth-bcp. It's likely there's a temporary version skew somewhere. JUnit version 4.4 .IIIIII..E...E...................E Time: 0.731 There were 3 failures: 1) testFindVirtual(MethodHandlesTest) java.lang.AssertionError: expected:<(MethodHandlesTest$Example)void> but was:<(java.lang.Object)void> at org.junit.Assert.fail(Assert.java:74) at org.junit.Assert.failNotEquals(Assert.java:448) at org.junit.Assert.assertEquals(Assert.java:102) at org.junit.Assert.assertEquals(Assert.java:117) at MethodHandlesTest.testFindVirtual(MethodHandlesTest.java:518) at MethodHandlesTest.testFindVirtual(MethodHandlesTest.java:492) at MethodHandlesTest.testFindVirtual(MethodHandlesTest.java:488) at MethodHandlesTest.testFindVirtual(MethodHandlesTest.java:467) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:613) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.junit.internal.runners.CompositeRunner.runChildren(CompositeRunner.java:33) at org.junit.internal.runners.CompositeRunner.run(CompositeRunner.java:28) at org.junit.runner.JUnitCore.run(JUnitCore.java:130) at org.junit.runner.JUnitCore.run(JUnitCore.java:109) at org.junit.runner.JUnitCore.run(JUnitCore.java:100) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:81) at org.junit.runner.JUnitCore.main(JUnitCore.java:44) 2) testUnreflect(MethodHandlesTest) java.lang.AssertionError: expected: but was: at org.junit.Assert.fail(Assert.java:74) at org.junit.Assert.failNotEquals(Assert.java:448) at org.junit.Assert.assertEquals(Assert.java:102) at org.junit.Assert.assertEquals(Assert.java:117) at MethodHandlesTest.testUnreflectMaybeSpecial(MethodHandlesTest.java:716) at MethodHandlesTest.testUnreflect(MethodHandlesTest.java:663) at MethodHandlesTest.testUnreflect(MethodHandlesTest.java:651) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:613) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.junit.internal.runners.CompositeRunner.runChildren(CompositeRunner.java:33) at org.junit.internal.runners.CompositeRunner.run(CompositeRunner.java:28) at org.junit.runner.JUnitCore.run(JUnitCore.java:130) at org.junit.runner.JUnitCore.run(JUnitCore.java:109) at org.junit.runner.JUnitCore.run(JUnitCore.java:100) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:81) at org.junit.runner.JUnitCore.main(JUnitCore.java:44) 3) testUserClassInSignature(MethodHandlesTest) java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:74) at org.junit.Assert.assertTrue(Assert.java:37) at org.junit.Assert.assertTrue(Assert.java:46) at MethodHandlesTest.testUserClassInSignature(MethodHandlesTest.java:1879) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:613) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.junit.internal.runners.CompositeRunner.runChildren(CompositeRunner.java:33) at org.junit.internal.runners.CompositeRunner.run(CompositeRunner.java:28) at org.junit.runner.JUnitCore.run(JUnitCore.java:130) at org.junit.runner.JUnitCore.run(JUnitCore.java:109) at org.junit.runner.JUnitCore.run(JUnitCore.java:100) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:81) at org.junit.runner.JUnitCore.main(JUnitCore.java:44) FAILURES!!! Tests run: 25, Failures: 3 > > Additionally I found a bug in SPARC C1 with one of the tests (I think > > it's testCastFailure). Obviously I have to fix that before pushing. > > Foo. Let me know if I can help. It's odd. It only happens with a fastdebug build, a debug build runs fine. C2 and interpreter also works so it must be a C1 bug. Hmm... > BTW, did the cpindex changes for sparc break anything on your end? No, except this one bug everything was good on SPARC. -- Christian From john.r.rose at oracle.com Mon May 3 15:17:18 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 3 May 2010 15:17:18 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1272912260.4703.22.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> <1272912260.4703.22.camel@macbook> Message-ID: <02672F04-CFDC-4212-A0C1-701D56FE88D8@oracle.com> On May 3, 2010, at 11:44 AM, Christian Thalinger wrote: > I built the hotspot-comp forest to really test what is then in the > repository. > >> >> Possible explanation: The tests change (improve) with both meth-ing >> and meth-bcp. It's likely there's a temporary version skew somewhere. > > JUnit version 4.4 > .IIIIII..E...E...................E > Time: 0.731 > There were 3 failures: > 1) testFindVirtual(MethodHandlesTest) > java.lang.AssertionError: expected:<(MethodHandlesTest$Example)void> but was:<(java.lang.Object)void> Good news: That's probably a stale test, my fault. Try testing the same build again, but use the patches to MethodHandlesTest.java in mlvm/jdk/meth-bcp*.patch. It should pass cleanly. I'll make sure the updated unit test gets pushed to hotspot-comp/jdk/. -- John From David.Holmes at oracle.com Mon May 3 15:21:20 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 04 May 2010 08:21:20 +1000 Subject: [Fwd: Re: Performance of locally copied members ?] Message-ID: <4BDF4C60.2010709@oracle.com> Compiler folks, do we know what exactly C1 is not doing in this scenario? People should not have to do this kind of optimization at the Java level. Cheers, David Holmes -------------- next part -------------- An embedded message was scrubbed... From: Osvaldo Doederlein Subject: Re: Performance of locally copied members ? Date: Mon, 3 May 2010 17:13:44 -0300 Size: 10867 Url: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100504/f22ce25c/attachment.eml From tom.rodriguez at oracle.com Mon May 3 16:21:21 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 3 May 2010 16:21:21 -0700 Subject: [Fwd: Re: Performance of locally copied members ?] In-Reply-To: <4BDF4C60.2010709@oracle.com> References: <4BDF4C60.2010709@oracle.com> Message-ID: <1441FCB9-773C-416A-A509-65B3A10E3110@oracle.com> Client doesn't perform loop invariant code motion so caching by hand will certainly make a difference for hot loops. tom On May 3, 2010, at 3:21 PM, David Holmes wrote: > Compiler folks, do we know what exactly C1 is not doing in this scenario? > > People should not have to do this kind of optimization at the Java level. > > Cheers, > David Holmes > From David.Holmes at oracle.com Mon May 3 17:03:57 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 04 May 2010 10:03:57 +1000 Subject: [Fwd: Re: Performance of locally copied members ?] In-Reply-To: <1441FCB9-773C-416A-A509-65B3A10E3110@oracle.com> References: <4BDF4C60.2010709@oracle.com> <1441FCB9-773C-416A-A509-65B3A10E3110@oracle.com> Message-ID: <4BDF646D.9030908@oracle.com> Thanks Tom. Tom Rodriguez said the following on 05/04/10 09:21: > Client doesn't perform loop invariant code motion so caching by hand will certainly make a difference for hot loops. Is this a feasible improvement for C1? David > tom > > On May 3, 2010, at 3:21 PM, David Holmes wrote: > >> Compiler folks, do we know what exactly C1 is not doing in this scenario? >> >> People should not have to do this kind of optimization at the Java level. >> >> Cheers, >> David Holmes >> > From tom.rodriguez at oracle.com Mon May 3 17:10:57 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 3 May 2010 17:10:57 -0700 Subject: [Fwd: Re: Performance of locally copied members ?] In-Reply-To: <4BDF646D.9030908@oracle.com> References: <4BDF4C60.2010709@oracle.com> <1441FCB9-773C-416A-A509-65B3A10E3110@oracle.com> <4BDF646D.9030908@oracle.com> Message-ID: <770252FF-5CA0-460A-8B68-9917912E9121@oracle.com> It's feasible, except that no one is working on C1 performance. tom On May 3, 2010, at 5:03 PM, David Holmes wrote: > Thanks Tom. > > Tom Rodriguez said the following on 05/04/10 09:21: >> Client doesn't perform loop invariant code motion so caching by hand will certainly make a difference for hot loops. > > Is this a feasible improvement for C1? > > David > >> tom >> On May 3, 2010, at 3:21 PM, David Holmes wrote: >>> Compiler folks, do we know what exactly C1 is not doing in this scenario? >>> >>> People should not have to do this kind of optimization at the Java level. >>> >>> Cheers, >>> David Holmes >>> From wimmer at ssw.jku.at Mon May 3 17:30:57 2010 From: wimmer at ssw.jku.at (Christian Wimmer) Date: Mon, 3 May 2010 17:30:57 -0700 Subject: [Fwd: Re: Performance of locally copied members ?] In-Reply-To: <4BDF646D.9030908@oracle.com> References: <4BDF4C60.2010709@oracle.com> <1441FCB9-773C-416A-A509-65B3A10E3110@oracle.com> <4BDF646D.9030908@oracle.com> Message-ID: <64B823D1-484B-4908-BEDF-B8627B12C89C@ssw.jku.at> >> Client doesn't perform loop invariant code motion so caching by >> hand will certainly make a difference for hot loops. > > Is this a feasible improvement for C1? Thomas Wuerthinger implemented a limited form of loop invariant code motion as part of the array bounds check elimination work. It is part of the global value numbering and optimized all the loops that the current global value numbering also optimizes, i.e., call-free blocks with a maximum length of a few basic blocks. Christian From john.r.rose at oracle.com Mon May 3 23:35:26 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 04 May 2010 06:35:26 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 6939196: method handle signatures off the boot class path get linkage errors Message-ID: <20100504063538.BF16C44DD5@hg.openjdk.java.net> Changeset: 4a28a204b726 Author: jrose Date: 2010-05-03 23:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4a28a204b726 6939196: method handle signatures off the boot class path get linkage errors Summary: Remove workaround from MethodHandleImpl lookup code; add JUnit regression test to MethodHandlesTest. Reviewed-by: twisti ! src/share/classes/sun/dyn/MethodHandleImpl.java ! test/java/dyn/MethodHandlesTest.java From john.r.rose at oracle.com Mon May 3 23:54:58 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 3 May 2010 23:54:58 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <02672F04-CFDC-4212-A0C1-701D56FE88D8@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> <1272912260.4703.22.camel@macbook> <02672F04-CFDC-4212-A0C1-701D56FE88D8@oracle.com> Message-ID: <235CD2B7-40D3-4E95-ACF5-A76D3D89F61F@oracle.com> On May 3, 2010, at 3:17 PM, John Rose wrote: > On May 3, 2010, at 11:44 AM, Christian Thalinger wrote: > >> JUnit version 4.4 >> .IIIIII..E...E...................E >> Time: 0.731 >> There were 3 failures: >> 1) testFindVirtual(MethodHandlesTest) >> java.lang.AssertionError: expected:<(MethodHandlesTest$Example)void> but was:<(java.lang.Object)void> > > I'll make sure the updated unit test gets pushed to hotspot-comp/jdk/. I pushed the JDK update for meth-bcp-6939196.patch to hotspot-comp/jdk/. You are right that this shouldn't affect just a fastdebug build. Maybe the discrepancy is a problem with CHECK_UNHANDLED_OOPS, which is turned on *only* with Solaris fastdebug builds. If it's not a Solaris build, or it's product or plain debug build, CHECK_UNHANDLED_OOPS will not do its special thing. If in addition it is a SPARC-only problem, that narrows it down to an occurence of the name 'oop' methodHandles_sparc or similar code. -- John From goetz.lindenmaier at sap.com Tue May 4 02:00:51 2010 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 4 May 2010 11:00:51 +0200 Subject: Potential scheduling problem with compressed Oops. Message-ID: <140FA3E3585AD840A3316D2853F974DC0764D0573D@DEWDFECCR03.wdf.sap.corp> Hi Tom, before scheduling, I saw something like this: LoadN | \ | Safepoint | DecodeN | | AddP Where DecodeN defines a new register. Scheduling added a (dotted) precedence edge: LoadN | \ | Safepoint | : DecodeN : | : | ....: AddP After scheduling, we had this: LoadN | \ DecodeN \ | \ | Safepoint | : | ....: AddP And the register defined by DecodeN was not updated during a GC. In my case, DecodeN and AddP were in a block succeeding the block with the Safepoint, and our scheduler moved the Decode up, but I assume the same can happen within a single block. I can't reproduce this with the Sun HotSpot, but wanted to point to this potential problem. Cheers, Goetz. -----Original Message----- From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Montag, 3. Mai 2010 19:30 To: Lindenmaier, Goetz Cc: hotspot compiler Subject: Re: Potential scheduling problem with compressed Oops. On May 3, 2010, at 4:49 AM, Lindenmaier, Goetz wrote: > Hi, > > we are working on a port of HotSpot for ia64. Currently, we > enable this port to support compressed Oops. > > I ran into an issue where a Decode node was moved above a safepoint > by the scheduler. A precedence edge was missing to force the node > behind the safepoint. Can you describe in more detail why this causes a problem? In general DecodeN and EncodeP can safely span safepoints as long as the anti-deps of their inputs are respected. tom > This edge can easily be added if ComputeRegisterAntidependencies() > not only considers AddP in this code: > > 2627 if( n->jvms() ) { // Precedence edge from derived to safept > 2628 // Check if last_safept_node was moved by pinch-point insertion in anti_do_use() > 2629 if( b->_nodes[last_safept] != last_safept_node ) { > 2630 last_safept = b->find_node(last_safept_node); > 2631 } > 2632 for( uint j=last_safept; j > i; j-- ) { > 2633 Node *mach = b->_nodes[j]; > 2634 if( mach->is_Mach() && mach->as_Mach()->ideal_Opcode() == Op_AddP ) > 2635 mach->add_prec( n ); > 2636 } > 2637 last_safept = i; > 2638 last_safept_node = m; > 2639 } > > So I changed the code here to test for Op_DecodeN and our problem > disappeared. > I want to share this information as I think this can happen on other > platforms, too. And it was pretty hard to track down. > We extended the scheduler to consider several blocks, increasing the > situations where nodes can be moved past Safepoints. But I assume, > a suiting dataflow graph can appear on other platforms, too. Or is > there a constraint I missed? > > Regards, > Goetz. > > > > > > > > > From Christian.Thalinger at Sun.COM Tue May 4 03:21:44 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 04 May 2010 12:21:44 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <235CD2B7-40D3-4E95-ACF5-A76D3D89F61F@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> <1272912260.4703.22.camel@macbook> <02672F04-CFDC-4212-A0C1-701D56FE88D8@oracle.com> <235CD2B7-40D3-4E95-ACF5-A76D3D89F61F@oracle.com> Message-ID: <1272968504.4703.112.camel@macbook> On Mon, 2010-05-03 at 23:54 -0700, John Rose wrote: > On May 3, 2010, at 3:17 PM, John Rose wrote: > > > On May 3, 2010, at 11:44 AM, Christian Thalinger wrote: > > > >> JUnit version 4.4 > >> .IIIIII..E...E...................E > >> Time: 0.731 > >> There were 3 failures: > >> 1) testFindVirtual(MethodHandlesTest) > >> java.lang.AssertionError: expected:<(MethodHandlesTest$Example)void> but was:<(java.lang.Object)void> > > > > I'll make sure the updated unit test gets pushed to hotspot-comp/jdk/. > > I pushed the JDK update for meth-bcp-6939196.patch to hotspot-comp/jdk/. All tests pass now. Thanks. > > You are right that this shouldn't affect just a fastdebug build. > > Maybe the discrepancy is a problem with CHECK_UNHANDLED_OOPS, which is > turned on *only* with Solaris fastdebug builds. > If it's not a Solaris build, or it's product or plain debug build, > CHECK_UNHANDLED_OOPS will not do its special thing. > If in addition it is a SPARC-only problem, that narrows it down to an > occurence of the name 'oop' methodHandles_sparc or similar code. Ohh, it also happens with a debug build when using -Xbatch. It seems the compiler was too slow to finish the compile. And it also fails with C2 using -Xbatch. So this is a more basic bug. -- Christian From Christian.Thalinger at Sun.COM Tue May 4 07:20:23 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 04 May 2010 16:20:23 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1272968504.4703.112.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> <1272912260.4703.22.camel@macbook> <02672F04-CFDC-4212-A0C1-701D56FE88D8@oracle.com> <235CD2B7-40D3-4E95-ACF5-A76D3D89F61F@oracle.com> <1272968504.4703.112.camel@macbook> Message-ID: <1272982823.950.14.camel@macbook> On Tue, 2010-05-04 at 12:21 +0200, Christian Thalinger wrote: > Ohh, it also happens with a debug build when using -Xbatch. It seems > the compiler was too slow to finish the compile. And it also fails with > C2 using -Xbatch. So this is a more basic bug. I think I got it: diff -r 2ffde6cfe049 src/cpu/sparc/vm/methodHandles_sparc.cpp --- a/src/cpu/sparc/vm/methodHandles_sparc.cpp +++ b/src/cpu/sparc/vm/methodHandles_sparc.cpp @@ -369,8 +369,6 @@ void MethodHandles::generate_method_hand // registers, as required type in O3, failing object (or NULL) // in O2, failing bytecode type in O1. - __ mov(O5_savedSP, SP); // Cut the stack back to where the caller started. - // Push arguments as if coming from the interpreter. Register O0_scratch = O0_argslot; int stackElementSize = Interpreter::stackElementSize; I currently don't see why this should be a problem since O5_savedSP should contain the correct sender SP. -- Christian From Christian.Thalinger at Sun.COM Tue May 4 08:17:19 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 04 May 2010 15:17:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6949423: remove tagged stack interpreter for Zero Message-ID: <20100504151728.E23F844EBE@hg.openjdk.java.net> Changeset: 68d6683eaef7 Author: twisti Date: 2010-05-04 02:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/68d6683eaef7 6949423: remove tagged stack interpreter for Zero Summary: Missed Zero changes for 6943304. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/interpreter_zero.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp From john.r.rose at oracle.com Tue May 4 10:34:00 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 4 May 2010 10:34:00 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1272982823.950.14.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> <1272912260.4703.22.camel@macbook> <02672F04-CFDC-4212-A0C1-701D56FE88D8@oracle.com> <235CD2B7-40D3-4E95-ACF5-A76D3D89F61F@oracle.com> <1272968504.4703.112.camel@macbook> <1272982823.950.14.camel@macbook> Message-ID: <5740DFD5-4DE3-46DE-A2E7-EF71B81AA56B@oracle.com> On May 4, 2010, at 7:20 AM, Christian Thalinger wrote: > I currently don't see why this should be a problem since O5_savedSP > should contain the correct sender SP. Maybe O5 is getting trashed by a trip through C2I or I2C adapters? Could the throwing MH in question be getting called from compiled code maybe? -- John P.S. I just noticed that this comment a few lines above above isn't obviously correct: // save: Gargs, O5_savedSP The call_VM_leaf macro probably trashes the G registers. That only happens with -XX:+TraceMethodHandles, so it's OK for now. From tom.rodriguez at oracle.com Tue May 4 10:56:39 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 4 May 2010 10:56:39 -0700 Subject: Potential scheduling problem with compressed Oops. In-Reply-To: <140FA3E3585AD840A3316D2853F974DC0764D0573D@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC0764D0573D@DEWDFECCR03.wdf.sap.corp> Message-ID: <7ED0297E-45CF-4DFA-A8AC-A9414036F23E@oracle.com> Narrow oops can and do appear in oopmaps so I don't see anything wrong with that schedule. Narrow oops that are live across a safepoint are handled by this code in BuildOopMaps: } else if( t->isa_narrowoop() ) { assert( !OptoReg::is_valid(_callees[reg]), "oop can't be callee save" ); // Check for a legal reg name in the oopMap and bailout if it is not. if (!omap->legal_vm_reg_name(r)) { regalloc->C->record_method_not_compilable("illegal oopMap register name"); continue; } if( mcall ) { // Outgoing argument GC mask responsibility belongs to the callee, // not the caller. Inspect the inputs to the call, to see if // this live-range is one of them. uint cnt = mcall->tf()->domain()->cnt(); uint j; for( j = TypeFunc::Parms; j < cnt; j++) if( mcall->in(j) == def ) break; // reaching def is an argument oop if( j < cnt ) // arg oops dont go in GC map continue; // Continue on to the next register } omap->set_narrowoop(r); So I think if you have a bug it's not with scheduling. You need to figure out why the DecodeN wasn't added to the oopmap. tom On May 4, 2010, at 2:00 AM, Lindenmaier, Goetz wrote: > Hi Tom, > > before scheduling, I saw something like this: > > LoadN > | \ > | Safepoint > | > DecodeN > | > | > AddP > > Where DecodeN defines a new register. > Scheduling added a (dotted) precedence edge: > > LoadN > | \ > | Safepoint > | : > DecodeN : > | : > | ....: > AddP > > After scheduling, we had this: > > LoadN > | \ > DecodeN \ > | \ > | Safepoint > | : > | ....: > AddP > > And the register defined by DecodeN was not updated during a GC. > > In my case, DecodeN and AddP were in a block succeeding the block with > the Safepoint, and our scheduler moved the Decode up, but I assume the > same can happen within a single block. > I can't reproduce this with the Sun HotSpot, but wanted to point to > this potential problem. > > Cheers, > Goetz. > > > > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Montag, 3. Mai 2010 19:30 > To: Lindenmaier, Goetz > Cc: hotspot compiler > Subject: Re: Potential scheduling problem with compressed Oops. > > > On May 3, 2010, at 4:49 AM, Lindenmaier, Goetz wrote: > >> Hi, >> >> we are working on a port of HotSpot for ia64. Currently, we >> enable this port to support compressed Oops. >> >> I ran into an issue where a Decode node was moved above a safepoint >> by the scheduler. A precedence edge was missing to force the node >> behind the safepoint. > > Can you describe in more detail why this causes a problem? In general DecodeN and EncodeP can safely span safepoints as long as the anti-deps of their inputs are respected. > > tom > > >> This edge can easily be added if ComputeRegisterAntidependencies() >> not only considers AddP in this code: >> >> 2627 if( n->jvms() ) { // Precedence edge from derived to safept >> 2628 // Check if last_safept_node was moved by pinch-point insertion in anti_do_use() >> 2629 if( b->_nodes[last_safept] != last_safept_node ) { >> 2630 last_safept = b->find_node(last_safept_node); >> 2631 } >> 2632 for( uint j=last_safept; j > i; j-- ) { >> 2633 Node *mach = b->_nodes[j]; >> 2634 if( mach->is_Mach() && mach->as_Mach()->ideal_Opcode() == Op_AddP ) >> 2635 mach->add_prec( n ); >> 2636 } >> 2637 last_safept = i; >> 2638 last_safept_node = m; >> 2639 } >> >> So I changed the code here to test for Op_DecodeN and our problem >> disappeared. >> I want to share this information as I think this can happen on other >> platforms, too. And it was pretty hard to track down. >> We extended the scheduler to consider several blocks, increasing the >> situations where nodes can be moved past Safepoints. But I assume, >> a suiting dataflow graph can appear on other platforms, too. Or is >> there a constraint I missed? >> >> Regards, >> Goetz. >> >> >> >> >> >> >> >> >> > From Christian.Thalinger at Sun.COM Tue May 4 12:52:00 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 04 May 2010 21:52:00 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <5740DFD5-4DE3-46DE-A2E7-EF71B81AA56B@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> <1272912260.4703.22.camel@macbook> <02672F04-CFDC-4212-A0C1-701D56FE88D8@oracle.com> <235CD2B7-40D3-4E95-ACF5-A76D3D89F61F@oracle.com> <1272968504.4703.112.camel@macbook> <1272982823.950.14.camel@macbook> <5740DFD5-4DE3-46DE-A2E7-EF71B81AA56B@oracle.com> Message-ID: <1273002720.950.104.camel@macbook> On Tue, 2010-05-04 at 10:34 -0700, John Rose wrote: > On May 4, 2010, at 7:20 AM, Christian Thalinger wrote: > > > I currently don't see why this should be a problem since O5_savedSP > > should contain the correct sender SP. > > Maybe O5 is getting trashed by a trip through C2I or I2C adapters? Hmm, not sure where that could happen. I'll look again. > Could the throwing MH in question be getting called from compiled code > maybe? How could that happen? I thought every call to a MH needs to go through c2i before. > P.S. I just noticed that this comment a few lines above above isn't obviously correct: > // save: Gargs, O5_savedSP I fix that. -- Christian From gbenson at redhat.com Wed May 5 04:51:26 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 5 May 2010 12:51:26 +0100 Subject: Review Request: 6939134 broke Zero Message-ID: <20100505115125.GB5054@redhat.com> Hi all, The commit for 6939134 broke Zero. This webrev fixes: http://cr.openjdk.java.net/~gbenson/6939134-broke-zero/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Wed May 5 06:11:11 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 05 May 2010 15:11:11 +0200 Subject: Review Request: 6939134 broke Zero In-Reply-To: <20100505115125.GB5054@redhat.com> References: <20100505115125.GB5054@redhat.com> Message-ID: <1273065071.950.117.camel@macbook> On Wed, 2010-05-05 at 12:51 +0100, Gary Benson wrote: > Hi all, > > The commit for 6939134 broke Zero. This webrev fixes: > > http://cr.openjdk.java.net/~gbenson/6939134-broke-zero/ > > I don't have a bug id for this. 6949830: 6939134 broke Zero Changes are good and the job is in the queue. -- Christian From gbenson at redhat.com Wed May 5 06:17:26 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 5 May 2010 14:17:26 +0100 Subject: Review Request: 6939134 broke Zero In-Reply-To: <1273065071.950.117.camel@macbook> References: <20100505115125.GB5054@redhat.com> <1273065071.950.117.camel@macbook> Message-ID: <20100505131726.GC5054@redhat.com> Christian Thalinger wrote: > On Wed, 2010-05-05 at 12:51 +0100, Gary Benson wrote: > > The commit for 6939134 broke Zero. This webrev fixes: > > > > http://cr.openjdk.java.net/~gbenson/6939134-broke-zero/ > > > > I don't have a bug id for this. > > 6949830: 6939134 broke Zero > > Changes are good and the job is in the queue. Thanks Christian. Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Wed May 5 08:00:16 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 5 May 2010 16:00:16 +0100 Subject: Review Request: Zero stack improvements Message-ID: <20100505150015.GD5054@redhat.com> Hi all, In Zero, at present, the logic for determining the size of the Zero stack is in the call stub. This webrev moves this logic into a method of the ZeroStack class, ZeroStack::suggest_size(). This consolidates access to the ABI stack, and includes the shadow pages in all calculations. (Previously the call stub did not consider the shadow pages, which led to some odd sizes being chosen on systems with large pages.) http://cr.openjdk.java.net/~gbenson/zero-stack-improvements/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Thu May 6 01:55:15 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 06 May 2010 08:55:15 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6949830: 6939134 broke Zero Message-ID: <20100506085518.46863444AA@hg.openjdk.java.net> Changeset: d6e880569997 Author: twisti Date: 2010-05-05 05:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d6e880569997 6949830: 6939134 broke Zero Summary: The commit for 6939134 broke Zero. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/methodHandles_zero.cpp From Christian.Thalinger at Sun.COM Thu May 6 02:11:40 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 06 May 2010 11:11:40 +0200 Subject: Review Request: Zero stack improvements In-Reply-To: <20100505150015.GD5054@redhat.com> References: <20100505150015.GD5054@redhat.com> Message-ID: <1273137100.950.130.camel@macbook> On Wed, 2010-05-05 at 16:00 +0100, Gary Benson wrote: > Hi all, > > In Zero, at present, the logic for determining the size of the Zero > stack is in the call stub. This webrev moves this logic into a > method of the ZeroStack class, ZeroStack::suggest_size(). This > consolidates access to the ABI stack, and includes the shadow pages > in all calculations. (Previously the call stub did not consider the > shadow pages, which led to some odd sizes being chosen on systems > with large pages.) > > http://cr.openjdk.java.net/~gbenson/zero-stack-improvements/ > > I don't have a bug id for this. 6950178: Zero stack improvements Changes are good and it's in the queue. -- Christian From Christian.Thalinger at Sun.COM Thu May 6 04:30:52 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 06 May 2010 11:30:52 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6950178: Zero stack improvements Message-ID: <20100506113055.01C0644506@hg.openjdk.java.net> Changeset: 348346af6676 Author: twisti Date: 2010-05-06 02:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/348346af6676 6950178: Zero stack improvements Summary: Moves the logic for determining the size of the Zero stack into the ZeroStack class. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/stack_zero.cpp ! src/cpu/zero/vm/stack_zero.hpp ! src/cpu/zero/vm/stack_zero.inline.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/share/vm/includeDB_zero From gbenson at redhat.com Thu May 6 04:42:57 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 6 May 2010 12:42:57 +0100 Subject: Review Request: Zero stack improvements In-Reply-To: <1273137100.950.130.camel@macbook> References: <20100505150015.GD5054@redhat.com> <1273137100.950.130.camel@macbook> Message-ID: <20100506114257.GD3529@redhat.com> Christian Thalinger wrote: > On Wed, 2010-05-05 at 16:00 +0100, Gary Benson wrote: > > In Zero, at present, the logic for determining the size of the Zero > > stack is in the call stub. This webrev moves this logic into a > > method of the ZeroStack class, ZeroStack::suggest_size(). This > > consolidates access to the ABI stack, and includes the shadow pages > > in all calculations. (Previously the call stub did not consider the > > shadow pages, which led to some odd sizes being chosen on systems > > with large pages.) > > > > http://cr.openjdk.java.net/~gbenson/zero-stack-improvements/ > > > > I don't have a bug id for this. > > 6950178: Zero stack improvements > > Changes are good and it's in the queue. Thank you :) Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Thu May 6 06:46:32 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 6 May 2010 14:46:32 +0100 Subject: Review Request: Zero/Shark interface updates Message-ID: <20100506134632.GE3529@redhat.com> Hi all, Zero needs a couple of new methods to allow Shark to access the new frame anchor field JavaFrameAnchor::_last_Java_fp that was added by 6939182. It also needs a method to allow Shark's fake stub frames to be identified from within the frame walker. This webrev adds them: http://cr.openjdk.java.net/~gbenson/shark-api-updates/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Fri May 7 04:26:36 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 07 May 2010 13:26:36 +0200 Subject: Review Request: Zero/Shark interface updates In-Reply-To: <20100506134632.GE3529@redhat.com> References: <20100506134632.GE3529@redhat.com> Message-ID: <1273231596.950.151.camel@macbook> On Thu, 2010-05-06 at 14:46 +0100, Gary Benson wrote: > Hi all, > > Zero needs a couple of new methods to allow Shark to access the new > frame anchor field JavaFrameAnchor::_last_Java_fp that was added by > 6939182. It also needs a method to allow Shark's fake stub frames > to be identified from within the frame walker. This webrev adds > them: > > http://cr.openjdk.java.net/~gbenson/shark-api-updates/ > > I don't have a bug id for this. I created: 6950617: Zero/Shark interface updates But I have quota problems and couldn't find quickly another machine from where I can submit the JPRT job. Trying to fix either or both issues. -- Christian From Christian.Thalinger at Sun.COM Mon May 10 03:37:20 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 10 May 2010 12:37:20 +0200 Subject: Review Request: Zero/Shark interface updates In-Reply-To: <1273231596.950.151.camel@macbook> References: <20100506134632.GE3529@redhat.com> <1273231596.950.151.camel@macbook> Message-ID: <1273487840.1439.6.camel@macbook> On Fri, 2010-05-07 at 13:26 +0200, Christian Thalinger wrote: > On Thu, 2010-05-06 at 14:46 +0100, Gary Benson wrote: > > Hi all, > > > > Zero needs a couple of new methods to allow Shark to access the new > > frame anchor field JavaFrameAnchor::_last_Java_fp that was added by > > 6939182. It also needs a method to allow Shark's fake stub frames > > to be identified from within the frame walker. This webrev adds > > them: > > > > http://cr.openjdk.java.net/~gbenson/shark-api-updates/ > > > > I don't have a bug id for this. > > I created: > > 6950617: Zero/Shark interface updates > > But I have quota problems and couldn't find quickly another machine from > where I can submit the JPRT job. Trying to fix either or both issues. My quota problem is resolved and the job is in the queue. -- Christian From gbenson at redhat.com Mon May 10 03:48:49 2010 From: gbenson at redhat.com (Gary Benson) Date: Mon, 10 May 2010 11:48:49 +0100 Subject: Review Request: Zero/Shark interface updates In-Reply-To: <1273487840.1439.6.camel@macbook> References: <20100506134632.GE3529@redhat.com> <1273231596.950.151.camel@macbook> <1273487840.1439.6.camel@macbook> Message-ID: <20100510104848.GB3328@redhat.com> Christian Thalinger wrote: > On Fri, 2010-05-07 at 13:26 +0200, Christian Thalinger wrote: > > I created: > > > > 6950617: Zero/Shark interface updates > > > > But I have quota problems and couldn't find quickly another machine from > > where I can submit the JPRT job. Trying to fix either or both issues. > > My quota problem is resolved and the job is in the queue. Awesome, thanks :) Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Mon May 10 04:51:48 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 10 May 2010 13:51:48 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1273002720.950.104.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> <1272912260.4703.22.camel@macbook> <02672F04-CFDC-4212-A0C1-701D56FE88D8@oracle.com> <235CD2B7-40D3-4E95-ACF5-A76D3D89F61F@oracle.com> <1272968504.4703.112.camel@macbook> <1272982823.950.14.camel@macbook> <5740DFD5-4DE3-46DE-A2E7-EF71B81AA56B@oracle.com> <1273002720.950.104.camel@macbook> Message-ID: <1273492308.1439.18.camel@macbook> On Tue, 2010-05-04 at 21:52 +0200, Christian Thalinger wrote: > On Tue, 2010-05-04 at 10:34 -0700, John Rose wrote: > > On May 4, 2010, at 7:20 AM, Christian Thalinger wrote: > > > > > I currently don't see why this should be a problem since O5_savedSP > > > should contain the correct sender SP. > > > > Maybe O5 is getting trashed by a trip through C2I or I2C adapters? > > Hmm, not sure where that could happen. I'll look again. > > > Could the throwing MH in question be getting called from compiled code > > maybe? > > How could that happen? I thought every call to a MH needs to go through > c2i before. Can't we simply not cut back to the caller's SP? Since SP should be restored correctly from FP during unwind anyways. -- Christian From Christian.Thalinger at Sun.COM Mon May 10 05:12:39 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 10 May 2010 14:12:39 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1273492308.1439.18.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> <1272912260.4703.22.camel@macbook> <02672F04-CFDC-4212-A0C1-701D56FE88D8@oracle.com> <235CD2B7-40D3-4E95-ACF5-A76D3D89F61F@oracle.com> <1272968504.4703.112.camel@macbook> <1272982823.950.14.camel@macbook> <5740DFD5-4DE3-46DE-A2E7-EF71B81AA56B@oracle.com> <1273002720.950.104.camel@macbook> <1273492308.1439.18.camel@macbook> Message-ID: <1273493559.1439.19.camel@macbook> On Mon, 2010-05-10 at 13:51 +0200, Christian Thalinger wrote: > On Tue, 2010-05-04 at 21:52 +0200, Christian Thalinger wrote: > > On Tue, 2010-05-04 at 10:34 -0700, John Rose wrote: > > > On May 4, 2010, at 7:20 AM, Christian Thalinger wrote: > > > > > > > I currently don't see why this should be a problem since O5_savedSP > > > > should contain the correct sender SP. > > > > > > Maybe O5 is getting trashed by a trip through C2I or I2C adapters? > > > > Hmm, not sure where that could happen. I'll look again. > > > > > Could the throwing MH in question be getting called from compiled code > > > maybe? > > > > How could that happen? I thought every call to a MH needs to go through > > c2i before. > > Can't we simply not cut back to the caller's SP? Since SP should be > restored correctly from FP during unwind anyways. ...actually from L7. -- Christian From Christian.Thalinger at Sun.COM Mon May 10 07:54:25 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 10 May 2010 14:54:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6950617: Zero/Shark interface updates Message-ID: <20100510145429.B41B044112@hg.openjdk.java.net> Changeset: 6cfbdb113e52 Author: twisti Date: 2010-05-07 04:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6cfbdb113e52 6950617: Zero/Shark interface updates Summary: Zero needs a couple of new methods to allow Shark to access the new frame anchor field. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.hpp ! src/cpu/zero/vm/javaFrameAnchor_zero.hpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp From gbenson at redhat.com Tue May 11 09:09:03 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 11 May 2010 17:09:03 +0100 Subject: Review Request: Zero deoptimizer changes Message-ID: <20100511160902.GC25502@redhat.com> Hi all, The way Zero currently handles deoptimization can lead to methods being freed while they are still being executed, with the obvious consequences. This webrev fixes: http://cr.openjdk.java.net/~gbenson/zero-deopt-fix/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From vladimir.kozlov at oracle.com Tue May 11 17:38:09 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 May 2010 17:38:09 -0700 Subject: Request for reviews (XS): 6951686: Using large pages on Linux prevents zero based compressed oops Message-ID: <4BE9F871.1040009@oracle.com> http://cr.openjdk.java.net/~kvn/6951686/webrev Fixed 6951686: Using large pages on Linux prevents zero based compressed oops The method os::reserve_memory_special() is used with -XX:+UseLargePages on Linux. It uses shared memory API to reserve memory but it does not use req_addr. Use req_addr when attaching shared memory segment. From john.r.rose at oracle.com Tue May 11 18:26:23 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 12 May 2010 01:26:23 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 17 new changesets Message-ID: <20100512012658.802D3443D7@hg.openjdk.java.net> Changeset: 615a9d95d265 Author: johnc Date: 2010-04-27 18:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/615a9d95d265 6946056: assert((intptr_t) sp()<=(intptr_t) result,"result must>=than stack pointer"), frame_x86.cpp:295 Summary: frame::interpreter_frame_monitor_end() will spuriously assert for a frame that spans 0x80000000. Cast values to intptr_t* (rather than intptr_t) so that an unsigned pointer compare is performed. Reviewed-by: never, jcoomes, pbk ! src/cpu/x86/vm/frame_x86.cpp Changeset: cff162798819 Author: jcoomes Date: 2009-10-11 16:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cff162798819 6888953: some calls to function-like macros are missing semicolons Reviewed-by: pbk, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/utilities/xmlstream.cpp Changeset: f03d0a26bf83 Author: jcoomes Date: 2010-04-22 13:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f03d0a26bf83 6888954: argument formatting for assert() and friends Reviewed-by: kvn, twisti, apetrusenko, never, dcubed ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp + test/runtime/6888954/vmerrors.sh Changeset: befdf73d6b82 Author: tonyp Date: 2010-05-03 16:31 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/befdf73d6b82 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: e0a1a502e402 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e0a1a502e402 Added tag jdk7-b90 for changeset 605c9707a766 ! .hgtags Changeset: 7b03170e1fcb Author: trims Date: 2010-04-29 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7b03170e1fcb Merge Changeset: 310cdbc35535 Author: trims Date: 2010-04-29 15:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/310cdbc35535 6948636: Bump the HS18 build number to 04 Summary: Update the HS18 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 03a8443caa4b Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/03a8443caa4b Added tag jdk7-b91 for changeset e0a1a502e402 ! .hgtags Changeset: e3fa0cc77f74 Author: trims Date: 2010-05-04 12:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e3fa0cc77f74 Merge Changeset: 3221d1887d30 Author: trims Date: 2010-05-04 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3221d1887d30 Added tag hs18-b03 for changeset 25f53b53aaa3 ! .hgtags Changeset: 731bcbe3c9c4 Author: trims Date: 2010-05-06 12:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/731bcbe3c9c4 6950438: Add 6u18 and 6u20 release values explicitly to jprt.properties file Summary: modify jprt.properties to allow JPRT to use 6u18 and 6u18 targets Reviewed-by: ohair ! make/jprt.properties Changeset: 5dabb4e73380 Author: trims Date: 2010-05-06 13:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5dabb4e73380 Merge Changeset: fd3de7134574 Author: mikejwre Date: 2010-05-06 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fd3de7134574 Added tag jdk7-b92 for changeset 3221d1887d30 ! .hgtags Changeset: 80ccc94456b2 Author: trims Date: 2010-05-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/80ccc94456b2 Merge Changeset: 359375cb7de6 Author: trims Date: 2010-05-07 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/359375cb7de6 Added tag hs18-b04 for changeset 310cdbc35535 ! .hgtags Changeset: e8e83be27dd7 Author: never Date: 2010-05-10 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e8e83be27dd7 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: df736661d0c8 Author: jrose Date: 2010-05-11 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/df736661d0c8 Merge ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/signature.cpp From Christian.Thalinger at Sun.COM Wed May 12 04:06:49 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 12 May 2010 13:06:49 +0200 Subject: Review Request: Zero deoptimizer changes In-Reply-To: <20100511160902.GC25502@redhat.com> References: <20100511160902.GC25502@redhat.com> Message-ID: <1273662409.12536.20.camel@macbook> On Tue, 2010-05-11 at 17:09 +0100, Gary Benson wrote: > Hi all, > > The way Zero currently handles deoptimization can lead to methods > being freed while they are still being executed, with the obvious > consequences. This webrev fixes: > > http://cr.openjdk.java.net/~gbenson/zero-deopt-fix/ > > I don't have a bug id for this. 6951784: Zero deoptimizer changes Changes look good and it's in the queue. -- Christian From gbenson at redhat.com Wed May 12 04:10:53 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 12 May 2010 12:10:53 +0100 Subject: Review Request: Zero deoptimizer changes In-Reply-To: <1273662409.12536.20.camel@macbook> References: <20100511160902.GC25502@redhat.com> <1273662409.12536.20.camel@macbook> Message-ID: <20100512111053.GE3310@redhat.com> Christian Thalinger wrote: > On Tue, 2010-05-11 at 17:09 +0100, Gary Benson wrote: > > The way Zero currently handles deoptimization can lead to methods > > being freed while they are still being executed, with the obvious > > consequences. This webrev fixes: > > > > http://cr.openjdk.java.net/~gbenson/zero-deopt-fix/ > > > > I don't have a bug id for this. > > 6951784: Zero deoptimizer changes > > Changes look good and it's in the queue. Thank you :) Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Wed May 12 04:25:01 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 12 May 2010 13:25:01 +0200 Subject: Review Request: Zero deoptimizer changes In-Reply-To: <20100512111053.GE3310@redhat.com> References: <20100511160902.GC25502@redhat.com> <1273662409.12536.20.camel@macbook> <20100512111053.GE3310@redhat.com> Message-ID: <1273663501.12536.21.camel@macbook> On Wed, 2010-05-12 at 12:10 +0100, Gary Benson wrote: > Christian Thalinger wrote: > > On Tue, 2010-05-11 at 17:09 +0100, Gary Benson wrote: > > > The way Zero currently handles deoptimization can lead to methods > > > being freed while they are still being executed, with the obvious > > > consequences. This webrev fixes: > > > > > > http://cr.openjdk.java.net/~gbenson/zero-deopt-fix/ > > > > > > I don't have a bug id for this. > > > > 6951784: Zero deoptimizer changes > > > > Changes look good and it's in the queue. > > Thank you :) I should make a template for these conversations ;-) -- Christian From gbenson at redhat.com Wed May 12 05:43:38 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 12 May 2010 13:43:38 +0100 Subject: Review Request: Zero deoptimizer changes In-Reply-To: <1273663501.12536.21.camel@macbook> References: <20100511160902.GC25502@redhat.com> <1273662409.12536.20.camel@macbook> <20100512111053.GE3310@redhat.com> <1273663501.12536.21.camel@macbook> Message-ID: <20100512124338.GG3310@redhat.com> Christian Thalinger wrote: > On Wed, 2010-05-12 at 12:10 +0100, Gary Benson wrote: > > Christian Thalinger wrote: > > > On Tue, 2010-05-11 at 17:09 +0100, Gary Benson wrote: > > > > The way Zero currently handles deoptimization can lead to methods > > > > being freed while they are still being executed, with the obvious > > > > consequences. This webrev fixes: > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-deopt-fix/ > > > > > > > > I don't have a bug id for this. > > > > > > 6951784: Zero deoptimizer changes > > > > > > Changes look good and it's in the queue. > > > > Thank you :) > > I should make a template for these conversations ;-) Yeah, me too! Thanks though... From Christian.Thalinger at Sun.COM Wed May 12 07:44:21 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 12 May 2010 14:44:21 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6951784: Zero deoptimizer changes Message-ID: <20100512144425.3E9E7444CA@hg.openjdk.java.net> Changeset: 22af4ce8dba1 Author: twisti Date: 2010-05-12 03:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/22af4ce8dba1 6951784: Zero deoptimizer changes Summary: The way Zero currently handles deoptimization can lead to methods being freed while they are still being executed. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/entry_zero.hpp From Christian.Thalinger at Sun.COM Wed May 12 09:02:02 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 12 May 2010 18:02:02 +0200 Subject: Request for reviews (L): 6951083: oops and relocations should part of nmethod not CodeBlob Message-ID: <1273680122.12536.50.camel@macbook> http://cr.openjdk.java.net/~twisti/6951083/webrev.01/ 6951083: oops and relocations should part of nmethod not CodeBlob Summary: This moves the oops from Codeblob to nmethod. Reviewed-by: This moves the oops from Codeblob to nmethod and is a preparation for better oop-loading code. agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java agent/src/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java src/cpu/sparc/vm/nativeInst_sparc.cpp src/os/solaris/dtrace/generateJvmOffsets.cpp src/os/solaris/dtrace/libjvm_db.c src/share/vm/asm/codeBuffer.hpp src/share/vm/code/codeBlob.cpp src/share/vm/code/codeBlob.hpp src/share/vm/code/codeCache.cpp src/share/vm/code/compiledIC.cpp src/share/vm/code/nmethod.cpp src/share/vm/code/nmethod.hpp src/share/vm/code/oopRecorder.cpp src/share/vm/code/oopRecorder.hpp src/share/vm/code/relocInfo.cpp src/share/vm/code/relocInfo.hpp src/share/vm/includeDB_core src/share/vm/memory/iterator.cpp src/share/vm/runtime/sharedRuntime.cpp src/share/vm/runtime/vmStructs.cpp From gbenson at redhat.com Wed May 12 09:44:31 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 12 May 2010 17:44:31 +0100 Subject: Review Request: 6888954 broke Zero Message-ID: <20100512164430.GI3310@redhat.com> Hi all, The commit for 6888954 broke Zero. This webrev fixes: http://cr.openjdk.java.net/~gbenson/6888954-broke-zero/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From John.Coomes at oracle.com Wed May 12 10:03:11 2010 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 12 May 2010 10:03:11 -0700 Subject: Review Request: 6888954 broke Zero In-Reply-To: <20100512164430.GI3310@redhat.com> References: <20100512164430.GI3310@redhat.com> Message-ID: <19434.57167.288150.473267@oracle.com> Gary Benson (gbenson at redhat.com) wrote: > Hi all, > > The commit for 6888954 broke Zero. This webrev fixes: > > http://cr.openjdk.java.net/~gbenson/6888954-broke-zero/ > > I don't have a bug id for this. Hi Gary, I pushed 6888954, so I'll take this. The changes look good. -John From Christian.Thalinger at Sun.COM Wed May 12 10:04:37 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 12 May 2010 19:04:37 +0200 Subject: Review Request: 6888954 broke Zero In-Reply-To: <19434.57167.288150.473267@oracle.com> References: <20100512164430.GI3310@redhat.com> <19434.57167.288150.473267@oracle.com> Message-ID: <1273683877.12536.55.camel@macbook> On Wed, 2010-05-12 at 10:03 -0700, John Coomes wrote: > Gary Benson (gbenson at redhat.com) wrote: > > Hi all, > > > > The commit for 6888954 broke Zero. This webrev fixes: > > > > http://cr.openjdk.java.net/~gbenson/6888954-broke-zero/ > > > > I don't have a bug id for this. > > Hi Gary, > > I pushed 6888954, so I'll take this. The changes look good. Thanks John ;-) -- Christian From vladimir.kozlov at oracle.com Wed May 12 10:15:57 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 May 2010 10:15:57 -0700 Subject: Request for reviews (L): 6951083: oops and relocations should part of nmethod not CodeBlob In-Reply-To: <1273680122.12536.50.camel@macbook> References: <1273680122.12536.50.camel@macbook> Message-ID: <4BEAE24D.50405@oracle.com> src/share/vm/code/oopRecorder.hpp // => code->copy_oops(_handles) ^ nm-> src/share/vm/code/nmethod.hpp Add embedded oop table information into nmethod's comment: 104 // A nmethod contains: 105 // - header (the nmethod structure) src/share/vm/includeDB_core Why it is codeBlob.hpp and not nmethod.cpp?: + codeBlob.hpp jniHandles.hpp Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6951083/webrev.01/ > > 6951083: oops and relocations should part of nmethod not CodeBlob > Summary: This moves the oops from Codeblob to nmethod. > Reviewed-by: > > This moves the oops from Codeblob to nmethod and is a preparation for > better oop-loading code. > > agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java > agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java > agent/src/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java > src/cpu/sparc/vm/nativeInst_sparc.cpp > src/os/solaris/dtrace/generateJvmOffsets.cpp > src/os/solaris/dtrace/libjvm_db.c > src/share/vm/asm/codeBuffer.hpp > src/share/vm/code/codeBlob.cpp > src/share/vm/code/codeBlob.hpp > src/share/vm/code/codeCache.cpp > src/share/vm/code/compiledIC.cpp > src/share/vm/code/nmethod.cpp > src/share/vm/code/nmethod.hpp > src/share/vm/code/oopRecorder.cpp > src/share/vm/code/oopRecorder.hpp > src/share/vm/code/relocInfo.cpp > src/share/vm/code/relocInfo.hpp > src/share/vm/includeDB_core > src/share/vm/memory/iterator.cpp > src/share/vm/runtime/sharedRuntime.cpp > src/share/vm/runtime/vmStructs.cpp > From John.Coomes at oracle.com Wed May 12 11:16:27 2010 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 12 May 2010 11:16:27 -0700 Subject: Review Request: 6888954 broke Zero In-Reply-To: <19434.57167.288150.473267@oracle.com> References: <20100512164430.GI3310@redhat.com> <19434.57167.288150.473267@oracle.com> Message-ID: <19434.61563.706644.281052@oracle.com> I (John.Coomes at oracle.com) wrote: > Gary Benson (gbenson at redhat.com) wrote: > > Hi all, > > > > The commit for 6888954 broke Zero. This webrev fixes: > > > > http://cr.openjdk.java.net/~gbenson/6888954-broke-zero/ > > > > I don't have a bug id for this. > > Hi Gary, > > I pushed 6888954, so I'll take this. The changes look good. The bug id is 6951923: some uses of fatal1 were missed by 6888954. It's in the jprt queue headed for the hotspot-gc repo, which should get pushed up to the main hotspot repo (http://hg.openjdk.java.net/jdk7/hotspot/hotspot) later today. -John From dmytro_sheyko at hotmail.com Thu May 13 00:31:36 2010 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 13 May 2010 14:31:36 +0700 Subject: native x86 code for "3-way if" (one or two comparisons?) Message-ID: Hi, What native x86 code is to be generated for following java code? if (midVal < key) { // ... } else if (midVal > key) { // ... } else { // midVal == key // ... } Especially I am interested how many times "midVal" and "key" are compared. It seems to me that one time is enough. And code is to be generated like this: cmp midVal, key jb @less ja @greater @equal: ... jmp @end @less: ... jmp @end @greater: ... @end: However, below code works a little bit faster than above assuming that always (midVal >= key). if (false) { // ... } else if (midVal > key) { // ... } else { // midVal == key // ... } This leads me to conclusion that java code transformed to native literally and "midVal" and "key" are compared twice. cmp midVal, key jb @less cmp midVal, key ja @greater @equal: ... jmp @end @less: ... jmp @end @greater: ... @end: Well, do we compare values twice in such cases? If so, is this necessary to do the second one? Thank you, Dmytro Sheyko _________________________________________________________________ Hotmail: Trusted email with Microsoft?s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100513/631c0cbb/attachment.html From gbenson at redhat.com Thu May 13 02:49:32 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 13 May 2010 10:49:32 +0100 Subject: Review Request: 6888954 broke Zero In-Reply-To: <19434.61563.706644.281052@oracle.com> References: <20100512164430.GI3310@redhat.com> <19434.57167.288150.473267@oracle.com> <19434.61563.706644.281052@oracle.com> Message-ID: <20100513094931.GA11135@redhat.com> John Coomes wrote: > I (John.Coomes at oracle.com) wrote: > > Gary Benson (gbenson at redhat.com) wrote: > > > The commit for 6888954 broke Zero. This webrev fixes: > > > > > > http://cr.openjdk.java.net/~gbenson/6888954-broke-zero/ > > > > > > I don't have a bug id for this. > > > > I pushed 6888954, so I'll take this. The changes look good. > > The bug id is 6951923: some uses of fatal1 were missed by 6888954. > It's in the jprt queue headed for the hotspot-gc repo, which should > get pushed up to the main hotspot repo > (http://hg.openjdk.java.net/jdk7/hotspot/hotspot) later today. Awesome, thanks John. Cheers, Gary -- http://gbenson.net/ From john.r.rose at oracle.com Thu May 13 05:11:18 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 13 May 2010 12:11:18 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7 new changesets Message-ID: <20100513121141.16136446B8@hg.openjdk.java.net> Changeset: 96d554193f72 Author: coleenp Date: 2010-04-19 18:58 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/96d554193f72 6944822: Fix for 6938627 exposes problem with hard-coded buffer sizes Summary: Make tmpdir buffer sizes MAX_PATH+1 Reviewed-by: dholmes, coleenp Contributed-by: andreas.kohn at fredhopper.com ! src/os/linux/vm/attachListener_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: 77261afdc5f2 Author: coleenp Date: 2010-05-04 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/77261afdc5f2 6935118: UseCompressedOops modification in methodOopDesc::sort_methods() causes JCK timeout Summary: Add comparison functions for compressed oops to use bubblesort. Reviewed-by: never, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/oops/methodOop.cpp + test/runtime/6925573/SortMethodsTest.java Changeset: f43b5e9f7881 Author: kamg Date: 2010-05-05 09:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f43b5e9f7881 6949118: jvm.dll shows the company name as Sun Microsystems Summary: Changed to "Oracle Corporation" Reviewed-by: coleenp, dcubed ! make/hotspot_distro Changeset: 3fca8e9cd36a Author: dcubed Date: 2010-05-05 16:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3fca8e9cd36a Merge ! src/os/linux/vm/os_linux.cpp Changeset: 4ad4e0ee3779 Author: dcubed Date: 2010-05-10 13:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4ad4e0ee3779 Merge Changeset: 2ad074ba8456 Author: dcubed Date: 2010-05-11 17:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2ad074ba8456 Merge Changeset: ef1a1d051971 Author: jrose Date: 2010-05-12 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ef1a1d051971 Merge ! src/share/vm/oops/methodOop.cpp From john.coomes at oracle.com Thu May 13 20:32:06 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 03:32:06 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b92 for changeset 5f5c33d417f3 Message-ID: <20100514033206.5D5FD447BD@hg.openjdk.java.net> Changeset: b7b4797303cb Author: mikejwre Date: 2010-05-06 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/b7b4797303cb Added tag jdk7-b92 for changeset 5f5c33d417f3 ! .hgtags From john.coomes at oracle.com Thu May 13 20:32:09 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 03:32:09 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b92 for changeset 930582f667a1 Message-ID: <20100514033211.A9958447BE@hg.openjdk.java.net> Changeset: ae18df0d4767 Author: mikejwre Date: 2010-05-06 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/ae18df0d4767 Added tag jdk7-b92 for changeset 930582f667a1 ! .hgtags From john.coomes at oracle.com Thu May 13 20:35:03 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 03:35:03 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b92 for changeset e6a40e4bb104 Message-ID: <20100514033504.1C63E447BF@hg.openjdk.java.net> Changeset: c725ca829c5a Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/c725ca829c5a Added tag jdk7-b92 for changeset e6a40e4bb104 ! .hgtags From john.coomes at oracle.com Thu May 13 20:35:07 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 03:35:07 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b92 for changeset df7c033f6a11 Message-ID: <20100514033507.6DA59447C0@hg.openjdk.java.net> Changeset: 797bef191975 Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/797bef191975 Added tag jdk7-b92 for changeset df7c033f6a11 ! .hgtags From john.coomes at oracle.com Thu May 13 20:35:13 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 03:35:13 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 2 new changesets Message-ID: <20100514033549.03C8E447C1@hg.openjdk.java.net> Changeset: fa09af0e5b7c Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fa09af0e5b7c Added tag jdk7-b92 for changeset f2dce7210cc0 ! .hgtags Changeset: 3cf85945abef Author: jrose Date: 2010-05-13 20:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3cf85945abef Merge From john.coomes at oracle.com Thu May 13 20:37:56 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 03:37:56 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 2 new changesets Message-ID: <20100514033802.3C6EA447C2@hg.openjdk.java.net> Changeset: 683cd1f6bc4b Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/683cd1f6bc4b Added tag jdk7-b92 for changeset 98cba5876cb5 ! .hgtags Changeset: 2a28dcbef3a7 Author: jrose Date: 2010-05-13 20:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2a28dcbef3a7 Merge From john.coomes at oracle.com Fri May 14 11:44:33 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 18:44:33 +0000 Subject: hg: jdk7/hotspot-comp: 3 new changesets Message-ID: <20100514184433.2AD28448FC@hg.openjdk.java.net> Changeset: aa4f995fb65e Author: prr Date: 2010-05-11 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/aa4f995fb65e 6931180: Migration to recent versions of MS Platform SDK Summary: Changes to enable building JDK7 with Microsoft Visual Studio 2010 Reviewed-by: ohair, art, ccheung, dcubed ! README-builds.html Changeset: 5fc102ff48f0 Author: mikejwre Date: 2010-05-12 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/5fc102ff48f0 Merge Changeset: ec423e5e725d Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/ec423e5e725d Added tag jdk7-b93 for changeset 5fc102ff48f0 ! .hgtags From john.coomes at oracle.com Fri May 14 11:44:36 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 18:44:36 +0000 Subject: hg: jdk7/hotspot-comp/corba: 3 new changesets Message-ID: <20100514184441.0ACC6448FD@hg.openjdk.java.net> Changeset: ee2d8f1bef5b Author: prr Date: 2010-05-11 14:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/ee2d8f1bef5b 6931180: Migration to recent versions of MS Platform SDK Summary: Changes to enable building JDK7 with Microsoft Visual Studio 2010 Reviewed-by: ohair, art, ccheung, dcubed ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk Changeset: 9718d624864c Author: mikejwre Date: 2010-05-12 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/9718d624864c Merge Changeset: f2ff4938cecd Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/f2ff4938cecd Added tag jdk7-b93 for changeset 9718d624864c ! .hgtags From john.coomes at oracle.com Fri May 14 11:49:07 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 18:49:07 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b93 for changeset c725ca829c5a Message-ID: <20100514184907.E9F94448FE@hg.openjdk.java.net> Changeset: 2de307cd3b4e Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/2de307cd3b4e Added tag jdk7-b93 for changeset c725ca829c5a ! .hgtags From john.coomes at oracle.com Fri May 14 11:49:11 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 18:49:11 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b93 for changeset 797bef191975 Message-ID: <20100514184911.20798448FF@hg.openjdk.java.net> Changeset: 8515e093efd1 Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/8515e093efd1 Added tag jdk7-b93 for changeset 797bef191975 ! .hgtags From Christian.Thalinger at Sun.COM Mon May 17 06:05:04 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 17 May 2010 15:05:04 +0200 Subject: Request for reviews .02 (L): 6951083: oops and relocations should part of nmethod not CodeBlob In-Reply-To: <4BEAE24D.50405@oracle.com> References: <1273680122.12536.50.camel@macbook> <4BEAE24D.50405@oracle.com> Message-ID: <1274101504.1201.11.camel@macbook> On Wed, 2010-05-12 at 10:15 -0700, Vladimir Kozlov wrote: > src/share/vm/code/oopRecorder.hpp > > // => code->copy_oops(_handles) > ^ nm-> Done. > > src/share/vm/code/nmethod.hpp > Add embedded oop table information into nmethod's comment: > > 104 // A nmethod contains: > 105 // - header (the nmethod structure) Done. > src/share/vm/includeDB_core > Why it is codeBlob.hpp and not nmethod.cpp?: > > + codeBlob.hpp jniHandles.hpp Oops. This looks like a leftover. Removed. http://cr.openjdk.java.net/~twisti/6951083/webrev.02/ -- Christian From Christian.Thalinger at Sun.COM Mon May 17 06:59:25 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 17 May 2010 15:59:25 +0200 Subject: Request for reviews (XS): 6951686: Using large pages on Linux prevents zero based compressed oops In-Reply-To: <4BE9F871.1040009@oracle.com> References: <4BE9F871.1040009@oracle.com> Message-ID: <1274104765.1201.13.camel@macbook> On Tue, 2010-05-11 at 17:38 -0700, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6951686/webrev > > Fixed 6951686: Using large pages on Linux prevents zero based compressed oops > > The method os::reserve_memory_special() is used with -XX:+UseLargePages on Linux. > It uses shared memory API to reserve memory but it does not use req_addr. > > Use req_addr when attaching shared memory segment. I looked at the changes and it seems they are good. I guess Solaris is behaving completely different and that's why this is only required on Linux. -- Christian From vladimir.kozlov at Oracle.com Mon May 17 09:35:15 2010 From: vladimir.kozlov at Oracle.com (Vladimir Kozlov) Date: Mon, 17 May 2010 09:35:15 -0700 Subject: Request for reviews .02 (L): 6951083: oops and relocations should part of nmethod not CodeBlob In-Reply-To: <1274101504.1201.11.camel@macbook> References: <1273680122.12536.50.camel@macbook> <4BEAE24D.50405@oracle.com> <1274101504.1201.11.camel@macbook> Message-ID: <4BF17043.3030109@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > On Wed, 2010-05-12 at 10:15 -0700, Vladimir Kozlov wrote: >> src/share/vm/code/oopRecorder.hpp >> >> // => code->copy_oops(_handles) >> ^ nm-> > > Done. > >> src/share/vm/code/nmethod.hpp >> Add embedded oop table information into nmethod's comment: >> >> 104 // A nmethod contains: >> 105 // - header (the nmethod structure) > > Done. > >> src/share/vm/includeDB_core >> Why it is codeBlob.hpp and not nmethod.cpp?: >> >> + codeBlob.hpp jniHandles.hpp > > Oops. This looks like a leftover. Removed. > > http://cr.openjdk.java.net/~twisti/6951083/webrev.02/ > > -- Christian > From vladimir.kozlov at oracle.com Mon May 17 09:54:59 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 May 2010 09:54:59 -0700 Subject: Request for reviews (XS): 6951686: Using large pages on Linux prevents zero based compressed oops In-Reply-To: <1274104765.1201.13.camel@macbook> References: <4BE9F871.1040009@oracle.com> <1274104765.1201.13.camel@macbook> Message-ID: <4BF174E3.4060703@oracle.com> Thank you, Christian It does not work with Solaris. I tried to pass the address to shmat() instead of 0: retAddr = (char *) shmat(shmid, 0, SHM_SHARE_MMU | SHM_R | SHM_W); but the method returns NULL. It seems, specifying the address interfere with flags. So I decided to not do it. Also this path is not used by default, only when -XX:+UseISM is specified which is not used since Solaris 9. Thanks, Vladimir Christian Thalinger wrote: > On Tue, 2010-05-11 at 17:38 -0700, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6951686/webrev >> >> Fixed 6951686: Using large pages on Linux prevents zero based compressed oops >> >> The method os::reserve_memory_special() is used with -XX:+UseLargePages on Linux. >> It uses shared memory API to reserve memory but it does not use req_addr. >> >> Use req_addr when attaching shared memory segment. > > I looked at the changes and it seems they are good. I guess Solaris is > behaving completely different and that's why this is only required on > Linux. > > -- Christian > From Christian.Thalinger at Sun.COM Mon May 17 10:29:42 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 17 May 2010 19:29:42 +0200 Subject: Request for reviews (XS): 6951686: Using large pages on Linux prevents zero based compressed oops In-Reply-To: <4BF174E3.4060703@oracle.com> References: <4BE9F871.1040009@oracle.com> <1274104765.1201.13.camel@macbook> <4BF174E3.4060703@oracle.com> Message-ID: <1274117382.1201.34.camel@macbook> On Mon, 2010-05-17 at 09:54 -0700, Vladimir Kozlov wrote: > Thank you, Christian > > It does not work with Solaris. I tried to pass the address to shmat() instead of 0: > > retAddr = (char *) shmat(shmid, 0, SHM_SHARE_MMU | SHM_R | SHM_W); > > but the method returns NULL. It seems, specifying the address interfere with flags. > So I decided to not do it. Also this path is not used by default, only when -XX:+UseISM > is specified which is not used since Solaris 9. Thanks for the clarification. -- Christian From tom.rodriguez at oracle.com Mon May 17 11:26:42 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 17 May 2010 11:26:42 -0700 Subject: Request for reviews .02 (L): 6951083: oops and relocations should part of nmethod not CodeBlob In-Reply-To: <1274101504.1201.11.camel@macbook> References: <1273680122.12536.50.camel@macbook> <4BEAE24D.50405@oracle.com> <1274101504.1201.11.camel@macbook> Message-ID: Can you go ahead and move do_unloading out of CodeBlob completely since it's really nmethod specific. You should switch CodeCache::do_unloading to use FOR_ALL_ALIVE_NMETHODS too. in libjvm_db.c, oops_end - oops_beg isn't the same as oops_len since oops_end/oops_beg aren't pointers, they are integer offsets, so you'd need to divide by the sizeof oop. in nmethod.cpp, I think they nmethod constructor for the dtrace helpers also needs to this logic: + _scopes_data_offset = _oops_offset + round_to(code_buffer->total_oop_size (), oopSize); since there is a copy_oops_to call in that constructor. Otherwise I think this looks good. tom On May 17, 2010, at 6:05 AM, Christian Thalinger wrote: > On Wed, 2010-05-12 at 10:15 -0700, Vladimir Kozlov wrote: >> src/share/vm/code/oopRecorder.hpp >> >> // => code->copy_oops(_handles) >> ^ nm-> > > Done. > >> >> src/share/vm/code/nmethod.hpp >> Add embedded oop table information into nmethod's comment: >> >> 104 // A nmethod contains: >> 105 // - header (the nmethod structure) > > Done. > >> src/share/vm/includeDB_core >> Why it is codeBlob.hpp and not nmethod.cpp?: >> >> + codeBlob.hpp jniHandles.hpp > > Oops. This looks like a leftover. Removed. > > http://cr.openjdk.java.net/~twisti/6951083/webrev.02/ > > -- Christian > From vladimir.kozlov at oracle.com Mon May 17 13:43:16 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 17 May 2010 20:43:16 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6951686: Using large pages on Linux prevents zero based compressed oops Message-ID: <20100517204318.AE08B44EC2@hg.openjdk.java.net> Changeset: 79bf863697eb Author: kvn Date: 2010-05-17 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/79bf863697eb 6951686: Using large pages on Linux prevents zero based compressed oops Summary: Use req_addr when attaching shared memory segment. Reviewed-by: twisti ! src/os/linux/vm/os_linux.cpp From vladimir.kozlov at oracle.com Mon May 17 17:10:55 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 May 2010 17:10:55 -0700 Subject: Request for reviews (S): 6953267: assert in EA code with -XX:+StressReflectiveCode Message-ID: <4BF1DB0F.8040001@oracle.com> http://cr.openjdk.java.net/~kvn/6953267/webrev Fixed 6953267: assert in EA code with -XX:+StressReflectiveCode EA code does not handle code generated with StressReflectiveCode when an array klass is used for Allocate node or instance klass for AllocateArray node on never executed path (see method LibraryCallKit::inline_native_clone()). Add missing checks into EA code. From tom.rodriguez at oracle.com Mon May 17 19:04:26 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 17 May 2010 19:04:26 -0700 Subject: Request for reviews (S): 6953267: assert in EA code with -XX:+StressReflectiveCode In-Reply-To: <4BF1DB0F.8040001@oracle.com> References: <4BF1DB0F.8040001@oracle.com> Message-ID: escape.cpp: Why isn't this snippet: + const TypeKlassPtr *kt; + if (k->Opcode() == Op_LoadKlass) { + kt = k->as_Load()->type()->isa_klassptr(); + } else { + // Also works for DecodeN(LoadNKlass). + kt = k->as_Type()->type()->isa_klassptr(); + } just this? const TypeKlassPtr* kt = k->bottom_type()->isa_klassptr(); they are and should be equivalent. Otherwise it's ok. tom On May 17, 2010, at 5:10 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6953267/webrev > > Fixed 6953267: assert in EA code with -XX:+StressReflectiveCode > > EA code does not handle code generated with StressReflectiveCode > when an array klass is used for Allocate node or instance klass > for AllocateArray node on never executed path (see method > LibraryCallKit::inline_native_clone()). > > Add missing checks into EA code. From vladimir.kozlov at oracle.com Mon May 17 21:16:44 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 May 2010 21:16:44 -0700 Subject: Request for reviews (S): 6953267: assert in EA code with -XX:+StressReflectiveCode In-Reply-To: References: <4BF1DB0F.8040001@oracle.com> Message-ID: <4BF214AC.1070301@oracle.com> You are absolutely right. The only difference: bottom_type() is virtual method and type() is simple inline method. But this advantage of type() disappeared when I added Opcode() (virtual method) check. I will change the code to use bottom_type(). Thanks, Vladimir On 5/17/10 7:04 PM, Tom Rodriguez wrote: > escape.cpp: > > Why isn't this snippet: > > + const TypeKlassPtr *kt; > + if (k->Opcode() == Op_LoadKlass) { > + kt = k->as_Load()->type()->isa_klassptr(); > + } else { > + // Also works for DecodeN(LoadNKlass). > + kt = k->as_Type()->type()->isa_klassptr(); > + } > > > just this? > > const TypeKlassPtr* kt = k->bottom_type()->isa_klassptr(); > > they are and should be equivalent. Otherwise it's ok. > > tom > > On May 17, 2010, at 5:10 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6953267/webrev >> >> Fixed 6953267: assert in EA code with -XX:+StressReflectiveCode >> >> EA code does not handle code generated with StressReflectiveCode >> when an array klass is used for Allocate node or instance klass >> for AllocateArray node on never executed path (see method >> LibraryCallKit::inline_native_clone()). >> >> Add missing checks into EA code. > From tom.rodriguez at oracle.com Mon May 17 23:33:51 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 18 May 2010 06:33:51 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6950075: nmethod sweeper should operate concurrently Message-ID: <20100518063359.0AD7C44F6C@hg.openjdk.java.net> Changeset: bfe29ec02863 Author: never Date: 2010-05-17 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bfe29ec02863 6950075: nmethod sweeper should operate concurrently Reviewed-by: never, kvn Contributed-by: eric.caspole at amd.com ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp From Christian.Thalinger at Sun.COM Tue May 18 03:25:10 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 18 May 2010 12:25:10 +0200 Subject: Request for reviews .02 (L): 6951083: oops and relocations should part of nmethod not CodeBlob In-Reply-To: References: <1273680122.12536.50.camel@macbook> <4BEAE24D.50405@oracle.com> <1274101504.1201.11.camel@macbook> Message-ID: <1274178310.1373.28.camel@macbook> On Mon, 2010-05-17 at 11:26 -0700, Tom Rodriguez wrote: > Can you go ahead and move do_unloading out of CodeBlob completely > since it's really nmethod specific. You should switch > CodeCache::do_unloading to use FOR_ALL_ALIVE_NMETHODS too. Sure. I also removed the oops_do method from the CodeBlob subclasses. > > in libjvm_db.c, oops_end - oops_beg isn't the same as oops_len since > oops_end/oops_beg aren't pointers, they are integer offsets, so you'd > need to divide by the sizeof oop. Right. I missed that. Thanks. > > in nmethod.cpp, I think they nmethod constructor for the dtrace > helpers also needs to this logic: > > + _scopes_data_offset = _oops_offset + round_to(code_buffer->total_oop_size (), oopSize); > > since there is a copy_oops_to call in that constructor. That's odd. I added that but it's not in the webrev. Anyway, it should there now. http://cr.openjdk.java.net/~twisti/6951083/webrev.03/ -- Christian From tom.rodriguez at oracle.com Tue May 18 08:25:31 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 May 2010 08:25:31 -0700 Subject: Request for reviews .02 (L): 6951083: oops and relocations should part of nmethod not CodeBlob In-Reply-To: <1274178310.1373.28.camel@macbook> References: <1273680122.12536.50.camel@macbook> <4BEAE24D.50405@oracle.com> <1274101504.1201.11.camel@macbook> <1274178310.1373.28.camel@macbook> Message-ID: Looks good. tom On May 18, 2010, at 3:25 AM, Christian Thalinger wrote: > On Mon, 2010-05-17 at 11:26 -0700, Tom Rodriguez wrote: >> Can you go ahead and move do_unloading out of CodeBlob completely >> since it's really nmethod specific. You should switch >> CodeCache::do_unloading to use FOR_ALL_ALIVE_NMETHODS too. > > Sure. I also removed the oops_do method from the CodeBlob subclasses. > >> >> in libjvm_db.c, oops_end - oops_beg isn't the same as oops_len since >> oops_end/oops_beg aren't pointers, they are integer offsets, so you'd >> need to divide by the sizeof oop. > > Right. I missed that. Thanks. > >> >> in nmethod.cpp, I think they nmethod constructor for the dtrace >> helpers also needs to this logic: >> >> + _scopes_data_offset = _oops_offset + round_to(code_buffer->total_oop_size (), oopSize); >> >> since there is a copy_oops_to call in that constructor. > > That's odd. I added that but it's not in the webrev. Anyway, it should > there now. > > http://cr.openjdk.java.net/~twisti/6951083/webrev.03/ > > -- Christian > From tom.rodriguez at oracle.com Tue May 18 11:14:38 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 May 2010 11:14:38 -0700 Subject: review (XS) for 6953539: after 6892658 c1 no longer inlines StringBuffer.append Message-ID: <221BC237-F800-43D3-AAE7-5E8522D9C090@oracle.com> http://cr.openjdk.java.net/~never/6953539 6953539: after 6892658 c1 no longer inlines StringBuffer.append Reviewed-by: 6892658 added intrinsic ids for several StringBuffer/StringBuilder methods which triggered some long dormant logic in try_inline_intrinsic which bails out of inlining if an intrinsic is synchronized. It really shouldn't be a full bailout, it should simply return false to indicate that it didn't do anything. Tested by inspecting PrintInlining output. From Christian.Thalinger at Sun.COM Tue May 18 11:59:04 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 18 May 2010 20:59:04 +0200 Subject: review (XS) for 6953539: after 6892658 c1 no longer inlines StringBuffer.append In-Reply-To: <221BC237-F800-43D3-AAE7-5E8522D9C090@oracle.com> References: <221BC237-F800-43D3-AAE7-5E8522D9C090@oracle.com> Message-ID: <1274209144.1373.48.camel@macbook> On Tue, 2010-05-18 at 11:14 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6953539 > > 6953539: after 6892658 c1 no longer inlines StringBuffer.append > Reviewed-by: > > 6892658 added intrinsic ids for several StringBuffer/StringBuilder > methods which triggered some long dormant logic in > try_inline_intrinsic which bails out of inlining if an intrinsic is > synchronized. It really shouldn't be a full bailout, it should simply > return false to indicate that it didn't do anything. Tested by > inspecting PrintInlining output. INLINE_BAILOUT just sets _inline_bailout_msg and returns false. And it seems _inline_bailout_msg is not read somewhere except printing it. Why does this fix change the behavior? I must be missing something. -- Christian From tom.rodriguez at oracle.com Tue May 18 12:25:32 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 May 2010 12:25:32 -0700 Subject: review (XS) for 6953539: after 6892658 c1 no longer inlines StringBuffer.append In-Reply-To: <1274209144.1373.48.camel@macbook> References: <221BC237-F800-43D3-AAE7-5E8522D9C090@oracle.com> <1274209144.1373.48.camel@macbook> Message-ID: <1E15D5A8-4911-4401-B8DF-CD66622E6E0D@oracle.com> On May 18, 2010, at 11:59 AM, Christian Thalinger wrote: > On Tue, 2010-05-18 at 11:14 -0700, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6953539 >> >> 6953539: after 6892658 c1 no longer inlines StringBuffer.append >> Reviewed-by: >> >> 6892658 added intrinsic ids for several StringBuffer/StringBuilder >> methods which triggered some long dormant logic in >> try_inline_intrinsic which bails out of inlining if an intrinsic is >> synchronized. It really shouldn't be a full bailout, it should simply >> return false to indicate that it didn't do anything. Tested by >> inspecting PrintInlining output. > > INLINE_BAILOUT just sets _inline_bailout_msg and returns false. And it > seems _inline_bailout_msg is not read somewhere except printing it. Why > does this fix change the behavior? I must be missing something. You're right it is actually being inlined but the PrintInlining output implies that it's not. Normally C1 only prints messages when it didn't inline something so I trusted the output. So the bug is simply that the PrintInlining output is misleading. I'll correct the report but I still want to make the change itself. tom > > -- Christian > From Christian.Thalinger at Sun.COM Tue May 18 12:32:40 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 18 May 2010 21:32:40 +0200 Subject: review (XS) for 6953539: after 6892658 c1 no longer inlines StringBuffer.append In-Reply-To: <1E15D5A8-4911-4401-B8DF-CD66622E6E0D@oracle.com> References: <221BC237-F800-43D3-AAE7-5E8522D9C090@oracle.com> <1274209144.1373.48.camel@macbook> <1E15D5A8-4911-4401-B8DF-CD66622E6E0D@oracle.com> Message-ID: <1274211160.1373.49.camel@macbook> On Tue, 2010-05-18 at 12:25 -0700, Tom Rodriguez wrote: > On May 18, 2010, at 11:59 AM, Christian Thalinger wrote: > > > On Tue, 2010-05-18 at 11:14 -0700, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/6953539 > >> > >> 6953539: after 6892658 c1 no longer inlines StringBuffer.append > >> Reviewed-by: > >> > >> 6892658 added intrinsic ids for several StringBuffer/StringBuilder > >> methods which triggered some long dormant logic in > >> try_inline_intrinsic which bails out of inlining if an intrinsic is > >> synchronized. It really shouldn't be a full bailout, it should simply > >> return false to indicate that it didn't do anything. Tested by > >> inspecting PrintInlining output. > > > > INLINE_BAILOUT just sets _inline_bailout_msg and returns false. And it > > seems _inline_bailout_msg is not read somewhere except printing it. Why > > does this fix change the behavior? I must be missing something. > > You're right it is actually being inlined but the PrintInlining output > implies that it's not. Normally C1 only prints messages when it > didn't inline something so I trusted the output. So the bug is simply > that the PrintInlining output is misleading. I'll correct the report > but I still want to make the change itself. That makes sense. Then the changes look good. -- Christian From vladimir.kozlov at oracle.com Tue May 18 11:30:49 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 May 2010 11:30:49 -0700 Subject: review (XS) for 6953539: after 6892658 c1 no longer inlines StringBuffer.append In-Reply-To: <221BC237-F800-43D3-AAE7-5E8522D9C090@oracle.com> References: <221BC237-F800-43D3-AAE7-5E8522D9C090@oracle.com> Message-ID: <4BF2DCD9.3040905@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6953539 > > 6953539: after 6892658 c1 no longer inlines StringBuffer.append > Reviewed-by: > > 6892658 added intrinsic ids for several StringBuffer/StringBuilder > methods which triggered some long dormant logic in > try_inline_intrinsic which bails out of inlining if an intrinsic is > synchronized. It really shouldn't be a full bailout, it should simply > return false to indicate that it didn't do anything. Tested by > inspecting PrintInlining output. From vladimir.kozlov at oracle.com Tue May 18 13:08:31 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 18 May 2010 20:08:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6953267: assert in EA code with -XX:+StressReflectiveCode Message-ID: <20100518200840.4951644078@hg.openjdk.java.net> Changeset: c52275c698d1 Author: kvn Date: 2010-05-18 09:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c52275c698d1 6953267: assert in EA code with -XX:+StressReflectiveCode Summary: Add missing checks into EA code. Reviewed-by: never ! src/share/vm/opto/escape.cpp From tom.rodriguez at oracle.com Tue May 18 14:09:46 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 May 2010 14:09:46 -0700 Subject: review (S) for 6953576: bottom_type for matched AddPNodes doesn't always agree with ideal Message-ID: <75F240A7-B2F2-45E2-B834-DF1922C52BA7@oracle.com> http://cr.openjdk.java.net/~never/6953576/ 6953576: bottom_type for matched AddPNodes doesn't always agree with ideal Reviewed-by: 6715633 added an assert to make sure that the adr_type of nodes doesn't change during matching. If the address pieces are matched separately this assert can fail because the logic in AddPNode::mach_bottom_type isn't the equivalent to AddPNode::bottom_type. The fix is to simply capture the bottom_type when transforming the nodes by making AddP matches inherit from MachTypeNode. This was originally discovered in the ia64 port but I reproduced it by disabling the use of complex addressing modes to force the matching AddPs separately. From vladimir.kozlov at oracle.com Tue May 18 14:59:46 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 May 2010 14:59:46 -0700 Subject: review (S) for 6953576: bottom_type for matched AddPNodes doesn't always agree with ideal In-Reply-To: <75F240A7-B2F2-45E2-B834-DF1922C52BA7@oracle.com> References: <75F240A7-B2F2-45E2-B834-DF1922C52BA7@oracle.com> Message-ID: <4BF30DD2.7010505@oracle.com> Did not I review it already? Anyway it looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6953576/ > > 6953576: bottom_type for matched AddPNodes doesn't always agree with ideal > Reviewed-by: > > 6715633 added an assert to make sure that the adr_type of nodes > doesn't change during matching. If the address pieces are matched > separately this assert can fail because the logic in > AddPNode::mach_bottom_type isn't the equivalent to > AddPNode::bottom_type. The fix is to simply capture the bottom_type > when transforming the nodes by making AddP matches inherit from > MachTypeNode. This was originally discovered in the ia64 port but I > reproduced it by disabling the use of complex addressing modes to > force the matching AddPs separately. From tom.rodriguez at oracle.com Tue May 18 15:14:59 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 May 2010 15:14:59 -0700 Subject: review (S) for 6953576: bottom_type for matched AddPNodes doesn't always agree with ideal In-Reply-To: <4BF30DD2.7010505@oracle.com> References: <75F240A7-B2F2-45E2-B834-DF1922C52BA7@oracle.com> <4BF30DD2.7010505@oracle.com> Message-ID: <8EC23F6F-9F35-407D-9631-D8B640E8958F@oracle.com> We talked about it but I never officially sent it out for review. It's unchanged from what you saw earlier. Thanks! tom On May 18, 2010, at 2:59 PM, Vladimir Kozlov wrote: > Did not I review it already? > Anyway it looks good. > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6953576/ >> 6953576: bottom_type for matched AddPNodes doesn't always agree with ideal >> Reviewed-by: >> 6715633 added an assert to make sure that the adr_type of nodes >> doesn't change during matching. If the address pieces are matched >> separately this assert can fail because the logic in >> AddPNode::mach_bottom_type isn't the equivalent to >> AddPNode::bottom_type. The fix is to simply capture the bottom_type >> when transforming the nodes by making AddP matches inherit from >> MachTypeNode. This was originally discovered in the ia64 port but I >> reproduced it by disabling the use of complex addressing modes to >> force the matching AddPs separately. From tom.rodriguez at oracle.com Tue May 18 23:05:39 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 19 May 2010 06:05:39 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6953539: after 6892658 c1 reports that it doesn't inline StringBuffer.append Message-ID: <20100519060543.2EE12441DC@hg.openjdk.java.net> Changeset: 99791ad65936 Author: never Date: 2010-05-18 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/99791ad65936 6953539: after 6892658 c1 reports that it doesn't inline StringBuffer.append Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp From tom.rodriguez at oracle.com Wed May 19 13:12:44 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 19 May 2010 20:12:44 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6953576: bottom_type for matched AddPNodes doesn't always agree with ideal Message-ID: <20100519201246.D0AD644304@hg.openjdk.java.net> Changeset: b5fdf39b9749 Author: never Date: 2010-05-18 23:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b5fdf39b9749 6953576: bottom_type for matched AddPNodes doesn't always agree with ideal Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/addnode.hpp From vladimir.kozlov at oracle.com Wed May 19 15:15:29 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 19 May 2010 22:15:29 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20100519221534.30C1244338@hg.openjdk.java.net> Changeset: eb79484f795f Author: kvn Date: 2010-04-05 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/eb79484f795f 6937111: Restore optimization for Phi of AddP (6552204) Summary: Restored the original code which was removed by the fix for 6614100. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp Changeset: 1a1603f975b5 Author: kvn Date: 2010-05-19 10:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1a1603f975b5 Merge ! src/share/vm/opto/cfgnode.cpp From john.r.rose at oracle.com Thu May 20 03:36:18 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 20 May 2010 10:36:18 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 16 new changesets Message-ID: <20100520103653.223684438A@hg.openjdk.java.net> Changeset: 3bfae429e2cf Author: ysr Date: 2010-05-03 10:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3bfae429e2cf 6948537: CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT Summary: On sun4v/CMT avoid use of memset() in BOT updates so as to prevent concurrent BOT readers from seeing the phantom zeros arising from memset()'s use of BIS. Reviewed-by: jmasa, johnc, minqi, poonam, tonyp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/runtime/globals.hpp Changeset: 7145628c2fa2 Author: tonyp Date: 2010-05-03 17:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7145628c2fa2 Merge Changeset: bb843ebc7c55 Author: ysr Date: 2010-05-03 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bb843ebc7c55 6919638: CMS: ExplicitGCInvokesConcurrent misinteracts with gc locker Summary: GC-locker induced concurrent full gc should be asynchronous; policy now controlled by a separate flag, which defaults to false. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: a8127dc669ba Author: ysr Date: 2010-05-10 12:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a8127dc669ba 6951188: CMS: move PromotionInfo into its own file Summary: Moved PromotionInfo and friends into new files promotionInfo.{h,c}pp from their previous compactibleFreeListSpace.{h,c}pp home. Reviewed-by: apetrusenko ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp + src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp + src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep Changeset: 67d74f7a15d9 Author: jcoomes Date: 2010-05-12 10:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/67d74f7a15d9 6951923: some uses of fatal1 were missed by 6888954 Reviewed-by: jcoomes Contributed-by: Gary Benson ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp Changeset: 8bfe9058ca46 Author: jcoomes Date: 2010-05-13 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8bfe9058ca46 Merge ! src/share/vm/runtime/globals.hpp Changeset: fb57d4cf76c2 Author: prr Date: 2010-05-11 14:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fb57d4cf76c2 6931180: Migration to recent versions of MS Platform SDK 6951582: Build problems on win64 Summary: Changes to enable building JDK7 with Microsoft Visual Studio 2010 Reviewed-by: ohair, art, ccheung, dcubed ! make/windows/build_vm_def.sh ! make/windows/makefiles/compile.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/sanity.make ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/runtime/sharedRuntimeTrig.cpp Changeset: 9d865fc2f644 Author: mikejwre Date: 2010-05-12 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9d865fc2f644 Merge Changeset: 2fb8834f4446 Author: trims Date: 2010-05-13 14:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2fb8834f4446 Merge Changeset: eefa1a6f1582 Author: trims Date: 2010-05-13 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/eefa1a6f1582 6952178: Fork HS18 to HS19 - renumber Major and build numbers of JVM Summary: Update the Major and build numbers for HS19 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 093432aa7573 Author: trims Date: 2010-05-13 17:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/093432aa7573 Merge Changeset: 9d4dd91c4a0a Author: poonam Date: 2010-05-15 18:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9d4dd91c4a0a 6745217: jmap assertion failure Summary: SA shows exception with core files > 2GB. These changes fix that by correcting the size of CMSBitmap during its allocation. Reviewed-by: swamyv ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSBitMap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java Changeset: 7ccc203eb6ff Author: dcubed Date: 2010-05-17 03:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7ccc203eb6ff Merge Changeset: d3562366cbfd Author: dcubed Date: 2010-05-17 06:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d3562366cbfd 6949515: 3/3 VM crash when calling GetMethodDeclaringClass Summary: Use resolve_external_guard() instead of resolve_non_null(). Reviewed-by: thurka, kamg, acorn ! src/share/vm/runtime/jniHandles.hpp Changeset: 892898e961c5 Author: dcubed Date: 2010-05-17 07:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/892898e961c5 Merge ! src/share/vm/runtime/jniHandles.hpp Changeset: 1a88d3c58e1d Author: jrose Date: 2010-05-20 01:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1a88d3c58e1d Merge ! src/share/vm/runtime/globals.hpp From Christian.Thalinger at Sun.COM Thu May 20 06:33:34 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 20 May 2010 15:33:34 +0200 Subject: Request for reviews .04 (L): 6951083: oops and relocations should part of nmethod not CodeBlob In-Reply-To: References: <1273680122.12536.50.camel@macbook> <4BEAE24D.50405@oracle.com> <1274101504.1201.11.camel@macbook> <1274178310.1373.28.camel@macbook> Message-ID: <1274362415.13130.20.camel@macbook> On Tue, 2010-05-18 at 08:25 -0700, Tom Rodriguez wrote: > > http://cr.openjdk.java.net/~twisti/6951083/webrev.03/ I had a bug in src/cpu/sparc/vm/nativeInst_sparc.cpp. The following version fixes it: http://cr.openjdk.java.net/~twisti/6951083/webrev.04/ I commit this one. -- Christian From Christian.Thalinger at Sun.COM Thu May 20 11:58:41 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 20 May 2010 20:58:41 +0200 Subject: Request for reviews .06 (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1273493559.1439.19.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> <1272900838.4703.17.camel@macbook> <1272912260.4703.22.camel@macbook> <02672F04-CFDC-4212-A0C1-701D56FE88D8@oracle.com> <235CD2B7-40D3-4E95-ACF5-A76D3D89F61F@oracle.com> <1272968504.4703.112.camel@macbook> <1272982823.950.14.camel@macbook> <5740DFD5-4DE3-46DE-A2E7-EF71B81AA56B@oracle.com> <1273002720.950.104.camel@macbook> <1273492308.1439.18.camel@macbook> <1273493559.1439.19.camel@macbook> Message-ID: <1274381921.13130.24.camel@macbook> On Mon, 2010-05-10 at 14:12 +0200, Christian Thalinger wrote: > On Mon, 2010-05-10 at 13:51 +0200, Christian Thalinger wrote: > > On Tue, 2010-05-04 at 21:52 +0200, Christian Thalinger wrote: > > > On Tue, 2010-05-04 at 10:34 -0700, John Rose wrote: > > > > On May 4, 2010, at 7:20 AM, Christian Thalinger wrote: > > > > > > > > > I currently don't see why this should be a problem since O5_savedSP > > > > > should contain the correct sender SP. > > > > > > > > Maybe O5 is getting trashed by a trip through C2I or I2C adapters? > > > > > > Hmm, not sure where that could happen. I'll look again. > > > > > > > Could the throwing MH in question be getting called from compiled code > > > > maybe? > > > > > > How could that happen? I thought every call to a MH needs to go through > > > c2i before. > > > > Can't we simply not cut back to the caller's SP? Since SP should be > > restored correctly from FP during unwind anyways. > > ...actually from L7. -- Christian Finally we found the bug and this should be the final version to be commited: http://cr.openjdk.java.net/~twisti/6930772/webrev.06/ The only change between .05 is: http://cr.openjdk.java.net/~twisti/6930772/webrev.06/src/cpu/sparc/vm/methodHandles_sparc.cpp.udiff.html -- Christian From vladimir.kozlov at oracle.com Thu May 20 18:02:03 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 May 2010 18:02:03 -0700 Subject: Request for reviews (M): 6954029: Improve implicit null check generation with compressed oops Message-ID: <4BF5DB8B.8050909@oracle.com> http://cr.openjdk.java.net/~kvn/6954029/webrev Fixed 6954029: Improve implicit null check generation with compressed oops Problem: When DecodeN instruction does not fold into address expression it may prevent implicit null check generation if it is scheduled below the null check since the corresponding memory instruction could not be moved. Solution: If needed move DecodeN instruction before null check to generate implicit null check. I also removed code which switch off default COOP usage on N1: currently generated COOP code perform better on N1 (tested jbb2005). From Christian.Thalinger at Sun.COM Fri May 21 03:07:34 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 21 May 2010 12:07:34 +0200 Subject: Request for reviews (M): 6954029: Improve implicit null check generation with compressed oops In-Reply-To: <4BF5DB8B.8050909@oracle.com> References: <4BF5DB8B.8050909@oracle.com> Message-ID: <1274436454.21073.10.camel@macbook> On Thu, 2010-05-20 at 18:02 -0700, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6954029/webrev > > Fixed 6954029: Improve implicit null check generation with compressed oops > > Problem: > When DecodeN instruction does not fold into address expression > it may prevent implicit null check generation if it is scheduled > below the null check since the corresponding memory instruction > could not be moved. > > Solution: > If needed move DecodeN instruction before null check to generate > implicit null check. > > I also removed code which switch off default COOP usage on N1: > currently generated COOP code perform better on N1 (tested jbb2005). src/cpu/sparc/vm/sparc.ad: src/cpu/x86/vm/x86_64.ad: + assert(UseCompressedOops, "only for comressed oops code"); ^ typo Otherwise (I think) it's OK. -- Christian From vladimir.kozlov at oracle.com Fri May 21 08:36:22 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 May 2010 08:36:22 -0700 Subject: Request for reviews (M): 6954029: Improve implicit null check generation with compressed oops In-Reply-To: <1274436454.21073.10.camel@macbook> References: <4BF5DB8B.8050909@oracle.com> <1274436454.21073.10.camel@macbook> Message-ID: <4BF6A876.7000204@oracle.com> Thank you, Christian I fixed typo. Vladimir Christian Thalinger wrote: > On Thu, 2010-05-20 at 18:02 -0700, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6954029/webrev >> >> Fixed 6954029: Improve implicit null check generation with compressed oops >> >> Problem: >> When DecodeN instruction does not fold into address expression >> it may prevent implicit null check generation if it is scheduled >> below the null check since the corresponding memory instruction >> could not be moved. >> >> Solution: >> If needed move DecodeN instruction before null check to generate >> implicit null check. >> >> I also removed code which switch off default COOP usage on N1: >> currently generated COOP code perform better on N1 (tested jbb2005). > > src/cpu/sparc/vm/sparc.ad: > src/cpu/x86/vm/x86_64.ad: > > + assert(UseCompressedOops, "only for comressed oops code"); > ^ typo > > Otherwise (I think) it's OK. > > -- Christian > From vladimir.kozlov at oracle.com Fri May 21 10:48:22 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 May 2010 10:48:22 -0700 Subject: Request for reviews (M): 6954029: Improve implicit null check generation with compressed oops In-Reply-To: <4BF6A876.7000204@oracle.com> References: <4BF5DB8B.8050909@oracle.com> <1274436454.21073.10.camel@macbook> <4BF6A876.7000204@oracle.com> Message-ID: <4BF6C766.8060401@oracle.com> I found bug in the code. x64 DecodeN may change flags I have to hoist flag-killing projections: http://cr.openjdk.java.net/~kvn/6954029/webrev.01 Only opto/lcm.cpp was changed vs previous webrev. Thanks, Vladimir Vladimir Kozlov wrote: > Thank you, Christian > > I fixed typo. > > Vladimir > > Christian Thalinger wrote: >> On Thu, 2010-05-20 at 18:02 -0700, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6954029/webrev >>> >>> Fixed 6954029: Improve implicit null check generation with compressed >>> oops >>> >>> Problem: >>> When DecodeN instruction does not fold into address expression >>> it may prevent implicit null check generation if it is scheduled >>> below the null check since the corresponding memory instruction >>> could not be moved. >>> >>> Solution: >>> If needed move DecodeN instruction before null check to generate >>> implicit null check. >>> >>> I also removed code which switch off default COOP usage on N1: >>> currently generated COOP code perform better on N1 (tested jbb2005). >> >> src/cpu/sparc/vm/sparc.ad: >> src/cpu/x86/vm/x86_64.ad: >> >> + assert(UseCompressedOops, "only for comressed oops code"); >> ^ typo >> >> Otherwise (I think) it's OK. >> >> -- Christian >> From vladimir.kozlov at oracle.com Fri May 21 11:14:30 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 May 2010 11:14:30 -0700 Subject: Please ignore. Testing Message-ID: <4BF6CD86.5060006@oracle.com> Vladimir From john.r.rose at oracle.com Sun May 23 01:38:00 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 23 May 2010 01:38:00 -0700 Subject: Request for reviews (L): 6939207: refactor constant pool index processing In-Reply-To: <1272875987.4703.9.camel@macbook> References: <1270631795.2639.207.camel@macbook> <2C343FD4-0DDD-4E23-8D36-BC0822237586@oracle.com> <1272031594.15338.957.camel@macbook> <347FD1C4-6BED-42E6-A3C0-7C9FD1EE8AD5@oracle.com> <1272446638.19839.330.camel@macbook> <2408D46F-E6EE-4685-8E79-B3ACA5A09621@oracle.com> <1272875987.4703.9.camel@macbook> Message-ID: <7A6B1639-9B88-4E7E-B2B6-966C42D53DC7@oracle.com> I made slight updates to the assertion-checking code, and added a missing "__ ldx" to the SPARC code. (It is obvious in retrospect.) This updated webrev is probably final: http://cr.openjdk.java.net/~jrose/6939207/webrev.04/ New diffs: http://cr.openjdk.java.net/~jrose/6939207/webrev.04/diff-03-to-04.patch -- John From john.r.rose at oracle.com Sun May 23 11:06:34 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 23 May 2010 18:06:34 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6939207: refactor constant pool index processing Message-ID: <20100523180642.071464452E@hg.openjdk.java.net> Changeset: ab102d5d923e Author: jrose Date: 2010-05-23 01:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ab102d5d923e 6939207: refactor constant pool index processing Summary: Factored cleanup of instruction decode which prepares for enhanced ldc semantics. Reviewed-by: twisti ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodHandleWalk.cpp From john.r.rose at oracle.com Tue May 25 00:14:09 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 25 May 2010 07:14:09 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7 new changesets Message-ID: <20100525071426.EF5F5445AE@hg.openjdk.java.net> Changeset: cc387008223e Author: apetrusenko Date: 2010-05-14 10:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cc387008223e 6921317: (partial) G1: assert(top() == bottom() || zfs == Allocated,"Region must be empty, or we must be setting it to Summary: Extended the failing assertion with the new message format to get more data. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: a00b51b2dda4 Author: ysr Date: 2010-05-17 00:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a00b51b2dda4 6948539: CMS+UseCompressedOops: placement of cms_free bit interferes with promoted object link Summary: When using compressed oops, use compressed promoted pointers in b63:b31 of the mark word, so as not to interfere with the CMS "freeness bit" at b7. Updated mark-word layout documentation. Reviewed-by: minqi, poonam, jmasa, coleenp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/oops/markOop.hpp Changeset: fb1a39993f69 Author: jcoomes Date: 2010-05-18 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fb1a39993f69 6951319: enable solaris builds using Sun Studio 12 update 1 Reviewed-by: kamg, ysr, dholmes, johnc ! make/solaris/makefiles/amd64.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/i486.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/dtrace.hpp Changeset: 15190cbcabe9 Author: ysr Date: 2010-05-19 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/15190cbcabe9 6953483: Typo related to ReduceInitialCardMarks leaves concurrent collectors vulnerable to heap corruption Summary: Corrected mis-spelling of COMPILER2 in #ifdef, which could cause heap corruption in CMS due to precleaning when +ReduceInitialCardMarks. Thanks to ChenGuang Sun for bringing this typo to our attention. Reviewed-by: tonyp, jmasa, jcoomes, kvn ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 1634cec09505 Author: ysr Date: 2010-05-19 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1634cec09505 6953952: collectedHeap.cpp should use #ifdef _LP64 not LP64 Summary: Changed LP64 to _LP64 in collectedHeap.cpp. Reviewed-by: kvn, jcoomes ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: c9a07413e82b Author: jcoomes Date: 2010-05-20 08:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c9a07413e82b Merge ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 9f669cf29cb0 Author: jrose Date: 2010-05-24 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9f669cf29cb0 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp From Christian.Thalinger at Sun.COM Tue May 25 00:42:20 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 25 May 2010 09:42:20 +0200 Subject: [Fwd: hg: jdk7/hotspot-comp/hotspot: 6930772: JSR 292 needs to support SPARC C1] Message-ID: <1274773341.2370.4.camel@macbook> [This one bounced. I'm resending it to the list for the record.] -------- Forwarded Message -------- From: Christian.Thalinger at Sun.COM To: jdk7-changes at openjdk.java.net, hotspot-compiler-dev at openjdk.java.net Subject: hg: jdk7/hotspot-comp/hotspot: 6930772: JSR 292 needs to support SPARC C1 Date: Fri, 21 May 2010 18:54:55 +0000 Changeset: 61b2245abf36 Author: twisti Date: 2010-05-21 02:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/61b2245abf36 6930772: JSR 292 needs to support SPARC C1 Summary: C1 for SPARC needs to support JSR 292. Reviewed-by: never, jrose ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/register_definitions_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/runtime/sharedRuntime.cpp From Christian.Thalinger at Sun.COM Tue May 25 00:47:37 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 25 May 2010 09:47:37 +0200 Subject: [Fwd: hg: jdk7/hotspot-comp/hotspot: 6951083: oops and relocations should part of nmethod not CodeBlob] Message-ID: <1274773657.2370.6.camel@macbook> [This one bounced too.] -------- Forwarded Message -------- From: Christian.Thalinger at sun.com To: jdk7-changes at openjdk.java.net, hotspot-compiler-dev at openjdk.java.net Subject: hg: jdk7/hotspot-comp/hotspot: 6951083: oops and relocations should part of nmethod not CodeBlob Date: Thu, 20 May 2010 16:09:11 +0000 Changeset: 1a5913bf5e19 Author: twisti Date: 2010-05-20 06:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1a5913bf5e19 6951083: oops and relocations should part of nmethod not CodeBlob Summary: This moves the oops from Codeblob to nmethod. Reviewed-by: kvn, never ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/libjvm_db.c ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/oopRecorder.cpp ! src/share/vm/code/oopRecorder.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vmStructs.cpp From Christian.Thalinger at Sun.COM Tue May 25 01:36:03 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 25 May 2010 10:36:03 +0200 Subject: Request for reviews (L): 6939207: refactor constant pool index processing In-Reply-To: <7A6B1639-9B88-4E7E-B2B6-966C42D53DC7@oracle.com> References: <1270631795.2639.207.camel@macbook> <2C343FD4-0DDD-4E23-8D36-BC0822237586@oracle.com> <1272031594.15338.957.camel@macbook> <347FD1C4-6BED-42E6-A3C0-7C9FD1EE8AD5@oracle.com> <1272446638.19839.330.camel@macbook> <2408D46F-E6EE-4685-8E79-B3ACA5A09621@oracle.com> <1272875987.4703.9.camel@macbook> <7A6B1639-9B88-4E7E-B2B6-966C42D53DC7@oracle.com> Message-ID: <1274776563.2370.9.camel@macbook> On Sun, 2010-05-23 at 01:38 -0700, John Rose wrote: > I made slight updates to the assertion-checking code, and added a missing "__ ldx" to the SPARC code. (It is obvious in retrospect.) > > This updated webrev is probably final: > http://cr.openjdk.java.net/~jrose/6939207/webrev.04/ > > New diffs: > http://cr.openjdk.java.net/~jrose/6939207/webrev.04/diff-03-to-04.patch Looks good. -- Christian From Christian.Thalinger at Sun.COM Tue May 25 10:20:48 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 25 May 2010 17:20:48 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6934104: JSR 292 needs to support SPARC C2 Message-ID: <20100525172059.68C8646E04@hg.openjdk.java.net> Changeset: 110501f54a99 Author: twisti Date: 2010-05-25 02:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/110501f54a99 6934104: JSR 292 needs to support SPARC C2 Summary: C2 for SPARC needs to support JSR 292. Reviewed-by: kvn, never ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad From igor.veresov at oracle.com Tue May 25 14:42:38 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 25 May 2010 14:42:38 -0700 Subject: Request for review(S) 6955349: C1: Make G1 barriers work with x64 Message-ID: <4BFC444E.9060809@oracle.com> This fixes G1 barriers in c1 on x64. I've also changed the type of disp (was int now intx) in LIR_Address constructor in order to make recent invokedynamic changes compile on 64 bit and to make it consistent with c2. Webrev: http://cr.openjdk.java.net/~iveresov/6955349/webrev.00/ Thanks! igor From tom.rodriguez at oracle.com Tue May 25 15:16:37 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 25 May 2010 15:16:37 -0700 Subject: Request for review(S) 6955349: C1: Make G1 barriers work with x64 In-Reply-To: <4BFC444E.9060809@oracle.com> References: <4BFC444E.9060809@oracle.com> Message-ID: <9E6B149F-2477-4782-BDD2-2C53020DCB21@oracle.com> On May 25, 2010, at 2:42 PM, Igor Veresov wrote: > This fixes G1 barriers in c1 on x64. > > I've also changed the type of disp (was int now intx) in LIR_Address constructor in order to make recent invokedynamic changes compile on 64 bit and to make it consistent with c2. The cast of 0 to intx is pretty gross. Could we just add a constructor that looks like: LIR_Address(LIR_Opr base, BasicType type); instead? Otherwise it looks ok. tom > > Webrev: http://cr.openjdk.java.net/~iveresov/6955349/webrev.00/ > > Thanks! > igor From tom.rodriguez at oracle.com Tue May 25 18:58:24 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 26 May 2010 01:58:24 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20100526015828.D77D646E1A@hg.openjdk.java.net> Changeset: 1747f04ad0c4 Author: never Date: 2010-05-24 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1747f04ad0c4 6490487: java support on 64 bit solaris x86 machines is broken. Reviewed-by: kvn, kamg ! make/solaris/makefiles/defs.make Changeset: f9a202dd8899 Author: never Date: 2010-05-25 13:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f9a202dd8899 Merge From igor.veresov at oracle.com Tue May 25 19:22:31 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 25 May 2010 19:22:31 -0700 Subject: Request for review(S) 6955349: C1: Make G1 barriers work with x64 In-Reply-To: <9E6B149F-2477-4782-BDD2-2C53020DCB21@oracle.com> References: <4BFC444E.9060809@oracle.com> <9E6B149F-2477-4782-BDD2-2C53020DCB21@oracle.com> Message-ID: <4BFC85E7.8050807@oracle.com> On 5/25/10 3:16 PM, Tom Rodriguez wrote: > > On May 25, 2010, at 2:42 PM, Igor Veresov wrote: > >> This fixes G1 barriers in c1 on x64. >> >> I've also changed the type of disp (was int now intx) in LIR_Address constructor in order to make recent invokedynamic changes compile on 64 bit and to make it consistent with c2. > > The cast of 0 to intx is pretty gross. Could we just add a constructor that looks like: > > LIR_Address(LIR_Opr base, BasicType type); > > instead? Sure. > Otherwise it looks ok. > Thanks, Tom! igor > tom > >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6955349/webrev.00/ >> >> Thanks! >> igor > From tom.rodriguez at oracle.com Wed May 26 16:01:57 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 May 2010 16:01:57 -0700 Subject: review (XS) for 6930994: Code cache is full warning should be visible in product Message-ID: <26E75F0A-D00E-45B5-84B9-852F15707DA0@oracle.com> http://cr.openjdk.java.net/~never/6930994/ 6930994: Code cache is full warning should be visible in product Reviewed-by: In debug build we print a warning indicating that the code cache has filled up but this isn't visible in the product. It's an important enough event that it should be visible in the product. src/share/vm/compiler/compileBroker.cpp From vladimir.kozlov at oracle.com Wed May 26 16:20:15 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 May 2010 16:20:15 -0700 Subject: review (XS) for 6930994: Code cache is full warning should be visible in product In-Reply-To: <26E75F0A-D00E-45B5-84B9-852F15707DA0@oracle.com> References: <26E75F0A-D00E-45B5-84B9-852F15707DA0@oracle.com> Message-ID: <4BFDACAF.80909@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6930994/ > > 6930994: Code cache is full warning should be visible in product > Reviewed-by: > > In debug build we print a warning indicating that the code cache has > filled up but this isn't visible in the product. It's an important > enough event that it should be visible in the product. > > src/share/vm/compiler/compileBroker.cpp From Christian.Thalinger at Sun.COM Thu May 27 01:55:24 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 27 May 2010 10:55:24 +0200 Subject: review (XS) for 6930994: Code cache is full warning should be visible in product In-Reply-To: <26E75F0A-D00E-45B5-84B9-852F15707DA0@oracle.com> References: <26E75F0A-D00E-45B5-84B9-852F15707DA0@oracle.com> Message-ID: <1274950525.24305.0.camel@macbook> On Wed, 2010-05-26 at 16:01 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6930994/ > > 6930994: Code cache is full warning should be visible in product > Reviewed-by: > > In debug build we print a warning indicating that the code cache has > filled up but this isn't visible in the product. It's an important > enough event that it should be visible in the product. > > src/share/vm/compiler/compileBroker.cpp Looks good. -- Christian From john.r.rose at oracle.com Thu May 27 14:42:57 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 27 May 2010 21:42:57 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6956164: nightly regressions from 6939207 Message-ID: <20100527214259.8477B46E4C@hg.openjdk.java.net> Changeset: de91a2f25c7e Author: jrose Date: 2010-05-27 09:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/de91a2f25c7e 6956164: nightly regressions from 6939207 Summary: Fix errors in 6939207. Reviewed-by: kvn ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp From vladimir.kozlov at oracle.com Thu May 27 20:34:19 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 28 May 2010 03:34:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6916623: Align object to 16 bytes to use Compressed Oops with java heap up to 64Gb Message-ID: <20100528033421.6636846E4F@hg.openjdk.java.net> Changeset: 2d127394260e Author: kvn Date: 2010-05-27 18:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2d127394260e 6916623: Align object to 16 bytes to use Compressed Oops with java heap up to 64Gb Summary: Added new product ObjectAlignmentInBytes flag to control object alignment. Reviewed-by: twisti, ysr, iveresov ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/cpu/sparc/vm/copy_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/threadLocalAllocBuffer.inline.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp From igor.veresov at oracle.com Thu May 27 23:53:14 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 28 May 2010 06:53:14 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6955349: C1: Make G1 barriers work with x64 Message-ID: <20100528065317.23E3C46E52@hg.openjdk.java.net> Changeset: 87fc6aca31ab Author: iveresov Date: 2010-05-27 22:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87fc6aca31ab 6955349: C1: Make G1 barriers work with x64 Summary: This fixes G1 barriers in c1 on x64. Reviewed-by: never ! 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/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp From john.coomes at oracle.com Fri May 28 02:01:53 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 May 2010 09:01:53 +0000 Subject: hg: jdk7/hotspot-comp: 3 new changesets Message-ID: <20100528090153.58DCE46E62@hg.openjdk.java.net> Changeset: 412712f77af6 Author: ohair Date: 2010-05-25 15:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/412712f77af6 6943119: Rebrand source copyright notices Reviewed-by: darcy ! Makefile ! make/Defs-internal.gmk ! make/corba-rules.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/jdk-rules.gmk ! make/jprt.gmk ! make/jprt.properties ! make/langtools-rules.gmk ! make/sanity-rules.gmk ! make/sponsors-rules.gmk ! make/templates/bsd-header ! make/templates/gpl-cp-header ! test/Makefile Changeset: fd3663286e77 Author: ohair Date: 2010-05-26 10:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/fd3663286e77 Merge Changeset: cf71cb515116 Author: mikejwre Date: 2010-05-27 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/cf71cb515116 Added tag jdk7-b95 for changeset fd3663286e77 ! .hgtags From john.coomes at oracle.com Fri May 28 02:04:51 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 May 2010 09:04:51 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 3 new changesets Message-ID: <20100528090452.0405246E63@hg.openjdk.java.net> Changeset: 72d78db95fb1 Author: ohair Date: 2010-05-25 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/72d78db95fb1 6943119: Rebrand source copyright notices Reviewed-by: darcy ! build-defs.xml ! build-drop-template.xml ! build.properties ! build.xml ! jaxp.properties ! make/Makefile ! make/jprt.properties Changeset: 07050840f98c Author: ohair Date: 2010-05-26 10:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/07050840f98c Merge Changeset: 9510ed0e1c7a Author: mikejwre Date: 2010-05-27 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/9510ed0e1c7a Added tag jdk7-b95 for changeset 07050840f98c ! .hgtags From john.coomes at oracle.com Fri May 28 02:04:55 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 May 2010 09:04:55 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 3 new changesets Message-ID: <20100528090455.DD69946E64@hg.openjdk.java.net> Changeset: 4ac192952d75 Author: ohair Date: 2010-05-25 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/4ac192952d75 6943119: Rebrand source copyright notices Reviewed-by: darcy ! build-defs.xml ! build-drop-template.xml ! build.properties ! build.xml ! jaxws.properties ! make/Makefile ! make/jprt.properties Changeset: ee06cfb113d5 Author: ohair Date: 2010-05-26 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/ee06cfb113d5 Merge Changeset: 208fd4451232 Author: mikejwre Date: 2010-05-27 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/208fd4451232 Added tag jdk7-b95 for changeset ee06cfb113d5 ! .hgtags From Christian.Thalinger at Sun.COM Fri May 28 02:08:34 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 28 May 2010 11:08:34 +0200 Subject: JIT bug? In-Reply-To: <20100520164758.2656E56425@rebar.astron.com> References: <20100520164758.2656E56425@rebar.astron.com> Message-ID: <1275037714.18513.1.camel@macbook> [Moving this to hotspot-compiler-dev.] On Thu, 2010-05-20 at 12:47 -0400, Christos Zoulas wrote: > A friend of mine Andrew Neitsch sent this to me: > > christos > > public class Mainiac { > > public static void main(String[] args) > throws Exception > { > int limit = Integer.MAX_VALUE; > > System.out.println("limit is " + limit); > int i = 0; > while (i++ < limit) { > System.err.format("i = %d < limit: %b\n", i, i < limit); > } > System.err.println("i = " + i); > System.err.println("limit = " + limit); > } > } There is very little information but I guess this is with C2. This is a known bug: 5091921: Sign flip issues in loop optimizer -- Christian From rasbold at google.com Fri May 28 11:16:44 2010 From: rasbold at google.com (Chuck Rasbold) Date: Fri, 28 May 2010 11:16:44 -0700 Subject: JIT bug? In-Reply-To: <1275037714.18513.1.camel@macbook> References: <20100520164758.2656E56425@rebar.astron.com> <1275037714.18513.1.camel@macbook> Message-ID: Is 5091921 still assigned to me? On Fri, May 28, 2010 at 2:08 AM, Christian Thalinger < Christian.Thalinger at sun.com> wrote: > [Moving this to hotspot-compiler-dev.] > > On Thu, 2010-05-20 at 12:47 -0400, Christos Zoulas wrote: > > A friend of mine Andrew Neitsch sent this to me: > > > > christos > > > > public class Mainiac { > > > > public static void main(String[] args) > > throws Exception > > { > > int limit = Integer.MAX_VALUE; > > > > System.out.println("limit is " + limit); > > int i = 0; > > while (i++ < limit) { > > System.err.format("i = %d < limit: %b\n", i, i < limit); > > } > > System.err.println("i = " + i); > > System.err.println("limit = " + limit); > > } > > } > > There is very little information but I guess this is with C2. This is a > known bug: > > 5091921: Sign flip issues in loop optimizer > > -- Christian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100528/60ef16a2/attachment.html From tom.rodriguez at oracle.com Fri May 28 11:18:49 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 28 May 2010 11:18:49 -0700 Subject: JIT bug? In-Reply-To: References: <20100520164758.2656E56425@rebar.astron.com> <1275037714.18513.1.camel@macbook> Message-ID: <7A26B061-84C5-4A23-9BF5-A0F03C4B0A5F@oracle.com> No, Chang Peng had picked it up before he left. tom On May 28, 2010, at 11:16 AM, Chuck Rasbold wrote: > Is 5091921 still assigned to me? > > On Fri, May 28, 2010 at 2:08 AM, Christian Thalinger wrote: > [Moving this to hotspot-compiler-dev.] > > On Thu, 2010-05-20 at 12:47 -0400, Christos Zoulas wrote: > > A friend of mine Andrew Neitsch sent this to me: > > > > christos > > > > public class Mainiac { > > > > public static void main(String[] args) > > throws Exception > > { > > int limit = Integer.MAX_VALUE; > > > > System.out.println("limit is " + limit); > > int i = 0; > > while (i++ < limit) { > > System.err.format("i = %d < limit: %b\n", i, i < limit); > > } > > System.err.println("i = " + i); > > System.err.println("limit = " + limit); > > } > > } > > There is very little information but I guess this is with C2. This is a > known bug: > > 5091921: Sign flip issues in loop optimizer > > -- Christian > > From john.r.rose at oracle.com Fri May 28 23:33:36 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 29 May 2010 06:33:36 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6957004: MethodComparator uses the wrong CP index accessor Message-ID: <20100529063339.1E9F146E97@hg.openjdk.java.net> Changeset: beb77f0d41b3 Author: jrose Date: 2010-05-28 16:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/beb77f0d41b3 6957004: MethodComparator uses the wrong CP index accessor Summary: Change two uses of get_index_u2 to get_index_u2_cpcache; also tweak some debugging print functions Reviewed-by: kvn ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/prims/methodComparator.cpp From john.r.rose at oracle.com Sat May 29 22:36:29 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 30 May 2010 05:36:29 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6957080: MethodComparator needs stress testing Message-ID: <20100530053633.795C446E9F@hg.openjdk.java.net> Changeset: 1eb493f33423 Author: jrose Date: 2010-05-29 19:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1eb493f33423 6957080: MethodComparator needs stress testing Summary: Add a stress-test flag for running MethodComparator over many inputs. Fix bugs that crop up. Reviewed-by: kvn ! src/share/vm/includeDB_core ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/runtime/globals.hpp