From christian.wimmer at oracle.com Wed Jun 1 10:59:08 2011 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Wed, 1 Jun 2011 10:59:08 -0700 Subject: IdealGraphVisualizer In-Reply-To: <39A4CEF1-5AA1-4DBD-9E72-3144C57BF4AA@oracle.com> References: <7930257e-c9a1-4925-a7ca-24e976296fc5@default> <995C4FE8-BB84-4F5F-AD4C-B94AC2253FB3@oracle.com> <39A4CEF1-5AA1-4DBD-9E72-3144C57BF4AA@oracle.com> Message-ID: Unfortunately, every new version of NetBeans requires a bunch of trivial and a few non-trivial changes to get a NetBeans-based application running again. The good news is, a student at the University Linz - Peter Hofer - is actively working on the visualizer, and probably already has a version working with NetBeans 7. I copied him on this mail, hopefully he can help with this. -Christian On Tue, May 31, 2011 at 11:13 AM, Tom Rodriguez wrote: > IGV is based on an older version of netbeans, 6.5.1 I think. > http://netbeans.org/downloads/6.5.1/index.html. It could probably be > forward ported to 7 but that would require more knowledge than I have. > > tom > > On May 31, 2011, at 9:53 AM, Mikael Vidstedt wrote: > > > > > IdealGraphVisualizer gurus, > > > > I?m trying to build the latest greatest version of the project in > Netbeans (7.0) but my success rate is so far limited. The build terminates > with the following error: > > > > com.sun.hotspot.igv.filter.compile: > > Compiling 12 source files to > D:\hg\hotspot\tst\hotspot-comp\src\share\tools\IdealGraphVisualizer\Filter\build\classes > > Note: Attempting to workaround 6512707 > > > D:\hg\hotspot\tst\hotspot-comp\src\share\tools\IdealGraphVisualizer\Filter\src\com\sun\hotspot\igv\filter\CustomFilter.java:81: > cannot access org.netbeans.api.actions.Openable > > class file for org.netbeans.api.actions.Openable not found > > return new OpenCookie() { > > C:\Program Files\NetBeans 7.0\harness\suite.xml:182: The following error > occurred while executing this line: > > C:\Program Files\NetBeans 7.0\harness\common.xml:206: Compile failed; see > the compiler error output for details. > > > > Anybody seen this problem before? > > > > Thanks, > > Mikael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110601/a95af92d/attachment.html From tom.rodriguez at oracle.com Wed Jun 1 11:21:44 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 11:21:44 -0700 Subject: IdealGraphVisualizer In-Reply-To: References: <7930257e-c9a1-4925-a7ca-24e976296fc5@default> <995C4FE8-BB84-4F5F-AD4C-B94AC2253FB3@oracle.com> <39A4CEF1-5AA1-4DBD-9E72-3144C57BF4AA@oracle.com> Message-ID: Is this based on the improved kenai version? The text view in that is nice but there seem to be some interaction bugs that result in exceptions in the event thread that screw up the display. tom On Jun 1, 2011, at 10:59 AM, Christian Wimmer wrote: > Unfortunately, every new version of NetBeans requires a bunch of trivial and a few non-trivial changes to get a NetBeans-based application running again. > > The good news is, a student at the University Linz - Peter Hofer - is actively working on the visualizer, and probably already has a version working with NetBeans 7. I copied him on this mail, hopefully he can help with this. > > -Christian > > > On Tue, May 31, 2011 at 11:13 AM, Tom Rodriguez wrote: > IGV is based on an older version of netbeans, 6.5.1 I think. http://netbeans.org/downloads/6.5.1/index.html. It could probably be forward ported to 7 but that would require more knowledge than I have. > > tom > > On May 31, 2011, at 9:53 AM, Mikael Vidstedt wrote: > > > > > IdealGraphVisualizer gurus, > > > > I?m trying to build the latest greatest version of the project in Netbeans (7.0) but my success rate is so far limited. The build terminates with the following error: > > > > com.sun.hotspot.igv.filter.compile: > > Compiling 12 source files to D:\hg\hotspot\tst\hotspot-comp\src\share\tools\IdealGraphVisualizer\Filter\build\classes > > Note: Attempting to workaround 6512707 > > D:\hg\hotspot\tst\hotspot-comp\src\share\tools\IdealGraphVisualizer\Filter\src\com\sun\hotspot\igv\filter\CustomFilter.java:81: cannot access org.netbeans.api.actions.Openable > > class file for org.netbeans.api.actions.Openable not found > > return new OpenCookie() { > > C:\Program Files\NetBeans 7.0\harness\suite.xml:182: The following error occurred while executing this line: > > C:\Program Files\NetBeans 7.0\harness\common.xml:206: Compile failed; see the compiler error output for details. > > > > Anybody seen this problem before? > > > > Thanks, > > Mikael > > From john.r.rose at oracle.com Wed Jun 1 11:44:29 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jun 2011 11:44:29 -0700 Subject: review request (URGENT): 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Message-ID: <2BD3578B-6859-4300-9FB6-280EEF91B593@oracle.com> Low-level fix to ensure wrapping of early linkage errors in bootstrap method errors, for invokedynamic corner cases. 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError JVM Summary: Delegate invokedynamic linkage errors to MethodHandleNatives.raiseException. JDK Summary: Wrap invokedynamic linkage errors in BootstrapMethodError, as needed. http://cr.openjdk.java.net/~jrose/7049415/webrev.jvm.00 http://cr.openjdk.java.net/~jrose/7049415/webrev.jdk.00 These changes can integrate in any order. To fix the bug, both must be integrated. Test case attached. All paths have been exercised. -- John -------------- next part -------------- A non-text attachment was scrubbed... Name: Test7049415.java Type: application/octet-stream Size: 4469 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110601/da2c9254/attachment.obj From tom.rodriguez at oracle.com Wed Jun 1 11:50:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 11:50:27 -0700 Subject: review request (URGENT): 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError In-Reply-To: <2BD3578B-6859-4300-9FB6-280EEF91B593@oracle.com> References: <2BD3578B-6859-4300-9FB6-280EEF91B593@oracle.com> Message-ID: <301F800D-BF20-4C35-91B9-BCCDE64F6A67@oracle.com> Looks ok. tom On Jun 1, 2011, at 11:44 AM, John Rose wrote: > Low-level fix to ensure wrapping of early linkage errors in bootstrap method errors, for invokedynamic corner cases. > > 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError > JVM Summary: Delegate invokedynamic linkage errors to MethodHandleNatives.raiseException. > JDK Summary: Wrap invokedynamic linkage errors in BootstrapMethodError, as needed. > > http://cr.openjdk.java.net/~jrose/7049415/webrev.jvm.00 > http://cr.openjdk.java.net/~jrose/7049415/webrev.jdk.00 > > These changes can integrate in any order. To fix the bug, both must be integrated. > > Test case attached. All paths have been exercised. > > -- John > > From john.r.rose at oracle.com Wed Jun 1 12:02:50 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jun 2011 12:02:50 -0700 Subject: review request (URGENT): 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError In-Reply-To: <301F800D-BF20-4C35-91B9-BCCDE64F6A67@oracle.com> References: <2BD3578B-6859-4300-9FB6-280EEF91B593@oracle.com> <301F800D-BF20-4C35-91B9-BCCDE64F6A67@oracle.com> Message-ID: <503FC605-714C-42A4-A222-8780FF647007@oracle.com> Thanks, Tom. On Jun 1, 2011, at 11:50 AM, Tom Rodriguez wrote: > Looks ok. From thomas.wuerthinger at oracle.com Wed Jun 1 12:28:06 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 01 Jun 2011 21:28:06 +0200 Subject: IdealGraphVisualizer In-Reply-To: References: <7930257e-c9a1-4925-a7ca-24e976296fc5@default> <995C4FE8-BB84-4F5F-AD4C-B94AC2253FB3@oracle.com> <39A4CEF1-5AA1-4DBD-9E72-3144C57BF4AA@oracle.com> Message-ID: <4DE692C6.5000502@oracle.com> Peter Hofer is currently working on an improved IGV version that will also be able to display the graphs of the Graal compiler that is part of the Maxine project. The plan is to add the text view component of the c1visualizer, which supports folding of blocks and text highlighting. It will not be a complex interaction model between the text view and the graph view like in the current IGV. - thomas On 6/1/11 8:21 PM, Tom Rodriguez wrote: > Is this based on the improved kenai version? The text view in that is nice but there seem to be some interaction bugs that result in exceptions in the event thread that screw up the display. > > tom > > On Jun 1, 2011, at 10:59 AM, Christian Wimmer wrote: > >> Unfortunately, every new version of NetBeans requires a bunch of trivial and a few non-trivial changes to get a NetBeans-based application running again. >> >> The good news is, a student at the University Linz - Peter Hofer - is actively working on the visualizer, and probably already has a version working with NetBeans 7. I copied him on this mail, hopefully he can help with this. >> >> -Christian >> >> >> On Tue, May 31, 2011 at 11:13 AM, Tom Rodriguez wrote: >> IGV is based on an older version of netbeans, 6.5.1 I think. http://netbeans.org/downloads/6.5.1/index.html. It could probably be forward ported to 7 but that would require more knowledge than I have. >> >> tom >> >> On May 31, 2011, at 9:53 AM, Mikael Vidstedt wrote: >> >>> IdealGraphVisualizer gurus, >>> >>> I?m trying to build the latest greatest version of the project in Netbeans (7.0) but my success rate is so far limited. The build terminates with the following error: >>> >>> com.sun.hotspot.igv.filter.compile: >>> Compiling 12 source files to D:\hg\hotspot\tst\hotspot-comp\src\share\tools\IdealGraphVisualizer\Filter\build\classes >>> Note: Attempting to workaround 6512707 >>> D:\hg\hotspot\tst\hotspot-comp\src\share\tools\IdealGraphVisualizer\Filter\src\com\sun\hotspot\igv\filter\CustomFilter.java:81: cannot access org.netbeans.api.actions.Openable >>> class file for org.netbeans.api.actions.Openable not found >>> return new OpenCookie() { >>> C:\Program Files\NetBeans 7.0\harness\suite.xml:182: The following error occurred while executing this line: >>> C:\Program Files\NetBeans 7.0\harness\common.xml:206: Compile failed; see the compiler error output for details. >>> >>> Anybody seen this problem before? >>> >>> Thanks, >>> Mikael >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110601/7e501fe4/attachment.html From vladimir.kozlov at oracle.com Wed Jun 1 12:54:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Jun 2011 12:54:02 -0700 Subject: Request for reviews (S): 7044738: Loop unroll optimization causes incorrect result Message-ID: <4DE698DA.80101@oracle.com> For next release, too risky for jdk7. http://cr.openjdk.java.net/~kvn/7044738/webrev Fixed 7044738: Loop unroll optimization causes incorrect result It is rare case when OSR compilation is done for nested loop which prevents ciTypeFlow to clone loop's head. As result the control node of loop's nodes is loop's back control. During loop iterations split clone_up_backedge_goo() creates clones for nodes which are pinned to loop's back control and it does not take into account memory dependencies by creating duplicated clones. Added regression test. Tested with full CTW. From john.r.rose at oracle.com Wed Jun 1 13:39:58 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jun 2011 13:39:58 -0700 Subject: review request (URGENT): 7050328: (jsr-292) findConstructor throws ExceptionInInitializerError if run under SecurityManager Message-ID: <75BB12F8-13A8-4F23-A71E-C6FB89C78186@oracle.com> Summary: Wrap system property and reflection accesses under doPrivileged. Ensure constant pool linkage bypasses the SM as specified. http://cr.openjdk.java.net/~jrose/7050328/webrev.00 (jdk changes only; no jvm changes) Testing: - Passes jtreg unit tests for java.lang.invoke and ad hoc mlvm tests. - Newly modified unit test spot-tests APIs with a toxic security manager, to ensure that the specified security exceptions are thrown. - Passes test reported in 7050328. - No regression on related bug 7042829. Note to reviewers: Please confirm that the duplicated or moved code lines are accurate duplicates. The change to the unit test shows how I verified the places that needed change. These places were independently found by grepping. -- John From vladimir.kozlov at oracle.com Wed Jun 1 13:56:16 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Jun 2011 13:56:16 -0700 Subject: review request (URGENT): 7050328: (jsr-292) findConstructor throws ExceptionInInitializerError if run under SecurityManager In-Reply-To: <75BB12F8-13A8-4F23-A71E-C6FB89C78186@oracle.com> References: <75BB12F8-13A8-4F23-A71E-C6FB89C78186@oracle.com> Message-ID: <4DE6A770.70008@oracle.com> Looks good to me. Vladimir John Rose wrote: > Summary: Wrap system property and reflection accesses under doPrivileged. Ensure constant pool linkage bypasses the SM as specified. > > http://cr.openjdk.java.net/~jrose/7050328/webrev.00 (jdk changes only; no jvm changes) > > Testing: > - Passes jtreg unit tests for java.lang.invoke and ad hoc mlvm tests. > - Newly modified unit test spot-tests APIs with a toxic security manager, to ensure that the specified security exceptions are thrown. > - Passes test reported in 7050328. > - No regression on related bug 7042829. > > Note to reviewers: Please confirm that the duplicated or moved code lines are accurate duplicates. > > The change to the unit test shows how I verified the places that needed change. These places were independently found by grepping. > > -- John From john.r.rose at oracle.com Wed Jun 1 14:04:17 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jun 2011 14:04:17 -0700 Subject: review request (URGENT): 7050328: (jsr-292) findConstructor throws ExceptionInInitializerError if run under SecurityManager In-Reply-To: <4DE6A770.70008@oracle.com> References: <75BB12F8-13A8-4F23-A71E-C6FB89C78186@oracle.com> <4DE6A770.70008@oracle.com> Message-ID: <9EFDAB6D-0753-4E1C-8E4F-6622F931C7EE@oracle.com> Thanks, Vladimir. -- John On Jun 1, 2011, at 1:56 PM, Vladimir Kozlov wrote: > Looks good to me. From tom.rodriguez at oracle.com Wed Jun 1 14:23:14 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 14:23:14 -0700 Subject: review request (URGENT): 7050328: (jsr-292) findConstructor throws ExceptionInInitializerError if run under SecurityManager In-Reply-To: <75BB12F8-13A8-4F23-A71E-C6FB89C78186@oracle.com> References: <75BB12F8-13A8-4F23-A71E-C6FB89C78186@oracle.com> Message-ID: <1599A1F1-5915-4735-9D67-C93B3402D3AD@oracle.com> Looks good. tom On Jun 1, 2011, at 1:39 PM, John Rose wrote: > Summary: Wrap system property and reflection accesses under doPrivileged. Ensure constant pool linkage bypasses the SM as specified. > > http://cr.openjdk.java.net/~jrose/7050328/webrev.00 (jdk changes only; no jvm changes) > > Testing: > - Passes jtreg unit tests for java.lang.invoke and ad hoc mlvm tests. > - Newly modified unit test spot-tests APIs with a toxic security manager, to ensure that the specified security exceptions are thrown. > - Passes test reported in 7050328. > - No regression on related bug 7042829. > > Note to reviewers: Please confirm that the duplicated or moved code lines are accurate duplicates. > > The change to the unit test shows how I verified the places that needed change. These places were independently found by grepping. > > -- John From tom.rodriguez at oracle.com Wed Jun 1 14:38:40 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 14:38:40 -0700 Subject: review for 7050554: JSR 292 - need optimization for selectAlternative Message-ID: <6D1B1115-527E-4EE0-B28A-0A5DC745AAF0@oracle.com> http://cr.openjdk.java.net/~never/7050554 130 lines changed: 74 ins; 20 del; 36 mod; 4493 unchg 7050554: JSR 292 - need optimization for selectAlternative Reviewed-by: JSR 292 provides a GuardWithTest idiom is allow selection between two different method handles based on a boolean test. In earlier versions of the JDK code this was done with a bunch of little wrapper methods for different arities. This resulted in a call site for a each call which allowed existing constant folding code to statically bind the call sites. Because this didn't scale it was replaced with a new idiom that looks more like (test ? a : b).invoke() which only have a single call site. This interferes with inlining making the code perform terribly. We need a new bimorhphic inline for invokedynamic callsites to deal with this. Without it performance of invokedynamic for things like jruby is pretty terrible. Tested with regression tests and jruby tests. I also fixed a problem in the shared print compilation code where attempting to print zombie for an unloaded nmethod causes a segv because the method is NULL. From tom.rodriguez at oracle.com Wed Jun 1 14:38:41 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 14:38:41 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames Message-ID: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> http://cr.openjdk.java.net/~never/7045514 2389 lines changed: 1833 ins; 363 del; 193 mod; 46455 unchg 7045514: SPARC assembly code for JSR 292 ricochet frames Reviewed-by: This is the complete support for Ricochet frames on sparc. Christian did all the work and testing and I just did some final testing and bug fixing. A potential issue with checkcasts reusing locals in methodHandleWalk.cpp was fixed. Comments weren't being transferred onto the MethodHandlesAdapterBlob. A derived oop issue was found where an assert was complaining that an offset was too large but there's no real restriction on the offset of derived oops so I disabled the assert. ResourceMarks were added in verification logic. A verify_vmargslot call was verifying against the wrong signature resulting in occasional incorrect exceptions. I updated the MacroAssembler::debug assertion messages to include the passed in message. Many of blob declarations were moved into shared code so that we don't have to replicate code. Some x86 method handles code was changed to make signatures match. Currently it passes all the jdk regression tests on sparc but I can't run any of the others because of version mismatches between the JDK and the tests. Earlier versions ran those as well they had previously. I also ran the jruby tests and those seemed clean as well. From john.r.rose at oracle.com Wed Jun 1 14:46:03 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jun 2011 14:46:03 -0700 Subject: review request (URGENT): 7049122: java/lang/invoke/RicochetTest.java with MAX_ARITY=255 in -Xcomp mode overflows code cache Message-ID: <88E86D94-BBEC-49CA-839F-F241A9633BA2@oracle.com> Summary: reduce the scope of the unit test (mark high water mark of testing with @ignore tags) http://cr.openjdk.java.net/~jrose/7049122/webrev.00 Compensate somewhat for missing coverage by enabling ValueConversionsTest, which tests additional varargs array types. Testing: jtreg runs the modified tests on x86, with and without -Xcomp -Xbatch, 32 and 64 bit (b145 preview). This fails on adm64, with about 8000 adapters: jtreg -Xcomp -Xbatch -DValueConversionsTest.MAX_ARITY=255 -jdk:$JAVA7X64_BUILD test/sun/invoke/util/ValueConversionsTest.java By comparison, this arity limit (which is about 3x the proposed size) succeeds in about 10 seconds: jtreg -Xcomp -Xbatch -DValueConversionsTest.MAX_ARITY=150 -jdk:$JAVA7X64_BUILD test/sun/invoke/util/ValueConversionsTest.java There is no testing yet on SPARC. -- John From tom.rodriguez at oracle.com Wed Jun 1 14:50:54 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 14:50:54 -0700 Subject: review request (URGENT): 7049122: java/lang/invoke/RicochetTest.java with MAX_ARITY=255 in -Xcomp mode overflows code cache In-Reply-To: <88E86D94-BBEC-49CA-839F-F241A9633BA2@oracle.com> References: <88E86D94-BBEC-49CA-839F-F241A9633BA2@oracle.com> Message-ID: Looks good. tom On Jun 1, 2011, at 2:46 PM, John Rose wrote: > Summary: reduce the scope of the unit test (mark high water mark of testing with @ignore tags) > > http://cr.openjdk.java.net/~jrose/7049122/webrev.00 > > Compensate somewhat for missing coverage by enabling ValueConversionsTest, which tests additional varargs array types. > > Testing: jtreg runs the modified tests on x86, with and without -Xcomp -Xbatch, 32 and 64 bit (b145 preview). > > This fails on adm64, with about 8000 adapters: > jtreg -Xcomp -Xbatch -DValueConversionsTest.MAX_ARITY=255 -jdk:$JAVA7X64_BUILD test/sun/invoke/util/ValueConversionsTest.java > > By comparison, this arity limit (which is about 3x the proposed size) succeeds in about 10 seconds: > jtreg -Xcomp -Xbatch -DValueConversionsTest.MAX_ARITY=150 -jdk:$JAVA7X64_BUILD test/sun/invoke/util/ValueConversionsTest.java > > There is no testing yet on SPARC. > > -- John From vladimir.kozlov at oracle.com Wed Jun 1 16:38:29 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Jun 2011 16:38:29 -0700 Subject: review for 7050554: JSR 292 - need optimization for selectAlternative In-Reply-To: <6D1B1115-527E-4EE0-B28A-0A5DC745AAF0@oracle.com> References: <6D1B1115-527E-4EE0-B28A-0A5DC745AAF0@oracle.com> Message-ID: <4DE6CD75.4060407@oracle.com> What about when only one call site could be inlined in bimorhphic case? Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7050554 > 130 lines changed: 74 ins; 20 del; 36 mod; 4493 unchg > > 7050554: JSR 292 - need optimization for selectAlternative > Reviewed-by: > > JSR 292 provides a GuardWithTest idiom is allow selection between two > different method handles based on a boolean test. In earlier versions > of the JDK code this was done with a bunch of little wrapper methods > for different arities. This resulted in a call site for a each call > which allowed existing constant folding code to statically bind the > call sites. Because this didn't scale it was replaced with a new > idiom that looks more like (test ? a : b).invoke() which only have a > single call site. This interferes with inlining making the code > perform terribly. We need a new bimorhphic inline for invokedynamic > callsites to deal with this. Without it performance of invokedynamic > for things like jruby is pretty terrible. Tested with regression > tests and jruby tests. > > I also fixed a problem in the shared print compilation code where > attempting to print zombie for an unloaded nmethod causes a segv > because the method is NULL. > From john.r.rose at oracle.com Wed Jun 1 16:51:17 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jun 2011 16:51:17 -0700 Subject: review request (URGENT): 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM Message-ID: 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM This is a one-bit change to the source code. (OK, one boolean token plus whitespace.) http://cr.openjdk.java.net/~jrose/7050328/webrev.00/ -- John From tom.rodriguez at oracle.com Wed Jun 1 16:51:28 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 16:51:28 -0700 Subject: review for 7050554: JSR 292 - need optimization for selectAlternative In-Reply-To: <4DE6CD75.4060407@oracle.com> References: <6D1B1115-527E-4EE0-B28A-0A5DC745AAF0@oracle.com> <4DE6CD75.4060407@oracle.com> Message-ID: On Jun 1, 2011, at 4:38 PM, Vladimir Kozlov wrote: > What about when only one call site could be inlined in bimorhphic case? I considered allowing only one to be inlined but that doesn't really seem to occur. Since these are method handle chains they should all be constants and each side is method handle and we will pretty much always inline them once we start a chain. This is really about getting back performance that we lost because of JDK changes more than attempting to do the most optimal thing. We'll revisit the inlining optimizations after 7 ships. tom > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7050554 >> 130 lines changed: 74 ins; 20 del; 36 mod; 4493 unchg >> 7050554: JSR 292 - need optimization for selectAlternative >> Reviewed-by: >> JSR 292 provides a GuardWithTest idiom is allow selection between two >> different method handles based on a boolean test. In earlier versions >> of the JDK code this was done with a bunch of little wrapper methods >> for different arities. This resulted in a call site for a each call >> which allowed existing constant folding code to statically bind the >> call sites. Because this didn't scale it was replaced with a new >> idiom that looks more like (test ? a : b).invoke() which only have a >> single call site. This interferes with inlining making the code >> perform terribly. We need a new bimorhphic inline for invokedynamic >> callsites to deal with this. Without it performance of invokedynamic >> for things like jruby is pretty terrible. Tested with regression >> tests and jruby tests. >> I also fixed a problem in the shared print compilation code where >> attempting to print zombie for an unloaded nmethod causes a segv >> because the method is NULL. From tom.rodriguez at oracle.com Wed Jun 1 16:54:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 16:54:27 -0700 Subject: review request (URGENT): 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM In-Reply-To: References: Message-ID: <352003E7-29BB-46F5-9F8F-D0B82EDB82C6@oracle.com> http://cr.openjdk.java.net/~jrose/7049410/webrev.00 looks good. tom On Jun 1, 2011, at 4:51 PM, John Rose wrote: > 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM > > This is a one-bit change to the source code. (OK, one boolean token plus whitespace.) > > http://cr.openjdk.java.net/~jrose/7050328/webrev.00/ > > -- John From vladimir.kozlov at oracle.com Wed Jun 1 17:00:49 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Jun 2011 17:00:49 -0700 Subject: review for 7050554: JSR 292 - need optimization for selectAlternative In-Reply-To: References: <6D1B1115-527E-4EE0-B28A-0A5DC745AAF0@oracle.com> <4DE6CD75.4060407@oracle.com> Message-ID: <4DE6D2B1.6080506@oracle.com> Good. Thanks, Vladimir Tom Rodriguez wrote: > On Jun 1, 2011, at 4:38 PM, Vladimir Kozlov wrote: > >> What about when only one call site could be inlined in bimorhphic case? > > I considered allowing only one to be inlined but that doesn't really seem to occur. Since these are method handle chains they should all be constants and each side is method handle and we will pretty much always inline them once we start a chain. This is really about getting back performance that we lost because of JDK changes more than attempting to do the most optimal thing. We'll revisit the inlining optimizations after 7 ships. > > tom > >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7050554 >>> 130 lines changed: 74 ins; 20 del; 36 mod; 4493 unchg >>> 7050554: JSR 292 - need optimization for selectAlternative >>> Reviewed-by: >>> JSR 292 provides a GuardWithTest idiom is allow selection between two >>> different method handles based on a boolean test. In earlier versions >>> of the JDK code this was done with a bunch of little wrapper methods >>> for different arities. This resulted in a call site for a each call >>> which allowed existing constant folding code to statically bind the >>> call sites. Because this didn't scale it was replaced with a new >>> idiom that looks more like (test ? a : b).invoke() which only have a >>> single call site. This interferes with inlining making the code >>> perform terribly. We need a new bimorhphic inline for invokedynamic >>> callsites to deal with this. Without it performance of invokedynamic >>> for things like jruby is pretty terrible. Tested with regression >>> tests and jruby tests. >>> I also fixed a problem in the shared print compilation code where >>> attempting to print zombie for an unloaded nmethod causes a segv >>> because the method is NULL. > From john.r.rose at oracle.com Wed Jun 1 17:02:12 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jun 2011 17:02:12 -0700 Subject: review request (URGENT): 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM In-Reply-To: <352003E7-29BB-46F5-9F8F-D0B82EDB82C6@oracle.com> References: <352003E7-29BB-46F5-9F8F-D0B82EDB82C6@oracle.com> Message-ID: <847EE28E-A86F-45F6-951E-56FF6D380437@oracle.com> Thanks Tom. -- John On Jun 1, 2011, at 4:54 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~jrose/7049410/webrev.00 looks good. > > tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110601/5be7a3a0/attachment.html From vladimir.kozlov at oracle.com Wed Jun 1 18:15:23 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Jun 2011 18:15:23 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames In-Reply-To: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> References: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> Message-ID: <4DE6E42B.1030707@oracle.com> Christian is hero to write all this :) Did you test with -XX:-EnableInvokeDynamic (off)? methodHandles_sparc.cpp: Can you do the decrement of slot_num as separate expressions?: + intptr_t* loc = &base[slot_num -= 1]; + loc = &base[slot_num -= type2size[ptype]]; + // Emit code to verify that RBP is pointing at a valid ricochet frame. ^ no RBP on sparc RicochetFrame::verify_clean() has commented out code. Should next code use brx() instruction?: + __ ld_ptr(L4_saved_args_base, __ argument_offset(O5_temp), O7_temp); + __ cmp(O7_temp, (int32_t) RETURN_VALUE_PLACEHOLDER); + __ br(Assembler::equal, false, Assembler::pt, L_ok_4); In load_conversion_vminfo() could you just use the same assert (CONV_VMINFO_SHIFT == 0) as next method and simplify address expression. MethodHandles::verify_stack_move() has commented code. Should UNREASONABLE_STACK_MOVE depends on LP64? Could you move following verification code under first condition?: + if (collect_count_constant >= 0) { + collect_count = collect_count_constant; + } else { + __ load_method_handle_vmslots(O1_collect_count, G3_method_handle, O2_scratch); + collect_count = O1_collect_count; + } + #ifdef ASSERT + if (VerifyMethodHandles && collect_count_constant >= 0) { + BLOCK_COMMENT("verify collect_count_constant {"); + __ load_method_handle_vmslots(O3_scratch, G3_method_handle, O2_scratch); The same for dest_slot_constant verification. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7045514 > 2389 lines changed: 1833 ins; 363 del; 193 mod; 46455 unchg > > 7045514: SPARC assembly code for JSR 292 ricochet frames > Reviewed-by: > > This is the complete support for Ricochet frames on sparc. Christian > did all the work and testing and I just did some final testing and bug > fixing. > > A potential issue with checkcasts reusing locals in > methodHandleWalk.cpp was fixed. Comments weren't being transferred > onto the MethodHandlesAdapterBlob. A derived oop issue was found > where an assert was complaining that an offset was too large but > there's no real restriction on the offset of derived oops so I > disabled the assert. ResourceMarks were added in verification logic. > A verify_vmargslot call was verifying against the wrong signature > resulting in occasional incorrect exceptions. I updated the > MacroAssembler::debug assertion messages to include the passed in > message. Many of blob declarations were moved into shared code so > that we don't have to replicate code. Some x86 method handles code > was changed to make signatures match. > > Currently it passes all the jdk regression tests on sparc but I can't > run any of the others because of version mismatches between the JDK > and the tests. Earlier versions ran those as well they had > previously. I also ran the jruby tests and those seemed clean as well. > From john.r.rose at oracle.com Wed Jun 1 19:19:23 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jun 2011 19:19:23 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames In-Reply-To: <4DE6E42B.1030707@oracle.com> References: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> <4DE6E42B.1030707@oracle.com> Message-ID: On Jun 1, 2011, at 6:15 PM, Vladimir Kozlov wrote: > Christian is hero to write all this :) I agree. :-) > MethodHandles::verify_stack_move() has commented code. Should UNREASONABLE_STACK_MOVE depends on LP64? It could. Tom writes this: // extra-large, XXX large enough? The key idea is that the most a MH can move the SP is by up to 255 argument positions, assuming an extreme spread or collect operation. Since an argument is 4 or 8 bytes, we round up and get the constant. Could also use something like (MAX_ARITY+FENCE_POST_ERROR)*stackElementSize, but that seems like overkill to me. The idea is to defend (partially) against garbage values that move the SP by large leaps. > Could you move following verification code under first condition?: > > + if (collect_count_constant >= 0) { > + collect_count = collect_count_constant; > + } else { > + __ load_method_handle_vmslots(O1_collect_count, G3_method_handle, O2_scratch); > + collect_count = O1_collect_count; > + } > + #ifdef ASSERT > + if (VerifyMethodHandles && collect_count_constant >= 0) { > + BLOCK_COMMENT("verify collect_count_constant {"); > + __ load_method_handle_vmslots(O3_scratch, G3_method_handle, O2_scratch); > > The same for dest_slot_constant verification. Remember that it's also helpful, when reading the code, to see both cases together (constant/nonconstant). Either way is fine with me. (I agree with your other points.) -- John From john.r.rose at oracle.com Wed Jun 1 19:58:11 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jun 2011 19:58:11 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames In-Reply-To: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> References: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> Message-ID: On Jun 1, 2011, at 2:38 PM, Tom Rodriguez wrote: > 7045514: SPARC assembly code for JSR 292 ricochet frames --- methodHandles_sparc.hpp Looks good. --- methodHandles_sparc.cpp // Gargs points to the first word so adjust by BytesPerWord Heavy sigh. IMO, that off-by-one design is a plague on our source base. (Also, later: __ add(FP, STACK_BIAS - (1 * Interpreter::stackElementSize), Gargs)) This expression assumes a tricky relation (including an exp2(1+log2(n))) between the two constants: (offset + 1*BytesPerWord) & ~TwoWordAlignmentMask I would prefer simply: round_to(offset, TwoWordAlignmentMask+1 /*or whatever*/) There's also a __ round_to(reg, mod) to use on the other branch. Could be a __ round_down also. (Nice factorization of the tricky bits in adjust_SP_and_Gargs_down_by_slots etc.) Is it worth testing that the incoming value to adjust_... is always >= 0? Does this indicate a bug on amd64? - int slot_size = (arg_size > wordSize) ? arg_size : wordSize; + int slot_size = is_subword_type(type) ? type2aelembytes(T_INT) : arg_size; // store int sub-words as int Or is it just a big-endian thing? If it's an amd64 bug let's fix it. This line makes me uneasy: + __ store_sized_value(O0, return_slot, type_size); The return_slot is the address of a "hole" in the stacked argument list. It's going to get passed to the final target of the RF. So whatever gets stored into it will be all the information in the stack slot for that argument. I think what you wrote works only because there was a "42" in the hole already. If there is garbage, and you store a byte on top, you get a partly garbage value. I like this; can we have it on the x86 side too? + BLOCK_COMMENT(err_msg("Begin %s", entry_name(ek))); + BLOCK_COMMENT(err_msg("End %s", entry_name(ek))); Did you consider making the temp argument to argument_address be mandatory? It seems tricky that it can kill its input. This seems like you don't need it: + // reload from rdx_argslot_limit since rax_argslot is now decremented + __ ld_ptr(Address(O2_argslot_limit, -Interpreter::stackElementSize), O1_array); The reload is on the x86 side because of the scarcity of registers. Reviewed. -- John From tom.rodriguez at oracle.com Wed Jun 1 20:44:34 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 20:44:34 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames In-Reply-To: References: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> <4DE6E42B.1030707@oracle.com> Message-ID: <95437DB2-65A8-4089-A8FE-736A3DC35A48@oracle.com> On Jun 1, 2011, at 7:19 PM, John Rose wrote: > On Jun 1, 2011, at 6:15 PM, Vladimir Kozlov wrote: > >> Christian is hero to write all this :) > > I agree. :-) > >> MethodHandles::verify_stack_move() has commented code. Should UNREASONABLE_STACK_MOVE depends on LP64? > > It could. Tom writes this: // extra-large, XXX large enough? I had disabled because it was triggering but it didn't seem like there was a real problem. This was in 32 bit mode I think. I meant to go back and figure out why it was wrong. I'll see if I can correct it. > > The key idea is that the most a MH can move the SP is by up to 255 argument positions, assuming an extreme spread or collect operation. > > Since an argument is 4 or 8 bytes, we round up and get the constant. Could also use something like (MAX_ARITY+FENCE_POST_ERROR)*stackElementSize, but that seems like overkill to me. The idea is to defend (partially) against garbage values that move the SP by large leaps. > >> Could you move following verification code under first condition?: >> >> + if (collect_count_constant >= 0) { >> + collect_count = collect_count_constant; >> + } else { >> + __ load_method_handle_vmslots(O1_collect_count, G3_method_handle, O2_scratch); >> + collect_count = O1_collect_count; >> + } >> + #ifdef ASSERT >> + if (VerifyMethodHandles && collect_count_constant >= 0) { >> + BLOCK_COMMENT("verify collect_count_constant {"); >> + __ load_method_handle_vmslots(O3_scratch, G3_method_handle, O2_scratch); >> >> The same for dest_slot_constant verification. > > Remember that it's also helpful, when reading the code, to see both cases together (constant/nonconstant). Either way is fine with me. I kind of prefer it separate given the ordering but maybe if they were swapped then the verify code wouldn't be in the middle of the main logic. At root I'm happy either way. Which would you prefer? tom > > (I agree with your other points.) > > -- John From tom.rodriguez at oracle.com Wed Jun 1 21:10:03 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 21:10:03 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames In-Reply-To: <4DE6E42B.1030707@oracle.com> References: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> <4DE6E42B.1030707@oracle.com> Message-ID: On Jun 1, 2011, at 6:15 PM, Vladimir Kozlov wrote: > Christian is hero to write all this :) Yep. > > Did you test with -XX:-EnableInvokeDynamic (off)? No. Are you asking if we can run normal programs with -EnableInvokeDynamic? > > methodHandles_sparc.cpp: > > Can you do the decrement of slot_num as separate expressions?: -= is the same as predecrement not postdecrement, right? > > + intptr_t* loc = &base[slot_num -= 1]; int slot_num = slot_count - 1; intptr_t* loc = &base[slot_num]; > > + loc = &base[slot_num -= type2size[ptype]]; slot_num -= type2size[ptype]; loc = &base[slot_num]; > > + // Emit code to verify that RBP is pointing at a valid ricochet frame. > ^ no RBP on sparc Fixed. > > RicochetFrame::verify_clean() has commented out code. I've removed it. > > Should next code use brx() instruction?: > > + __ ld_ptr(L4_saved_args_base, __ argument_offset(O5_temp), O7_temp); > + __ cmp(O7_temp, (int32_t) RETURN_VALUE_PLACEHOLDER); > + __ br(Assembler::equal, false, Assembler::pt, L_ok_4); Probably. > > In load_conversion_vminfo() could you just use the same assert (CONV_VMINFO_SHIFT == 0) as next method and simplify address expression. This? void MethodHandles::load_conversion_vminfo(MacroAssembler* _masm, Address conversion_field_addr, Register reg) { assert(CONV_VMINFO_SHIFT == 0, "preshifted"); assert(CONV_VMINFO_MASK == right_n_bits(BitsPerBte), "else change type of following load"); __ ldub(conversion_field_addr.plus_disp(BytesPerInt - 1), reg); } > > MethodHandles::verify_stack_move() has commented code. Should UNREASONABLE_STACK_MOVE depends on LP64? I'm going to rework this. > > Could you move following verification code under first condition?: > > + if (collect_count_constant >= 0) { > + collect_count = collect_count_constant; > + } else { > + __ load_method_handle_vmslots(O1_collect_count, G3_method_handle, O2_scratch); > + collect_count = O1_collect_count; > + } > + #ifdef ASSERT > + if (VerifyMethodHandles && collect_count_constant >= 0) { > + BLOCK_COMMENT("verify collect_count_constant {"); > + __ load_method_handle_vmslots(O3_scratch, G3_method_handle, O2_scratch); > > The same for dest_slot_constant verification. I can join them but I think I might swap the conditions. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7045514 >> 2389 lines changed: 1833 ins; 363 del; 193 mod; 46455 unchg >> 7045514: SPARC assembly code for JSR 292 ricochet frames >> Reviewed-by: >> This is the complete support for Ricochet frames on sparc. Christian >> did all the work and testing and I just did some final testing and bug >> fixing. >> A potential issue with checkcasts reusing locals in >> methodHandleWalk.cpp was fixed. Comments weren't being transferred >> onto the MethodHandlesAdapterBlob. A derived oop issue was found >> where an assert was complaining that an offset was too large but >> there's no real restriction on the offset of derived oops so I >> disabled the assert. ResourceMarks were added in verification logic. >> A verify_vmargslot call was verifying against the wrong signature >> resulting in occasional incorrect exceptions. I updated the >> MacroAssembler::debug assertion messages to include the passed in >> message. Many of blob declarations were moved into shared code so >> that we don't have to replicate code. Some x86 method handles code >> was changed to make signatures match. >> Currently it passes all the jdk regression tests on sparc but I can't >> run any of the others because of version mismatches between the JDK >> and the tests. Earlier versions ran those as well they had >> previously. I also ran the jruby tests and those seemed clean as well. From john.r.rose at oracle.com Thu Jun 2 01:48:24 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 02 Jun 2011 08:48:24 +0000 Subject: hg: hsx/hotspot-comp/jdk: 3 new changesets Message-ID: <20110602084913.A379E47AFA@hg.openjdk.java.net> Changeset: 8318d03e1766 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8318d03e1766 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Wrap invokedynamic linkage errors in BootstrapMethodError, as needed. Reviewed-by: never ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 0b8b6eace473 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0b8b6eace473 7050328: (jsr-292) findConstructor throws ExceptionInInitializerError if run under SecurityManager Summary: Wrap system property and reflection accesses under doPrivileged. Ensure constant pool linkage bypasses the SM as specified. Reviewed-by: kvn, never ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: 34481a4012c3 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/34481a4012c3 7049122: java/lang/invoke/RicochetTest.java with MAX_ARITY=255 in -Xcomp mode overflows code cache Summary: reduce the scope of the unit test (mark high water mark of testing with @ignore tags) Reviewed-by: never ! test/java/lang/invoke/RicochetTest.java From john.r.rose at oracle.com Thu Jun 2 03:12:06 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 02 Jun 2011 10:12:06 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110602101211.E801647AFD@hg.openjdk.java.net> Changeset: 60b8287df30e Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/60b8287df30e 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Delegate invokedynamic linkage errors to MethodHandleNatives.raiseException. Reviewed-by: never ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: a93146d0e4be Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a93146d0e4be 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM Summary: change the default setting of the flag AllowInvokeGeneric to false Reviewed-by: never ! src/share/vm/runtime/globals.hpp From vladimir.kozlov at oracle.com Thu Jun 2 09:20:48 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Jun 2011 09:20:48 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames In-Reply-To: References: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> <4DE6E42B.1030707@oracle.com> Message-ID: <4DE7B860.4090402@oracle.com> On 6/1/11 9:10 PM, Tom Rodriguez wrote: > > On Jun 1, 2011, at 6:15 PM, Vladimir Kozlov wrote: > >> Christian is hero to write all this :) > > Yep. > >> >> Did you test with -XX:-EnableInvokeDynamic (off)? > > No. Are you asking if we can run normal programs with -EnableInvokeDynamic? Yes, this flag is on by default so I want to know if we can run with it off. > >> >> methodHandles_sparc.cpp: >> >> Can you do the decrement of slot_num as separate expressions?: > > -= is the same as predecrement not postdecrement, right? I am not sure, this is why is why I asked to separate it. > >> >> + intptr_t* loc =&base[slot_num -= 1]; > > int slot_num = slot_count - 1; > intptr_t* loc =&base[slot_num]; > >> >> + loc =&base[slot_num -= type2size[ptype]]; > > slot_num -= type2size[ptype]; > loc =&base[slot_num]; > Good. >> >> In load_conversion_vminfo() could you just use the same assert (CONV_VMINFO_SHIFT == 0) as next method and simplify address expression. > > This? > > void MethodHandles::load_conversion_vminfo(MacroAssembler* _masm, Address conversion_field_addr, Register reg) { > assert(CONV_VMINFO_SHIFT == 0, "preshifted"); > assert(CONV_VMINFO_MASK == right_n_bits(BitsPerBte), "else change type of following load"); > __ ldub(conversion_field_addr.plus_disp(BytesPerInt - 1), reg); > } Good. > >> >> Could you move following verification code under first condition?: >> >> + if (collect_count_constant>= 0) { >> + collect_count = collect_count_constant; >> + } else { >> + __ load_method_handle_vmslots(O1_collect_count, G3_method_handle, O2_scratch); >> + collect_count = O1_collect_count; >> + } >> + #ifdef ASSERT >> + if (VerifyMethodHandles&& collect_count_constant>= 0) { >> + BLOCK_COMMENT("verify collect_count_constant {"); >> + __ load_method_handle_vmslots(O3_scratch, G3_method_handle, O2_scratch); >> >> The same for dest_slot_constant verification. > > I can join them but I think I might swap the conditions. Swap is fine. Thanks, Vladimir > > tom > >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7045514 >>> 2389 lines changed: 1833 ins; 363 del; 193 mod; 46455 unchg >>> 7045514: SPARC assembly code for JSR 292 ricochet frames >>> Reviewed-by: >>> This is the complete support for Ricochet frames on sparc. Christian >>> did all the work and testing and I just did some final testing and bug >>> fixing. >>> A potential issue with checkcasts reusing locals in >>> methodHandleWalk.cpp was fixed. Comments weren't being transferred >>> onto the MethodHandlesAdapterBlob. A derived oop issue was found >>> where an assert was complaining that an offset was too large but >>> there's no real restriction on the offset of derived oops so I >>> disabled the assert. ResourceMarks were added in verification logic. >>> A verify_vmargslot call was verifying against the wrong signature >>> resulting in occasional incorrect exceptions. I updated the >>> MacroAssembler::debug assertion messages to include the passed in >>> message. Many of blob declarations were moved into shared code so >>> that we don't have to replicate code. Some x86 method handles code >>> was changed to make signatures match. >>> Currently it passes all the jdk regression tests on sparc but I can't >>> run any of the others because of version mismatches between the JDK >>> and the tests. Earlier versions ran those as well they had >>> previously. I also ran the jruby tests and those seemed clean as well. > From tom.rodriguez at oracle.com Thu Jun 2 11:49:15 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 2 Jun 2011 11:49:15 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames In-Reply-To: <4DE7B860.4090402@oracle.com> References: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> <4DE6E42B.1030707@oracle.com> <4DE7B860.4090402@oracle.com> Message-ID: <20AC3C2F-A12C-4132-804C-9825B7624DB8@oracle.com> On Jun 2, 2011, at 9:20 AM, Vladimir Kozlov wrote: > On 6/1/11 9:10 PM, Tom Rodriguez wrote: >> >> On Jun 1, 2011, at 6:15 PM, Vladimir Kozlov wrote: >> >>> Christian is hero to write all this :) >> >> Yep. >> >>> >>> Did you test with -XX:-EnableInvokeDynamic (off)? >> >> No. Are you asking if we can run normal programs with -EnableInvokeDynamic? > > Yes, this flag is on by default so I want to know if we can run with it off. It seems to work with it off. > >> >>> >>> methodHandles_sparc.cpp: >>> >>> Can you do the decrement of slot_num as separate expressions?: >> >> -= is the same as predecrement not postdecrement, right? > > I am not sure, this is why is why I asked to separate it. > >> >>> >>> + intptr_t* loc =&base[slot_num -= 1]; >> >> int slot_num = slot_count - 1; >> intptr_t* loc =&base[slot_num]; >> >>> >>> + loc =&base[slot_num -= type2size[ptype]]; >> >> slot_num -= type2size[ptype]; >> loc =&base[slot_num]; >> > > Good. > >>> >>> In load_conversion_vminfo() could you just use the same assert (CONV_VMINFO_SHIFT == 0) as next method and simplify address expression. >> >> This? >> >> void MethodHandles::load_conversion_vminfo(MacroAssembler* _masm, Address conversion_field_addr, Register reg) { >> assert(CONV_VMINFO_SHIFT == 0, "preshifted"); >> assert(CONV_VMINFO_MASK == right_n_bits(BitsPerBte), "else change type of following load"); >> __ ldub(conversion_field_addr.plus_disp(BytesPerInt - 1), reg); >> } > > Good. > >> >>> >>> Could you move following verification code under first condition?: >>> >>> + if (collect_count_constant>= 0) { >>> + collect_count = collect_count_constant; >>> + } else { >>> + __ load_method_handle_vmslots(O1_collect_count, G3_method_handle, O2_scratch); >>> + collect_count = O1_collect_count; >>> + } >>> + #ifdef ASSERT >>> + if (VerifyMethodHandles&& collect_count_constant>= 0) { >>> + BLOCK_COMMENT("verify collect_count_constant {"); >>> + __ load_method_handle_vmslots(O3_scratch, G3_method_handle, O2_scratch); >>> >>> The same for dest_slot_constant verification. >> >> I can join them but I think I might swap the conditions. > > Swap is fine. Fixed. tom > > Thanks, > Vladimir > >> >> tom >> >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7045514 >>>> 2389 lines changed: 1833 ins; 363 del; 193 mod; 46455 unchg >>>> 7045514: SPARC assembly code for JSR 292 ricochet frames >>>> Reviewed-by: >>>> This is the complete support for Ricochet frames on sparc. Christian >>>> did all the work and testing and I just did some final testing and bug >>>> fixing. >>>> A potential issue with checkcasts reusing locals in >>>> methodHandleWalk.cpp was fixed. Comments weren't being transferred >>>> onto the MethodHandlesAdapterBlob. A derived oop issue was found >>>> where an assert was complaining that an offset was too large but >>>> there's no real restriction on the offset of derived oops so I >>>> disabled the assert. ResourceMarks were added in verification logic. >>>> A verify_vmargslot call was verifying against the wrong signature >>>> resulting in occasional incorrect exceptions. I updated the >>>> MacroAssembler::debug assertion messages to include the passed in >>>> message. Many of blob declarations were moved into shared code so >>>> that we don't have to replicate code. Some x86 method handles code >>>> was changed to make signatures match. >>>> Currently it passes all the jdk regression tests on sparc but I can't >>>> run any of the others because of version mismatches between the JDK >>>> and the tests. Earlier versions ran those as well they had >>>> previously. I also ran the jruby tests and those seemed clean as well. >> From tom.rodriguez at oracle.com Thu Jun 2 11:52:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 2 Jun 2011 11:52:57 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames In-Reply-To: References: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> <4DE6E42B.1030707@oracle.com> Message-ID: <74AA4136-E2DE-4205-B5E5-E18A906C22AE@oracle.com> > >> >> MethodHandles::verify_stack_move() has commented code. Should UNREASONABLE_STACK_MOVE depends on LP64? > > I'm going to rework this. We seem to need a larger slop on sparc though I'm not totally clear why. I think it's because of the register save area but I'm not sure. I increased it to 31 which allows RicochetTest to pass with max arity 255. tom > >> >> Could you move following verification code under first condition?: >> >> + if (collect_count_constant >= 0) { >> + collect_count = collect_count_constant; >> + } else { >> + __ load_method_handle_vmslots(O1_collect_count, G3_method_handle, O2_scratch); >> + collect_count = O1_collect_count; >> + } >> + #ifdef ASSERT >> + if (VerifyMethodHandles && collect_count_constant >= 0) { >> + BLOCK_COMMENT("verify collect_count_constant {"); >> + __ load_method_handle_vmslots(O3_scratch, G3_method_handle, O2_scratch); >> >> The same for dest_slot_constant verification. > > I can join them but I think I might swap the conditions. > > tom > >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7045514 >>> 2389 lines changed: 1833 ins; 363 del; 193 mod; 46455 unchg >>> 7045514: SPARC assembly code for JSR 292 ricochet frames >>> Reviewed-by: >>> This is the complete support for Ricochet frames on sparc. Christian >>> did all the work and testing and I just did some final testing and bug >>> fixing. >>> A potential issue with checkcasts reusing locals in >>> methodHandleWalk.cpp was fixed. Comments weren't being transferred >>> onto the MethodHandlesAdapterBlob. A derived oop issue was found >>> where an assert was complaining that an offset was too large but >>> there's no real restriction on the offset of derived oops so I >>> disabled the assert. ResourceMarks were added in verification logic. >>> A verify_vmargslot call was verifying against the wrong signature >>> resulting in occasional incorrect exceptions. I updated the >>> MacroAssembler::debug assertion messages to include the passed in >>> message. Many of blob declarations were moved into shared code so >>> that we don't have to replicate code. Some x86 method handles code >>> was changed to make signatures match. >>> Currently it passes all the jdk regression tests on sparc but I can't >>> run any of the others because of version mismatches between the JDK >>> and the tests. Earlier versions ran those as well they had >>> previously. I also ran the jruby tests and those seemed clean as well. > From tom.rodriguez at oracle.com Thu Jun 2 12:21:50 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 2 Jun 2011 12:21:50 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames In-Reply-To: References: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> Message-ID: On Jun 1, 2011, at 7:58 PM, John Rose wrote: > On Jun 1, 2011, at 2:38 PM, Tom Rodriguez wrote: > >> 7045514: SPARC assembly code for JSR 292 ricochet frames > > --- methodHandles_sparc.hpp > > Looks good. > > --- methodHandles_sparc.cpp > // Gargs points to the first word so adjust by BytesPerWord > Heavy sigh. IMO, that off-by-one design is a plague on our source base. > (Also, later: __ add(FP, STACK_BIAS - (1 * Interpreter::stackElementSize), Gargs)) Yes, it's ugly. > > This expression assumes a tricky relation (including an exp2(1+log2(n))) between the two constants: > (offset + 1*BytesPerWord) & ~TwoWordAlignmentMask > > I would prefer simply: > round_to(offset, TwoWordAlignmentMask+1 /*or whatever*/) Fixed. > > There's also a __ round_to(reg, mod) to use on the other branch. Could be a __ round_down also. I'd prefer not to futz with that now. It's too easy to get wrong. > > (Nice factorization of the tricky bits in adjust_SP_and_Gargs_down_by_slots etc.) > > Is it worth testing that the incoming value to adjust_... is always >= 0? Added. > > Does this indicate a bug on amd64? > - int slot_size = (arg_size > wordSize) ? arg_size : wordSize; > + int slot_size = is_subword_type(type) ? type2aelembytes(T_INT) : arg_size; // store int sub-words as int > > Or is it just a big-endian thing? If it's an amd64 bug let's fix it. I didn't write that so I'm not sure but it looks like an endianness issue. > > This line makes me uneasy: > + __ store_sized_value(O0, return_slot, type_size); > > The return_slot is the address of a "hole" in the stacked argument list. It's going to get passed to the final target of the RF. > So whatever gets stored into it will be all the information in the stack slot for that argument. > I think what you wrote works only because there was a "42" in the hole already. If there is garbage, and you store a byte on top, you get a partly garbage value. Again, I don't know why it was written that way. It seems like it should be using type2alembytes(T_INT). I've adjusted it. > > I like this; can we have it on the x86 side too? > + BLOCK_COMMENT(err_msg("Begin %s", entry_name(ek))); > + BLOCK_COMMENT(err_msg("End %s", entry_name(ek))); Ok. I'll use { and } instead of begin end like the other messages too. BLOCK_COMMENT(err_msg("Entry %s {", entry_name(ek))); BLOCK_COMMENT(err_msg("} Entry %s", entry_name(ek))); > > Did you consider making the temp argument to argument_address be mandatory? > It seems tricky that it can kill its input. Yes I found that a bit confusing to understand. I'll make it explicit. > > This seems like you don't need it: > + // reload from rdx_argslot_limit since rax_argslot is now decremented > + __ ld_ptr(Address(O2_argslot_limit, -Interpreter::stackElementSize), O1_array); > > The reload is on the x86 side because of the scarcity of registers. The previous line appear to use O1 as a temp: insert_arg_slots(_masm, O3_stack_move, O0_argslot, O4_scratch, G5_scratch, O1_scratch); // reload from rdx_argslot_limit since rax_argslot is now decremented __ ld_ptr(Address(O2_argslot_limit, -Interpreter::stackElementSize), O1_array); > > Reviewed. Thanks! tom > > -- John From tom.rodriguez at oracle.com Thu Jun 2 12:40:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 2 Jun 2011 12:40:32 -0700 Subject: review for 7050554: JSR 292 - need optimization for selectAlternative In-Reply-To: <4DE6D2B1.6080506@oracle.com> References: <6D1B1115-527E-4EE0-B28A-0A5DC745AAF0@oracle.com> <4DE6CD75.4060407@oracle.com> <4DE6D2B1.6080506@oracle.com> Message-ID: Thanks Vladimir and John. tom On Jun 1, 2011, at 5:00 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Jun 1, 2011, at 4:38 PM, Vladimir Kozlov wrote: >>> What about when only one call site could be inlined in bimorhphic case? >> I considered allowing only one to be inlined but that doesn't really seem to occur. Since these are method handle chains they should all be constants and each side is method handle and we will pretty much always inline them once we start a chain. This is really about getting back performance that we lost because of JDK changes more than attempting to do the most optimal thing. We'll revisit the inlining optimizations after 7 ships. >> tom >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7050554 >>>> 130 lines changed: 74 ins; 20 del; 36 mod; 4493 unchg >>>> 7050554: JSR 292 - need optimization for selectAlternative >>>> Reviewed-by: >>>> JSR 292 provides a GuardWithTest idiom is allow selection between two >>>> different method handles based on a boolean test. In earlier versions >>>> of the JDK code this was done with a bunch of little wrapper methods >>>> for different arities. This resulted in a call site for a each call >>>> which allowed existing constant folding code to statically bind the >>>> call sites. Because this didn't scale it was replaced with a new >>>> idiom that looks more like (test ? a : b).invoke() which only have a >>>> single call site. This interferes with inlining making the code >>>> perform terribly. We need a new bimorhphic inline for invokedynamic >>>> callsites to deal with this. Without it performance of invokedynamic >>>> for things like jruby is pretty terrible. Tested with regression >>>> tests and jruby tests. >>>> I also fixed a problem in the shared print compilation code where >>>> attempting to print zombie for an unloaded nmethod causes a segv >>>> because the method is NULL. From tom.rodriguez at oracle.com Thu Jun 2 16:24:52 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 2 Jun 2011 16:24:52 -0700 Subject: Request for reviews (S): 7044738: Loop unroll optimization causes incorrect result In-Reply-To: <4DE698DA.80101@oracle.com> References: <4DE698DA.80101@oracle.com> Message-ID: Looks good. tom On Jun 1, 2011, at 12:54 PM, Vladimir Kozlov wrote: > For next release, too risky for jdk7. > > http://cr.openjdk.java.net/~kvn/7044738/webrev > > Fixed 7044738: Loop unroll optimization causes incorrect result > > It is rare case when OSR compilation is done for nested loop which prevents ciTypeFlow to clone loop's head. As result the control node of loop's nodes is loop's back control. During loop iterations split clone_up_backedge_goo() creates clones for nodes which are pinned to loop's back control and it does not take into account memory dependencies by creating duplicated clones. > > Added regression test. Tested with full CTW. From vladimir.kozlov at oracle.com Thu Jun 2 16:44:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Jun 2011 16:44:02 -0700 Subject: Request for reviews (S): 7044738: Loop unroll optimization causes incorrect result In-Reply-To: References: <4DE698DA.80101@oracle.com> Message-ID: <4DE82042.70902@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Jun 1, 2011, at 12:54 PM, Vladimir Kozlov wrote: > >> For next release, too risky for jdk7. >> >> http://cr.openjdk.java.net/~kvn/7044738/webrev >> >> Fixed 7044738: Loop unroll optimization causes incorrect result >> >> It is rare case when OSR compilation is done for nested loop which prevents ciTypeFlow to clone loop's head. As result the control node of loop's nodes is loop's back control. During loop iterations split clone_up_backedge_goo() creates clones for nodes which are pinned to loop's back control and it does not take into account memory dependencies by creating duplicated clones. >> >> Added regression test. Tested with full CTW. > From tom.rodriguez at oracle.com Thu Jun 2 18:02:12 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 03 Jun 2011 01:02:12 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7050554: JSR 292 - need optimization for selectAlternative Message-ID: <20110603010217.921AD47B28@hg.openjdk.java.net> Changeset: f918d6096e23 Author: never Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f918d6096e23 7050554: JSR 292 - need optimization for selectAlternative Reviewed-by: kvn, jrose ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp From vladimir.kozlov at oracle.com Thu Jun 2 19:25:25 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Jun 2011 19:25:25 -0700 Subject: Request for reviews (S): 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity Message-ID: <4DE84615.4000604@oracle.com> http://cr.openjdk.java.net/~kvn/7050280/webrev Fixed 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity Marking locks for elimination is done in IGVN. Unfortunately the order of IGVN worklist processing may affect this marking. Also during EA obj may point to several objects but after few ideal graph transformations (CCP) it may point to only one non escaping object (but still using phi), corresponding locks and unlocks will be marked for elimination. Later obj could be replaced with a new node (new phi) and will be no escape information about it. And later after some graph reshape other locks and unlocks (which were not marked for elimination before) are connected to this new obj but they still will not be marked for elimination since new obj has no escape information. Fix: Do first round of locks marking during EA after ConnectionGraph is constructed when all nodes have escape information. During Macro nodes expansion move creation of new eliminated BoxLock into new separate method which is called before locks elimination. Use this method to mark all associated (same box and obj) lock and unlock nodes which were not marked before (instead of the assert). Tested with failing case and full CTW. From john.r.rose at oracle.com Fri Jun 3 00:48:23 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 3 Jun 2011 00:48:23 -0700 Subject: review request (URGENT): 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated Message-ID: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> http://cr.openjdk.java.net/~jrose/7051206 This is a changed method name (and inverted sense), replacing SwitchPoint.isValid. Here's the updated javadoc: hasBeenInvalidated public boolean hasBeenInvalidated() Determines if this switch point has been invalidated yet. Discussion: Because of the one-way nature of invalidation, once a switch point begins to return true for hasBeenInvalidated, it will always do so in the future. On the other hand, a valid switch point visible to other threads may invalidated at any moment, due to a request by another thread. Since invalidation is a global and immediate operation, the execution of this query, on a valid switchpoint, must be internally sequenced with any other threads that could cause invalidation. This query may therefore be expensive. The recommended way to build a boolean-valued method handle which queries the invalidation state of a switch point s is to call s.guardWithTest on constant true and false method handles. Returns: true if this switch point has been invalidated -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110603/ee02ca7c/attachment-0001.html From headius at headius.com Fri Jun 3 09:04:05 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 3 Jun 2011 11:04:05 -0500 Subject: review request (URGENT): 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated In-Reply-To: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> References: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> Message-ID: On Fri, Jun 3, 2011 at 2:48 AM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7051206 > This is a changed method name (and inverted sense), replacing > SwitchPoint.isValid. ?Here's the updated javadoc: > > hasBeenInvalidated > > public?boolean?hasBeenInvalidated() A side effect of this is that it's no longer a valid JavaBean name and won't be recognized by bean-aware setups. It's an entirely unimportant point, though. > Determines if this switch point has been invalidated yet. > > Discussion:?Because of the one-way nature of invalidation, once a switch > point begins to return true for?hasBeenInvalidated, it will always do so in > the future. On the other hand, a valid switch point visible to other threads > may invalidated at any moment, due to a request by another thread. > > Since invalidation is a global and immediate operation, the execution of > this query, on a valid switchpoint, must be internally sequenced with any > other threads that could cause invalidation. This query may therefore be > expensive. The recommended way to build a boolean-valued method handle which > queries the invalidation state of a switch point?s?is to > call?s.guardWithTest?on?constant?true and false method handles. If this is the recommended way and it's not expensive, why doesn't hasBeenInvalidated simply do this under the covers and avoid the drama? I'm confused why one way is expensive and the other is not, when they produce the same result with the same threading effects and the same instability/stability of true/false results. - Charlie From vladimir.kozlov at oracle.com Fri Jun 3 09:20:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Jun 2011 09:20:02 -0700 Subject: review request (URGENT): 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated In-Reply-To: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> References: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> Message-ID: <4DE909B2.30907@oracle.com> Looks good to me. Vladimir John Rose wrote: > http://cr.openjdk.java.net/~jrose/7051206 > > This is a changed method name (and inverted sense), replacing > SwitchPoint.isValid. Here's the updated javadoc: > > > hasBeenInvalidated > > public boolean hasBeenInvalidated() > > Determines if this switch point has been invalidated yet. > > /Discussion:/ Because of the one-way nature of invalidation, once a > switch point begins to return true for |hasBeenInvalidated|, it will > always do so in the future. On the other hand, a valid switch point > visible to other threads may invalidated at any moment, due to a request > by another thread. > > Since invalidation is a global and immediate operation, the execution of > this query, on a valid switchpoint, must be internally sequenced with > any other threads that could cause invalidation. This query may > therefore be expensive. The recommended way to build a boolean-valued > method handle which queries the invalidation state of a switch > point |s| is to call |s.guardWithTest| on |constant| > true > and false method handles. > > Returns: > true if this switch point has been invalidated > > From tom.rodriguez at oracle.com Fri Jun 3 09:41:18 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 3 Jun 2011 09:41:18 -0700 Subject: review request (URGENT): 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated In-Reply-To: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> References: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> Message-ID: Looks good. tom On Jun 3, 2011, at 12:48 AM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7051206 > > This is a changed method name (and inverted sense), replacing SwitchPoint.isValid. Here's the updated javadoc: > > hasBeenInvalidated > public boolean hasBeenInvalidated() > Determines if this switch point has been invalidated yet. > Discussion: Because of the one-way nature of invalidation, once a switch point begins to return true for hasBeenInvalidated, it will always do so in the future. On the other hand, a valid switch point visible to other threads may invalidated at any moment, due to a request by another thread. > > Since invalidation is a global and immediate operation, the execution of this query, on a valid switchpoint, must be internally sequenced with any other threads that could cause invalidation. This query may therefore be expensive. The recommended way to build a boolean-valued method handle which queries the invalidation state of a switch point s is to call s.guardWithTest on constant true and false method handles. > > Returns: > true if this switch point has been invalidated > From y.s.ramakrishna at oracle.com Fri Jun 3 10:22:52 2011 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Fri, 03 Jun 2011 10:22:52 -0700 Subject: review request (URGENT): 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated In-Reply-To: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> References: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> Message-ID: <4DE9186C.1040607@oracle.com> Looks good. Thanks for caring for the unwary user (which i unwittingly represented when i previously pointed out the admittedly somewhat subjective naturalness of the stable negative sense compared with the unstable positive sense). -- ramki On 6/3/2011 12:48 AM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7051206 > > This is a changed method name (and inverted sense), replacing SwitchPoint.isValid. Here's the updated javadoc: > > hasBeenInvalidated > public boolean hasBeenInvalidated() > Determines if this switch point has been invalidated yet. > Discussion: Because of the one-way nature of invalidation, once a switch point begins to return true for hasBeenInvalidated, it will always do so in the future. On the other hand, a valid switch point visible to other threads may invalidated at any moment, due to a request by another thread. > > Since invalidation is a global and immediate operation, the execution of this query, on a valid switchpoint, must be internally sequenced with any other threads that could cause invalidation. This query may therefore be expensive. The recommended way to build a boolean-valued method handle which queries the invalidation state of a switch point s is to call s.guardWithTest on constant true and false method handles. > > Returns: > true if this switch point has been invalidated > > > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From john.r.rose at oracle.com Fri Jun 3 10:29:29 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 3 Jun 2011 10:29:29 -0700 Subject: review request (URGENT): 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated In-Reply-To: <4DE9186C.1040607@oracle.com> References: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> <4DE9186C.1040607@oracle.com> Message-ID: On Jun 3, 2011, at 10:22 AM, Y. Srinivas Ramakrishna wrote: > Looks good. Thanks for caring for the unwary user (which i unwittingly > represented when i previously pointed out the admittedly somewhat > subjective naturalness of the stable negative sense compared with > the unstable positive sense). Yes! You get some of the credit for setting up the sense of urgency about the name. Charlie: By using the nonstandard name, we hope to make it harder to access the name casually. This applies to beans too. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110603/675dfecb/attachment.html From john.r.rose at oracle.com Fri Jun 3 11:02:37 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 3 Jun 2011 11:02:37 -0700 Subject: review request (URGENT): 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated In-Reply-To: References: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> Message-ID: On Jun 3, 2011, at 9:04 AM, Charles Oliver Nutter wrote: > If this is the recommended way and it's not expensive, why doesn't > hasBeenInvalidated simply do this under the covers and avoid the > drama? I'm confused why one way is expensive and the other is not, > when they produce the same result with the same threading effects and > the same instability/stability of true/false results. Actually, both are potentially expensive. It's not likely that hasBeenInvalidated (on a valid SP) will be cheaper than creating throwaway a gWT node and calling it. To build a SP.gWT node, the JVM potentially has to register it somewhere (depending on what the SP state is and how underlying safepointing stuff works). We think it's better to emphasize the node creation at the surface of the API. The mistake we are trying to guide users away from is using bit1 instead of bit2: SwitchPoint sp = ...; MethodHandle bit1 = sp.bindTo(#hasBeenInvalidated); MethodHandle bit2 = sp.guardWithTest(constant(boolean.class, false), constant(boolean.class, true)) Note that bit1 is likely (in simple implementations) to create a throwaway node on every use, while bit2 creates a reusable node for all uses. -- John From john.r.rose at oracle.com Fri Jun 3 11:03:23 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 3 Jun 2011 11:03:23 -0700 Subject: review request (URGENT): 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated In-Reply-To: References: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> <4DE9186C.1040607@oracle.com> Message-ID: <14AF125A-B4F5-4B74-BB2C-1F50A34486EE@oracle.com> And, thanks for the code review, Ramki, Vladimir, and Tom. -- John From john.r.rose at oracle.com Fri Jun 3 11:54:53 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 03 Jun 2011 18:54:53 +0000 Subject: hg: hsx/hotspot-comp/jdk: 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated Message-ID: <20110603185523.5993947B63@hg.openjdk.java.net> Changeset: 802994506203 Author: jrose Date: 2011-06-03 11:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/802994506203 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated Reviewed-by: kvn, never, ysr ! src/share/classes/java/lang/invoke/SwitchPoint.java ! test/java/lang/invoke/JavaDocExamplesTest.java From igor.veresov at oracle.com Fri Jun 3 13:53:37 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 03 Jun 2011 13:53:37 -0700 Subject: Request for reviews (S): 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity In-Reply-To: <4DE84615.4000604@oracle.com> References: <4DE84615.4000604@oracle.com> Message-ID: <4DE949D1.5060108@oracle.com> This seems ok. igor On 6/2/11 7:25 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7050280/webrev > > Fixed 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity > > Marking locks for elimination is done in IGVN. Unfortunately the order > of IGVN worklist processing may affect this marking. Also during EA obj > may point to several objects but after few ideal graph transformations > (CCP) it may point to only one non escaping object (but still using > phi), corresponding locks and unlocks will be marked for elimination. > Later obj could be replaced with a new node (new phi) and will be no > escape information about it. And later after some graph reshape other > locks and unlocks (which were not marked for elimination before) are > connected to this new obj but they still will not be marked for > elimination since new obj has no escape information. > > Fix: > Do first round of locks marking during EA after ConnectionGraph is > constructed when all nodes have escape information. During Macro nodes > expansion move creation of new eliminated BoxLock into new separate > method which is called before locks elimination. Use this method to mark > all associated (same box and obj) lock and unlock nodes which were not > marked before (instead of the assert). > > Tested with failing case and full CTW. From vladimir.kozlov at oracle.com Fri Jun 3 14:27:43 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Jun 2011 14:27:43 -0700 Subject: Request for reviews (S): 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity In-Reply-To: <4DE949D1.5060108@oracle.com> References: <4DE84615.4000604@oracle.com> <4DE949D1.5060108@oracle.com> Message-ID: <4DE951CF.3020602@oracle.com> Thank you, Igor Vladimir Igor Veresov wrote: > This seems ok. > > igor > > On 6/2/11 7:25 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7050280/webrev >> >> Fixed 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity >> >> Marking locks for elimination is done in IGVN. Unfortunately the order >> of IGVN worklist processing may affect this marking. Also during EA obj >> may point to several objects but after few ideal graph transformations >> (CCP) it may point to only one non escaping object (but still using >> phi), corresponding locks and unlocks will be marked for elimination. >> Later obj could be replaced with a new node (new phi) and will be no >> escape information about it. And later after some graph reshape other >> locks and unlocks (which were not marked for elimination before) are >> connected to this new obj but they still will not be marked for >> elimination since new obj has no escape information. >> >> Fix: >> Do first round of locks marking during EA after ConnectionGraph is >> constructed when all nodes have escape information. During Macro nodes >> expansion move creation of new eliminated BoxLock into new separate >> method which is called before locks elimination. Use this method to mark >> all associated (same box and obj) lock and unlock nodes which were not >> marked before (instead of the assert). >> >> Tested with failing case and full CTW. > From John.Coomes at oracle.com Fri Jun 3 14:47:43 2011 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 3 Jun 2011 14:47:43 -0700 Subject: review request (URGENT): 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated In-Reply-To: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> References: <55A120CC-471E-4C46-9111-873A6951D0F5@oracle.com> Message-ID: <19945.22143.780816.941996@oracle.com> John Rose (john.r.rose at oracle.com) wrote: > http://cr.openjdk.java.net/~jrose/7051206 > > This is a changed method name (and inverted sense), replacing SwitchPoint.isValid. Here's the updated javadoc: > > hasBeenInvalidated > public boolean hasBeenInvalidated() > Determines if this switch point has been invalidated yet. > Discussion: Because of the one-way nature of invalidation, once a > switch point begins to return true for hasBeenInvalidated, it will > always do so in the future. On the other hand, a valid switch point > visible to other threads may invalidated at any moment, due to a ^^^ insert "be" > request by another thread. > ... Aside from the trivial typo above, looks good to me. -John From tom.rodriguez at oracle.com Fri Jun 3 14:56:10 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 3 Jun 2011 14:56:10 -0700 Subject: Request for reviews (S): 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity In-Reply-To: <4DE84615.4000604@oracle.com> References: <4DE84615.4000604@oracle.com> Message-ID: <56722E10-EA56-4687-9540-30E354CB4B65@oracle.com> Looks good. tom On Jun 2, 2011, at 7:25 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7050280/webrev > > Fixed 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity > > Marking locks for elimination is done in IGVN. Unfortunately the order of IGVN worklist processing may affect this marking. Also during EA obj may point to several objects but after few ideal graph transformations (CCP) it may point to only one non escaping object (but still using phi), corresponding locks and unlocks will be marked for elimination. Later obj could be replaced with a new node (new phi) and will be no escape information about it. And later after some graph reshape other locks and unlocks (which were not marked for elimination before) are connected to this new obj but they still will not be marked for elimination since new obj has no escape information. > > Fix: > Do first round of locks marking during EA after ConnectionGraph is constructed when all nodes have escape information. During Macro nodes expansion move creation of new eliminated BoxLock into new separate method which is called before locks elimination. Use this method to mark all associated (same box and obj) lock and unlock nodes which were not marked before (instead of the assert). > > Tested with failing case and full CTW. From vladimir.kozlov at oracle.com Fri Jun 3 14:56:24 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Jun 2011 14:56:24 -0700 Subject: Request for reviews (S): 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity In-Reply-To: <56722E10-EA56-4687-9540-30E354CB4B65@oracle.com> References: <4DE84615.4000604@oracle.com> <56722E10-EA56-4687-9540-30E354CB4B65@oracle.com> Message-ID: <4DE95888.9080809@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Jun 2, 2011, at 7:25 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7050280/webrev >> >> Fixed 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity >> >> Marking locks for elimination is done in IGVN. Unfortunately the order of IGVN worklist processing may affect this marking. Also during EA obj may point to several objects but after few ideal graph transformations (CCP) it may point to only one non escaping object (but still using phi), corresponding locks and unlocks will be marked for elimination. Later obj could be replaced with a new node (new phi) and will be no escape information about it. And later after some graph reshape other locks and unlocks (which were not marked for elimination before) are connected to this new obj but they still will not be marked for elimination since new obj has no escape information. >> >> Fix: >> Do first round of locks marking during EA after ConnectionGraph is constructed when all nodes have escape information. During Macro nodes expansion move creation of new eliminated BoxLock into new separate method which is called before locks elimination. Use this method to mark all associated (same box and obj) lock and unlock nodes which were not marked before (instead of the assert). >> >> Tested with failing case and full CTW. > From tom.rodriguez at oracle.com Sat Jun 4 01:56:19 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 04 Jun 2011 08:56:19 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7045514: SPARC assembly code for JSR 292 ricochet frames Message-ID: <20110604085622.680A447B9F@hg.openjdk.java.net> Changeset: cba7b5c2d53f Author: never Date: 2011-06-03 22:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cba7b5c2d53f 7045514: SPARC assembly code for JSR 292 ricochet frames Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp + src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/registerMap_sparc.hpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp From vladimir.kozlov at oracle.com Sat Jun 4 12:41:33 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 04 Jun 2011 19:41:33 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity Message-ID: <20110604194137.5A67B47BBE@hg.openjdk.java.net> Changeset: 642c68c75db9 Author: kvn Date: 2011-06-04 10:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/642c68c75db9 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity Summary: Mark all associated (same box and obj) lock and unlock nodes for elimination if some of them marked already. Reviewed-by: iveresov, never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp From christian.thalinger at oracle.com Sun Jun 5 09:56:36 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Sun, 5 Jun 2011 09:56:36 -0700 Subject: review for 7045514: SPARC assembly code for JSR 292 ricochet frames In-Reply-To: References: <690DD6EF-6B7A-4C86-8A70-FF234CE888EF@oracle.com> Message-ID: On Jun 2, 2011, at 12:21 PM, Tom Rodriguez wrote: >> Does this indicate a bug on amd64? >> - int slot_size = (arg_size > wordSize) ? arg_size : wordSize; >> + int slot_size = is_subword_type(type) ? type2aelembytes(T_INT) : arg_size; // store int sub-words as int >> >> Or is it just a big-endian thing? If it's an amd64 bug let's fix it. > > I didn't write that so I'm not sure but it looks like an endianness issue. Yes, that's an endian issue. > >> >> This line makes me uneasy: >> + __ store_sized_value(O0, return_slot, type_size); >> >> The return_slot is the address of a "hole" in the stacked argument list. It's going to get passed to the final target of the RF. >> So whatever gets stored into it will be all the information in the stack slot for that argument. >> I think what you wrote works only because there was a "42" in the hole already. If there is garbage, and you store a byte on top, you get a partly garbage value. > > Again, I don't know why it was written that way. It seems like it should be using type2alembytes(T_INT). I've adjusted it. Not sure about that one, I need to look at it again. But type2alembytes(T_INT) sounds reasonable. >> This seems like you don't need it: >> + // reload from rdx_argslot_limit since rax_argslot is now decremented >> + __ ld_ptr(Address(O2_argslot_limit, -Interpreter::stackElementSize), O1_array); >> >> The reload is on the x86 side because of the scarcity of registers. > > The previous line appear to use O1 as a temp: > > insert_arg_slots(_masm, O3_stack_move, > O0_argslot, O4_scratch, G5_scratch, O1_scratch); > // reload from rdx_argslot_limit since rax_argslot is now decremented > __ ld_ptr(Address(O2_argslot_limit, -Interpreter::stackElementSize), O1_array); Right. I tried to get away without the reload but it didn't work out. Thanks Tom for fixing the remaining problems and pushing it. Thanks John and Vladimir for the reviews. -- Christian From peter.hofer at jku.at Mon Jun 6 09:31:57 2011 From: peter.hofer at jku.at (Peter Hofer) Date: Mon, 6 Jun 2011 18:31:57 +0200 Subject: IdealGraphVisualizer In-Reply-To: References: <7930257e-c9a1-4925-a7ca-24e976296fc5@default> <995C4FE8-BB84-4F5F-AD4C-B94AC2253FB3@oracle.com> <39A4CEF1-5AA1-4DBD-9E72-3144C57BF4AA@oracle.com> Message-ID: <20110606183157.3148b3c6@sunflower> Hello Tom and Mikael, I have indeed ported the IdealGraphVisualizer to NetBeans 7.0. You can download a source package from here (approx. 500 KB): http://ssw.jku.at/General/Staff/PH/igv_netbeans70.zip This is based on the IGV from the HotSpot tree and other than NetBeans 7 support only includes a minor (non-breaking) extension to the file format. > Is this based on the improved kenai version? The text view in that > is nice but there seem to be some interaction bugs that result in > exceptions in the event thread that screw up the display. Thomas and I decided today that we'll use the IGV code base from Kenai for further development. -- Peter From john.r.rose at oracle.com Wed Jun 8 03:49:16 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Jun 2011 03:49:16 -0700 Subject: review request (URGENT): 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp Message-ID: 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp http://cr.openjdk.java.net/~jrose/7047697/webrev.00/ The bug is that if a method handle stub must raise an error condition, and the method handle stub was called directly from compiled code, the transition from the compiled frame to the VM fails, because the existing code assumes that the call comes from an interpreter frame. This bug shows up most reliably when run with "-client" and "-Xcomp". Otherwise, it is sporadic. When this bug is removed, another bug appears behind it. There is a missing line of code in one of the constructors of class frame. This causes the compiled frame (containing a method handle call) to be improperly parsed, because the _unextended_sp is not correctly initialized, specifically in the case of a method handle call from compiled code. Details by file: 1. (assembler) The method handle stubs are generated from an InterpreterMacroAssembler. But stubs can be called either from compiled or interpreted callers. If a stub needs to call out to the JVM, it has to use the call_VM macro. This macro should be the version from MacroAssembler, which is generic for all kinds of callers. 2. (frame) One of the x86 constructors for class frame failed to adjust the _unextended_sp field. Add the subroutine which does this to the affected constructor. (All others do.) This constructor happens to be used for creating the caller of an entry_frame (used to represent a Java-to-VM call). 3. (methodHandles) When raising a WrongMethodTypeException directly from a method handle stub, do so directly using call_VM. Do not use an interpreter stub. (See #1 above.) 4. (pcDesc) When printing a PcDesc, print its tag bits. (Used for investigating this bug.) From bertrand.delsart at oracle.com Wed Jun 8 04:45:22 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 08 Jun 2011 13:45:22 +0200 Subject: review request (URGENT): 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp In-Reply-To: References: Message-ID: <4DEF60D2.7020803@oracle.com> Hi John, Looks OK... but I'm concerned for ARM. This fix involves fixes in x86 code, which is mirrored in ARM. Hence, even if the QA has not yet filed the bug for ARM, I expect we have the same issue (my understanding is that this also applies to C1). I've seen on the CR comments that this is might have caused JCK failures. Do you confirm that it lead to JCK failures, which we may be forced to solve for ARM ? Bertrand. On 06/ 8/11 12:49 PM, John Rose wrote: > 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp > http://cr.openjdk.java.net/~jrose/7047697/webrev.00/ > > The bug is that if a method handle stub must raise an error condition, and the method handle stub was called directly from compiled code, the transition from the compiled frame to the VM fails, because the existing code assumes that the call comes from an interpreter frame. > > This bug shows up most reliably when run with "-client" and "-Xcomp". Otherwise, it is sporadic. > > When this bug is removed, another bug appears behind it. There is a missing line of code in one of the constructors of class frame. This causes the compiled frame (containing a method handle call) to be improperly parsed, because the _unextended_sp is not correctly initialized, specifically in the case of a method handle call from compiled code. > > Details by file: > > 1. (assembler) The method handle stubs are generated from an InterpreterMacroAssembler. But stubs can be called either from compiled or interpreted callers. If a stub needs to call out to the JVM, it has to use the call_VM macro. This macro should be the version from MacroAssembler, which is generic for all kinds of callers. > > 2. (frame) One of the x86 constructors for class frame failed to adjust the _unextended_sp field. Add the subroutine which does this to the affected constructor. (All others do.) This constructor happens to be used for creating the caller of an entry_frame (used to represent a Java-to-VM call). > > 3. (methodHandles) When raising a WrongMethodTypeException directly from a method handle stub, do so directly using call_VM. Do not use an interpreter stub. (See #1 above.) > > 4. (pcDesc) When printing a PcDesc, print its tag bits. (Used for investigating this bug.) > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From tom.rodriguez at oracle.com Wed Jun 8 07:35:10 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 8 Jun 2011 07:35:10 -0700 Subject: review request (URGENT): 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp In-Reply-To: References: Message-ID: <122971D9-89B6-4F6E-9BC4-94486110A549@oracle.com> On Jun 8, 2011, at 3:49 AM, John Rose wrote: > 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp > http://cr.openjdk.java.net/~jrose/7047697/webrev.00/ > > The bug is that if a method handle stub must raise an error condition, and the method handle stub was called directly from compiled code, the transition from the compiled frame to the VM fails, because the existing code assumes that the call comes from an interpreter frame. > > This bug shows up most reliably when run with "-client" and "-Xcomp". Otherwise, it is sporadic. > > When this bug is removed, another bug appears behind it. There is a missing line of code in one of the constructors of class frame. This causes the compiled frame (containing a method handle call) to be improperly parsed, because the _unextended_sp is not correctly initialized, specifically in the case of a method handle call from compiled code. > > Details by file: > > 1. (assembler) The method handle stubs are generated from an InterpreterMacroAssembler. But stubs can be called either from compiled or interpreted callers. If a stub needs to call out to the JVM, it has to use the call_VM macro. This macro should be the version from MacroAssembler, which is generic for all kinds of callers. > > 2. (frame) One of the x86 constructors for class frame failed to adjust the _unextended_sp field. Add the subroutine which does this to the affected constructor. (All others do.) This constructor happens to be used for creating the caller of an entry_frame (used to represent a Java-to-VM call). There another one missing around line 47. Otherwise this looks good. tom > > 3. (methodHandles) When raising a WrongMethodTypeException directly from a method handle stub, do so directly using call_VM. Do not use an interpreter stub. (See #1 above.) > > 4. (pcDesc) When printing a PcDesc, print its tag bits. (Used for investigating this bug.) > From john.r.rose at oracle.com Wed Jun 8 21:27:15 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 09 Jun 2011 04:27:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp Message-ID: <20110609042719.E97BE47D6A@hg.openjdk.java.net> Changeset: 5cf771a79037 Author: jrose Date: 2011-06-08 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5cf771a79037 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp Reviewed-by: never, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/code/pcDesc.cpp From john.coomes at oracle.com Thu Jun 9 20:35:13 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jun 2011 03:35:13 +0000 Subject: hg: jdk7/hotspot-comp: 3 new changesets Message-ID: <20110610033513.63B4747E13@hg.openjdk.java.net> Changeset: 93d2590fd849 Author: jeff Date: 2011-05-27 14:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/93d2590fd849 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 55e9ebf03218 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/55e9ebf03218 Merge Changeset: 2d38c2a79c14 Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/2d38c2a79c14 Added tag jdk7-b145 for changeset 55e9ebf03218 ! .hgtags From john.coomes at oracle.com Thu Jun 9 20:35:23 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jun 2011 03:35:23 +0000 Subject: hg: jdk7/hotspot-comp/corba: 5 new changesets Message-ID: <20110610033529.80E2B47E16@hg.openjdk.java.net> Changeset: 93e77c49b3bb Author: miroslawzn Date: 2011-05-26 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/93e77c49b3bb 7046882: Regression : JDK 7b123 : Enum exchanged as parameters using CORBA call results in Exception Reviewed-by: raginip ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 643f267ca234 Author: jeff Date: 2011-05-27 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/643f267ca234 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 7839048ec99e Author: jeff Date: 2011-05-27 15:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/7839048ec99e Merge Changeset: 77ec0541aa2a Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/77ec0541aa2a Merge Changeset: 770227a4087e Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/770227a4087e Added tag jdk7-b145 for changeset 77ec0541aa2a ! .hgtags From john.coomes at oracle.com Thu Jun 9 20:35:39 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jun 2011 03:35:39 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 5 new changesets Message-ID: <20110610033539.83C2047E19@hg.openjdk.java.net> Changeset: bdf77cbd9958 Author: ohair Date: 2011-05-19 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/bdf77cbd9958 7044493: Incorrectly formated GPL headers in JDK7 JAXP source drop Reviewed-by: joehw ! jaxp.properties Changeset: 775dd77e4730 Author: lana Date: 2011-05-20 21:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/775dd77e4730 Merge Changeset: a70a042c8600 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/a70a042c8600 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 10ca7570f47f Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/10ca7570f47f Merge Changeset: bcd31fa1e3c6 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/bcd31fa1e3c6 Added tag jdk7-b145 for changeset 10ca7570f47f ! .hgtags From john.coomes at oracle.com Thu Jun 9 20:35:49 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jun 2011 03:35:49 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 4 new changesets Message-ID: <20110610033549.306AE47E1C@hg.openjdk.java.net> Changeset: c902e39c384e Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/c902e39c384e 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: bcca8afc019f Author: ohair Date: 2011-06-01 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/bcca8afc019f 7049699: Problem with xml/jax-ws Reviewed-by: ramap ! jaxws.properties Changeset: 42bfba80beb7 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/42bfba80beb7 Merge Changeset: 6ec12c60ad13 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/6ec12c60ad13 Added tag jdk7-b145 for changeset 42bfba80beb7 ! .hgtags From john.coomes at oracle.com Thu Jun 9 20:36:49 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jun 2011 03:36:49 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 42 new changesets Message-ID: <20110610034428.02D3447E2F@hg.openjdk.java.net> Changeset: f09930d526ba Author: jrose Date: 2011-05-26 17:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f09930d526ba 7032323: code changes for JSR 292 EG adjustments to API, through Public Review Summary: API code changes and javadoc changes following JSR 292 Public Review comments, through PFD Reviewed-by: never ! src/share/classes/java/lang/BootstrapMethodError.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/6998541/Test6998541.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/indify/Indify.java Changeset: 81f957f86ba5 Author: jcoomes Date: 2011-05-27 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/81f957f86ba5 Merge Changeset: 8318d03e1766 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8318d03e1766 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Wrap invokedynamic linkage errors in BootstrapMethodError, as needed. Reviewed-by: never ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 0b8b6eace473 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0b8b6eace473 7050328: (jsr-292) findConstructor throws ExceptionInInitializerError if run under SecurityManager Summary: Wrap system property and reflection accesses under doPrivileged. Ensure constant pool linkage bypasses the SM as specified. Reviewed-by: kvn, never ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: 34481a4012c3 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/34481a4012c3 7049122: java/lang/invoke/RicochetTest.java with MAX_ARITY=255 in -Xcomp mode overflows code cache Summary: reduce the scope of the unit test (mark high water mark of testing with @ignore tags) Reviewed-by: never ! test/java/lang/invoke/RicochetTest.java Changeset: 802994506203 Author: jrose Date: 2011-06-03 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/802994506203 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated Reviewed-by: kvn, never, ysr ! src/share/classes/java/lang/invoke/SwitchPoint.java ! test/java/lang/invoke/JavaDocExamplesTest.java Changeset: bc97b962330e Author: mfang Date: 2011-05-26 20:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bc97b962330e 7045184: GTK L&F doesn't have hotkeys in jdk7 b141, while b139 has. Reviewed-by: yhuang, ogino ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties Changeset: 6943c4d9caa3 Author: mfang Date: 2011-05-31 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6943c4d9caa3 Merge Changeset: 7c5bc5a807ee Author: dholmes Date: 2011-05-27 19:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7c5bc5a807ee 7024120: Verify reduced JRE contents for java 7 Summary: stripped all symbols from libs and executables to reduce JRE size. Restored missing classes needed to pass JCK in headless mode Reviewed-by: bobv, ohair ! make/common/Defs-embedded.gmk ! make/common/Release-embedded.gmk Changeset: f4895b3fe1be Author: dholmes Date: 2011-05-31 17:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f4895b3fe1be Merge Changeset: eab27338b3d9 Author: schien Date: 2011-06-01 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eab27338b3d9 Merge Changeset: 8d91855a1f4e Author: prr Date: 2011-05-27 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8d91855a1f4e 7046587: Outlines in OTF/CFF fonts are misclassified as quadratic curves Reviewed-by: igor ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0b0b92707cf5 Author: bae Date: 2011-05-30 12:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0b0b92707cf5 7032904: XRender: Java2Demo : Infinite loop in Java_sun_java2d_loops_MaskBlit_MaskBlit on OEL 5.6 x64 Reviewed-by: prr ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 290daca0a693 Author: prr Date: 2011-05-30 22:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/290daca0a693 7049874: OpenJDK Build breakage fix: freetypescaler.c needs to match updated signature Reviewed-by: lana, igor ! src/share/native/sun/font/freetypeScaler.c Changeset: b351af09bfa3 Author: lana Date: 2011-06-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b351af09bfa3 Merge Changeset: d2081a1f417f Author: bagiras Date: 2011-05-27 11:45 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d2081a1f417f 7045174: Most of the tests in awt area fails with jdk 7b142 on windows with -Xcheck:jni Reviewed-by: art, denis ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 000a845b1e38 Author: denis Date: 2011-05-28 12:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/000a845b1e38 7046325: Broken links in java.awt.Toolkit's javadoc Reviewed-by: dav, yan ! src/share/classes/java/awt/Toolkit.java Changeset: eab94f59b6dc Author: dcherepanov Date: 2011-05-30 13:25 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eab94f59b6dc 7045354: Korean IME's Hanja candidate window is not displayed on IMFDemo Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Component.cpp Changeset: f05164caa490 Author: serb Date: 2011-05-30 17:16 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f05164caa490 7045193: interactive JCK tests java_awt/interactive/FileDialogTests fail Reviewed-by: dcherepanov, dav, art, denis ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: b955226868af Author: lana Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b955226868af Merge Changeset: 1fbaf2b688a6 Author: rupashka Date: 2011-05-24 11:37 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1fbaf2b688a6 7045593: Possible Regression : JTextfield cursor placement behavior algorithm has changed. Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java + test/javax/swing/text/Utilities/bug7045593.java Changeset: 442237d3ec2c Author: rupashka Date: 2011-05-28 11:55 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/442237d3ec2c 7048204: NPE from NimbusLookAndFeel.addDefault Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java + test/javax/swing/plaf/nimbus/Test7048204.java Changeset: 386516fdf40b Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/386516fdf40b Merge Changeset: 0a80650409e1 Author: mullan Date: 2011-05-24 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0a80650409e1 7044443: Permissions resolved incorrectly for jar protocol (Patch from bugs.openjdk.java.net) Reviewed-by: alanb, chegar Contributed-by: dbhole at redhat.com ! src/share/classes/sun/security/provider/PolicyFile.java + test/java/security/Policy/GetPermissions/JarURL.java Changeset: ace2dfdecda1 Author: mullan Date: 2011-05-24 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ace2dfdecda1 Merge Changeset: 70942be348af Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/70942be348af 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: b49a0af85821 Author: vinnie Date: 2011-05-30 16:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b49a0af85821 7049173: Replace the software license for ECC native code Reviewed-by: alanb ! src/share/native/sun/security/ec/impl/ec.c ! src/share/native/sun/security/ec/impl/ec.h ! src/share/native/sun/security/ec/impl/ec2.h ! src/share/native/sun/security/ec/impl/ec2_163.c ! src/share/native/sun/security/ec/impl/ec2_193.c ! src/share/native/sun/security/ec/impl/ec2_233.c ! src/share/native/sun/security/ec/impl/ec2_aff.c ! src/share/native/sun/security/ec/impl/ec2_mont.c ! src/share/native/sun/security/ec/impl/ec_naf.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/ecl-curve.h ! src/share/native/sun/security/ec/impl/ecl-exp.h ! src/share/native/sun/security/ec/impl/ecl-priv.h ! src/share/native/sun/security/ec/impl/ecl.c ! src/share/native/sun/security/ec/impl/ecl.h ! src/share/native/sun/security/ec/impl/ecl_curve.c ! src/share/native/sun/security/ec/impl/ecl_gf.c ! src/share/native/sun/security/ec/impl/ecl_mult.c ! src/share/native/sun/security/ec/impl/ecp.h ! src/share/native/sun/security/ec/impl/ecp_192.c ! src/share/native/sun/security/ec/impl/ecp_224.c ! src/share/native/sun/security/ec/impl/ecp_256.c ! src/share/native/sun/security/ec/impl/ecp_384.c ! src/share/native/sun/security/ec/impl/ecp_521.c ! src/share/native/sun/security/ec/impl/ecp_aff.c ! src/share/native/sun/security/ec/impl/ecp_jac.c ! src/share/native/sun/security/ec/impl/ecp_jm.c ! src/share/native/sun/security/ec/impl/ecp_mont.c ! src/share/native/sun/security/ec/impl/logtab.h ! src/share/native/sun/security/ec/impl/mp_gf2m-priv.h ! src/share/native/sun/security/ec/impl/mp_gf2m.c ! src/share/native/sun/security/ec/impl/mp_gf2m.h ! src/share/native/sun/security/ec/impl/mpi-config.h ! src/share/native/sun/security/ec/impl/mpi-priv.h ! src/share/native/sun/security/ec/impl/mpi.c ! src/share/native/sun/security/ec/impl/mpi.h ! src/share/native/sun/security/ec/impl/mplogic.c ! src/share/native/sun/security/ec/impl/mplogic.h ! src/share/native/sun/security/ec/impl/mpmontg.c ! src/share/native/sun/security/ec/impl/mpprime.h ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/ec/impl/secoidt.h Changeset: 4ed7c877a463 Author: michaelm Date: 2011-05-30 23:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4ed7c877a463 7042550: Reintegrate 6569621 Reviewed-by: chegar, alanb ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java + src/share/classes/sun/net/RegisteredDomain.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/http/HttpClient.java Changeset: c79a089ae13b Author: wetmore Date: 2011-05-31 12:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c79a089ae13b 7042097: JDK 7's Unlimited Cryptographic Policy bundle text files must be updated. Reviewed-by: valeriep ! make/javax/crypto/Makefile Changeset: a00f48c96345 Author: lancea Date: 2011-06-02 12:02 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a00f48c96345 7049107: Cannot call initCause() on BatchUpdateException Reviewed-by: darcy ! src/share/classes/java/sql/BatchUpdateException.java Changeset: 39de8937c1d8 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/39de8937c1d8 Merge Changeset: e8e6cdff5995 Author: trims Date: 2011-06-03 20:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e8e6cdff5995 Merge Changeset: 8f19b165347b Author: bae Date: 2011-06-04 23:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8f19b165347b 7042594: 3 testis api/java_awt/Color/ICC_ProfileRGB/index.html fail against RI b138 OEL6x64. Reviewed-by: prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java + test/sun/java2d/cmm/ProfileOp/SetDataTest.java Changeset: bbb4cef2208b Author: lana Date: 2011-06-04 17:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bbb4cef2208b Merge Changeset: 03a828e368ca Author: rupashka Date: 2011-06-04 01:13 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/03a828e368ca 6977587: GTK L&F: jnlp: java.io.IOException thrown when choosing more than 1 file in the dialog Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java Changeset: 6c9c55ae313b Author: lana Date: 2011-06-03 22:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6c9c55ae313b Merge Changeset: e81d259442ed Author: lana Date: 2011-06-04 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e81d259442ed Merge Changeset: 53d759eb580c Author: alanb Date: 2011-06-04 11:18 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/53d759eb580c 7050358: (fs spec) Path.toUri doesn't allow custom providers to use opaque URIs Reviewed-by: sherman ! src/share/classes/java/nio/file/Path.java Changeset: 49aef5a5416e Author: mullan Date: 2011-06-04 06:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/49aef5a5416e 7050329: test/java/security/Policy/GetPermissions/JarURL.java fails on Windows Reviewed-by: alanb ! test/java/security/Policy/GetPermissions/JarURL.java + test/java/security/Policy/GetPermissions/JarURL.policy Changeset: 1f39ca0b9598 Author: mullan Date: 2011-06-04 06:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1f39ca0b9598 Merge Changeset: 1e04b38b3824 Author: lana Date: 2011-06-04 17:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1e04b38b3824 Merge Changeset: 7a341c412ea9 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7a341c412ea9 Added tag jdk7-b145 for changeset 1e04b38b3824 ! .hgtags From antoine.artaudmacari at free.fr Fri Jun 10 08:52:34 2011 From: antoine.artaudmacari at free.fr (antoine artaud-macari) Date: Fri, 10 Jun 2011 17:52:34 +0200 Subject: Force method compilation in HotSpot JVM Message-ID: Dear HotSpot developers ! We are working on performance optimization for a Java critical system and we would like to force the compilation of some Java methods (chosen by our own algorithm). So we have looked at the OpenJDK HotSpot source code and for time being we succeeded in forcing compilation of these methods but the interpreter still executes the bytecode. For example, we used : nmethod * nm = CompileBroker::compile_method(m, 0, m, 0,"forced > compilation", THREAD); > where m is a methodHandle on the method to be compiled. Would you please send us some technical reference or documentation about compilation process or how compiled method are executed ? Best regards, -- *Antoine ARTAUD-MACARI ** ** * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110610/9d309e4b/attachment-0001.html From igor.veresov at oracle.com Fri Jun 10 09:46:09 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 10 Jun 2011 09:46:09 -0700 Subject: Force method compilation in HotSpot JVM In-Reply-To: References: Message-ID: <4DF24A51.2030304@oracle.com> On 6/10/11 8:52 AM, antoine artaud-macari wrote: > > Dear HotSpot developers ! > > We are working on performance optimization for a Java critical system > and we would like to force the compilation of some Java methods (chosen > by our own algorithm). > So we have looked at the OpenJDK HotSpot source code and for time being > we succeeded in forcing compilation of these methods but the interpreter > still executes the bytecode. > For example, we used : > > nmethod * nm = CompileBroker::compile_method(m, 0, m, 0,"forced > compilation", THREAD); > > where m is a methodHandle on the method to be compiled. > > Would you please send us some technical reference or documentation about > compilation process or how compiled method are executed ? > > For osr_bci parameter you should specify the InvocationEntryBci constant (which is -1). igor > > Best regards, > > -- > *Antoine ARTAUD-MACARI ***** > > > From christian.thalinger at oracle.com Fri Jun 10 10:20:11 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 10 Jun 2011 10:20:11 -0700 Subject: Request for review (XXS): 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops Message-ID: <602090DE-93DE-40B6-BFD0-194DF8F44715@oracle.com> http://cr.openjdk.java.net/~twisti/7053520 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops Reviewed-by: We are trying to decode the address of the CallSite object stored in constant pool cache as if it were an oop but it's a raw pointer which results in crashes. The fix is to replace the load instruction with move_wide. Tested with JRuby tests. src/share/vm/c1/c1_LIRGenerator.cpp From igor.veresov at oracle.com Fri Jun 10 10:56:11 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 10 Jun 2011 10:56:11 -0700 Subject: Request for review (XXS): 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops In-Reply-To: <602090DE-93DE-40B6-BFD0-194DF8F44715@oracle.com> References: <602090DE-93DE-40B6-BFD0-194DF8F44715@oracle.com> Message-ID: <4DF25ABB.2080900@oracle.com> Looks good. igor On 6/10/11 10:20 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7053520 > > 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops > Reviewed-by: > > We are trying to decode the address of the CallSite object stored in > constant pool cache as if it were an oop but it's a raw pointer which > results in crashes. The fix is to replace the load instruction with > move_wide. > > Tested with JRuby tests. > > src/share/vm/c1/c1_LIRGenerator.cpp > From tom.rodriguez at oracle.com Fri Jun 10 15:27:21 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 10 Jun 2011 15:27:21 -0700 Subject: Request for review (XXS): 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops In-Reply-To: <602090DE-93DE-40B6-BFD0-194DF8F44715@oracle.com> References: <602090DE-93DE-40B6-BFD0-194DF8F44715@oracle.com> Message-ID: Looks good. tom On Jun 10, 2011, at 10:20 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7053520 > > 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops > Reviewed-by: > > We are trying to decode the address of the CallSite object stored in > constant pool cache as if it were an oop but it's a raw pointer which > results in crashes. The fix is to replace the load instruction with > move_wide. > > Tested with JRuby tests. > > src/share/vm/c1/c1_LIRGenerator.cpp > From john.coomes at oracle.com Fri Jun 10 17:11:14 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 11 Jun 2011 00:11:14 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 5 new changesets Message-ID: <20110611001130.B13FA47EF5@hg.openjdk.java.net> Changeset: 6bb526ccf5ff Author: mcimadamore Date: 2011-05-23 11:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6bb526ccf5ff 7046348: Regression: javac complains of missing classfile for a seemingly unrelated interface Summary: Types.implementation forces unnecessary symbol completion on superinterfaces of a given type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: 6211df69f7e0 Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6211df69f7e0 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 6762754eb7c0 Author: jjg Date: 2011-06-01 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6762754eb7c0 7042623: Regression: javac silently crash when attributing non-existent annotation Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T7042623.java + test/tools/javac/T7042623.out Changeset: c455e2ae5c93 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c455e2ae5c93 Merge Changeset: 9ff91d0e7154 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/9ff91d0e7154 Added tag jdk7-b145 for changeset c455e2ae5c93 ! .hgtags From rednaxelafx at gmail.com Sun Jun 12 03:59:33 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sun, 12 Jun 2011 18:59:33 +0800 Subject: Force method compilation in HotSpot JVM In-Reply-To: <4DF24A51.2030304@oracle.com> References: <4DF24A51.2030304@oracle.com> Message-ID: Hi Antoine, With the HotSpot server compiler (C2), even if you forced some methods to get compiled, if you haven't let it run in the interpreter for a couple of times before the compilation, you may well get a false sense of compilation due to unloaded classes. When the interpreter runs, it'll load classes on demand, where as when C2 compiles a method, if it sees a point in the method that encounters a class not-yet-loaded or already-unloaded, it'll generate a call to a trampoline that jumps back into the interpreter; that's called an "uncommon trap". There's are some documentation on the HotSpot VM here: http://wikis.sun.com/display/HotSpotInternals But I don't think there's any official documentation that describes the whole compilation process, yet. Parts of it are described in a few papers. "The Java HotSpot Server Compiler"( http://www.usenix.org/events/jvm01/full_papers/paleczny/paleczny.pdf) might be a good starting point; the "2. Runtime Environment" part should have what you want to know. Although it doesn't cover how the tiered compilation system in current version of HotSpot works. Compiled methods are managed with an "nmethod" object. There's a field, "_code" in the methodOopDesc of the method compiled that keeps track of the compiled code. There are two separate entry points in a methodOopDesc, one is _from_compiled_entry, the other is _from_interpreted_entry. Read the comments in oops/methodOop.hpp, it explains what these two entry points are for.Depending on whether the caller is interpreted or compiled, going through the entry point may go into a c2i (compiled-to-interpreted) or i2c (interpreted-to-compiled) adapter. An nmethod has two entry points by itself, one is the "entry point" and the other is the "verified entry point". These are used to implement inline caching for virtual call dispatch. More details described here: http://wikis.sun.com/display/HotSpotInternals/VirtualCalls Regards, Kris Mok On Sat, Jun 11, 2011 at 12:46 AM, Igor Veresov wrote: > On 6/10/11 8:52 AM, antoine artaud-macari wrote: > >> >> Dear HotSpot developers ! >> >> We are working on performance optimization for a Java critical system >> and we would like to force the compilation of some Java methods (chosen >> by our own algorithm). >> So we have looked at the OpenJDK HotSpot source code and for time being >> we succeeded in forcing compilation of these methods but the interpreter >> still executes the bytecode. >> For example, we used : >> >> nmethod * nm = CompileBroker::compile_method(m, 0, m, 0,"forced >> compilation", THREAD); >> >> where m is a methodHandle on the method to be compiled. >> >> Would you please send us some technical reference or documentation about >> compilation process or how compiled method are executed ? >> >> >> > For osr_bci parameter you should specify the InvocationEntryBci constant > (which is -1). > > igor > > > > >> Best regards, >> >> -- >> *Antoine ARTAUD-MACARI ***** >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110612/547ced0e/attachment.html From damjan.jov at gmail.com Sun Jun 12 04:03:08 2011 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Sun, 12 Jun 2011 13:03:08 +0200 Subject: support for SIMD in Hotspot (c2) In-Reply-To: References: Message-ID: On Wed, Apr 6, 2011 at 7:35 AM, Vitaly Davidovich wrote: > Hi guys, > Are there any current plans to support SIMD SSE/AVX vector ops in c2 (i.e. > loop vectorization transforms)? I came across a few related Oracle(Sun) RFEs > in the database, saw the superword.hpp/cpp source in the OpenJDK repository, > and did a bit of googl'ing but cannot tell where this stands at the moment. > Thanks, > Vitaly > > Hi I'd also like to know where SIMD in Java stands. Vitaly have you read all of these threads: http://mail.openjdk.java.net/pipermail/hotspot-dev/2008-December/thread.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-January/000994.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-January/001118.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-February/001145.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-February/001389.html Regards Damjan From john.r.rose at oracle.com Mon Jun 13 21:22:20 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 13 Jun 2011 21:22:20 -0700 Subject: review request (URGENT): 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray Message-ID: <94E61D7E-EA48-45E3-8F0D-B0049D8101BC@oracle.com> These are the JDK-side fixes for several crashes in method handle adapters. http://cr.openjdk.java.net/~jrose/7052202/webrev.jdk.00/ Summary of changes: - correct parameters of some rotate (OP_ROT_ARGS) permutation adapters - communicate the rotation convention with the JVM via OP_ROT_ARGS_DOWN_LIMIT_BIAS - adjust code in MethodHandleImpl for GWT transformations - fix typo in SwitchPoint javadoc - fix non-compliant logic in MethodHandleProxies - fix invalid private classes in MethodHandlesTest 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. This bug also has a set of JVM-side fixes, which will also be posted for review. A preview may be found in the mlvm patch repository: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-rot-7052202.patch Both change sets are required to fix the bug. Either change set is safe to apply by itself, and will cause no regression. Thanks, -- John From paul.hohensee at oracle.com Tue Jun 14 07:07:43 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 14 Jun 2011 10:07:43 -0400 Subject: Request for review (XXS): 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops In-Reply-To: <602090DE-93DE-40B6-BFD0-194DF8F44715@oracle.com> References: <602090DE-93DE-40B6-BFD0-194DF8F44715@oracle.com> Message-ID: <4DF76B2F.3060505@oracle.com> Haven't seen reviews for this. Anyone? Thanks, Paul On 6/10/11 1:20 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7053520 > > 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops > Reviewed-by: > > We are trying to decode the address of the CallSite object stored in > constant pool cache as if it were an oop but it's a raw pointer which > results in crashes. The fix is to replace the load instruction with > move_wide. > > Tested with JRuby tests. > > src/share/vm/c1/c1_LIRGenerator.cpp > From christian.thalinger at oracle.com Tue Jun 14 09:34:58 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 14 Jun 2011 18:34:58 +0200 Subject: Request for review (XXS): 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops In-Reply-To: <4DF76B2F.3060505@oracle.com> References: <602090DE-93DE-40B6-BFD0-194DF8F44715@oracle.com> <4DF76B2F.3060505@oracle.com> Message-ID: <4930C073-0821-4ECC-9275-76C8A42FA2FF@oracle.com> On Jun 14, 2011, at 4:07 PM, Paul Hohensee wrote: > Haven't seen reviews for this. Anyone? There were two, from Igor and Tom. They were also sent to the list. -- Christian > > Thanks, > > Paul > > On 6/10/11 1:20 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7053520 >> >> 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops >> Reviewed-by: >> >> We are trying to decode the address of the CallSite object stored in >> constant pool cache as if it were an oop but it's a raw pointer which >> results in crashes. The fix is to replace the load instruction with >> move_wide. >> >> Tested with JRuby tests. >> >> src/share/vm/c1/c1_LIRGenerator.cpp From tom.rodriguez at oracle.com Tue Jun 14 09:40:33 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 14 Jun 2011 09:40:33 -0700 Subject: Request for review (XXS): 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops In-Reply-To: <4DF76B2F.3060505@oracle.com> References: <602090DE-93DE-40B6-BFD0-194DF8F44715@oracle.com> <4DF76B2F.3060505@oracle.com> Message-ID: There were two reviews on Friday. tom On Jun 14, 2011, at 7:07 AM, Paul Hohensee wrote: > Haven't seen reviews for this. Anyone? > > Thanks, > > Paul > > On 6/10/11 1:20 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7053520 >> >> 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops >> Reviewed-by: >> >> We are trying to decode the address of the CallSite object stored in >> constant pool cache as if it were an oop but it's a raw pointer which >> results in crashes. The fix is to replace the load instruction with >> move_wide. >> >> Tested with JRuby tests. >> >> src/share/vm/c1/c1_LIRGenerator.cpp >> From paul.hohensee at oracle.com Tue Jun 14 09:45:13 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 14 Jun 2011 12:45:13 -0400 Subject: Request for review (XXS): 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops In-Reply-To: References: <602090DE-93DE-40B6-BFD0-194DF8F44715@oracle.com> <4DF76B2F.3060505@oracle.com> Message-ID: <4DF79019.6010403@oracle.com> Then my bad. Thanks! Paul On 6/14/11 12:40 PM, Tom Rodriguez wrote: > There were two reviews on Friday. > > tom > > On Jun 14, 2011, at 7:07 AM, Paul Hohensee wrote: > >> Haven't seen reviews for this. Anyone? >> >> Thanks, >> >> Paul >> >> On 6/10/11 1:20 PM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7053520 >>> >>> 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops >>> Reviewed-by: >>> >>> We are trying to decode the address of the CallSite object stored in >>> constant pool cache as if it were an oop but it's a raw pointer which >>> results in crashes. The fix is to replace the load instruction with >>> move_wide. >>> >>> Tested with JRuby tests. >>> >>> src/share/vm/c1/c1_LIRGenerator.cpp >>> From christian.thalinger at oracle.com Tue Jun 14 09:49:51 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 14 Jun 2011 18:49:51 +0200 Subject: review request (URGENT): 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray In-Reply-To: <94E61D7E-EA48-45E3-8F0D-B0049D8101BC@oracle.com> References: <94E61D7E-EA48-45E3-8F0D-B0049D8101BC@oracle.com> Message-ID: On Jun 14, 2011, at 6:22 AM, John Rose wrote: > These are the JDK-side fixes for several crashes in method handle adapters. > http://cr.openjdk.java.net/~jrose/7052202/webrev.jdk.00/ > > Summary of changes: > - correct parameters of some rotate (OP_ROT_ARGS) permutation adapters > - communicate the rotation convention with the JVM via OP_ROT_ARGS_DOWN_LIMIT_BIAS > - adjust code in MethodHandleImpl for GWT transformations > - fix typo in SwitchPoint javadoc > - fix non-compliant logic in MethodHandleProxies > - fix invalid private classes in MethodHandlesTest > > 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray > Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. > > This bug also has a set of JVM-side fixes, which will also be posted for review. A preview may be found in the mlvm patch repository: > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-rot-7052202.patch > > Both change sets are required to fix the bug. Either change set is safe to apply by itself, and will cause no regression. Looks good. -- Christian From tom.rodriguez at oracle.com Tue Jun 14 10:11:17 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 14 Jun 2011 10:11:17 -0700 Subject: review for 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters Message-ID: <7B15C9DA-74CB-4099-9DBC-656858E67349@oracle.com> http://cr.openjdk.java.net/~never/7052219 136 lines changed: 79 ins; 31 del; 26 mod; 14582 unchg 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters Summary: Reviewed-by: There were a set of bugs on both the JDK and VM side when dealing with rotation of arguments that could cause argument shearing which resulted in a large class of failures. The mostly obvious ones were crashes from corrupted oops but it caused failures in other computations. The primary bug was inconsistent rules for how the rotate was specified when writing over a double word value but there were also issues with how the source size was accounted for. The main assembly had to be slightly adjusted to take this into account. Equivalent adjustments in the MethodHandleWalk were needed as well. I also included a minor fix to skip unneeded interface checkcasts. The verify logic was adjust to correctly complain about all these cases and there were some minor printing changes needed for debugging. Tested on x86 and sparc 32/64 with the regression tests and vm.mlvm in both product and fastdebug. All regression tests ran cleanly and the vm.mlwm tests are as clean as expected. All the product crashes we'd been seeing before are fixed, though there's still some undiagnosed issue on sparc that results in occasional crashes in one of the stress tests. From tom.rodriguez at oracle.com Tue Jun 14 10:27:55 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 14 Jun 2011 10:27:55 -0700 Subject: review request (URGENT): 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray In-Reply-To: <94E61D7E-EA48-45E3-8F0D-B0049D8101BC@oracle.com> References: <94E61D7E-EA48-45E3-8F0D-B0049D8101BC@oracle.com> Message-ID: <0A6053DB-D921-4E08-A3C2-09385DBC261D@oracle.com> Looks good. tom On Jun 13, 2011, at 9:22 PM, John Rose wrote: > These are the JDK-side fixes for several crashes in method handle adapters. > http://cr.openjdk.java.net/~jrose/7052202/webrev.jdk.00/ > > Summary of changes: > - correct parameters of some rotate (OP_ROT_ARGS) permutation adapters > - communicate the rotation convention with the JVM via OP_ROT_ARGS_DOWN_LIMIT_BIAS > - adjust code in MethodHandleImpl for GWT transformations > - fix typo in SwitchPoint javadoc > - fix non-compliant logic in MethodHandleProxies > - fix invalid private classes in MethodHandlesTest > > 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray > Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. > > This bug also has a set of JVM-side fixes, which will also be posted for review. A preview may be found in the mlvm patch repository: > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-rot-7052202.patch > > Both change sets are required to fix the bug. Either change set is safe to apply by itself, and will cause no regression. > > Thanks, > -- John > > From forax at univ-mlv.fr Tue Jun 14 10:28:52 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 14 Jun 2011 19:28:52 +0200 Subject: review for 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters In-Reply-To: <7B15C9DA-74CB-4099-9DBC-656858E67349@oracle.com> References: <7B15C9DA-74CB-4099-9DBC-656858E67349@oracle.com> Message-ID: <4DF79A54.9060602@univ-mlv.fr> On 06/14/2011 07:11 PM, Tom Rodriguez wrote: > I also included a minor fix to skip unneeded interface checkcasts. Not sure you have the right to do that with the current state of the JSR292 spec. But I think the spec should be changed on that peculiar point. R?mi From christian.thalinger at oracle.com Tue Jun 14 10:37:18 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 14 Jun 2011 19:37:18 +0200 Subject: review for 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters In-Reply-To: <7B15C9DA-74CB-4099-9DBC-656858E67349@oracle.com> References: <7B15C9DA-74CB-4099-9DBC-656858E67349@oracle.com> Message-ID: On Jun 14, 2011, at 7:11 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7052219 > 136 lines changed: 79 ins; 31 del; 26 mod; 14582 unchg > > 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters > Summary: > Reviewed-by: > > There were a set of bugs on both the JDK and VM side when dealing with > rotation of arguments that could cause argument shearing which > resulted in a large class of failures. The mostly obvious ones were > crashes from corrupted oops but it caused failures in other > computations. The primary bug was inconsistent rules for how the > rotate was specified when writing over a double word value but there > were also issues with how the source size was accounted for. The main > assembly had to be slightly adjusted to take this into account. > Equivalent adjustments in the MethodHandleWalk were needed as well. I > also included a minor fix to skip unneeded interface checkcasts. The > verify logic was adjust to correctly complain about all these cases > and there were some minor printing changes needed for debugging. > > Tested on x86 and sparc 32/64 with the regression tests and vm.mlvm in > both product and fastdebug. All regression tests ran cleanly and the > vm.mlwm tests are as clean as expected. All the product crashes we'd > been seeing before are fixed, though there's still some undiagnosed > issue on sparc that results in occasional crashes in one of the stress > tests. Looks good. -- Christian From john.r.rose at oracle.com Tue Jun 14 10:53:28 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Jun 2011 10:53:28 -0700 Subject: review for 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters In-Reply-To: <4DF79A54.9060602@univ-mlv.fr> References: <7B15C9DA-74CB-4099-9DBC-656858E67349@oracle.com> <4DF79A54.9060602@univ-mlv.fr> Message-ID: On Jun 14, 2011, at 10:28 AM, R?mi Forax wrote: > Not sure you have the right to do that with the current state of the JSR292 spec. > But I think the spec should be changed on that peculiar point. He's only skipping "unneeded" ones, specifically those that the JVM itself had invisibly inserted at return points in the MH compiler. -- John From tom.rodriguez at oracle.com Tue Jun 14 10:54:31 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 14 Jun 2011 10:54:31 -0700 Subject: review for 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters In-Reply-To: <4DF79A54.9060602@univ-mlv.fr> References: <7B15C9DA-74CB-4099-9DBC-656858E67349@oracle.com> <4DF79A54.9060602@univ-mlv.fr> Message-ID: <26311D42-D3B5-4FA6-84B4-72DD9B46C92E@oracle.com> On Jun 14, 2011, at 10:28 AM, R?mi Forax wrote: > On 06/14/2011 07:11 PM, Tom Rodriguez wrote: >> I also included a minor fix to skip unneeded interface checkcasts. > > Not sure you have the right to do that with the current state of the JSR292 spec. > But I think the spec should be changed on that peculiar point. I'm making it consistent with another place in MethodHandleWalk where this is done: klassOop rklass = java_lang_Class::as_klassOop( java_lang_invoke_MethodType::rtype(recursive_mtype()) ); if (rklass != SystemDictionary::Object_klass() && !Klass::cast(rklass)->is_interface()) { // preserve type safety ret = make_conversion(T_OBJECT, rklass, Bytecodes::_checkcast, ret, CHECK_(empty)); } Note that this is code that is used to build bytecode equivalents of MethodHandle chains for compilation. As far as I can tell the MethodHandles proper don't have any of these casts in place as part of the fold/collect logic so I'm a little unclear why they are being emitted in the first place. checkcast MethodHandles are handled completely separately and not affected by this change. Anyway, John suggested the change in the first place so he can probably better speak to their correctness. tom > > R?mi > > From vladimir.kozlov at oracle.com Tue Jun 14 11:08:28 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jun 2011 11:08:28 -0700 Subject: review for 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters In-Reply-To: <7B15C9DA-74CB-4099-9DBC-656858E67349@oracle.com> References: <7B15C9DA-74CB-4099-9DBC-656858E67349@oracle.com> Message-ID: <4DF7A39C.10303@oracle.com> Looks good to me. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7052219 > 136 lines changed: 79 ins; 31 del; 26 mod; 14582 unchg > > 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters > Summary: > Reviewed-by: > > There were a set of bugs on both the JDK and VM side when dealing with > rotation of arguments that could cause argument shearing which > resulted in a large class of failures. The mostly obvious ones were > crashes from corrupted oops but it caused failures in other > computations. The primary bug was inconsistent rules for how the > rotate was specified when writing over a double word value but there > were also issues with how the source size was accounted for. The main > assembly had to be slightly adjusted to take this into account. > Equivalent adjustments in the MethodHandleWalk were needed as well. I > also included a minor fix to skip unneeded interface checkcasts. The > verify logic was adjust to correctly complain about all these cases > and there were some minor printing changes needed for debugging. > > Tested on x86 and sparc 32/64 with the regression tests and vm.mlvm in > both product and fastdebug. All regression tests ran cleanly and the > vm.mlwm tests are as clean as expected. All the product crashes we'd > been seeing before are fixed, though there's still some undiagnosed > issue on sparc that results in occasional crashes in one of the stress > tests. > From christian.thalinger at oracle.com Tue Jun 14 15:17:38 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 14 Jun 2011 22:17:38 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops Message-ID: <20110614221743.24A7A47021@hg.openjdk.java.net> Changeset: c8f2186acf6d Author: twisti Date: 2011-06-14 12:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c8f2186acf6d 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops Reviewed-by: iveresov, never ! src/share/vm/c1/c1_LIRGenerator.cpp From tom.rodriguez at oracle.com Tue Jun 14 17:20:34 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 15 Jun 2011 00:20:34 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110615002040.4EDC44702B@hg.openjdk.java.net> Changeset: f8c9417e3571 Author: never Date: 2011-06-14 14:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f8c9417e3571 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters Reviewed-by: twisti, kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp Changeset: e2ce15aa3daf Author: never Date: 2011-06-14 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e2ce15aa3daf Merge From john.r.rose at oracle.com Tue Jun 14 18:18:29 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Jun 2011 18:18:29 -0700 Subject: review request (URGENT): 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray In-Reply-To: <94E61D7E-EA48-45E3-8F0D-B0049D8101BC@oracle.com> References: <94E61D7E-EA48-45E3-8F0D-B0049D8101BC@oracle.com> Message-ID: I have reviews from Christian and Tom; thanks. For more accurate tracking, I have split out some of the changes into a different bug, 7054590: http://cr.openjdk.java.net/~jrose/7054590/webrev.00 The updated webrev for the remaining changes is here: http://cr.openjdk.java.net/~jrose/7052202/webrev.jdk.01 Please give it a quick re-review. Besides the split, I also simplified the adjustment in MethodHandleImpl.java to the GWT transformations, as follows: static boolean preferRicochetFrame(MethodType type) { - return (type.parameterCount() >= INVOKES.length || type.hasPrimitives()); + return true; // always use RF if available } This particular simplification has been "soaking" in the mlvm-dev builds since 6/03. -- John On Jun 13, 2011, at 9:22 PM, John Rose wrote: > These are the JDK-side fixes for several crashes in method handle adapters. > http://cr.openjdk.java.net/~jrose/7052202/webrev.jdk.00/ > > Summary of changes: > - correct parameters of some rotate (OP_ROT_ARGS) permutation adapters > - communicate the rotation convention with the JVM via OP_ROT_ARGS_DOWN_LIMIT_BIAS > - adjust code in MethodHandleImpl for GWT transformations > - fix typo in SwitchPoint javadoc > - fix non-compliant logic in MethodHandleProxies > - fix invalid private classes in MethodHandlesTest > > 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray > Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. > > This bug also has a set of JVM-side fixes, which will also be posted for review. A preview may be found in the mlvm patch repository: > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-rot-7052202.patch > > Both change sets are required to fix the bug. Either change set is safe to apply by itself, and will cause no regression. > > Thanks, > -- John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110614/252dcb6c/attachment.html From john.r.rose at oracle.com Tue Jun 14 19:35:27 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Jun 2011 19:35:27 -0700 Subject: review request (URGENT): 7054590: (JSR-292) MethodHandleProxies.asInterfaceInstance() accepts private/protected nested interfaces Message-ID: (This has been previously reviewed under the bug 7052202. Here is a separate review for the record.) http://cr.openjdk.java.net/~jrose/7054590/webrev.00 7054590: (JSR-292) MethodHandleProxies.asInterfaceInstance() accepts private/protected nested interfaces Summary: fix non-compliant logic in MethodHandleProxies, fix invalid private classes in MethodHandlesTest Reviewed-by: twisti, never This has been tested by new unit tests which are not included in this push. The unit tests may be examined here: http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-unittests.patch (near 'asInterfaceInstance') Negative tests include: - non-interfaces Object, String - non-public-interface 'PrivateRunnable' - Interfaces without a unique method: CharSequence, java.io.Serializable - interfaces with a wrong-arity method: Runnable Positive tests include: - typical interface Runnable - overloaded interface Appendable - unchecked exceptions passed unwrapped - checked declared exceptions passed unwrapped - checked undeclared exceptions passed wrapped From christian.thalinger at oracle.com Wed Jun 15 05:05:30 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Jun 2011 14:05:30 +0200 Subject: review request (URGENT): 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray In-Reply-To: References: <94E61D7E-EA48-45E3-8F0D-B0049D8101BC@oracle.com> Message-ID: <95D8FAE1-F42B-41A7-A96A-E2B5428C083D@oracle.com> On Jun 15, 2011, at 3:18 AM, John Rose wrote: > I have reviews from Christian and Tom; thanks. > > For more accurate tracking, I have split out some of the changes into a different bug, 7054590: > http://cr.openjdk.java.net/~jrose/7054590/webrev.00 > > The updated webrev for the remaining changes is here: > http://cr.openjdk.java.net/~jrose/7052202/webrev.jdk.01 > > Please give it a quick re-review. Still looks good. -- Christian > > Besides the split, I also simplified the adjustment in MethodHandleImpl.java to the GWT transformations, as follows: > > static boolean preferRicochetFrame(MethodType type) { > - return (type.parameterCount() >= INVOKES.length || type.hasPrimitives()); > + return true; // always use RF if available > } > > This particular simplification has been "soaking" in the mlvm-dev builds since 6/03. > > -- John > > On Jun 13, 2011, at 9:22 PM, John Rose wrote: > >> These are the JDK-side fixes for several crashes in method handle adapters. >> http://cr.openjdk.java.net/~jrose/7052202/webrev.jdk.00/ >> >> Summary of changes: >> - correct parameters of some rotate (OP_ROT_ARGS) permutation adapters >> - communicate the rotation convention with the JVM via OP_ROT_ARGS_DOWN_LIMIT_BIAS >> - adjust code in MethodHandleImpl for GWT transformations >> - fix typo in SwitchPoint javadoc >> - fix non-compliant logic in MethodHandleProxies >> - fix invalid private classes in MethodHandlesTest >> >> 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray >> Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. >> >> This bug also has a set of JVM-side fixes, which will also be posted for review. A preview may be found in the mlvm patch repository: >> http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-rot-7052202.patch >> >> Both change sets are required to fix the bug. Either change set is safe to apply by itself, and will cause no regression. >> >> Thanks, >> -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110615/42f01315/attachment.html From christian.thalinger at oracle.com Wed Jun 15 05:07:00 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Jun 2011 14:07:00 +0200 Subject: review request (URGENT): 7054590: (JSR-292) MethodHandleProxies.asInterfaceInstance() accepts private/protected nested interfaces In-Reply-To: References: Message-ID: On Jun 15, 2011, at 4:35 AM, John Rose wrote: > (This has been previously reviewed under the bug 7052202. Here is a separate review for the record.) > > http://cr.openjdk.java.net/~jrose/7054590/webrev.00 > > 7054590: (JSR-292) MethodHandleProxies.asInterfaceInstance() accepts private/protected nested interfaces > Summary: fix non-compliant logic in MethodHandleProxies, fix invalid private classes in MethodHandlesTest > Reviewed-by: twisti, never Looks good. -- Christian > > This has been tested by new unit tests which are not included in this push. The unit tests may be examined here: > http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-unittests.patch (near 'asInterfaceInstance') > > Negative tests include: > - non-interfaces Object, String > - non-public-interface 'PrivateRunnable' > - Interfaces without a unique method: CharSequence, java.io.Serializable > - interfaces with a wrong-arity method: Runnable > > Positive tests include: > - typical interface Runnable > - overloaded interface Appendable > - unchecked exceptions passed unwrapped > - checked declared exceptions passed unwrapped > - checked undeclared exceptions passed wrapped From john.r.rose at oracle.com Wed Jun 15 14:17:31 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 15 Jun 2011 21:17:31 +0000 Subject: hg: hsx/hotspot-comp/jdk: 2 new changesets Message-ID: <20110615211813.80C5447065@hg.openjdk.java.net> Changeset: ad2d48306709 Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ad2d48306709 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/SwitchPoint.java + test/java/lang/invoke/PermuteArgsTest.java Changeset: 521e2254994c Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/521e2254994c 7054590: (JSR-292) MethodHandleProxies.asInterfaceInstance() accepts private/protected nested interfaces Summary: fix non-compliant logic in MethodHandleProxies, fix invalid private classes in MethodHandlesTest Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! test/java/lang/invoke/MethodHandlesTest.java From tom.rodriguez at oracle.com Wed Jun 15 14:30:30 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 15 Jun 2011 21:30:30 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7 new changesets Message-ID: <20110615213044.D5E2A47067@hg.openjdk.java.net> Changeset: 537a4053b0f9 Author: ysr Date: 2011-05-23 16:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/537a4053b0f9 7042740: CMS: assert(n> q) failed: Looping at: ... blockOffsetTable.cpp:557 Summary: Do a one-step look-ahead, when sweeping free or garbage blocks, to avoid overstepping sweep limit, which may become a non-block-boundary because of a heap expansion delta coalescing with a previously co-terminal free block. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/blockOffsetTable.cpp Changeset: f153114134c8 Author: jcoomes Date: 2011-06-07 13:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f153114134c8 Merge Changeset: d3b9f2be46ab Author: coleenp Date: 2011-05-21 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d3b9f2be46ab 7033141: assert(has_cp_cache(i)) failed: oob Summary: Unrewrite bytecodes for OOM error allocating the constant pool cache. Reviewed-by: dcubed, acorn, never ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 9dd6c4ba364f Author: coleenp Date: 2011-06-02 14:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9dd6c4ba364f 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 Summary: Removed extra change from another bug fix that caused this regression Reviewed-by: phh, dcubed, kvn, kamg, never ! src/share/vm/oops/methodOop.cpp Changeset: 96c891ebe56a Author: coleenp Date: 2011-06-02 21:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/96c891ebe56a Merge ! src/share/vm/prims/methodHandleWalk.cpp Changeset: ae1d716e395c Author: dsamersoff Date: 2011-06-09 01:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ae1d716e395c Merge Changeset: cfcf2ba8f3eb Author: never Date: 2011-06-15 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cfcf2ba8f3eb Merge ! src/share/vm/prims/methodHandleWalk.cpp From rednaxelafx at gmail.com Wed Jun 15 20:31:23 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 16 Jun 2011 11:31:23 +0800 Subject: Should C1 respect CompilerCommand "dontinline"? Message-ID: Hi all, Someone asked why he ran tests and found that the compiler command "dontinline" doesn't work, here: http://hllvm.group.iteye.com/group/topic/26381 It's clear that he's using HotSpot Client VM, so it's C1 in action. I found that C1's graph builder doesn't check whether a method has been tagged as "dontinline" by the CompilerOracle, src/share/vm/c1/c1_GraphBuilder.cpp, line 2984 bool GraphBuilder::try_inline(ciMethod* callee, bool holder_known) { // Clear out any existing inline bailout condition clear_inline_bailout(); if (callee->should_exclude()) { // callee is excluded INLINE_BAILOUT("excluded by CompilerOracle") } else if (!callee->can_be_compiled()) { // callee is not compilable (prob. has breakpoints) INLINE_BAILOUT("not compilable") } else if (callee->intrinsic_id() != vmIntrinsics::_none && try_inline_intrinsics(callee)) { // intrinsics can be native or not return true; } else if (callee->is_native()) { // non-intrinsic natives cannot be inlined INLINE_BAILOUT("non-intrinsic native") } else if (callee->is_abstract()) { INLINE_BAILOUT("abstract") } else { return try_inline_full(callee, holder_known); } } Should there be a check to callee->should_not_inline() after the should_exclude() branch, so that C1 respects the "dontinline" command? And perhaps another check to callee->should_inline() in GraphBuilder::try_inline_full() ? P.S. The code I'm using is from hsx/hsx20/baseline. It's the same on the tip of hsx/hotspot-comp Regards, Kris Mok -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110616/cb7da23d/attachment.html From tom.rodriguez at oracle.com Wed Jun 15 22:32:01 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 15 Jun 2011 22:32:01 -0700 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException Message-ID: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> http://cr.openjdk.java.net/~never/7055355 174 lines changed: 54 ins; 111 del; 9 mod; 30934 unchg 7055355: JSR 292: crash while throwing WrongMethodTypeException Reviewed-by: When throwing a WrongMethodTypeException from a MethodHandle the existing code was pretending it was in the interpreter which worked ok most of the time but would sometimes die when trying to throw with a compiled caller. It could cause asserts in some contexts or result in GC crashes. The fix is to remove the old machinery in favor of the more standard code for throwing exceptions in StubRoutines/SharedRuntime. There was one other use of the old throw machinery but it's in part of check that can never fail since we won't enable method handles unless we have a non-NULL rasie exception method. There's an extra fix in the there to reject lookups of clinit. It isn't critical but it allows all the JCK tests to run without asserting. Tested with failing JCK test and jruby crasher on sparc/x86 with client/server/d64, along with a full run of the invokedynamic JCK tests, the JLI regression tests and the vm.mlvm tests. From john.r.rose at oracle.com Wed Jun 15 23:22:36 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 15 Jun 2011 23:22:36 -0700 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> Message-ID: <8343C96A-A921-43A2-BF32-BC81D21DE590@oracle.com> Reviewed. Thanks for fixing this. -- John On Jun 15, 2011, at 10:32 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7055355 > 174 lines changed: 54 ins; 111 del; 9 mod; 30934 unchg > > 7055355: JSR 292: crash while throwing WrongMethodTypeException > Reviewed-by: > > When throwing a WrongMethodTypeException from a MethodHandle the > existing code was pretending it was in the interpreter which worked ok > most of the time but would sometimes die when trying to throw with a > compiled caller. It could cause asserts in some contexts or result in > GC crashes. The fix is to remove the old machinery in favor of the > more standard code for throwing exceptions in > StubRoutines/SharedRuntime. There was one other use of the old throw > machinery but it's in part of check that can never fail since we won't > enable method handles unless we have a non-NULL rasie exception > method. There's an extra fix in the there to reject lookups of > clinit. It isn't critical but it allows all the JCK tests to run > without asserting. Tested with failing JCK test and jruby crasher on > sparc/x86 with client/server/d64, along with a full run of the > invokedynamic JCK tests, the JLI regression tests and the vm.mlvm > tests. > From christian.thalinger at oracle.com Thu Jun 16 02:47:13 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Jun 2011 11:47:13 +0200 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> Message-ID: On Jun 16, 2011, at 7:32 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7055355 > 174 lines changed: 54 ins; 111 del; 9 mod; 30934 unchg > > 7055355: JSR 292: crash while throwing WrongMethodTypeException > Reviewed-by: > > When throwing a WrongMethodTypeException from a MethodHandle the > existing code was pretending it was in the interpreter which worked ok > most of the time but would sometimes die when trying to throw with a > compiled caller. It could cause asserts in some contexts or result in > GC crashes. The fix is to remove the old machinery in favor of the > more standard code for throwing exceptions in > StubRoutines/SharedRuntime. There was one other use of the old throw > machinery but it's in part of check that can never fail since we won't > enable method handles unless we have a non-NULL rasie exception > method. There's an extra fix in the there to reject lookups of > clinit. It isn't critical but it allows all the JCK tests to run > without asserting. Tested with failing JCK test and jruby crasher on > sparc/x86 with client/server/d64, along with a full run of the > invokedynamic JCK tests, the JLI regression tests and the vm.mlvm > tests. You didn't remove the NULL-checking code of the raise_exception method in methodHandles_sparc.cpp. Otherwise this looks good. -- Christian From christian.thalinger at oracle.com Thu Jun 16 05:49:19 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Jun 2011 14:49:19 +0200 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> Message-ID: <5E64EB49-4168-4BC7-B2DA-75ACEDC4AC14@oracle.com> On Jun 16, 2011, at 11:47 AM, Christian Thalinger wrote: > On Jun 16, 2011, at 7:32 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7055355 >> 174 lines changed: 54 ins; 111 del; 9 mod; 30934 unchg >> >> 7055355: JSR 292: crash while throwing WrongMethodTypeException >> Reviewed-by: >> >> When throwing a WrongMethodTypeException from a MethodHandle the >> existing code was pretending it was in the interpreter which worked ok >> most of the time but would sometimes die when trying to throw with a >> compiled caller. It could cause asserts in some contexts or result in >> GC crashes. The fix is to remove the old machinery in favor of the >> more standard code for throwing exceptions in >> StubRoutines/SharedRuntime. There was one other use of the old throw >> machinery but it's in part of check that can never fail since we won't >> enable method handles unless we have a non-NULL rasie exception >> method. There's an extra fix in the there to reject lookups of >> clinit. It isn't critical but it allows all the JCK tests to run >> without asserting. Tested with failing JCK test and jruby crasher on >> sparc/x86 with client/server/d64, along with a full run of the >> invokedynamic JCK tests, the JLI regression tests and the vm.mlvm >> tests. > > You didn't remove the NULL-checking code of the raise_exception method in methodHandles_sparc.cpp. Otherwise this looks good. The SPARC logic is broken, I get asserts with John's ThrowExceptionsTest. The problem is that SPARC's throw exception stub uses a save_frame and O1/O2 then contain some arbitrary values hitting the assert in SharedRuntime::throw_WrongMethodTypeException. I fixed it using the same logic you added for x86. I also removed the NULL-checking code I mentioned above. With the patch below applied we hit the unreasonable-stack-move assert at some point: # assert(false) failed: DEBUG MESSAGE: damaged ricochet frame: (L4 - UNREASONABLE_STACK_MOVE) > FP -- Christian diff -r cfcf2ba8f3eb src/cpu/sparc/vm/methodHandles_sparc.cpp --- a/src/cpu/sparc/vm/methodHandles_sparc.cpp +++ b/src/cpu/sparc/vm/methodHandles_sparc.cpp @@ -546,9 +546,9 @@ address MethodHandles::generate_method_h __ cmp(O1_scratch, (int) vmIntrinsics::_invokeExact); __ brx(Assembler::notEqual, false, Assembler::pt, invoke_generic_slow_path); __ delayed()->nop(); - __ mov(O0_mtype, G5_method_type); // required by throw_WrongMethodType + __ mov(O0_mtype, G5_method_type); // required by throw_WrongMethodType // mov(G3_method_handle, G3_method_handle); // already in this register - __ jump_to(AddressLiteral(Interpreter::throw_WrongMethodType_entry()), O1_scratch); + __ jump_to(AddressLiteral(StubRoutines::throw_WrongMethodTypeException_entry()), O1_scratch); __ delayed()->nop(); // here's where control starts out: @@ -1142,26 +1142,14 @@ void MethodHandles::generate_method_hand __ mov(O5_savedSP, SP); // Cut the stack back to where the caller started. Label L_no_method; - // FIXME: fill in _raise_exception_method with a suitable java.lang.invoke method __ set(AddressLiteral((address) &_raise_exception_method), G5_method); __ ld_ptr(Address(G5_method, 0), G5_method); - __ tst(G5_method); - __ brx(Assembler::zero, false, Assembler::pn, L_no_method); - __ delayed()->nop(); const int jobject_oop_offset = 0; - __ ld_ptr(Address(G5_method, jobject_oop_offset), G5_method); - __ tst(G5_method); - __ brx(Assembler::zero, false, Assembler::pn, L_no_method); - __ delayed()->nop(); - + __ ld_ptr(Address(G5_method, jobject_oop_offset), G5_method); // dereference the jobject __ verify_oop(G5_method); __ jump_indirect_to(G5_method_fce, O3_scratch); // jump to compiled entry __ delayed()->nop(); - - // Do something that is at least causes a valid throw from the interpreter. - __ bind(L_no_method); - __ unimplemented("call throw_WrongMethodType_entry"); } break; diff -r cfcf2ba8f3eb src/cpu/sparc/vm/stubGenerator_sparc.cpp --- a/src/cpu/sparc/vm/stubGenerator_sparc.cpp +++ b/src/cpu/sparc/vm/stubGenerator_sparc.cpp @@ -440,7 +440,8 @@ class StubGenerator: public StubCodeGene #undef __ #define __ masm-> - address generate_throw_exception(const char* name, address runtime_entry, bool restore_saved_exception_pc) { + address generate_throw_exception(const char* name, address runtime_entry, + bool restore_saved_exception_pc, Register arg1 = noreg, Register arg2 = noreg) { #ifdef ASSERT int insts_size = VerifyThread ? 1 * K : 600; #else @@ -477,6 +478,13 @@ class StubGenerator: public StubCodeGene if (VerifyThread) __ mov(G2_thread, O0); // about to be smashed; pass early __ save_thread(noreg); // do the call + if (arg1 != noreg) { + assert(arg2 != O1, "clobbered"); + __ mov(arg1, O1); + } + if (arg2 != noreg) { + __ mov(arg2, O2); + } BLOCK_COMMENT("call runtime_entry"); __ call(runtime_entry, relocInfo::runtime_call_type); if (!VerifyThread) @@ -3240,6 +3248,14 @@ class StubGenerator: public StubCodeGene StubRoutines::_atomic_cmpxchg_long_entry = generate_atomic_cmpxchg_long(); StubRoutines::_atomic_add_ptr_entry = StubRoutines::_atomic_add_entry; #endif // COMPILER2 !=> _LP64 + + // Build this early so it's available for the interpreter. The + // stub expects the required and actual type to already be in O1 + // and O2 respectively. + StubRoutines::_throw_WrongMethodTypeException_entry = + generate_throw_exception("WrongMethodTypeException throw_exception", + CAST_FROM_FN_PTR(address, SharedRuntime::throw_WrongMethodTypeException), + false, G5_method_type, G3_method_handle); } From christian.thalinger at oracle.com Thu Jun 16 07:44:09 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Jun 2011 16:44:09 +0200 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: <5E64EB49-4168-4BC7-B2DA-75ACEDC4AC14@oracle.com> References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> <5E64EB49-4168-4BC7-B2DA-75ACEDC4AC14@oracle.com> Message-ID: <2873A974-98CF-49AA-B822-CA177E543EEA@oracle.com> On Jun 16, 2011, at 2:49 PM, Christian Thalinger wrote: > On Jun 16, 2011, at 11:47 AM, Christian Thalinger wrote: >> On Jun 16, 2011, at 7:32 AM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7055355 >>> 174 lines changed: 54 ins; 111 del; 9 mod; 30934 unchg >>> >>> 7055355: JSR 292: crash while throwing WrongMethodTypeException >>> Reviewed-by: >>> >>> When throwing a WrongMethodTypeException from a MethodHandle the >>> existing code was pretending it was in the interpreter which worked ok >>> most of the time but would sometimes die when trying to throw with a >>> compiled caller. It could cause asserts in some contexts or result in >>> GC crashes. The fix is to remove the old machinery in favor of the >>> more standard code for throwing exceptions in >>> StubRoutines/SharedRuntime. There was one other use of the old throw >>> machinery but it's in part of check that can never fail since we won't >>> enable method handles unless we have a non-NULL rasie exception >>> method. There's an extra fix in the there to reject lookups of >>> clinit. It isn't critical but it allows all the JCK tests to run >>> without asserting. Tested with failing JCK test and jruby crasher on >>> sparc/x86 with client/server/d64, along with a full run of the >>> invokedynamic JCK tests, the JLI regression tests and the vm.mlvm >>> tests. >> >> You didn't remove the NULL-checking code of the raise_exception method in methodHandles_sparc.cpp. Otherwise this looks good. > > > The SPARC logic is broken, I get asserts with John's ThrowExceptionsTest. The problem is that SPARC's throw exception stub uses a save_frame and O1/O2 then contain some arbitrary values hitting the assert in SharedRuntime::throw_WrongMethodTypeException. I fixed it using the same logic you added for x86. I also removed the NULL-checking code I mentioned above. > > With the patch below applied we hit the unreasonable-stack-move assert at some point: > > # assert(false) failed: DEBUG MESSAGE: damaged ricochet frame: (L4 - UNREASONABLE_STACK_MOVE) > FP I know I ported this piece of code over from x86 but honestly I don't understand what it is checking for. L4 >= FP seems reasonable and we should keep that check but (L4 - UNREASONABLE_STACK_MOVE) > FP is not a constraint that must hold in all situations. I suggest removing that check. What do you think? -- Christian From christian.thalinger at oracle.com Thu Jun 16 09:24:00 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Jun 2011 18:24:00 +0200 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: <2873A974-98CF-49AA-B822-CA177E543EEA@oracle.com> References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> <5E64EB49-4168-4BC7-B2DA-75ACEDC4AC14@oracle.com> <2873A974-98CF-49AA-B822-CA177E543EEA@oracle.com> Message-ID: <391F69DE-FB07-4238-AA48-28D1031C4FAA@oracle.com> On Jun 16, 2011, at 4:44 PM, Christian Thalinger wrote: > On Jun 16, 2011, at 2:49 PM, Christian Thalinger wrote: >> On Jun 16, 2011, at 11:47 AM, Christian Thalinger wrote: >>> On Jun 16, 2011, at 7:32 AM, Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7055355 >>>> 174 lines changed: 54 ins; 111 del; 9 mod; 30934 unchg >>>> >>>> 7055355: JSR 292: crash while throwing WrongMethodTypeException >>>> Reviewed-by: >>>> >>>> When throwing a WrongMethodTypeException from a MethodHandle the >>>> existing code was pretending it was in the interpreter which worked ok >>>> most of the time but would sometimes die when trying to throw with a >>>> compiled caller. It could cause asserts in some contexts or result in >>>> GC crashes. The fix is to remove the old machinery in favor of the >>>> more standard code for throwing exceptions in >>>> StubRoutines/SharedRuntime. There was one other use of the old throw >>>> machinery but it's in part of check that can never fail since we won't >>>> enable method handles unless we have a non-NULL rasie exception >>>> method. There's an extra fix in the there to reject lookups of >>>> clinit. It isn't critical but it allows all the JCK tests to run >>>> without asserting. Tested with failing JCK test and jruby crasher on >>>> sparc/x86 with client/server/d64, along with a full run of the >>>> invokedynamic JCK tests, the JLI regression tests and the vm.mlvm >>>> tests. >>> >>> You didn't remove the NULL-checking code of the raise_exception method in methodHandles_sparc.cpp. Otherwise this looks good. >> >> >> The SPARC logic is broken, I get asserts with John's ThrowExceptionsTest. The problem is that SPARC's throw exception stub uses a save_frame and O1/O2 then contain some arbitrary values hitting the assert in SharedRuntime::throw_WrongMethodTypeException. I fixed it using the same logic you added for x86. I also removed the NULL-checking code I mentioned above. >> >> With the patch below applied we hit the unreasonable-stack-move assert at some point: >> >> # assert(false) failed: DEBUG MESSAGE: damaged ricochet frame: (L4 - UNREASONABLE_STACK_MOVE) > FP > > I know I ported this piece of code over from x86 but honestly I don't understand what it is checking for. L4 >= FP seems reasonable and we should keep that check but (L4 - UNREASONABLE_STACK_MOVE) > FP is not a constraint that must hold in all situations. I suggest removing that check. What do you think? ...and there seems to be a bug in: void MethodHandles::verify_stack_move(MacroAssembler* _masm, RegisterOrConstant arg_slots, int direction) { enum { UNREASONABLE_STACK_MOVE = 256 * 4 }; // limit of 255 arguments We redefine UNREASONABLE_STACK_MOVE with a wrong value, it seems. -- Christian From tom.rodriguez at oracle.com Thu Jun 16 09:58:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 16 Jun 2011 09:58:27 -0700 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> Message-ID: <0BCAF326-63F7-4E07-A176-8221A6460498@oracle.com> On Jun 16, 2011, at 2:47 AM, Christian Thalinger wrote: > On Jun 16, 2011, at 7:32 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7055355 >> 174 lines changed: 54 ins; 111 del; 9 mod; 30934 unchg >> >> 7055355: JSR 292: crash while throwing WrongMethodTypeException >> Reviewed-by: >> >> When throwing a WrongMethodTypeException from a MethodHandle the >> existing code was pretending it was in the interpreter which worked ok >> most of the time but would sometimes die when trying to throw with a >> compiled caller. It could cause asserts in some contexts or result in >> GC crashes. The fix is to remove the old machinery in favor of the >> more standard code for throwing exceptions in >> StubRoutines/SharedRuntime. There was one other use of the old throw >> machinery but it's in part of check that can never fail since we won't >> enable method handles unless we have a non-NULL rasie exception >> method. There's an extra fix in the there to reject lookups of >> clinit. It isn't critical but it allows all the JCK tests to run >> without asserting. Tested with failing JCK test and jruby crasher on >> sparc/x86 with client/server/d64, along with a full run of the >> invokedynamic JCK tests, the JLI regression tests and the vm.mlvm >> tests. > > You didn't remove the NULL-checking code of the raise_exception method in methodHandles_sparc.cpp. Otherwise this looks good. Thanks. I felt like I hadn't deleted enough copies but grep didn't find the old throw routine anymore so I thought I was done. I've deleted it now. tom > > -- Christian From tom.rodriguez at oracle.com Thu Jun 16 10:18:44 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 16 Jun 2011 10:18:44 -0700 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: <391F69DE-FB07-4238-AA48-28D1031C4FAA@oracle.com> References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> <5E64EB49-4168-4BC7-B2DA-75ACEDC4AC14@oracle.com> <2873A974-98CF-49AA-B822-CA177E543EEA@oracle.com> <391F69DE-FB07-4238-AA48-28D1031C4FAA@oracle.com> Message-ID: <2F8356FD-60D5-44CF-AC7D-D5468F395123@oracle.com> On Jun 16, 2011, at 9:24 AM, Christian Thalinger wrote: > On Jun 16, 2011, at 4:44 PM, Christian Thalinger wrote: >> On Jun 16, 2011, at 2:49 PM, Christian Thalinger wrote: >>> On Jun 16, 2011, at 11:47 AM, Christian Thalinger wrote: >>>> On Jun 16, 2011, at 7:32 AM, Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/7055355 >>>>> 174 lines changed: 54 ins; 111 del; 9 mod; 30934 unchg >>>>> >>>>> 7055355: JSR 292: crash while throwing WrongMethodTypeException >>>>> Reviewed-by: >>>>> >>>>> When throwing a WrongMethodTypeException from a MethodHandle the >>>>> existing code was pretending it was in the interpreter which worked ok >>>>> most of the time but would sometimes die when trying to throw with a >>>>> compiled caller. It could cause asserts in some contexts or result in >>>>> GC crashes. The fix is to remove the old machinery in favor of the >>>>> more standard code for throwing exceptions in >>>>> StubRoutines/SharedRuntime. There was one other use of the old throw >>>>> machinery but it's in part of check that can never fail since we won't >>>>> enable method handles unless we have a non-NULL rasie exception >>>>> method. There's an extra fix in the there to reject lookups of >>>>> clinit. It isn't critical but it allows all the JCK tests to run >>>>> without asserting. Tested with failing JCK test and jruby crasher on >>>>> sparc/x86 with client/server/d64, along with a full run of the >>>>> invokedynamic JCK tests, the JLI regression tests and the vm.mlvm >>>>> tests. >>>> >>>> You didn't remove the NULL-checking code of the raise_exception method in methodHandles_sparc.cpp. Otherwise this looks good. >>> >>> >>> The SPARC logic is broken, I get asserts with John's ThrowExceptionsTest. The problem is that SPARC's throw exception stub uses a save_frame and O1/O2 then contain some arbitrary values hitting the assert in SharedRuntime::throw_WrongMethodTypeException. I fixed it using the same logic you added for x86. I also removed the NULL-checking code I mentioned above. >>> >>> With the patch below applied we hit the unreasonable-stack-move assert at some point: >>> >>> # assert(false) failed: DEBUG MESSAGE: damaged ricochet frame: (L4 - UNREASONABLE_STACK_MOVE) > FP >> >> I know I ported this piece of code over from x86 but honestly I don't understand what it is checking for. L4 >= FP seems reasonable and we should keep that check but (L4 - UNREASONABLE_STACK_MOVE) > FP is not a constraint that must hold in all situations. I suggest removing that check. What do you think? I increased the slop value in my last set of changes and we're currently not failing this test that I can see. I agree that the test is slightly mystifying and wouldn't mind removing it. > > ...and there seems to be a bug in: > > void MethodHandles::verify_stack_move(MacroAssembler* _masm, > RegisterOrConstant arg_slots, int direction) { > enum { UNREASONABLE_STACK_MOVE = 256 * 4 }; // limit of 255 arguments > > We redefine UNREASONABLE_STACK_MOVE with a wrong value, it seems. That's odd. I don't think I've even see this particular test fail so it's probably benign for the moment. tom > > -- Christian From tom.rodriguez at oracle.com Thu Jun 16 10:29:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 16 Jun 2011 10:29:59 -0700 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: <5E64EB49-4168-4BC7-B2DA-75ACEDC4AC14@oracle.com> References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> <5E64EB49-4168-4BC7-B2DA-75ACEDC4AC14@oracle.com> Message-ID: > > The SPARC logic is broken, I get asserts with John's ThrowExceptionsTest. The problem is that SPARC's throw exception stub uses a save_frame and O1/O2 then contain some arbitrary values hitting the assert in SharedRuntime::throw_WrongMethodTypeException. I fixed it using the same logic you added for x86. I also removed the NULL-checking code I mentioned above. That's odd. I was rerunning the JCK tests using jtjck.jar but for some reason it's actually not running the test I was really interested in. I reran using the runthese setup for it and it showed the problem you saw. I've adopted your fix (which I had at one point until I decided to make it like normal argument setup) and retested and it looks good. Thanks for catching this. tom > > With the patch below applied we hit the unreasonable-stack-move assert at some point: > > # assert(false) failed: DEBUG MESSAGE: damaged ricochet frame: (L4 - UNREASONABLE_STACK_MOVE) > FP > > -- Christian > > > diff -r cfcf2ba8f3eb src/cpu/sparc/vm/methodHandles_sparc.cpp > --- a/src/cpu/sparc/vm/methodHandles_sparc.cpp > +++ b/src/cpu/sparc/vm/methodHandles_sparc.cpp > @@ -546,9 +546,9 @@ address MethodHandles::generate_method_h > __ cmp(O1_scratch, (int) vmIntrinsics::_invokeExact); > __ brx(Assembler::notEqual, false, Assembler::pt, invoke_generic_slow_path); > __ delayed()->nop(); > - __ mov(O0_mtype, G5_method_type); // required by throw_WrongMethodType > + __ mov(O0_mtype, G5_method_type); // required by throw_WrongMethodType > // mov(G3_method_handle, G3_method_handle); // already in this register > - __ jump_to(AddressLiteral(Interpreter::throw_WrongMethodType_entry()), O1_scratch); > + __ jump_to(AddressLiteral(StubRoutines::throw_WrongMethodTypeException_entry()), O1_scratch); > __ delayed()->nop(); > > // here's where control starts out: > @@ -1142,26 +1142,14 @@ void MethodHandles::generate_method_hand > __ mov(O5_savedSP, SP); // Cut the stack back to where the caller started. > > Label L_no_method; > - // FIXME: fill in _raise_exception_method with a suitable java.lang.invoke method > __ set(AddressLiteral((address) &_raise_exception_method), G5_method); > __ ld_ptr(Address(G5_method, 0), G5_method); > - __ tst(G5_method); > - __ brx(Assembler::zero, false, Assembler::pn, L_no_method); > - __ delayed()->nop(); > > const int jobject_oop_offset = 0; > - __ ld_ptr(Address(G5_method, jobject_oop_offset), G5_method); > - __ tst(G5_method); > - __ brx(Assembler::zero, false, Assembler::pn, L_no_method); > - __ delayed()->nop(); > - > + __ ld_ptr(Address(G5_method, jobject_oop_offset), G5_method); // dereference the jobject > __ verify_oop(G5_method); > __ jump_indirect_to(G5_method_fce, O3_scratch); // jump to compiled entry > __ delayed()->nop(); > - > - // Do something that is at least causes a valid throw from the interpreter. > - __ bind(L_no_method); > - __ unimplemented("call throw_WrongMethodType_entry"); > } > break; > > diff -r cfcf2ba8f3eb src/cpu/sparc/vm/stubGenerator_sparc.cpp > --- a/src/cpu/sparc/vm/stubGenerator_sparc.cpp > +++ b/src/cpu/sparc/vm/stubGenerator_sparc.cpp > @@ -440,7 +440,8 @@ class StubGenerator: public StubCodeGene > #undef __ > #define __ masm-> > > - address generate_throw_exception(const char* name, address runtime_entry, bool restore_saved_exception_pc) { > + address generate_throw_exception(const char* name, address runtime_entry, > + bool restore_saved_exception_pc, Register arg1 = noreg, Register arg2 = noreg) { > #ifdef ASSERT > int insts_size = VerifyThread ? 1 * K : 600; > #else > @@ -477,6 +478,13 @@ class StubGenerator: public StubCodeGene > if (VerifyThread) __ mov(G2_thread, O0); // about to be smashed; pass early > __ save_thread(noreg); > // do the call > + if (arg1 != noreg) { > + assert(arg2 != O1, "clobbered"); > + __ mov(arg1, O1); > + } > + if (arg2 != noreg) { > + __ mov(arg2, O2); > + } > BLOCK_COMMENT("call runtime_entry"); > __ call(runtime_entry, relocInfo::runtime_call_type); > if (!VerifyThread) > @@ -3240,6 +3248,14 @@ class StubGenerator: public StubCodeGene > StubRoutines::_atomic_cmpxchg_long_entry = generate_atomic_cmpxchg_long(); > StubRoutines::_atomic_add_ptr_entry = StubRoutines::_atomic_add_entry; > #endif // COMPILER2 !=> _LP64 > + > + // Build this early so it's available for the interpreter. The > + // stub expects the required and actual type to already be in O1 > + // and O2 respectively. > + StubRoutines::_throw_WrongMethodTypeException_entry = > + generate_throw_exception("WrongMethodTypeException throw_exception", > + CAST_FROM_FN_PTR(address, SharedRuntime::throw_WrongMethodTypeException), > + false, G5_method_type, G3_method_handle); > } > > > From john.r.rose at oracle.com Thu Jun 16 13:56:26 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 16 Jun 2011 13:56:26 -0700 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: <2F8356FD-60D5-44CF-AC7D-D5468F395123@oracle.com> References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> <5E64EB49-4168-4BC7-B2DA-75ACEDC4AC14@oracle.com> <2873A974-98CF-49AA-B822-CA177E543EEA@oracle.com> <391F69DE-FB07-4238-AA48-28D1031C4FAA@oracle.com> <2F8356FD-60D5-44CF-AC7D-D5468F395123@oracle.com> Message-ID: On Jun 16, 2011, at 10:18 AM, Tom Rodriguez wrote: > I increased the slop value in my last set of changes and we're currently not failing this test that I can see. I agree that the test is slightly mystifying and wouldn't mind removing it. I would prefer to keep it for the following reason: When control returns to a RF, the SP is restored to a saved value. Comparing it to the saved argument base is a reasonable thing, since the RF is known to contain only (a) up to 255 saved arguements, and (b) a a few words of fixed overhead. If the restored SP is bad, and/or if the saved argument base is bad, we can detect this quickly using the comparison before the corruption goes further. The slop has to be large enough to contain the "save_frame" size used by the RF. -- John From tom.rodriguez at oracle.com Thu Jun 16 14:05:11 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 16 Jun 2011 14:05:11 -0700 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> <5E64EB49-4168-4BC7-B2DA-75ACEDC4AC14@oracle.com> <2873A974-98CF-49AA-B822-CA177E543EEA@oracle.com> <391F69DE-FB07-4238-AA48-28D1031C4FAA@oracle.com> <2F8356FD-60D5-44CF-AC7D-D5468F395123@oracle.com> Message-ID: <51647EC8-B77A-469D-B187-D43F20E11500@oracle.com> On Jun 16, 2011, at 1:56 PM, John Rose wrote: > On Jun 16, 2011, at 10:18 AM, Tom Rodriguez wrote: > >> I increased the slop value in my last set of changes and we're currently not failing this test that I can see. I agree that the test is slightly mystifying and wouldn't mind removing it. > > I would prefer to keep it for the following reason: > > When control returns to a RF, the SP is restored to a saved value. Comparing it to the saved argument base is a reasonable thing, since the RF is known to contain only (a) up to 255 saved arguements, and (b) a a few words of fixed overhead. If the restored SP is bad, and/or if the saved argument base is bad, we can detect this quickly using the comparison before the corruption goes further. > > The slop has to be large enough to contain the "save_frame" size used by the RF. I agree in theory but the only thing it's done so far is report false positives. The old slop value was kind of in agreement with the save_frame size but I had to raise it to 45 to get it to shut up, with no apparent ill effects. My last push raised it to 35. After Christian's comments I decided to disabled it in my push since I think it's well intentioned but wrong. tom > > -- John From john.r.rose at oracle.com Thu Jun 16 14:13:12 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 16 Jun 2011 14:13:12 -0700 Subject: review for 7055355: JSR 292: crash while throwing WrongMethodTypeException In-Reply-To: <51647EC8-B77A-469D-B187-D43F20E11500@oracle.com> References: <937B9BF7-3A51-43BE-BEF1-DFD74321B150@oracle.com> <5E64EB49-4168-4BC7-B2DA-75ACEDC4AC14@oracle.com> <2873A974-98CF-49AA-B822-CA177E543EEA@oracle.com> <391F69DE-FB07-4238-AA48-28D1031C4FAA@oracle.com> <2F8356FD-60D5-44CF-AC7D-D5468F395123@oracle.com> <51647EC8-B77A-469D-B187-D43F20E11500@oracle.com> Message-ID: <2C8707FA-41C2-47E7-B605-395DF07EDE2E@oracle.com> On Jun 16, 2011, at 2:05 PM, Tom Rodriguez wrote: > I agree in theory but the only thing it's done so far is report false positives. The old slop value was kind of in agreement with the save_frame size but I had to raise it to 45 to get it to shut up, with no apparent ill effects. My last push raised it to 35. After Christian's comments I decided to disabled it in my push since I think it's well intentioned but wrong. Yes; I saw you commented it out. That's fine for now. I agree about the false positives. Also, SPARC SPs are not corrupted as easily as on x86. I just re-reviewed it; it looks good. Thanks, Christian, for catching the SPARC problem. -- John From tom.rodriguez at oracle.com Thu Jun 16 16:14:29 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 16 Jun 2011 23:14:29 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7055355: JSR 292: crash while throwing WrongMethodTypeException Message-ID: <20110616231433.CC01E470A7@hg.openjdk.java.net> Changeset: d83ac25d0304 Author: never Date: 2011-06-16 13:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d83ac25d0304 7055355: JSR 292: crash while throwing WrongMethodTypeException Reviewed-by: jrose, twisti, bdelsart ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp From vladimir.kozlov at oracle.com Fri Jun 17 16:57:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jun 2011 16:57:02 -0700 Subject: Request for reviews (S): 7052494: Eclipse test fails on JDK 7 b142 Message-ID: <4DFBE9CE.6050902@oracle.com> This is for 7u2. http://cr.openjdk.java.net/~kvn/7052494/webrev Fixed 7052494: Eclipse test fails on JDK 7 b142 New code in 5091921 fix incorrectly replaces loop test 'ne' with 'lt' (and with 'gt' for negative stride). As result loop's body is not executed when initial value > limit. Note, such loops are terminated usually by other checks inside loop's body (for example, range checks). Fix: Keep 'ne' test when we can't guarantee during compilation that init < limit. Regression test is added. Tested with Eclipse tests. From tom.rodriguez at oracle.com Mon Jun 20 16:30:08 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 20 Jun 2011 16:30:08 -0700 Subject: Request for reviews (S): 7052494: Eclipse test fails on JDK 7 b142 In-Reply-To: <4DFBE9CE.6050902@oracle.com> References: <4DFBE9CE.6050902@oracle.com> Message-ID: <5C96BE1A-BB72-4D10-86F5-51D0588B7EC4@oracle.com> So the first file is just anti-deltaing those two changes that disallowed other forms which seems fine. The second file looks ok but I think the comment should say "can" instead of "could". tom On Jun 17, 2011, at 4:57 PM, Vladimir Kozlov wrote: > This is for 7u2. > > http://cr.openjdk.java.net/~kvn/7052494/webrev > > Fixed 7052494: Eclipse test fails on JDK 7 b142 > > New code in 5091921 fix incorrectly replaces loop test 'ne' with 'lt' (and with 'gt' for negative stride). As result loop's body is not executed when initial value > limit. Note, such loops are terminated usually by other checks inside loop's body (for example, range checks). > > Fix: > Keep 'ne' test when we can't guarantee during compilation that init < limit. > Regression test is added. > > Tested with Eclipse tests. From vladimir.kozlov at oracle.com Mon Jun 20 16:38:38 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Jun 2011 16:38:38 -0700 Subject: Request for reviews (S): 7052494: Eclipse test fails on JDK 7 b142 In-Reply-To: <5C96BE1A-BB72-4D10-86F5-51D0588B7EC4@oracle.com> References: <4DFBE9CE.6050902@oracle.com> <5C96BE1A-BB72-4D10-86F5-51D0588B7EC4@oracle.com> Message-ID: <4DFFD9FE.8000404@oracle.com> Thank you, Tom On 6/20/11 4:30 PM, Tom Rodriguez wrote: > So the first file is just anti-deltaing those two changes that disallowed other forms which seems fine. Correct. > The second file looks ok but I think the comment should say "can" instead of "could". Agree, I will fix the comment. Thanks, Vladimir > > tom > > On Jun 17, 2011, at 4:57 PM, Vladimir Kozlov wrote: > >> This is for 7u2. >> >> http://cr.openjdk.java.net/~kvn/7052494/webrev >> >> Fixed 7052494: Eclipse test fails on JDK 7 b142 >> >> New code in 5091921 fix incorrectly replaces loop test 'ne' with 'lt' (and with 'gt' for negative stride). As result loop's body is not executed when initial value> limit. Note, such loops are terminated usually by other checks inside loop's body (for example, range checks). >> >> Fix: >> Keep 'ne' test when we can't guarantee during compilation that init< limit. >> Regression test is added. >> >> Tested with Eclipse tests. > From tom.rodriguez at oracle.com Mon Jun 20 17:39:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 20 Jun 2011 17:39:32 -0700 Subject: review for 7056380: VM crashes with SIGSEGV in compiled code Message-ID: <57B249C1-D055-4A73-B64E-5B397AF701AD@oracle.com> http://cr.openjdk.java.net/~never/7056380 55 lines changed: 20 ins; 30 del; 5 mod; 24757 unchg 7056380: VM crashes with SIGSEGV in compiled code Summary: code was using andq reg, imm instead of addq addr, imm Reviewed-by: In the changes for 6961690 a copy of cmpfp_fixup was moved inline but was translated incorrectly so that it was and'ing rsp instead of (rsp). This would cause garbage to be popped into the flags and corrupt rsp. Depending on the OS and values involved you would die at the next of use the flags or later after a return. The fix is to use the right andq form. I also converted the cmpfp_fixup code into MacroAssembler so that it was obviously equivalent. Tested with failing test case and by inspection of the resulting assembly. From vladimir.kozlov at oracle.com Mon Jun 20 18:13:01 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Jun 2011 18:13:01 -0700 Subject: review for 7056380: VM crashes with SIGSEGV in compiled code In-Reply-To: <57B249C1-D055-4A73-B64E-5B397AF701AD@oracle.com> References: <57B249C1-D055-4A73-B64E-5B397AF701AD@oracle.com> Message-ID: <4DFFF01D.8050103@oracle.com> Looks good. Thanks, Vladimir On 6/20/11 5:39 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7056380 > 55 lines changed: 20 ins; 30 del; 5 mod; 24757 unchg > > 7056380: VM crashes with SIGSEGV in compiled code > Summary: code was using andq reg, imm instead of addq addr, imm > Reviewed-by: > > In the changes for 6961690 a copy of cmpfp_fixup was moved inline but > was translated incorrectly so that it was and'ing rsp instead of > (rsp). This would cause garbage to be popped into the flags and > corrupt rsp. Depending on the OS and values involved you would die at > the next of use the flags or later after a return. The fix is to use > the right andq form. I also converted the cmpfp_fixup code into > MacroAssembler so that it was obviously equivalent. Tested with > failing test case and by inspection of the resulting assembly. > From john.r.rose at oracle.com Mon Jun 20 18:17:37 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 20 Jun 2011 18:17:37 -0700 Subject: review for 7056380: VM crashes with SIGSEGV in compiled code In-Reply-To: <57B249C1-D055-4A73-B64E-5B397AF701AD@oracle.com> References: <57B249C1-D055-4A73-B64E-5B397AF701AD@oracle.com> Message-ID: <2603FA3B-4CB5-48EA-8FBD-B76EABEE298C@oracle.com> Looks good. -- John On Jun 20, 2011, at 5:39 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7056380 > 55 lines changed: 20 ins; 30 del; 5 mod; 24757 unchg > > 7056380: VM crashes with SIGSEGV in compiled code > Summary: code was using andq reg, imm instead of addq addr, imm > Reviewed-by: > > In the changes for 6961690 a copy of cmpfp_fixup was moved inline but > was translated incorrectly so that it was and'ing rsp instead of > (rsp). This would cause garbage to be popped into the flags and > corrupt rsp. Depending on the OS and values involved you would die at > the next of use the flags or later after a return. The fix is to use > the right andq form. I also converted the cmpfp_fixup code into > MacroAssembler so that it was obviously equivalent. Tested with > failing test case and by inspection of the resulting assembly. > From vladimir.kozlov at oracle.com Mon Jun 20 22:54:54 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 21 Jun 2011 05:54:54 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7052494: Eclipse test fails on JDK 7 b142 Message-ID: <20110621055456.90245471B2@hg.openjdk.java.net> Changeset: aacaff365100 Author: kvn Date: 2011-06-20 16:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aacaff365100 7052494: Eclipse test fails on JDK 7 b142 Summary: Keep 'ne' test in Counted loop when we can't guarantee during compilation that init < limit. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp + test/compiler/7052494/Test7052494.java From christian.thalinger at oracle.com Tue Jun 21 00:04:47 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 21 Jun 2011 09:04:47 +0200 Subject: review for 7056380: VM crashes with SIGSEGV in compiled code In-Reply-To: <57B249C1-D055-4A73-B64E-5B397AF701AD@oracle.com> References: <57B249C1-D055-4A73-B64E-5B397AF701AD@oracle.com> Message-ID: <96FBF62B-DAE8-4309-BFEA-8EE8F15476F0@oracle.com> On Jun 21, 2011, at 2:39 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7056380 > 55 lines changed: 20 ins; 30 del; 5 mod; 24757 unchg > > 7056380: VM crashes with SIGSEGV in compiled code > Summary: code was using andq reg, imm instead of addq addr, imm > Reviewed-by: > > In the changes for 6961690 a copy of cmpfp_fixup was moved inline but > was translated incorrectly so that it was and'ing rsp instead of > (rsp). This would cause garbage to be popped into the flags and > corrupt rsp. Depending on the OS and values involved you would die at > the next of use the flags or later after a return. The fix is to use > the right andq form. I also converted the cmpfp_fixup code into > MacroAssembler so that it was obviously equivalent. Tested with > failing test case and by inspection of the resulting assembly. Oops. Thanks for fixing this. -- Christian From tom.rodriguez at oracle.com Tue Jun 21 11:07:55 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 21 Jun 2011 18:07:55 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7056380: VM crashes with SIGSEGV in compiled code Message-ID: <20110621180800.E0705471E2@hg.openjdk.java.net> Changeset: de6a837d75cf Author: never Date: 2011-06-21 09:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/de6a837d75cf 7056380: VM crashes with SIGSEGV in compiled code Summary: code was using andq reg, imm instead of addq addr, imm Reviewed-by: kvn, jrose, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_64.ad From igor.veresov at oracle.com Tue Jun 21 23:47:22 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 21 Jun 2011 23:47:22 -0700 Subject: review(M): 7057120: Tiered: Allow C1 to inline methods with loops Message-ID: <4E018FFA.6020200@oracle.com> This allows inlining of methods with loops by C1 on levels with profiling (2 and 3). The solution is to recompile the enclosing methods without inlining of the method that has OSRed to level 4 or recompile the enclosing method at level 4. There's no significant impact on performance because of these changes. Webrev: http://cr.openjdk.java.net/~iveresov/7057120/webrev.00/ The change is for 7u2. Thanks, igor From vladimir.kozlov at oracle.com Wed Jun 22 09:51:54 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2011 09:51:54 -0700 Subject: review(M): 7057120: Tiered: Allow C1 to inline methods with loops In-Reply-To: <4E018FFA.6020200@oracle.com> References: <4E018FFA.6020200@oracle.com> Message-ID: <4E021DAA.9060307@oracle.com> Can you explain why in counter_overflow_helper() (c1_Runtime1.cpp) you expect the caller (enclosing_method) to be nmethod? Could you rename should_not_inline() to should_not_inline_for_profile() or something since it is only for C1 compilation with profiling? Add {} for else: + } else + if (next_level != CompLevel_full_optimization) { + // next_level is not full opt, so we need to recompile the + // enclosing method without the inlinee + cur_level = CompLevel_none; + make_not_entrant = true; + } + if (make_not_entrant) { I don't understand why you need to recompile caller. It comes from a different frame so it did not inline callee before : + if (max_osr_level == CompLevel_full_optimization) { + // The inlinee OSRed to full opt, we need to modify the enclosing method to avoid deopts Also next check should be at the beginning of this logic since "Fix up" could trigger unneeded recompilation: + if (!CompileBroker::compilation_is_in_queue(mh, InvocationEntryBci) && cur_level != next_level) { Vladimir Igor Veresov wrote: > This allows inlining of methods with loops by C1 on levels with > profiling (2 and 3). The solution is to recompile the enclosing methods > without inlining of the method that has OSRed to level 4 or recompile > the enclosing method at level 4. > > There's no significant impact on performance because of these changes. > > Webrev: http://cr.openjdk.java.net/~iveresov/7057120/webrev.00/ > > The change is for 7u2. > > Thanks, > igor From tom.rodriguez at oracle.com Wed Jun 22 10:41:01 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Jun 2011 10:41:01 -0700 Subject: review for 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb Message-ID: http://cr.openjdk.java.net/~never/7057587 40 lines changed: 6 ins; 0 del; 34 mod; 4861 unchg 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb Summary: don't skip receiver when GC'ing compiled invokedynamic callsites Reviewed-by: When GC'ing at a call site during resolution the arguments to the call have to be handled specially. In most cases the implicit receiver to method handle invoke is ignored but in this case it must be treated as real so that it is properly GC'ed. Tested with failing test from report. Also ran jck, regression tests and vm.mlvm tests. I also included a fix to the inline level printing. For method handle invokes we don't want to count them against MaxInlineLevel and previously this was done by adding a bias to the inline_depth. This screwed up the indenting making the inlining output unreadable. Instead we should keep the depth count consistent and adjust the max inline level for the subtree. This is done by keeping that value in the InlineTree. inline_depth was renamed to inline_level to be consistent with MaxInlineLevel. From christian.thalinger at oracle.com Wed Jun 22 12:00:50 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 22 Jun 2011 21:00:50 +0200 Subject: review for 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb In-Reply-To: References: Message-ID: On Jun 22, 2011, at 7:41 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7057587 > 40 lines changed: 6 ins; 0 del; 34 mod; 4861 unchg > > 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb > Summary: don't skip receiver when GC'ing compiled invokedynamic callsites > Reviewed-by: > > When GC'ing at a call site during resolution the arguments to the call > have to be handled specially. In most cases the implicit receiver to > method handle invoke is ignored but in this case it must be treated as > real so that it is properly GC'ed. Tested with failing test from > report. Also ran jck, regression tests and vm.mlvm tests. > > I also included a fix to the inline level printing. For method handle > invokes we don't want to count them against MaxInlineLevel and > previously this was done by adding a bias to the inline_depth. This > screwed up the indenting making the inlining output unreadable. > Instead we should keep the depth count consistent and adjust the max > inline level for the subtree. This is done by keeping that value in > the InlineTree. inline_depth was renamed to inline_level to be > consistent with MaxInlineLevel. Looks good. -- Christian From vladimir.kozlov at oracle.com Wed Jun 22 12:23:44 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2011 12:23:44 -0700 Subject: review for 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb In-Reply-To: References: Message-ID: <4E024140.2080400@oracle.com> Is it possible to add an assert in nmethod::preserve_callee_argument_oops() to verify that invokedynamic has a receiver? Otherwise looks good. thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7057587 > 40 lines changed: 6 ins; 0 del; 34 mod; 4861 unchg > > 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb > Summary: don't skip receiver when GC'ing compiled invokedynamic callsites > Reviewed-by: > > When GC'ing at a call site during resolution the arguments to the call > have to be handled specially. In most cases the implicit receiver to > method handle invoke is ignored but in this case it must be treated as > real so that it is properly GC'ed. Tested with failing test from > report. Also ran jck, regression tests and vm.mlvm tests. > > I also included a fix to the inline level printing. For method handle > invokes we don't want to count them against MaxInlineLevel and > previously this was done by adding a bias to the inline_depth. This > screwed up the indenting making the inlining output unreadable. > Instead we should keep the depth count consistent and adjust the max > inline level for the subtree. This is done by keeping that value in > the InlineTree. inline_depth was renamed to inline_level to be > consistent with MaxInlineLevel. > From tom.rodriguez at oracle.com Wed Jun 22 12:32:49 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Jun 2011 12:32:49 -0700 Subject: review for 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb In-Reply-To: <4E024140.2080400@oracle.com> References: <4E024140.2080400@oracle.com> Message-ID: <22DD3F26-BC6D-4467-9288-106F025E0EE7@oracle.com> On Jun 22, 2011, at 12:23 PM, Vladimir Kozlov wrote: > Is it possible to add an assert in nmethod::preserve_callee_argument_oops() to verify that invokedynamic has a receiver? Do you mean to verify that the receiver is really a valid oop or something else? tom > > Otherwise looks good. > > thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7057587 >> 40 lines changed: 6 ins; 0 del; 34 mod; 4861 unchg >> 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb >> Summary: don't skip receiver when GC'ing compiled invokedynamic callsites >> Reviewed-by: >> When GC'ing at a call site during resolution the arguments to the call >> have to be handled specially. In most cases the implicit receiver to >> method handle invoke is ignored but in this case it must be treated as >> real so that it is properly GC'ed. Tested with failing test from >> report. Also ran jck, regression tests and vm.mlvm tests. >> I also included a fix to the inline level printing. For method handle >> invokes we don't want to count them against MaxInlineLevel and >> previously this was done by adding a bias to the inline_depth. This >> screwed up the indenting making the inlining output unreadable. >> Instead we should keep the depth count consistent and adjust the max >> inline level for the subtree. This is done by keeping that value in >> the InlineTree. inline_depth was renamed to inline_level to be >> consistent with MaxInlineLevel. From vladimir.kozlov at oracle.com Wed Jun 22 14:06:34 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2011 14:06:34 -0700 Subject: review for 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb In-Reply-To: <22DD3F26-BC6D-4467-9288-106F025E0EE7@oracle.com> References: <4E024140.2080400@oracle.com> <22DD3F26-BC6D-4467-9288-106F025E0EE7@oracle.com> Message-ID: <4E02595A.9060106@oracle.com> Tom Rodriguez wrote: > On Jun 22, 2011, at 12:23 PM, Vladimir Kozlov wrote: > >> Is it possible to add an assert in nmethod::preserve_callee_argument_oops() to verify that invokedynamic has a receiver? > > Do you mean to verify that the receiver is really a valid oop or something else? Yes, check for a valid oop since it will be GC'ed. What confused me is the sentence: "at this point". Does it mean that at some point invokedynamic does not have a valid receiver? Thanks, Vladimir > > tom > >> Otherwise looks good. >> >> thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7057587 >>> 40 lines changed: 6 ins; 0 del; 34 mod; 4861 unchg >>> 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb >>> Summary: don't skip receiver when GC'ing compiled invokedynamic callsites >>> Reviewed-by: >>> When GC'ing at a call site during resolution the arguments to the call >>> have to be handled specially. In most cases the implicit receiver to >>> method handle invoke is ignored but in this case it must be treated as >>> real so that it is properly GC'ed. Tested with failing test from >>> report. Also ran jck, regression tests and vm.mlvm tests. >>> I also included a fix to the inline level printing. For method handle >>> invokes we don't want to count them against MaxInlineLevel and >>> previously this was done by adding a bias to the inline_depth. This >>> screwed up the indenting making the inlining output unreadable. >>> Instead we should keep the depth count consistent and adjust the max >>> inline level for the subtree. This is done by keeping that value in >>> the InlineTree. inline_depth was renamed to inline_level to be >>> consistent with MaxInlineLevel. > From tom.rodriguez at oracle.com Wed Jun 22 14:12:08 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Jun 2011 14:12:08 -0700 Subject: review for 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb In-Reply-To: <4E02595A.9060106@oracle.com> References: <4E024140.2080400@oracle.com> <22DD3F26-BC6D-4467-9288-106F025E0EE7@oracle.com> <4E02595A.9060106@oracle.com> Message-ID: On Jun 22, 2011, at 2:06 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> On Jun 22, 2011, at 12:23 PM, Vladimir Kozlov wrote: >>> Is it possible to add an assert in nmethod::preserve_callee_argument_oops() to verify that invokedynamic has a receiver? >> Do you mean to verify that the receiver is really a valid oop or something else? > > Yes, check for a valid oop since it will be GC'ed. What confused me is the sentence: "at this point". Does it mean that at some point invokedynamic does not have a valid receiver? Yes that's confusing. At a compiled call site the receiver is always there at a point where we might gc. In other contexts the order of operations might be different. In the interpreter the implicit receiver is injected after resolution. I think this might get cleaned up later to be more consistent. tom > > Thanks, > Vladimir > >> tom >>> Otherwise looks good. >>> >>> thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7057587 >>>> 40 lines changed: 6 ins; 0 del; 34 mod; 4861 unchg >>>> 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb >>>> Summary: don't skip receiver when GC'ing compiled invokedynamic callsites >>>> Reviewed-by: >>>> When GC'ing at a call site during resolution the arguments to the call >>>> have to be handled specially. In most cases the implicit receiver to >>>> method handle invoke is ignored but in this case it must be treated as >>>> real so that it is properly GC'ed. Tested with failing test from >>>> report. Also ran jck, regression tests and vm.mlvm tests. >>>> I also included a fix to the inline level printing. For method handle >>>> invokes we don't want to count them against MaxInlineLevel and >>>> previously this was done by adding a bias to the inline_depth. This >>>> screwed up the indenting making the inlining output unreadable. >>>> Instead we should keep the depth count consistent and adjust the max >>>> inline level for the subtree. This is done by keeping that value in >>>> the InlineTree. inline_depth was renamed to inline_level to be >>>> consistent with MaxInlineLevel. From tom.rodriguez at oracle.com Wed Jun 22 14:35:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Jun 2011 14:35:19 -0700 Subject: review for 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb In-Reply-To: References: <4E024140.2080400@oracle.com> <22DD3F26-BC6D-4467-9288-106F025E0EE7@oracle.com> <4E02595A.9060106@oracle.com> Message-ID: <3B237724-6F18-4EAD-9C44-257D31900BD7@oracle.com> I updated the comment to this: diff -r de6a837d75cf src/share/vm/code/nmethod.cpp --- a/src/share/vm/code/nmethod.cpp +++ b/src/share/vm/code/nmethod.cpp @@ -1832,7 +1832,9 @@ if (!method()->is_native()) { SimpleScopeDesc ssd(this, fr.pc()); Bytecode_invoke call(ssd.method(), ssd.bci()); - bool has_receiver = call.has_receiver(); + // compiled invokedynamic call sites have an implicit receiver at + // resolution time, so make sure it gets GC'ed. + bool has_receiver = !call.is_invokestatic(); Symbol* signature = call.signature(); fr.oops_compiled_arguments_do(signature, has_receiver, reg_map, f); } tom On Jun 22, 2011, at 2:12 PM, Tom Rodriguez wrote: > > On Jun 22, 2011, at 2:06 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>> On Jun 22, 2011, at 12:23 PM, Vladimir Kozlov wrote: >>>> Is it possible to add an assert in nmethod::preserve_callee_argument_oops() to verify that invokedynamic has a receiver? >>> Do you mean to verify that the receiver is really a valid oop or something else? >> >> Yes, check for a valid oop since it will be GC'ed. What confused me is the sentence: "at this point". Does it mean that at some point invokedynamic does not have a valid receiver? > > Yes that's confusing. At a compiled call site the receiver is always there at a point where we might gc. In other contexts the order of operations might be different. In the interpreter the implicit receiver is injected after resolution. I think this might get cleaned up later to be more consistent. > > tom > >> >> Thanks, >> Vladimir >> >>> tom >>>> Otherwise looks good. >>>> >>>> thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/7057587 >>>>> 40 lines changed: 6 ins; 0 del; 34 mod; 4861 unchg >>>>> 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb >>>>> Summary: don't skip receiver when GC'ing compiled invokedynamic callsites >>>>> Reviewed-by: >>>>> When GC'ing at a call site during resolution the arguments to the call >>>>> have to be handled specially. In most cases the implicit receiver to >>>>> method handle invoke is ignored but in this case it must be treated as >>>>> real so that it is properly GC'ed. Tested with failing test from >>>>> report. Also ran jck, regression tests and vm.mlvm tests. >>>>> I also included a fix to the inline level printing. For method handle >>>>> invokes we don't want to count them against MaxInlineLevel and >>>>> previously this was done by adding a bias to the inline_depth. This >>>>> screwed up the indenting making the inlining output unreadable. >>>>> Instead we should keep the depth count consistent and adjust the max >>>>> inline level for the subtree. This is done by keeping that value in >>>>> the InlineTree. inline_depth was renamed to inline_level to be >>>>> consistent with MaxInlineLevel. > From igor.veresov at oracle.com Wed Jun 22 14:49:55 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 22 Jun 2011 14:49:55 -0700 Subject: review(M): 7057120: Tiered: Allow C1 to inline methods with loops In-Reply-To: <4E021DAA.9060307@oracle.com> References: <4E018FFA.6020200@oracle.com> <4E021DAA.9060307@oracle.com> Message-ID: <4E026383.10300@oracle.com> Thanks for the review, Vladimir! Webrev updated. Please find the replies inline. On 6/22/11 9:51 AM, Vladimir Kozlov wrote: > Can you explain why in counter_overflow_helper() (c1_Runtime1.cpp) you > expect the caller (enclosing_method) to be nmethod? It's not the caller. The enclosing_method is the actual method to which the nmethod belongs. In other words: enclosing_method is a method who's frame is current on stack and "method" is possibly the inlinee inside the enclosing method that generated the event. > > Could you rename should_not_inline() to should_not_inline_for_profile() > or something since it is only for C1 compilation with profiling? > I'd rather leave it generalized if you're not totally against it. We can use it later as a wrapper for oracle to control inlining in both compilers. > Add {} for else: > > + } else > + if (next_level != CompLevel_full_optimization) { > + // next_level is not full opt, so we need to recompile the > + // enclosing method without the inlinee > + cur_level = CompLevel_none; > + make_not_entrant = true; > + } > + if (make_not_entrant) { > Ok. > I don't understand why you need to recompile caller. It comes from a > different frame so it did not inline callee before : > > + if (max_osr_level == CompLevel_full_optimization) { > + // The inlinee OSRed to full opt, we need to modify the enclosing > method to avoid deopts > If we're are in this clause (that is we passed the mh() != imh() check) that means that the event was generated by the imh() that was inlined in mh(). So, we need to recompile mh() because otherwise we would be still executing the inline version of imh() and would be deoptimizing and switching to the full opt version. > Also next check should be at the beginning of this logic since "Fix up" > could trigger unneeded recompilation: > > + if (!CompileBroker::compilation_is_in_queue(mh, InvocationEntryBci) && > cur_level != next_level) { But that would mean that we won't be able to make mh() non-entrant in case mh() is in the queue already. I move the fix up down since the code that makes the enclosing method non-entrant doesn't depend on it. igor > > Vladimir > > Igor Veresov wrote: >> This allows inlining of methods with loops by C1 on levels with >> profiling (2 and 3). The solution is to recompile the enclosing >> methods without inlining of the method that has OSRed to level 4 or >> recompile the enclosing method at level 4. >> >> There's no significant impact on performance because of these changes. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7057120/webrev.00/ >> >> The change is for 7u2. >> >> Thanks, >> igor From vladimir.kozlov at oracle.com Wed Jun 22 14:50:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2011 14:50:33 -0700 Subject: review for 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb In-Reply-To: <3B237724-6F18-4EAD-9C44-257D31900BD7@oracle.com> References: <4E024140.2080400@oracle.com> <22DD3F26-BC6D-4467-9288-106F025E0EE7@oracle.com> <4E02595A.9060106@oracle.com> <3B237724-6F18-4EAD-9C44-257D31900BD7@oracle.com> Message-ID: <4E0263A9.5090702@oracle.com> Good. Vladimir Tom Rodriguez wrote: > I updated the comment to this: > > diff -r de6a837d75cf src/share/vm/code/nmethod.cpp > --- a/src/share/vm/code/nmethod.cpp > +++ b/src/share/vm/code/nmethod.cpp > @@ -1832,7 +1832,9 @@ > if (!method()->is_native()) { > SimpleScopeDesc ssd(this, fr.pc()); > Bytecode_invoke call(ssd.method(), ssd.bci()); > - bool has_receiver = call.has_receiver(); > + // compiled invokedynamic call sites have an implicit receiver at > + // resolution time, so make sure it gets GC'ed. > + bool has_receiver = !call.is_invokestatic(); > Symbol* signature = call.signature(); > fr.oops_compiled_arguments_do(signature, has_receiver, reg_map, f); > } > > tom > > On Jun 22, 2011, at 2:12 PM, Tom Rodriguez wrote: > >> On Jun 22, 2011, at 2:06 PM, Vladimir Kozlov wrote: >> >>> Tom Rodriguez wrote: >>>> On Jun 22, 2011, at 12:23 PM, Vladimir Kozlov wrote: >>>>> Is it possible to add an assert in nmethod::preserve_callee_argument_oops() to verify that invokedynamic has a receiver? >>>> Do you mean to verify that the receiver is really a valid oop or something else? >>> Yes, check for a valid oop since it will be GC'ed. What confused me is the sentence: "at this point". Does it mean that at some point invokedynamic does not have a valid receiver? >> Yes that's confusing. At a compiled call site the receiver is always there at a point where we might gc. In other contexts the order of operations might be different. In the interpreter the implicit receiver is injected after resolution. I think this might get cleaned up later to be more consistent. >> >> tom >> >>> Thanks, >>> Vladimir >>> >>>> tom >>>>> Otherwise looks good. >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/7057587 >>>>>> 40 lines changed: 6 ins; 0 del; 34 mod; 4861 unchg >>>>>> 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb >>>>>> Summary: don't skip receiver when GC'ing compiled invokedynamic callsites >>>>>> Reviewed-by: >>>>>> When GC'ing at a call site during resolution the arguments to the call >>>>>> have to be handled specially. In most cases the implicit receiver to >>>>>> method handle invoke is ignored but in this case it must be treated as >>>>>> real so that it is properly GC'ed. Tested with failing test from >>>>>> report. Also ran jck, regression tests and vm.mlvm tests. >>>>>> I also included a fix to the inline level printing. For method handle >>>>>> invokes we don't want to count them against MaxInlineLevel and >>>>>> previously this was done by adding a bias to the inline_depth. This >>>>>> screwed up the indenting making the inlining output unreadable. >>>>>> Instead we should keep the depth count consistent and adjust the max >>>>>> inline level for the subtree. This is done by keeping that value in >>>>>> the InlineTree. inline_depth was renamed to inline_level to be >>>>>> consistent with MaxInlineLevel. > From tom.rodriguez at oracle.com Wed Jun 22 14:52:06 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Jun 2011 14:52:06 -0700 Subject: review for 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb In-Reply-To: <4E0263A9.5090702@oracle.com> References: <4E024140.2080400@oracle.com> <22DD3F26-BC6D-4467-9288-106F025E0EE7@oracle.com> <4E02595A.9060106@oracle.com> <3B237724-6F18-4EAD-9C44-257D31900BD7@oracle.com> <4E0263A9.5090702@oracle.com> Message-ID: <9CB8DBCD-AC62-423A-BFB4-C782E3CF78F1@oracle.com> Thanks for the reviews. tom On Jun 22, 2011, at 2:50 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > Tom Rodriguez wrote: >> I updated the comment to this: >> diff -r de6a837d75cf src/share/vm/code/nmethod.cpp --- a/src/share/vm/code/nmethod.cpp +++ b/src/share/vm/code/nmethod.cpp @@ -1832,7 +1832,9 @@ >> if (!method()->is_native()) { SimpleScopeDesc ssd(this, fr.pc()); Bytecode_invoke call(ssd.method(), ssd.bci()); - bool has_receiver = call.has_receiver(); + // compiled invokedynamic call sites have an implicit receiver at + // resolution time, so make sure it gets GC'ed. + bool has_receiver = !call.is_invokestatic(); Symbol* signature = call.signature(); fr.oops_compiled_arguments_do(signature, has_receiver, reg_map, f); } >> tom >> On Jun 22, 2011, at 2:12 PM, Tom Rodriguez wrote: >>> On Jun 22, 2011, at 2:06 PM, Vladimir Kozlov wrote: >>> >>>> Tom Rodriguez wrote: >>>>> On Jun 22, 2011, at 12:23 PM, Vladimir Kozlov wrote: >>>>>> Is it possible to add an assert in nmethod::preserve_callee_argument_oops() to verify that invokedynamic has a receiver? >>>>> Do you mean to verify that the receiver is really a valid oop or something else? >>>> Yes, check for a valid oop since it will be GC'ed. What confused me is the sentence: "at this point". Does it mean that at some point invokedynamic does not have a valid receiver? >>> Yes that's confusing. At a compiled call site the receiver is always there at a point where we might gc. In other contexts the order of operations might be different. In the interpreter the implicit receiver is injected after resolution. I think this might get cleaned up later to be more consistent. >>> >>> tom >>> >>>> Thanks, >>>> Vladimir >>>> >>>>> tom >>>>>> Otherwise looks good. >>>>>> >>>>>> thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> http://cr.openjdk.java.net/~never/7057587 >>>>>>> 40 lines changed: 6 ins; 0 del; 34 mod; 4861 unchg >>>>>>> 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb >>>>>>> Summary: don't skip receiver when GC'ing compiled invokedynamic callsites >>>>>>> Reviewed-by: >>>>>>> When GC'ing at a call site during resolution the arguments to the call >>>>>>> have to be handled specially. In most cases the implicit receiver to >>>>>>> method handle invoke is ignored but in this case it must be treated as >>>>>>> real so that it is properly GC'ed. Tested with failing test from >>>>>>> report. Also ran jck, regression tests and vm.mlvm tests. >>>>>>> I also included a fix to the inline level printing. For method handle >>>>>>> invokes we don't want to count them against MaxInlineLevel and >>>>>>> previously this was done by adding a bias to the inline_depth. This >>>>>>> screwed up the indenting making the inlining output unreadable. >>>>>>> Instead we should keep the depth count consistent and adjust the max >>>>>>> inline level for the subtree. This is done by keeping that value in >>>>>>> the InlineTree. inline_depth was renamed to inline_level to be >>>>>>> consistent with MaxInlineLevel. From vladimir.kozlov at oracle.com Wed Jun 22 15:08:53 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2011 15:08:53 -0700 Subject: review(M): 7057120: Tiered: Allow C1 to inline methods with loops In-Reply-To: <4E026383.10300@oracle.com> References: <4E018FFA.6020200@oracle.com> <4E021DAA.9060307@oracle.com> <4E026383.10300@oracle.com> Message-ID: <4E0267F5.4010407@oracle.com> Igor Veresov wrote: > Thanks for the review, Vladimir! Webrev updated. Please find the replies > inline. > > On 6/22/11 9:51 AM, Vladimir Kozlov wrote: >> Can you explain why in counter_overflow_helper() (c1_Runtime1.cpp) you >> expect the caller (enclosing_method) to be nmethod? > > It's not the caller. The enclosing_method is the actual method to which > the nmethod belongs. In other words: enclosing_method is a method who's > frame is current on stack and "method" is possibly the inlinee inside > the enclosing method that generated the event. It would be better to say this in the comment for counter_overflow_helper() method since the current comment does not help at all. I don't see anything related to safepoint. > >> >> Could you rename should_not_inline() to should_not_inline_for_profile() >> or something since it is only for C1 compilation with profiling? >> > > I'd rather leave it generalized if you're not totally against it. We can > use it later as a wrapper for oracle to control inlining in both compilers. OK. > >> I don't understand why you need to recompile caller. It comes from a >> different frame so it did not inline callee before : >> >> + if (max_osr_level == CompLevel_full_optimization) { >> + // The inlinee OSRed to full opt, we need to modify the enclosing >> method to avoid deopts >> > > If we're are in this clause (that is we passed the mh() != imh() check) > that means that the event was generated by the imh() that was inlined in > mh(). So, we need to recompile mh() because otherwise we would be still > executing the inline version of imh() and would be deoptimizing and > switching to the full opt version. Add this as a comment instead of "// If there is an enclosing method" > >> Also next check should be at the beginning of this logic since "Fix up" >> could trigger unneeded recompilation: >> >> + if (!CompileBroker::compilation_is_in_queue(mh, InvocationEntryBci) && >> cur_level != next_level) { > > But that would mean that we won't be able to make mh() non-entrant in > case mh() is in the queue already. I move the fix up down since the code > that makes the enclosing method non-entrant doesn't depend on it. OK. Thanks, Vladimir > > > igor > >> >> Vladimir >> >> Igor Veresov wrote: >>> This allows inlining of methods with loops by C1 on levels with >>> profiling (2 and 3). The solution is to recompile the enclosing >>> methods without inlining of the method that has OSRed to level 4 or >>> recompile the enclosing method at level 4. >>> >>> There's no significant impact on performance because of these changes. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/7057120/webrev.00/ >>> >>> The change is for 7u2. >>> >>> Thanks, >>> igor > From tom.rodriguez at oracle.com Wed Jun 22 16:51:38 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 22 Jun 2011 23:51:38 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb Message-ID: <20110622235141.7DBA047249@hg.openjdk.java.net> Changeset: aabf25fa3f05 Author: never Date: 2011-06-22 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aabf25fa3f05 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb Summary: don't skip receiver when GC'ing compiled invokedynamic callsites Reviewed-by: twisti, kvn, jrose ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp From igor.veresov at oracle.com Wed Jun 22 17:12:48 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 22 Jun 2011 17:12:48 -0700 Subject: review(M): 7057120: Tiered: Allow C1 to inline methods with loops In-Reply-To: <4E0267F5.4010407@oracle.com> References: <4E018FFA.6020200@oracle.com> <4E021DAA.9060307@oracle.com> <4E026383.10300@oracle.com> <4E0267F5.4010407@oracle.com> Message-ID: <4E028500.3050805@oracle.com> On 6/22/11 3:08 PM, Vladimir Kozlov wrote: > Igor Veresov wrote: >> Thanks for the review, Vladimir! Webrev updated. Please find the >> replies inline. >> >> On 6/22/11 9:51 AM, Vladimir Kozlov wrote: >>> Can you explain why in counter_overflow_helper() (c1_Runtime1.cpp) you >>> expect the caller (enclosing_method) to be nmethod? >> >> It's not the caller. The enclosing_method is the actual method to >> which the nmethod belongs. In other words: enclosing_method is a >> method who's frame is current on stack and "method" is possibly the >> inlinee inside the enclosing method that generated the event. > > It would be better to say this in the comment for > counter_overflow_helper() method since the current comment does not help > at all. I don't see > anything related to safepoint. Done, webrev updated. igor From vladimir.kozlov at oracle.com Wed Jun 22 17:24:48 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2011 17:24:48 -0700 Subject: review(M): 7057120: Tiered: Allow C1 to inline methods with loops In-Reply-To: <4E028500.3050805@oracle.com> References: <4E018FFA.6020200@oracle.com> <4E021DAA.9060307@oracle.com> <4E026383.10300@oracle.com> <4E0267F5.4010407@oracle.com> <4E028500.3050805@oracle.com> Message-ID: <4E0287D0.6080405@oracle.com> Good. Vladimir Igor Veresov wrote: > On 6/22/11 3:08 PM, Vladimir Kozlov wrote: >> Igor Veresov wrote: >>> Thanks for the review, Vladimir! Webrev updated. Please find the >>> replies inline. >>> >>> On 6/22/11 9:51 AM, Vladimir Kozlov wrote: >>>> Can you explain why in counter_overflow_helper() (c1_Runtime1.cpp) you >>>> expect the caller (enclosing_method) to be nmethod? >>> >>> It's not the caller. The enclosing_method is the actual method to >>> which the nmethod belongs. In other words: enclosing_method is a >>> method who's frame is current on stack and "method" is possibly the >>> inlinee inside the enclosing method that generated the event. >> >> It would be better to say this in the comment for >> counter_overflow_helper() method since the current comment does not help >> at all. I don't see >> anything related to safepoint. > > Done, webrev updated. > > igor From igor.veresov at oracle.com Wed Jun 22 17:34:59 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 22 Jun 2011 17:34:59 -0700 Subject: review(M): 7057120: Tiered: Allow C1 to inline methods with loops In-Reply-To: <4E0287D0.6080405@oracle.com> References: <4E018FFA.6020200@oracle.com> <4E021DAA.9060307@oracle.com> <4E026383.10300@oracle.com> <4E0267F5.4010407@oracle.com> <4E028500.3050805@oracle.com> <4E0287D0.6080405@oracle.com> Message-ID: <4E028A33.20700@oracle.com> Thanks, Vladimir! igor On 6/22/11 5:24 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > Igor Veresov wrote: >> On 6/22/11 3:08 PM, Vladimir Kozlov wrote: >>> Igor Veresov wrote: >>>> Thanks for the review, Vladimir! Webrev updated. Please find the >>>> replies inline. >>>> >>>> On 6/22/11 9:51 AM, Vladimir Kozlov wrote: >>>>> Can you explain why in counter_overflow_helper() (c1_Runtime1.cpp) you >>>>> expect the caller (enclosing_method) to be nmethod? >>>> >>>> It's not the caller. The enclosing_method is the actual method to >>>> which the nmethod belongs. In other words: enclosing_method is a >>>> method who's frame is current on stack and "method" is possibly the >>>> inlinee inside the enclosing method that generated the event. >>> >>> It would be better to say this in the comment for >>> counter_overflow_helper() method since the current comment does not help >>> at all. I don't see >>> anything related to safepoint. >> >> Done, webrev updated. >> >> igor From john.r.rose at oracle.com Wed Jun 22 17:37:36 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Jun 2011 17:37:36 -0700 Subject: review request (M): 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path Message-ID: This is a possible fix for a JSR 292 bug in JDK 7. http://cr.openjdk.java.net/~jrose/7056328/webrev.00/ Bytecodes produced by MethodHandleWalk will incorrectly scope names off the boot class path. The fix is to specially process the constant pool of such bytecodes, by "pre-resolving" the affected entries. The fix includes new stress test logic (debug build only) for running every method handle created through MHW and the JIT. http://cr.openjdk.java.net/~jrose/7056328/webrev.00/ Testing so far: - JDK regression tests with and without the new stress modes - Tom's local tests (on previous version) - fixes customer problem (Ola Bini's NoClassDefFound error) From tom.rodriguez at oracle.com Wed Jun 22 23:11:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Jun 2011 23:11:59 -0700 Subject: review request (M): 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path In-Reply-To: References: Message-ID: Overall this looks good. It's unfortunate we have to jump through so many hoops for this. What's with these new constants? + ETF_FORCE_DIRECT_HANDLE = 64, + ETF_COMPILE_DIRECT_HANDLE = 65, Are they used over in the JDK side? tom On Jun 22, 2011, at 5:37 PM, John Rose wrote: > This is a possible fix for a JSR 292 bug in JDK 7. > > http://cr.openjdk.java.net/~jrose/7056328/webrev.00/ > > Bytecodes produced by MethodHandleWalk will incorrectly scope names off the boot class path. The fix is to specially process the constant pool of such bytecodes, by "pre-resolving" the affected entries. > > The fix includes new stress test logic (debug build only) for running every method handle created through MHW and the JIT. > > http://cr.openjdk.java.net/~jrose/7056328/webrev.00/ > > Testing so far: > - JDK regression tests with and without the new stress modes > - Tom's local tests (on previous version) > - fixes customer problem (Ola Bini's NoClassDefFound error) > From john.r.rose at oracle.com Wed Jun 22 23:59:01 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Jun 2011 23:59:01 -0700 Subject: review request (M): 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path In-Reply-To: References: Message-ID: <2CA8EDA3-3E14-4A5C-9F11-9B8619B6D68D@oracle.com> On Jun 22, 2011, at 11:11 PM, Tom Rodriguez wrote: > Overall this looks good. It's unfortunate we have to jump through so many hoops for this. What's with these new constants? > > + ETF_FORCE_DIRECT_HANDLE = 64, > + ETF_COMPILE_DIRECT_HANDLE = 65, > > Are they used over in the JDK side? They are used in stress testing; see this patch: http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-hackdirect.patch This patch is not going into JDK 7, but it is a useful stress test. It allows us to compile and run every MH that receives an invokeWithArguments. The JVM hook (which is package private) uses the above constants. -- John From john.r.rose at oracle.com Thu Jun 23 00:21:44 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 23 Jun 2011 00:21:44 -0700 Subject: review request (M): 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path In-Reply-To: <2CA8EDA3-3E14-4A5C-9F11-9B8619B6D68D@oracle.com> References: <2CA8EDA3-3E14-4A5C-9F11-9B8619B6D68D@oracle.com> Message-ID: <52314FB0-9A07-47D7-A365-0E3AFF48855D@oracle.com> On Jun 22, 2011, at 11:59 PM, John Rose wrote: > On Jun 22, 2011, at 11:11 PM, Tom Rodriguez wrote: > >> Overall this looks good. It's unfortunate we have to jump through so many hoops for this. What's with these new constants? >> >> + ETF_FORCE_DIRECT_HANDLE = 64, >> + ETF_COMPILE_DIRECT_HANDLE = 65, >> >> Are they used over in the JDK side? > > They are used in stress testing; see this patch: > http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-hackdirect.patch > > This patch is not going into JDK 7, but it is a useful stress test. It allows us to compile and run every MH that receives an invokeWithArguments. The JVM hook (which is package private) uses the above constants. > > -- John I'm working through several small bugs that the stress test uncovered. Will repost my webrev when done. -- John From john.r.rose at oracle.com Thu Jun 23 00:48:59 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 23 Jun 2011 00:48:59 -0700 Subject: review request (M): 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path In-Reply-To: <52314FB0-9A07-47D7-A365-0E3AFF48855D@oracle.com> References: <2CA8EDA3-3E14-4A5C-9F11-9B8619B6D68D@oracle.com> <52314FB0-9A07-47D7-A365-0E3AFF48855D@oracle.com> Message-ID: <67DEA81C-321F-4F44-AC14-FABFFEC5E947@oracle.com> On Jun 23, 2011, at 12:21 AM, John Rose wrote: > I'm working through several small bugs that the stress test uncovered. Will repost my webrev when done. -- John Here's the update: http://cr.openjdk.java.net/~jrose/7056328/webrev.01 http://cr.openjdk.java.net/~jrose/7056328/webrev.01/00-to-01.diff Stress testing uncovered a number of small bugs that are eventually going to bite us when users create invokedynamic bindings that get compiled, if those bindings use method handle graphs similar to those in the unit tests. - JVM_CONSTANT_Object entries not handled by sparc and x86 interpreters (hazard after deoptimization of JIT-ed indy instructions) - collect/fold adapters call their recursive MH using relaxed typing (erased signatures), which is tricky to represent in bytecodes - bytecode for spread adapters unpacked the arguments in reverse! - ldc(X.class) should use JVM_CONSTANT_Class, not JVM_CONSTANT_Object - preloading of CP-cache entries is different for static and non-static methods These bugs did not arise earlier apparently because the output of the method handle walker (which produces bytecode-based IR for the JIT) is only lightly exercised. The best we had before was -client -Xcomp, but we don't have many in-house tests that compile constant graphs of MHs. The best source of such patterns is external language engines like Charlie's and Ola's. In the long term, we need something like -Xcomp to test method handles. -- John From john.r.rose at oracle.com Thu Jun 23 05:37:45 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 23 Jun 2011 05:37:45 -0700 Subject: review request (M): 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path In-Reply-To: <67DEA81C-321F-4F44-AC14-FABFFEC5E947@oracle.com> References: <2CA8EDA3-3E14-4A5C-9F11-9B8619B6D68D@oracle.com> <52314FB0-9A07-47D7-A365-0E3AFF48855D@oracle.com> <67DEA81C-321F-4F44-AC14-FABFFEC5E947@oracle.com> Message-ID: <4D8A8D03-C19E-4130-96F4-C2BE589F117E@oracle.com> Final update: http://cr.openjdk.java.net/~jrose/7056328/webrev.02 Found one more path (which you Tom pointed out a few days ago!) along which the constant pool needs to be passed, in order to properly scope JSR 292 method lookups. This appears to really fix Ola's NoClassDefFound bug, even when indy code is compiled and then deoptimized. Cumulative diffs: http://cr.openjdk.java.net/~jrose/7056328/webrev.02/00-to-02.diff (The last missing bit was in linkResolver.cpp.) -- John On Jun 23, 2011, at 12:48 AM, John Rose wrote: > On Jun 23, 2011, at 12:21 AM, John Rose wrote: > >> I'm working through several small bugs that the stress test uncovered. Will repost my webrev when done. -- John > > Here's the update: > http://cr.openjdk.java.net/~jrose/7056328/webrev.01 > http://cr.openjdk.java.net/~jrose/7056328/webrev.01/00-to-01.diff > > Stress testing uncovered a number of small bugs that are eventually going to bite us when users create invokedynamic bindings that get compiled, if those bindings use method handle graphs similar to those in the unit tests. > > - JVM_CONSTANT_Object entries not handled by sparc and x86 interpreters (hazard after deoptimization of JIT-ed indy instructions) > - collect/fold adapters call their recursive MH using relaxed typing (erased signatures), which is tricky to represent in bytecodes > - bytecode for spread adapters unpacked the arguments in reverse! > - ldc(X.class) should use JVM_CONSTANT_Class, not JVM_CONSTANT_Object > - preloading of CP-cache entries is different for static and non-static methods > > These bugs did not arise earlier apparently because the output of the method handle walker (which produces bytecode-based IR for the JIT) is only lightly exercised. The best we had before was -client -Xcomp, but we don't have many in-house tests that compile constant graphs of MHs. The best source of such patterns is external language engines like Charlie's and Ola's. > > In the long term, we need something like -Xcomp to test method handles. > > -- John From tom.rodriguez at oracle.com Thu Jun 23 10:13:16 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 23 Jun 2011 10:13:16 -0700 Subject: review(M): 7057120: Tiered: Allow C1 to inline methods with loops In-Reply-To: <4E028A33.20700@oracle.com> References: <4E018FFA.6020200@oracle.com> <4E021DAA.9060307@oracle.com> <4E026383.10300@oracle.com> <4E0267F5.4010407@oracle.com> <4E028500.3050805@oracle.com> <4E0287D0.6080405@oracle.com> <4E028A33.20700@oracle.com> Message-ID: <55FCA7CF-DF9B-45F8-92BA-8DDC3A687BCC@oracle.com> Looks good. tom On Jun 22, 2011, at 5:34 PM, Igor Veresov wrote: > Thanks, Vladimir! > > igor > > On 6/22/11 5:24 PM, Vladimir Kozlov wrote: >> Good. >> >> Vladimir >> >> Igor Veresov wrote: >>> On 6/22/11 3:08 PM, Vladimir Kozlov wrote: >>>> Igor Veresov wrote: >>>>> Thanks for the review, Vladimir! Webrev updated. Please find the >>>>> replies inline. >>>>> >>>>> On 6/22/11 9:51 AM, Vladimir Kozlov wrote: >>>>>> Can you explain why in counter_overflow_helper() (c1_Runtime1.cpp) you >>>>>> expect the caller (enclosing_method) to be nmethod? >>>>> >>>>> It's not the caller. The enclosing_method is the actual method to >>>>> which the nmethod belongs. In other words: enclosing_method is a >>>>> method who's frame is current on stack and "method" is possibly the >>>>> inlinee inside the enclosing method that generated the event. >>>> >>>> It would be better to say this in the comment for >>>> counter_overflow_helper() method since the current comment does not help >>>> at all. I don't see >>>> anything related to safepoint. >>> >>> Done, webrev updated. >>> >>> igor > From igor.veresov at oracle.com Thu Jun 23 11:12:01 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 23 Jun 2011 11:12:01 -0700 Subject: review(M): 7057120: Tiered: Allow C1 to inline methods with loops In-Reply-To: <55FCA7CF-DF9B-45F8-92BA-8DDC3A687BCC@oracle.com> References: <4E018FFA.6020200@oracle.com> <4E021DAA.9060307@oracle.com> <4E026383.10300@oracle.com> <4E0267F5.4010407@oracle.com> <4E028500.3050805@oracle.com> <4E0287D0.6080405@oracle.com> <4E028A33.20700@oracle.com> <55FCA7CF-DF9B-45F8-92BA-8DDC3A687BCC@oracle.com> Message-ID: <4E0381F1.7080605@oracle.com> Thanks, Tom! igor On 6/23/11 10:13 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jun 22, 2011, at 5:34 PM, Igor Veresov wrote: > >> Thanks, Vladimir! >> >> igor >> >> On 6/22/11 5:24 PM, Vladimir Kozlov wrote: >>> Good. >>> >>> Vladimir >>> >>> Igor Veresov wrote: >>>> On 6/22/11 3:08 PM, Vladimir Kozlov wrote: >>>>> Igor Veresov wrote: >>>>>> Thanks for the review, Vladimir! Webrev updated. Please find the >>>>>> replies inline. >>>>>> >>>>>> On 6/22/11 9:51 AM, Vladimir Kozlov wrote: >>>>>>> Can you explain why in counter_overflow_helper() (c1_Runtime1.cpp) you >>>>>>> expect the caller (enclosing_method) to be nmethod? >>>>>> >>>>>> It's not the caller. The enclosing_method is the actual method to >>>>>> which the nmethod belongs. In other words: enclosing_method is a >>>>>> method who's frame is current on stack and "method" is possibly the >>>>>> inlinee inside the enclosing method that generated the event. >>>>> >>>>> It would be better to say this in the comment for >>>>> counter_overflow_helper() method since the current comment does not help >>>>> at all. I don't see >>>>> anything related to safepoint. >>>> >>>> Done, webrev updated. >>>> >>>> igor >> > From igor.veresov at oracle.com Thu Jun 23 17:14:16 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 23 Jun 2011 17:14:16 -0700 Subject: review(XS): 7058689 Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods Message-ID: <4E03D6D8.7010308@oracle.com> When we deopt from a C2-compiled method and request reprofiling (we're at level 0 at this point) natually we would want to start reprofiling in the interpreter and queue up a level 3 compile and continue profiling at level 3 when it arrives. However, when we decide to which level to switch we check the max comp level of the OSR versions of the method. If a the level is 4 and there's been more than one profiled invocation we would choose to compile at level 4. This was initroduced to avoid deopt loops when we deopt and switch to a higher level OSR method. So, with reprofiling we need to handle the situation differently. The solution is to check at which level an OSR would be even possible at the moment (by calling the transition function with a loop predicate), which will take into account the fact the we need to reprofile and return either level 2 or 3; and then checking what OSR methods are currently available and taking the minimum level. Webrev: http://cr.openjdk.java.net/~iveresov/7058689/webrev.00/ Thanks, igor From john.coomes at oracle.com Thu Jun 23 20:35:33 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Jun 2011 03:35:33 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b146 for changeset 2d38c2a79c14 Message-ID: <20110624033533.942A3472A7@hg.openjdk.java.net> Changeset: 3e0b96f8f6a0 Author: schien Date: 2011-06-20 16:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/3e0b96f8f6a0 Added tag jdk7-b146 for changeset 2d38c2a79c14 ! .hgtags From john.coomes at oracle.com Thu Jun 23 20:35:42 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Jun 2011 03:35:42 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b146 for changeset 770227a4087e Message-ID: <20110624033546.B0349472A8@hg.openjdk.java.net> Changeset: 36f0efbc66ef Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/36f0efbc66ef Added tag jdk7-b146 for changeset 770227a4087e ! .hgtags From john.coomes at oracle.com Thu Jun 23 20:35:55 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Jun 2011 03:35:55 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b146 for changeset bcd31fa1e3c6 Message-ID: <20110624033555.95D54472A9@hg.openjdk.java.net> Changeset: 9a4d09f33f01 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/9a4d09f33f01 Added tag jdk7-b146 for changeset bcd31fa1e3c6 ! .hgtags From john.coomes at oracle.com Thu Jun 23 20:36:04 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Jun 2011 03:36:04 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 11 new changesets Message-ID: <20110624033604.CF4DC472AA@hg.openjdk.java.net> Changeset: 581dab3f0773 Author: asaha Date: 2011-04-21 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/581dab3f0773 Merge Changeset: 26610bb80151 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/26610bb80151 Merge Changeset: c6ff860428c7 Author: asaha Date: 2011-05-05 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/c6ff860428c7 Merge Changeset: f4e1caef46d0 Author: asaha Date: 2011-05-24 11:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/f4e1caef46d0 Merge Changeset: 9896cee00786 Author: asaha Date: 2011-05-26 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/9896cee00786 Merge Changeset: d1febdcb0351 Author: asaha Date: 2011-05-26 21:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/d1febdcb0351 Merge Changeset: 239c80c331da Author: asaha Date: 2011-06-06 10:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/239c80c331da Merge Changeset: 09412171ca4b Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/09412171ca4b Merge Changeset: 9d8fd0982fb8 Author: asaha Date: 2011-06-06 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/9d8fd0982fb8 Merge Changeset: 05469dd4c366 Author: lana Date: 2011-06-15 16:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/05469dd4c366 Merge Changeset: faa394edbfe3 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/faa394edbfe3 Added tag jdk7-b146 for changeset 05469dd4c366 ! .hgtags From john.r.rose at oracle.com Thu Jun 23 20:46:26 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 23 Jun 2011 20:46:26 -0700 Subject: review request (XS): 7058630: JSR 292 method handle proxy violates contract for Object methods Message-ID: 7058630: JSR 292 method handle proxy violates contract for Object methods http://cr.openjdk.java.net/~jrose/7058630/webrev.00/ Summary: One-token change, plus a unit test. From john.coomes at oracle.com Thu Jun 23 20:39:05 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Jun 2011 03:39:05 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 44 new changesets Message-ID: <20110624034739.A0294472B3@hg.openjdk.java.net> Changeset: cf0632d2db2c Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cf0632d2db2c 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/SwitchPoint.java + test/java/lang/invoke/PermuteArgsTest.java Changeset: ae731399e525 Author: dav Date: 2011-06-07 22:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ae731399e525 7048568: Crash in Java_sun_awt_Win32GraphicsEnvironment_isVistaOS Reviewed-by: dcherepanov, art, amenkov ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp Changeset: f08fcae94813 Author: lana Date: 2011-06-10 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f08fcae94813 Merge Changeset: 6e961c328276 Author: michaelm Date: 2011-06-08 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6e961c328276 7050028: ISE "zip file closed" from JarURLConnection.getInputStream on JDK 7 when !useCaches Reviewed-by: chegar, alanb ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B7050028.java Changeset: b6ced5ad7a62 Author: dwanvik Date: 2011-06-10 17:44 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b6ced5ad7a62 7046557: Changes to the Java DB README files in JDK7 Summary: Update /README.html with correct mention of Java DB, add JDK specific README files to /db and /demo/db. Reviewed-by: ohair ! make/common/Release.gmk Changeset: 646ab254ff80 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/646ab254ff80 Merge Changeset: aca0dc2b921c Author: weijun Date: 2011-02-09 11:50 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aca0dc2b921c 6618658: Deserialization allows creation of mutable SignedObject Reviewed-by: hawtin, mullan ! src/share/classes/java/security/SignedObject.java + test/java/security/SignedObject/Correctness.java Changeset: df445f522425 Author: bae Date: 2011-02-17 12:21 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/df445f522425 7013519: [parfait] Integer overflows in 2D code Reviewed-by: prr, valeriep ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: ccb2fcfb6d6b Author: chegar Date: 2011-02-18 13:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ccb2fcfb6d6b 7013969: NetworkInterface.toString can reveal bindings Reviewed-by: alanb, michaelm, hawtin ! src/share/classes/java/net/NetworkInterface.java Changeset: 026adaac71f1 Author: dcherepanov Date: 2011-02-25 15:54 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/026adaac71f1 7012520: Heap overflow vulnerability in FileDialog.show() Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: d489f00d6c65 Author: flar Date: 2011-03-02 05:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d489f00d6c65 7016495: Crash in Java 2D transforming an image with scale close to zero Reviewed-by: prr, bae ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/native/sun/java2d/loops/TransformHelper.c + test/java/awt/image/BufferedImage/TinyScale.java Changeset: fe27fe44ac51 Author: ksrini Date: 2011-03-03 14:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fe27fe44ac51 7016985: (launcher) implement safe secure dll loading Reviewed-by: mchung ! src/windows/bin/java_md.c Changeset: 0efa64f13302 Author: chegar Date: 2011-04-05 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0efa64f13302 7033865: JDK: Add private API for secure/restrictive loading of system dlls Reviewed-by: alanb ! src/share/native/common/jdk_util.h + src/solaris/native/common/jdk_util_md.h ! src/windows/native/common/jdk_util_md.c + src/windows/native/common/jdk_util_md.h Changeset: 67992a58bfba Author: ksrini Date: 2011-04-05 16:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/67992a58bfba 7032593: DLL_LOADING: Upgrade solution to 7016985 to reflect JDK7 solution Reviewed-by: mchung, asaha ! src/windows/bin/java_md.c Changeset: 7181441faf72 Author: dcherepanov Date: 2011-04-08 16:44 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7181441faf72 7003962: AWT: securely load DLLs and launch executables using fully qualified path Reviewed-by: art, bae, alanb ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h ! src/windows/native/sun/windows/DllUtil.cpp ! src/windows/native/sun/windows/DllUtil.h ! src/windows/native/sun/windows/ShellFolder2.cpp ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/stdhdrs.h Changeset: 05a3923f516f Author: dcherepanov Date: 2011-04-08 17:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/05a3923f516f 7035077: Minor addition to the changes for 7003962 Reviewed-by: chegar ! src/windows/native/sun/windows/DllUtil.cpp Changeset: afcc1530e68b Author: asaha Date: 2011-04-08 10:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/afcc1530e68b Merge - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/MethodHandle.java - src/share/classes/java/dyn/MethodHandles.java - src/share/classes/java/dyn/MethodType.java - src/share/classes/java/dyn/MethodTypeForm.java - src/share/classes/java/dyn/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/sun/dyn/Access.java - src/share/classes/sun/dyn/AdapterMethodHandle.java - src/share/classes/sun/dyn/BoundMethodHandle.java - src/share/classes/sun/dyn/CallSiteImpl.java - src/share/classes/sun/dyn/DirectMethodHandle.java - src/share/classes/sun/dyn/FilterGeneric.java - src/share/classes/sun/dyn/FilterOneArgument.java - src/share/classes/sun/dyn/FromGeneric.java - src/share/classes/sun/dyn/InvokeGeneric.java - src/share/classes/sun/dyn/Invokers.java - src/share/classes/sun/dyn/MemberName.java - src/share/classes/sun/dyn/MethodHandleImpl.java - src/share/classes/sun/dyn/MethodHandleNatives.java - src/share/classes/sun/dyn/MethodTypeImpl.java - src/share/classes/sun/dyn/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.java - src/share/classes/sun/dyn/anon/AnonymousClassLoader.java - src/share/classes/sun/dyn/anon/ConstantPoolParser.java - src/share/classes/sun/dyn/anon/ConstantPoolPatch.java - src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java - src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java - src/share/classes/sun/dyn/empty/Empty.java - src/share/classes/sun/dyn/package-info.java - src/share/classes/sun/dyn/util/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.java - src/share/classes/sun/dyn/util/ValueConversions.java - src/share/classes/sun/dyn/util/VerifyAccess.java - src/share/classes/sun/dyn/util/VerifyType.java - src/share/classes/sun/dyn/util/Wrapper.java - src/share/classes/sun/dyn/util/package-info.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 557bd9b5d92f Author: asaha Date: 2011-04-08 10:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/557bd9b5d92f Merge Changeset: e142148d8b54 Author: asaha Date: 2011-04-12 14:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e142148d8b54 Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 76e0e562b617 Author: dcherepanov Date: 2011-04-15 17:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/76e0e562b617 7036952: build warning after the changes for 7003962 Reviewed-by: art, bae ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h Changeset: f8eddc85cc02 Author: zgu Date: 2011-04-15 09:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f8eddc85cc02 7003964: SERV: securely load DLLs and launch executables using fully qualified path Summary: Linked in Windows libraries that are available on jdk7 supported platforms, and used GetModuleHandle instead of LoadLibrary for already loaded Dlls. Reviewed-by: dcubed, alanb ! make/com/sun/tools/attach/Makefile ! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java ! src/windows/native/sun/tools/attach/WindowsAttachProvider.c ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/npt/npt_md.h Changeset: 0865aa0ad9b2 Author: zgu Date: 2011-04-19 10:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0865aa0ad9b2 Merge Changeset: 6f8a4d334fb2 Author: asaha Date: 2011-04-20 09:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6f8a4d334fb2 Merge ! make/com/sun/tools/attach/Makefile ! src/share/classes/java/net/NetworkInterface.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/windows/bin/java_md.c ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: f3645b5d6e62 Author: asaha Date: 2011-04-20 21:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f3645b5d6e62 Merge Changeset: b626f78c57e1 Author: asaha Date: 2011-04-21 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b626f78c57e1 Merge Changeset: cec45f3353be Author: asaha Date: 2011-04-21 08:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cec45f3353be Merge Changeset: 6133c9ee3a01 Author: asaha Date: 2011-04-21 08:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6133c9ee3a01 Merge Changeset: dd06e8d3da91 Author: asaha Date: 2011-04-21 15:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dd06e8d3da91 Merge Changeset: b2295905901a Author: asaha Date: 2011-04-21 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b2295905901a Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 3fedf261fb4f Author: valeriep Date: 2011-04-26 15:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3fedf261fb4f 7003952: SEC: securely load DLLs and launch executables using fully qualified path Summary: Enforce full path when specifying library locations. Reviewed-by: wetmore, ohair ! make/sun/security/pkcs11/Makefile ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/native/sun/security/pkcs11/j2secmod.c + test/sun/security/pkcs11/Provider/Absolute.cfg + test/sun/security/pkcs11/Provider/Absolute.java Changeset: 94ea3b8288f1 Author: alexp Date: 2011-05-04 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/94ea3b8288f1 7020198: ImageIcon creates Component with null acc Reviewed-by: rupashka, hawtin ! src/share/classes/javax/swing/ImageIcon.java Changeset: e6fdfb249e31 Author: asaha Date: 2011-05-04 16:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e6fdfb249e31 Merge - src/share/native/sun/font/layout/Features.h ! src/windows/native/sun/windows/awt_FileDialog.cpp - test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: 49244980d692 Author: asaha Date: 2011-05-05 22:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/49244980d692 Merge - src/share/classes/sun/security/util/SignatureFileManifest.java Changeset: 647b031200f0 Author: asaha Date: 2011-05-06 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/647b031200f0 Merge Changeset: 92b5197e9ff5 Author: asaha Date: 2011-05-26 21:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/92b5197e9ff5 Merge ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: cca9ea306c6e Author: asaha Date: 2011-05-26 21:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cca9ea306c6e Merge Changeset: dab3e66ebda7 Author: lana Date: 2011-06-06 19:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dab3e66ebda7 Merge Changeset: 9f17be5136d1 Author: wetmore Date: 2011-06-09 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9f17be5136d1 7052537: java/security/Security/NotInstalledProviders.java is causing -samevm tests to fail. Reviewed-by: valeriep, asaha, alanb ! test/java/security/Security/NoInstalledProviders.java Changeset: 4961be00d3b5 Author: lana Date: 2011-06-15 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4961be00d3b5 Merge Changeset: a65fa0f6717e Author: trims Date: 2011-06-17 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a65fa0f6717e Merge Changeset: c46f97579fe6 Author: alanb Date: 2011-06-17 16:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c46f97579fe6 7055508: (aio) EXCEPTION_ACCESS_VIOLATION in AsynchronousSocketChannel.connect on Windows 7 Reviewed-by: chegar ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c Changeset: c102e1221afa Author: lana Date: 2011-06-17 10:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c102e1221afa Merge Changeset: 539e576793a8 Author: lana Date: 2011-06-18 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/539e576793a8 Merge Changeset: 7b4f4230fecf Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7b4f4230fecf Added tag jdk7-b146 for changeset 539e576793a8 ! .hgtags From john.r.rose at oracle.com Thu Jun 23 20:50:15 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 23 Jun 2011 20:50:15 -0700 Subject: review request (M): 7058651: JSR 292 unit tests need a refresh Message-ID: 7058651: JSR 292 unit tests need a refresh Summary: Enhancements to unit tests. http://cr.openjdk.java.net/~jrose/7058651/webrev.00 These are additions to the jtreg/JUnit unit tests used for pre-commit testing of JSR 292 code. I've been using them consistently for my own work, and it's time to share. -- John From tom.rodriguez at oracle.com Thu Jun 23 21:58:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 23 Jun 2011 21:58:23 -0700 Subject: review request (XS): 7058630: JSR 292 method handle proxy violates contract for Object methods In-Reply-To: References: Message-ID: <26490EE1-7082-432F-A1E1-0FDB1A5EC6C0@oracle.com> Looks good. tom On Jun 23, 2011, at 8:46 PM, John Rose wrote: > 7058630: JSR 292 method handle proxy violates contract for Object methods > http://cr.openjdk.java.net/~jrose/7058630/webrev.00/ > Summary: One-token change, plus a unit test. > From tom.rodriguez at oracle.com Thu Jun 23 22:35:21 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 23 Jun 2011 22:35:21 -0700 Subject: review request (M): 7058651: JSR 292 unit tests need a refresh In-Reply-To: References: Message-ID: <6A9BAA37-8FF4-468A-8CBF-8BA88DEAC01C@oracle.com> These look good. tom On Jun 23, 2011, at 8:50 PM, John Rose wrote: > 7058651: JSR 292 unit tests need a refresh > Summary: Enhancements to unit tests. > http://cr.openjdk.java.net/~jrose/7058651/webrev.00 > > These are additions to the jtreg/JUnit unit tests used for pre-commit testing of JSR 292 code. I've been using them consistently for my own work, and it's time to share. > > -- John From john.r.rose at oracle.com Thu Jun 23 22:37:38 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 24 Jun 2011 05:37:38 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path Message-ID: <20110624053742.67B71472BA@hg.openjdk.java.net> Changeset: ddd894528dbc Author: jrose Date: 2011-06-23 17:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ddd894528dbc 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path Reviewed-by: never ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp From john.r.rose at oracle.com Thu Jun 23 22:53:02 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 23 Jun 2011 22:53:02 -0700 Subject: review request (M): 7058651: JSR 292 unit tests need a refresh In-Reply-To: <6A9BAA37-8FF4-468A-8CBF-8BA88DEAC01C@oracle.com> References: <6A9BAA37-8FF4-468A-8CBF-8BA88DEAC01C@oracle.com> Message-ID: Thanks, Tom. -- John On Jun 23, 2011, at 10:35 PM, Tom Rodriguez wrote: > These look good. > > tom > > On Jun 23, 2011, at 8:50 PM, John Rose wrote: > >> 7058651: JSR 292 unit tests need a refresh >> Summary: Enhancements to unit tests. >> http://cr.openjdk.java.net/~jrose/7058651/webrev.00 >> >> These are additions to the jtreg/JUnit unit tests used for pre-commit testing of JSR 292 code. I've been using them consistently for my own work, and it's time to share. >> >> -- John > From john.r.rose at oracle.com Thu Jun 23 22:53:11 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 23 Jun 2011 22:53:11 -0700 Subject: review request (XS): 7058630: JSR 292 method handle proxy violates contract for Object methods In-Reply-To: <26490EE1-7082-432F-A1E1-0FDB1A5EC6C0@oracle.com> References: <26490EE1-7082-432F-A1E1-0FDB1A5EC6C0@oracle.com> Message-ID: <71A7D1EC-B24B-44C8-9C3E-318DD50E343E@oracle.com> Thanks! -- John On Jun 23, 2011, at 9:58 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jun 23, 2011, at 8:46 PM, John Rose wrote: > >> 7058630: JSR 292 method handle proxy violates contract for Object methods >> http://cr.openjdk.java.net/~jrose/7058630/webrev.00/ >> Summary: One-token change, plus a unit test. >> > From christian.thalinger at oracle.com Thu Jun 23 23:30:56 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 24 Jun 2011 08:30:56 +0200 Subject: review request (XS): 7058630: JSR 292 method handle proxy violates contract for Object methods In-Reply-To: References: Message-ID: <6967D903-FFEF-4865-BF71-811E5A23135C@oracle.com> On Jun 24, 2011, at 5:46 AM, John Rose wrote: > 7058630: JSR 292 method handle proxy violates contract for Object methods > http://cr.openjdk.java.net/~jrose/7058630/webrev.00/ > Summary: One-token change, plus a unit test. Looks good. -- Christian From christian.thalinger at oracle.com Thu Jun 23 23:32:41 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 24 Jun 2011 08:32:41 +0200 Subject: review request (M): 7058651: JSR 292 unit tests need a refresh In-Reply-To: References: Message-ID: <726DCE78-3AE8-487D-A3CD-BD1FCE7C9B6F@oracle.com> On Jun 24, 2011, at 5:50 AM, John Rose wrote: > 7058651: JSR 292 unit tests need a refresh > Summary: Enhancements to unit tests. > http://cr.openjdk.java.net/~jrose/7058651/webrev.00 > > These are additions to the jtreg/JUnit unit tests used for pre-commit testing of JSR 292 code. I've been using them consistently for my own work, and it's time to share. Looks good. -- Christian From vladimir.kozlov at oracle.com Fri Jun 24 08:50:50 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jun 2011 08:50:50 -0700 Subject: review(XS): 7058689 Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods In-Reply-To: <4E03D6D8.7010308@oracle.com> References: <4E03D6D8.7010308@oracle.com> Message-ID: <4E04B25A.8060701@oracle.com> Looks good. Vladimir Igor Veresov wrote: > When we deopt from a C2-compiled method and request reprofiling (we're > at level 0 at this point) natually we would want to start reprofiling in > the interpreter and queue up a level 3 compile and continue profiling at > level 3 when it arrives. However, when we decide to which level to > switch we check the max comp level of the OSR versions of the method. If > a the level is 4 and there's been more than one profiled invocation we > would choose to compile at level 4. This was initroduced to avoid deopt > loops when we deopt and switch to a higher level OSR method. > > So, with reprofiling we need to handle the situation differently. The > solution is to check at which level an OSR would be even possible at the > moment (by calling the transition function with a loop predicate), which > will take into account the fact the we need to reprofile and return > either level 2 or 3; and then checking what OSR methods are currently > available and taking the minimum level. > > > Webrev: http://cr.openjdk.java.net/~iveresov/7058689/webrev.00/ > > > Thanks, > igor From tom.rodriguez at oracle.com Fri Jun 24 10:17:38 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 24 Jun 2011 10:17:38 -0700 Subject: review(XS): 7058689 Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods In-Reply-To: <4E03D6D8.7010308@oracle.com> References: <4E03D6D8.7010308@oracle.com> Message-ID: Looks good. tom On Jun 23, 2011, at 5:14 PM, Igor Veresov wrote: > When we deopt from a C2-compiled method and request reprofiling (we're at level 0 at this point) natually we would want to start reprofiling in the interpreter and queue up a level 3 compile and continue profiling at level 3 when it arrives. However, when we decide to which level to switch we check the max comp level of the OSR versions of the method. If a the level is 4 and there's been more than one profiled invocation we would choose to compile at level 4. This was initroduced to avoid deopt loops when we deopt and switch to a higher level OSR method. > > So, with reprofiling we need to handle the situation differently. The solution is to check at which level an OSR would be even possible at the moment (by calling the transition function with a loop predicate), which will take into account the fact the we need to reprofile and return either level 2 or 3; and then checking what OSR methods are currently available and taking the minimum level. > > > Webrev: http://cr.openjdk.java.net/~iveresov/7058689/webrev.00/ > > > Thanks, > igor From vladimir.kozlov at oracle.com Fri Jun 24 13:40:29 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jun 2011 13:40:29 -0700 Subject: Request for reviews (XS): 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM Message-ID: <4E04F63D.8030904@oracle.com> This is for 7u2. http://cr.openjdk.java.net/~kvn/7058036/webrev Fixed 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM ClassFileParser::parseClassFile() incorrectly uses nonstatic_oop_map_size() method instead of nonstatic_oop_map_count() when calculates a pointer to last oop map block. Verified by fields layout based on the example in the bug report. Contributed-by: Krystal Mok From tom.rodriguez at oracle.com Mon Jun 27 11:19:04 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 27 Jun 2011 11:19:04 -0700 Subject: Request for reviews (XS): 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM In-Reply-To: <4E04F63D.8030904@oracle.com> References: <4E04F63D.8030904@oracle.com> Message-ID: <3E0BAF61-086D-4461-A395-083C5B45D0B2@oracle.com> Looks good. tom On Jun 24, 2011, at 1:40 PM, Vladimir Kozlov wrote: > This is for 7u2. > > http://cr.openjdk.java.net/~kvn/7058036/webrev > > Fixed 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM > > ClassFileParser::parseClassFile() incorrectly uses nonstatic_oop_map_size() method instead of nonstatic_oop_map_count() when calculates a pointer to last oop map block. > > Verified by fields layout based on the example in the bug report. > > Contributed-by: Krystal Mok From vladimir.kozlov at oracle.com Mon Jun 27 11:38:20 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jun 2011 11:38:20 -0700 Subject: Request for reviews (XS): 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM In-Reply-To: <3E0BAF61-086D-4461-A395-083C5B45D0B2@oracle.com> References: <4E04F63D.8030904@oracle.com> <3E0BAF61-086D-4461-A395-083C5B45D0B2@oracle.com> Message-ID: <4E08CE1C.1050409@oracle.com> Thank you, Tom Vladimir On 6/27/11 11:19 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jun 24, 2011, at 1:40 PM, Vladimir Kozlov wrote: > >> This is for 7u2. >> >> http://cr.openjdk.java.net/~kvn/7058036/webrev >> >> Fixed 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM >> >> ClassFileParser::parseClassFile() incorrectly uses nonstatic_oop_map_size() method instead of nonstatic_oop_map_count() when calculates a pointer to last oop map block. >> >> Verified by fields layout based on the example in the bug report. >> >> Contributed-by: Krystal Mok > From igor.veresov at oracle.com Mon Jun 27 12:07:38 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 27 Jun 2011 12:07:38 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler Message-ID: <4E08D4FA.9070004@oracle.com> Problem: multinewarray with >= 6 dimensions is not supported by c2 and is plugged with uncommon trap. When executed in the main code path this yields performance far worse than even interpreter. Solution: Count these traps per bci and when the number exceeds PerBytecodeTrapLimit make it not compilable. With tiered it would result in recompilation at level 1 (pure C1), with regular scheme the method will continue in the interpreter. Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.00/ Thanks, igor From vladimir.kozlov at oracle.com Mon Jun 27 13:02:50 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jun 2011 13:02:50 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E08D4FA.9070004@oracle.com> References: <4E08D4FA.9070004@oracle.com> Message-ID: <4E08E1EA.607@oracle.com> I surprise to see that we only use one bit in _flags for flags, I looked through sources and found only null_seen_flag. Is it really true? Then why we did not do this change before? It could be for an other reason but I can't remember now. Do anyone remember? We always struggled to fit trap per bytecode info into MDO. I am for these changes if they really work. Thanks, Vladimir On 6/27/11 12:07 PM, Igor Veresov wrote: > Problem: multinewarray with >= 6 dimensions is not supported by c2 and is plugged with uncommon trap. When executed in > the main code path this yields performance far worse than even interpreter. > > Solution: Count these traps per bci and when the number exceeds PerBytecodeTrapLimit make it not compilable. With tiered > it would result in recompilation at level 1 (pure C1), with regular scheme the method will continue in the interpreter. > > > Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.00/ > > > Thanks, > igor From igor.veresov at oracle.com Mon Jun 27 13:36:28 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 27 Jun 2011 13:36:28 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E08E1EA.607@oracle.com> References: <4E08D4FA.9070004@oracle.com> <4E08E1EA.607@oracle.com> Message-ID: <4E08E9CC.3010608@oracle.com> On 6/27/11 1:02 PM, Vladimir Kozlov wrote: > I surprise to see that we only use one bit in _flags for flags, I looked > through sources and found only null_seen_flag. Is it really true? As far as I can see, yes. > Then > why we did not do this change before? It could be for an other reason > but I can't remember now. Do anyone remember? We always struggled to fit > trap per bytecode info into MDO. > > I am for these changes if they really work. > They do, I've tested it with Peter's test case and specjvm98. igor > Thanks, > Vladimir > > On 6/27/11 12:07 PM, Igor Veresov wrote: >> Problem: multinewarray with >= 6 dimensions is not supported by c2 and >> is plugged with uncommon trap. When executed in >> the main code path this yields performance far worse than even >> interpreter. >> >> Solution: Count these traps per bci and when the number exceeds >> PerBytecodeTrapLimit make it not compilable. With tiered >> it would result in recompilation at level 1 (pure C1), with regular >> scheme the method will continue in the interpreter. >> >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.00/ >> >> >> Thanks, >> igor From tom.rodriguez at oracle.com Mon Jun 27 13:41:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 27 Jun 2011 13:41:19 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E08D4FA.9070004@oracle.com> References: <4E08D4FA.9070004@oracle.com> Message-ID: <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> Is there any easy way to just make C2 support a varargs style call for multianewarray? C1 just does a funny calling convention where it passes a pointer a stack allocated array which is obviously possible with C2 though we don't have anything like it right now. I can see how to do this by cons'ing up type signatures as need with extra count and pointer arguments and then modifying the c_calling_convention to switch to the stack only calling convention after the first two. The only extra trick would be getting the address of the stack arguments into the call when it's converted into a MachCall. We don't really have a way to express that using MachNodes since stack slots are virtual are that point. Maybe it could simply be handled at the ad file level. So something like a new MachCallRuntimeVarargsNode with an index indicating which argument is the last real one, the c_calling_convention modified to take an index indicating when it should force a switch to stack only, and the ins_encode for that match inserting the right address computation for the address. Is that too complex for the limited benefit? Maybe compared to the complexity of the existing machinery, it's not too bad. As far as your webrev, I don't think you want to do this: + if (per_bc_reason == Reason_unhandled) { + make_not_compilable = true; + } There are other uses of Reason_unhandled and it's not clear the stopping compilation is the right action for those other cases. Maybe you need another action? Or maybe the actions need to be interpreted specially for Reason_unhandled. Doing a make_not_entrant doesn't seem like the right action for some of the other Reason_unhandleds. I do like the trap_state changes if it allows us to move Reason_loop_predicate and Reason_loop_limit_check into the per bci section. tom On Jun 27, 2011, at 12:07 PM, Igor Veresov wrote: > Problem: multinewarray with >= 6 dimensions is not supported by c2 and is plugged with uncommon trap. When executed in the main code path this yields performance far worse than even interpreter. > > Solution: Count these traps per bci and when the number exceeds PerBytecodeTrapLimit make it not compilable. With tiered it would result in recompilation at level 1 (pure C1), with regular scheme the method will continue in the interpreter. > > > Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.00/ > > > Thanks, > igor From igor.veresov at oracle.com Mon Jun 27 14:47:37 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 27 Jun 2011 14:47:37 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> Message-ID: <4E08FA79.3040608@oracle.com> Thanks for the review, Tom! I'll try to implement the vararg calls. igor On 6/27/11 1:41 PM, Tom Rodriguez wrote: > Is there any easy way to just make C2 support a varargs style call for multianewarray? C1 just does a funny calling convention where it passes a pointer a stack allocated array which is obviously possible with C2 though we don't have anything like it right now. I can see how to do this by cons'ing up type signatures as need with extra count and pointer arguments and then modifying the c_calling_convention to switch to the stack only calling convention after the first two. The only extra trick would be getting the address of the stack arguments into the call when it's converted into a MachCall. We don't really have a way to express that using MachNodes since stack slots are virtual are that point. Maybe it could simply be handled at the ad file level. > > So something like a new MachCallRuntimeVarargsNode with an index indicating which argument is the last real one, the c_calling_convention modified to take an index indicating when it should force a switch to stack only, and the ins_encode for that match inserting the right address computation for the address. Is that too complex for the limited benefit? Maybe compared to the complexity of the existing machinery, it's not too bad. > > As far as your webrev, I don't think you want to do this: > > + if (per_bc_reason == Reason_unhandled) { > + make_not_compilable = true; > + } > > There are other uses of Reason_unhandled and it's not clear the stopping compilation is the right action for those other cases. Maybe you need another action? Or maybe the actions need to be interpreted specially for Reason_unhandled. Doing a make_not_entrant doesn't seem like the right action for some of the other Reason_unhandleds. > > I do like the trap_state changes if it allows us to move Reason_loop_predicate and Reason_loop_limit_check into the per bci section. > > tom > > On Jun 27, 2011, at 12:07 PM, Igor Veresov wrote: > >> Problem: multinewarray with>= 6 dimensions is not supported by c2 and is plugged with uncommon trap. When executed in the main code path this yields performance far worse than even interpreter. >> >> Solution: Count these traps per bci and when the number exceeds PerBytecodeTrapLimit make it not compilable. With tiered it would result in recompilation at level 1 (pure C1), with regular scheme the method will continue in the interpreter. >> >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.00/ >> >> >> Thanks, >> igor > From vladimir.kozlov at oracle.com Tue Jun 28 10:49:09 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jun 2011 10:49:09 -0700 Subject: Request for reviews (S): 6990015: Incorrect Icache line size is used for 64 bit x86 Message-ID: <4E0A1415.4080601@oracle.com> This is for 7u2. http://cr.openjdk.java.net/~kvn/6990015/webrev Fixed 6990015: Incorrect Icache line size is used for 64 bit x86 Until 7059226 is fixed we can't use information from cpuid to determine the cache flashing size since flush_icache stub have to be generated before cpuid stub. For now I just fixed the ICache::line_size and added verification code into vm_version_x86. After 7059226 is fixed I will revisit this Icache code. Thanks, Vladimir From paul.hohensee at oracle.com Tue Jun 28 11:04:20 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 28 Jun 2011 14:04:20 -0400 Subject: Request for reviews (S): 6990015: Incorrect Icache line size is used for 64 bit x86 In-Reply-To: <4E0A1415.4080601@oracle.com> References: <4E0A1415.4080601@oracle.com> Message-ID: <4E0A17A4.50309@oracle.com> Your comment in the CR is correct: 32 bytes is used because that's the L1 icache line size on early AMD chips, including, if I recall correctly (and I might be wrong), Opterons. So we might trigger the guarantee in some obscure cases, but it'll be obvious what the problem is. You might want to change the second guarantee to* guarantee(_cpuid_info.std_cpuid1_ebx.bits.clflush_size * 8 == ICache::line_size, "clflush size is not supported");* Paul On 6/28/11 1:49 PM, Vladimir Kozlov wrote: > This is for 7u2. > > http://cr.openjdk.java.net/~kvn/6990015/webrev > > Fixed 6990015: Incorrect Icache line size is used for 64 bit x86 > > Until 7059226 is fixed we can't use information from cpuid to > determine the cache flashing size since flush_icache stub have to be > generated before cpuid stub. For now I just fixed the > ICache::line_size and added verification code into vm_version_x86. > After 7059226 is fixed I will revisit this Icache code. > > Thanks, > Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110628/c2039458/attachment-0001.html From tom.rodriguez at oracle.com Tue Jun 28 11:05:14 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 28 Jun 2011 11:05:14 -0700 Subject: Request for reviews (S): 6990015: Incorrect Icache line size is used for 64 bit x86 In-Reply-To: <4E0A1415.4080601@oracle.com> References: <4E0A1415.4080601@oracle.com> Message-ID: <38E07D1A-D612-4D88-A84B-604E0CE81D74@oracle.com> Looks ok. tom On Jun 28, 2011, at 10:49 AM, Vladimir Kozlov wrote: > This is for 7u2. > > http://cr.openjdk.java.net/~kvn/6990015/webrev > > Fixed 6990015: Incorrect Icache line size is used for 64 bit x86 > > Until 7059226 is fixed we can't use information from cpuid to determine the cache flashing size since flush_icache stub have to be generated before cpuid stub. For now I just fixed the ICache::line_size and added verification code into vm_version_x86. After 7059226 is fixed I will revisit this Icache code. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Jun 28 12:23:07 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jun 2011 12:23:07 -0700 (PDT) Subject: Request for reviews (S): 6990015: Incorrect Icache line size is used for 64 bit x86 In-Reply-To: <4E0A17A4.50309@oracle.com> References: <4E0A1415.4080601@oracle.com> <4E0A17A4.50309@oracle.com> Message-ID: <4E0A2A1B.6080202@oracle.com> Paul Hohensee wrote: > Your comment in the CR is correct: 32 bytes is used because that's the L1 > icache line size on early AMD chips, including, if I recall correctly (and I > might be wrong), Opterons. So we might trigger the guarantee in some > obscure cases, but it'll be obvious what the problem is. AMD says there were never x64 cpus with 32 bytes cache line. Yes, before x64 there were AMD cpus which had 32 bytes cache line. > > You might want to change the second guarantee to* > > guarantee(_cpuid_info.std_cpuid1_ebx.bits.clflush_size * 8 == > ICache::line_size, "clflush size is not supported"); I don't think it is correct. clflush_size defines what clflash instruction flashes which could be different from Icache line size. For example, on sparc it is smaller. Thanks, Vladimir > > Paul > > On 6/28/11 1:49 PM, Vladimir Kozlov wrote: >> This is for 7u2. >> >> http://cr.openjdk.java.net/~kvn/6990015/webrev >> >> Fixed 6990015: Incorrect Icache line size is used for 64 bit x86 >> >> Until 7059226 is fixed we can't use information from cpuid to >> determine the cache flashing size since flush_icache stub have to be >> generated before cpuid stub. For now I just fixed the >> ICache::line_size and added verification code into vm_version_x86. >> After 7059226 is fixed I will revisit this Icache code. >> >> Thanks, >> Vladimir From vladimir.kozlov at oracle.com Tue Jun 28 12:23:34 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jun 2011 12:23:34 -0700 Subject: Request for reviews (S): 6990015: Incorrect Icache line size is used for 64 bit x86 In-Reply-To: <38E07D1A-D612-4D88-A84B-604E0CE81D74@oracle.com> References: <4E0A1415.4080601@oracle.com> <38E07D1A-D612-4D88-A84B-604E0CE81D74@oracle.com> Message-ID: <4E0A2A36.2020609@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks ok. > > tom > > On Jun 28, 2011, at 10:49 AM, Vladimir Kozlov wrote: > >> This is for 7u2. >> >> http://cr.openjdk.java.net/~kvn/6990015/webrev >> >> Fixed 6990015: Incorrect Icache line size is used for 64 bit x86 >> >> Until 7059226 is fixed we can't use information from cpuid to determine the cache flashing size since flush_icache stub have to be generated before cpuid stub. For now I just fixed the ICache::line_size and added verification code into vm_version_x86. After 7059226 is fixed I will revisit this Icache code. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Thu Jun 30 11:13:10 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 30 Jun 2011 11:13:10 -0700 Subject: review for 7061101: adlc should complain about mixing block and expression forms of ins_encode Message-ID: <738FCD57-8961-48E5-ADCA-3FAF0D60EE63@oracle.com> http://cr.openjdk.java.net/~never/7061101 12 lines changed: 12 ins; 0 del; 0 mod; 5050 unchg 7061101: adlc should complain about mixing block and expression forms of ins_encode Reviewed-by: Only one ins_encode should be specified. Tested with bad ad file. From vladimir.kozlov at oracle.com Thu Jun 30 11:20:39 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jun 2011 11:20:39 -0700 Subject: review for 7061101: adlc should complain about mixing block and expression forms of ins_encode In-Reply-To: <738FCD57-8961-48E5-ADCA-3FAF0D60EE63@oracle.com> References: <738FCD57-8961-48E5-ADCA-3FAF0D60EE63@oracle.com> Message-ID: <4E0CBE77.4020001@oracle.com> Looks good but I do not understand your comment. Did you mean the check is done after parsing a ins_encode block instead of before it? Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7061101 > 12 lines changed: 12 ins; 0 del; 0 mod; 5050 unchg > > 7061101: adlc should complain about mixing block and expression forms of ins_encode > Reviewed-by: > > Only one ins_encode should be specified. Tested with bad ad file. > From tom.rodriguez at oracle.com Thu Jun 30 11:23:42 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 30 Jun 2011 11:23:42 -0700 Subject: review for 7061101: adlc should complain about mixing block and expression forms of ins_encode In-Reply-To: <4E0CBE77.4020001@oracle.com> References: <738FCD57-8961-48E5-ADCA-3FAF0D60EE63@oracle.com> <4E0CBE77.4020001@oracle.com> Message-ID: <7489783C-6AE8-47A1-9BA4-3BB7DA42B52D@oracle.com> On Jun 30, 2011, at 11:20 AM, Vladimir Kozlov wrote: > Looks good but I do not understand your comment. Did you mean the check is done after parsing a ins_encode block instead of before it? Yes. Should I change it somehow? tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7061101 >> 12 lines changed: 12 ins; 0 del; 0 mod; 5050 unchg >> 7061101: adlc should complain about mixing block and expression forms of ins_encode >> Reviewed-by: >> Only one ins_encode should be specified. Tested with bad ad file. From vladimir.kozlov at oracle.com Thu Jun 30 11:27:46 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jun 2011 11:27:46 -0700 Subject: review for 7061101: adlc should complain about mixing block and expression forms of ins_encode In-Reply-To: <7489783C-6AE8-47A1-9BA4-3BB7DA42B52D@oracle.com> References: <738FCD57-8961-48E5-ADCA-3FAF0D60EE63@oracle.com> <4E0CBE77.4020001@oracle.com> <7489783C-6AE8-47A1-9BA4-3BB7DA42B52D@oracle.com> Message-ID: <4E0CC022.3080409@oracle.com> Yes, could it says something like this?: // We do this check after block parsing so that we can also catch problems in the block Vladimir Tom Rodriguez wrote: > On Jun 30, 2011, at 11:20 AM, Vladimir Kozlov wrote: > >> Looks good but I do not understand your comment. Did you mean the check is done after parsing a ins_encode block instead of before it? > > Yes. Should I change it somehow? > > tom > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7061101 >>> 12 lines changed: 12 ins; 0 del; 0 mod; 5050 unchg >>> 7061101: adlc should complain about mixing block and expression forms of ins_encode >>> Reviewed-by: >>> Only one ins_encode should be specified. Tested with bad ad file. > From tom.rodriguez at oracle.com Thu Jun 30 12:50:53 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 30 Jun 2011 12:50:53 -0700 Subject: review for 7061101: adlc should complain about mixing block and expression forms of ins_encode In-Reply-To: <4E0CC022.3080409@oracle.com> References: <738FCD57-8961-48E5-ADCA-3FAF0D60EE63@oracle.com> <4E0CBE77.4020001@oracle.com> <7489783C-6AE8-47A1-9BA4-3BB7DA42B52D@oracle.com> <4E0CC022.3080409@oracle.com> Message-ID: <45499D44-A3B1-4F60-89A4-C20F4DA573ED@oracle.com> How about: + // Check for duplicate ins_encode sections after parsing the block + // so that parsing can continue and find any other errors. tom On Jun 30, 2011, at 11:27 AM, Vladimir Kozlov wrote: > Yes, could it says something like this?: > > // We do this check after block parsing so that we can also catch problems in the block > > Vladimir > > Tom Rodriguez wrote: >> On Jun 30, 2011, at 11:20 AM, Vladimir Kozlov wrote: >>> Looks good but I do not understand your comment. Did you mean the check is done after parsing a ins_encode block instead of before it? >> Yes. Should I change it somehow? >> tom >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7061101 >>>> 12 lines changed: 12 ins; 0 del; 0 mod; 5050 unchg >>>> 7061101: adlc should complain about mixing block and expression forms of ins_encode >>>> Reviewed-by: >>>> Only one ins_encode should be specified. Tested with bad ad file. From vladimir.kozlov at oracle.com Thu Jun 30 13:48:09 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jun 2011 13:48:09 -0700 Subject: review for 7061101: adlc should complain about mixing block and expression forms of ins_encode In-Reply-To: <45499D44-A3B1-4F60-89A4-C20F4DA573ED@oracle.com> References: <738FCD57-8961-48E5-ADCA-3FAF0D60EE63@oracle.com> <4E0CBE77.4020001@oracle.com> <7489783C-6AE8-47A1-9BA4-3BB7DA42B52D@oracle.com> <4E0CC022.3080409@oracle.com> <45499D44-A3B1-4F60-89A4-C20F4DA573ED@oracle.com> Message-ID: <4E0CE109.2080801@oracle.com> Good. Thanks, Vladimir Tom Rodriguez wrote: > How about: > > + // Check for duplicate ins_encode sections after parsing the block > + // so that parsing can continue and find any other errors. > > tom > > On Jun 30, 2011, at 11:27 AM, Vladimir Kozlov wrote: > >> Yes, could it says something like this?: >> >> // We do this check after block parsing so that we can also catch problems in the block >> >> Vladimir >> >> Tom Rodriguez wrote: >>> On Jun 30, 2011, at 11:20 AM, Vladimir Kozlov wrote: >>>> Looks good but I do not understand your comment. Did you mean the check is done after parsing a ins_encode block instead of before it? >>> Yes. Should I change it somehow? >>> tom >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/7061101 >>>>> 12 lines changed: 12 ins; 0 del; 0 mod; 5050 unchg >>>>> 7061101: adlc should complain about mixing block and expression forms of ins_encode >>>>> Reviewed-by: >>>>> Only one ins_encode should be specified. Tested with bad ad file. > From vladimir.kozlov at oracle.com Thu Jun 30 15:02:30 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 30 Jun 2011 22:02:30 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM Message-ID: <20110630220232.3C92E470BC@hg.openjdk.java.net> Changeset: 498c6cf70f7e Author: kvn Date: 2011-06-28 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/498c6cf70f7e 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM Summary: parseClassFile() incorrectly uses nonstatic_oop_map_size() method instead of nonstatic_oop_map_count(). Reviewed-by: never Contributed-by: Krystal Mok ! src/share/vm/classfile/classFileParser.cpp From vladimir.kozlov at oracle.com Thu Jun 30 17:38:47 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 01 Jul 2011 00:38:47 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6990015: Incorrect Icache line size is used for 64 bit x86 Message-ID: <20110701003849.4D716470C3@hg.openjdk.java.net> Changeset: 6ae7a1561b53 Author: kvn Date: 2011-06-28 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6ae7a1561b53 6990015: Incorrect Icache line size is used for 64 bit x86 Summary: correct Icache::line_size for x64 and add verification code into vm_version_x86. Reviewed-by: never, phh ! src/cpu/x86/vm/icache_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp From vladimir.kozlov at oracle.com Thu Jun 30 20:18:13 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 01 Jul 2011 03:18:13 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7044738: Loop unroll optimization causes incorrect result Message-ID: <20110701031815.AD13B470CC@hg.openjdk.java.net> Changeset: e3cbc9ddd434 Author: kvn Date: 2011-06-28 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e3cbc9ddd434 7044738: Loop unroll optimization causes incorrect result Summary: take into account memory dependencies when clonning nodes in clone_up_backedge_goo(). Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp + test/compiler/7044738/Test7044738.java + test/compiler/7046096/Test7046096.java From vladimir.kozlov at oracle.com Thu Jun 30 22:54:52 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 01 Jul 2011 05:54:52 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7047954: VM crashes with assert(is_Mem()) failed Message-ID: <20110701055454.99694470D3@hg.openjdk.java.net> Changeset: 7889bbcc7f88 Author: kvn Date: 2011-06-28 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7889bbcc7f88 7047954: VM crashes with assert(is_Mem()) failed Summary: cast constant array ptrs to bottom Reviewed-by: never ! src/share/vm/opto/compile.cpp