From vladimir.kozlov at oracle.com Mon Oct 3 15:48:12 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 03 Oct 2011 15:48:12 -0700 Subject: Request for review (S): 6865265 JVM crashes with "missing exception handler" error In-Reply-To: References: <4E2DA45B.6040807@oracle.com> <6C3604DF-B1DE-48C3-BAD6-6D9A50C1836B@oracle.com> <4E2DB3B4.6040007@oracle.com> Message-ID: <4E8A3BAC.40604@oracle.com> Thank you, Volker Your changes looks good to me. I will push it when we done with 7u2, may be next week. About your question: Question: is it correct that we implicitly create 'catch_all' CatchProjNode in Parse::catch_call_exceptions() with an handler_bci which is not '-1'? 'catch_all_index' catch projection is only checked in extract projections code when Java call is replaced with inlined code or when Allocate nodes are expanded. So it is fine to create "catch_all_index" CatchProjNode with not '-1' bci in catch_call_exceptions() since it is called only after runtime call to rethrow_Java() where all projections are treated equally (except fall_through which is dead). Thanks, Vladimir Volker Simonis wrote: > The following request for review somehow got lost in the summer holidays. > > I would need one additional reviewer and somebody who would be so kind > to actually submit the change once it was reviewed. > > Thank you and best regards, > Volker > > > On Tue, Jul 26, 2011 at 7:20 PM, Volker Simonis > wrote: >> Hi, >> >> I've made "original_exception" a Handle as suggested by Keith. Here's >> the new webrev: >> >> http://www.progdoc.de/webrev/6865265.v2 >> >> Regarding Keith' comments about the verification process: he's right, >> 'VerificationType::is_reference_assignable_from()' loads both >> references with the same class loader (the initiating one in this >> case). Initially I though that verifying if an Exception class in the >> class file's exception table is "java.lang.Throwable" only by name may >> be not enough, because a custom system class loader could load a bogus >> Throwable class which is different from the one loaded by the boot >> class loader. But I've just verified that such a scenario is >> prohibited by 'ClassLoader.defineClass()' which is final and rejects >> the loading of classes from the 'java.' package. >> >> Regards, >> Volker >> >> On Mon, Jul 25, 2011 at 8:19 PM, Vladimir Kozlov >> wrote: >>> Resending to all. >>> >>> Keith McGuigan wrote: >>>> I think the code looks ok, but why not use a Handle for the >>>> "original_exception" in runtime.cpp -- then you don't need to worry about >>>> the GC case either. >>>> >>>> As to the question about the verifier comparing by name, this is correct >>>> (in that this is what the verifier spec requires, IIRC), but intuitively it >>>> makes sense anyway because the class's current class loader is the >>>> initiating loader for any referenced class that might need to be loaded. >>>> Thus two different references to classes with the same name will always >>>> resolve to the same class implementation so a system dictionary lookup is >>>> unnecessary. The verifier actively attempts to NOT load or initialize >>>> classes when it can, but in some cases it must, unfortunately. >>>> >>>> -- >>>> - Keith >>>> >>>> >>>> On Jul 25, 2011, at 1:14 PM, Vladimir Kozlov wrote: >>>> >>>>> Forwarding to RT since runtime code is also involved. >>>>> >>>>> Vladimir >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Request for review (S): 6865265 JVM crashes with "missing >>>>> exception handler" error >>>>> Date: Mon, 25 Jul 2011 18:58:58 +0200 >>>>> From: Volker Simonis >>>>> To: hotspot compiler >>>>> >>>>> Although I've found a tiny test case for 6865265 and a small fix for >>>>> the problem, I'm still not sure if my fix is complete. >>>>> >>>>> I would appreciate it very much if somebody could review my (somewhat >>>>> lengthy) explanation for the fix and answer the two questions I >>>>> encountered. >>>>> Both, the explanation of the fix and the questions are in the webrev at: >>>>> >>>>> http://www.progdoc.de/webrev/6865265/ >>>>> >>>>> Regards, >>>>> Volker From igor.veresov at oracle.com Mon Oct 3 22:48:10 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 3 Oct 2011 22:48:10 -0700 Subject: review(S): 7097679: Tiered: events with bad bci to Gotos reduced from Ifs Message-ID: In case with back branches Runtime1::counter_overflow() routine expects to receive a bci of either a Goto of If instruction that generated the event. When emitting the counter overflow stub for the Goto we take the bci from the jvm state. However it is not correct for the Gotos that were produced as a result of the reduction of Ifs because in this case the state will have a bci that would possibly point to a Cmp preceding the If instead. The solution is to always store a proper bci for Goto and use it instead of the one in the jvm state. Webrev: http://cr.openjdk.java.net/~iveresov/7097679/webrev.00 Thanks! igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111003/1bdf3a19/attachment.html From vladimir.kozlov at oracle.com Tue Oct 4 08:49:54 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 04 Oct 2011 08:49:54 -0700 Subject: review(S): 7097679: Tiered: events with bad bci to Gotos reduced from Ifs In-Reply-To: References: Message-ID: <4E8B2B22.4080705@oracle.com> Looks good. Vladimir On 10/3/11 10:48 PM, Igor Veresov wrote: > In case with back branches Runtime1::counter_overflow() routine expects to receive a bci of either a Goto of If > instruction that generated > the event. When emitting the counter overflow stub for the Goto we take the bci from the jvm state. However it is not > correct for the Gotos > that were produced as a result of the reduction of Ifs because in this case the state will have a bci that would > possibly point to a Cmp preceding the If instead. > > The solution is to always store a proper bci for Goto and use it instead of the one in the jvm state. > > Webrev: http://cr.openjdk.java.net/~iveresov/7097679/webrev.00 > > Thanks! > igor From tom.rodriguez at oracle.com Tue Oct 4 09:06:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 4 Oct 2011 09:06:19 -0700 Subject: review(S): 7097679: Tiered: events with bad bci to Gotos reduced from Ifs In-Reply-To: References: Message-ID: Looks good. tom On Oct 3, 2011, at 10:48 PM, Igor Veresov wrote: > In case with back branches Runtime1::counter_overflow() routine expects to receive a bci of either a Goto of If instruction that generated > the event. When emitting the counter overflow stub for the Goto we take the bci from the jvm state. However it is not correct for the Gotos > that were produced as a result of the reduction of Ifs because in this case the state will have a bci that would possibly point to a Cmp preceding the If instead. > > The solution is to always store a proper bci for Goto and use it instead of the one in the jvm state. > > Webrev: http://cr.openjdk.java.net/~iveresov/7097679/webrev.00 > > Thanks! > igor From igor.veresov at oracle.com Tue Oct 4 09:46:05 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 4 Oct 2011 09:46:05 -0700 Subject: review(S): 7097679: Tiered: events with bad bci to Gotos reduced from Ifs In-Reply-To: References: Message-ID: <86DB196041B042D5BFEFA5BC8D42FE5C@oracle.com> Thanks Vladimir and Tom! igor On Tuesday, October 4, 2011 at 9:06 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 3, 2011, at 10:48 PM, Igor Veresov wrote: > > > In case with back branches Runtime1::counter_overflow() routine expects to receive a bci of either a Goto of If instruction that generated > > the event. When emitting the counter overflow stub for the Goto we take the bci from the jvm state. However it is not correct for the Gotos > > that were produced as a result of the reduction of Ifs because in this case the state will have a bci that would possibly point to a Cmp preceding the If instead. > > > > The solution is to always store a proper bci for Goto and use it instead of the one in the jvm state. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7097679/webrev.00 > > > > Thanks! > > igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111004/cb47f058/attachment.html From igor.veresov at oracle.com Tue Oct 4 14:04:49 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 04 Oct 2011 21:04:49 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7097679: Tiered: events with bad bci to Gotos reduced from Ifs Message-ID: <20111004210455.5E7C447BD5@hg.openjdk.java.net> Changeset: 940513efe83a Author: iveresov Date: 2011-10-04 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/940513efe83a 7097679: Tiered: events with bad bci to Gotos reduced from Ifs Summary: Save bci of instruction that produced Goto and use it to call back to runtime Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp From headius at headius.com Tue Oct 4 16:47:36 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 4 Oct 2011 16:47:36 -0700 Subject: Help with JIT talk for tomorrow Message-ID: Hey all...I'm updating and expanding my talk on C2 and will be posting some questions. Hopefully there's someone out there who can answer them :) First up... given this output from PrintCompilation, what do the "!" and "n" and "%" mean? Also, in Java 7 there's now two numbers instead of one at the begining of the line...what are they? 1401 70 java.util.concurrent.ConcurrentHashMap::hash (49 bytes) 1412 71 java.lang.String::indexOf (7 bytes) 1420 72 ! java.io.BufferedReader::readLine (304 bytes) 1420 73 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (543 bytes) 1422 42 java.util.zip.ZipCoder::getBytes (192 bytes) made not entrant 1435 74 n java.lang.Object::hashCode (0 bytes) 1443 29 ! sun.misc.URLClassPath$JarLoader::getResource (91 bytes) made zombie 1443 25 sun.misc.URLClassPath::getResource (74 bytes) made zombie 1443 36 sun.misc.URLClassPath::getResource (74 bytes) made not entrant 1443 43 java.util.zip.ZipCoder::encoder (35 bytes) made not entrant 1449 75 java.lang.String::endsWith (15 bytes) 1631 1 % sun.misc.URLClassPath::getResource @ 39 (74 bytes) 1665 76 java.lang.ClassLoader::checkName (43 bytes) - Charlie From tom.rodriguez at oracle.com Tue Oct 4 17:04:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 4 Oct 2011 17:04:19 -0700 Subject: Help with JIT talk for tomorrow In-Reply-To: References: Message-ID: <5798A261-2045-4E95-AC21-B06212A9CCB2@oracle.com> On Oct 4, 2011, at 4:47 PM, Charles Oliver Nutter wrote: > Hey all...I'm updating and expanding my talk on C2 and will be posting > some questions. Hopefully there's someone out there who can answer > them :) Fire away. > > First up... given this output from PrintCompilation, what do the "!" > and "n" and "%" mean? ! means the method is synchronized, n means it's a native method wrapper compile, and % means it's an OSR compile. > > Also, in Java 7 there's now two numbers instead of one at the begining > of the line...what are they? It's a timestamp in ms since the start of the VM. tom > > 1401 70 java.util.concurrent.ConcurrentHashMap::hash (49 bytes) > 1412 71 java.lang.String::indexOf (7 bytes) > 1420 72 ! java.io.BufferedReader::readLine (304 bytes) > 1420 73 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (543 bytes) > 1422 42 java.util.zip.ZipCoder::getBytes (192 bytes) > made not entrant > 1435 74 n java.lang.Object::hashCode (0 bytes) > 1443 29 ! sun.misc.URLClassPath$JarLoader::getResource > (91 bytes) made zombie > 1443 25 sun.misc.URLClassPath::getResource (74 bytes) > made zombie > 1443 36 sun.misc.URLClassPath::getResource (74 bytes) > made not entrant > 1443 43 java.util.zip.ZipCoder::encoder (35 bytes) > made not entrant > 1449 75 java.lang.String::endsWith (15 bytes) > 1631 1 % sun.misc.URLClassPath::getResource @ 39 (74 bytes) > 1665 76 java.lang.ClassLoader::checkName (43 bytes) > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From forax at univ-mlv.fr Tue Oct 4 17:05:00 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 05 Oct 2011 02:05:00 +0200 Subject: Help with JIT talk for tomorrow In-Reply-To: References: Message-ID: <4E8B9F2C.1060707@univ-mlv.fr> On 10/05/2011 01:47 AM, Charles Oliver Nutter wrote: > Hey all...I'm updating and expanding my talk on C2 and will be posting > some questions. Hopefully there's someone out there who can answer > them :) > > First up... given this output from PrintCompilation, what do the "!" > and "n" and "%" mean? n -> native % -> OSR (On Stack Replacement (loop optimizer)), you have the bytecode offset after the @ on the same line. > > Also, in Java 7 there's now two numbers instead of one at the begining > of the line...what are they? > > 1401 70 java.util.concurrent.ConcurrentHashMap::hash (49 bytes) > 1412 71 java.lang.String::indexOf (7 bytes) > 1420 72 ! java.io.BufferedReader::readLine (304 bytes) > 1420 73 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (543 bytes) > 1422 42 java.util.zip.ZipCoder::getBytes (192 bytes) > made not entrant > 1435 74 n java.lang.Object::hashCode (0 bytes) > 1443 29 ! sun.misc.URLClassPath$JarLoader::getResource > (91 bytes) made zombie > 1443 25 sun.misc.URLClassPath::getResource (74 bytes) > made zombie > 1443 36 sun.misc.URLClassPath::getResource (74 bytes) > made not entrant > 1443 43 java.util.zip.ZipCoder::encoder (35 bytes) > made not entrant > 1449 75 java.lang.String::endsWith (15 bytes) > 1631 1 % sun.misc.URLClassPath::getResource @ 39 (74 bytes) > 1665 76 java.lang.ClassLoader::checkName (43 bytes) good questions :) R?mi > > - Charlie From tom.rodriguez at oracle.com Tue Oct 4 17:17:37 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 4 Oct 2011 17:17:37 -0700 Subject: Help with JIT talk for tomorrow In-Reply-To: References: <5798A261-2045-4E95-AC21-B06212A9CCB2@oracle.com> Message-ID: <30037606-0761-4A59-AFBA-2E9E2E078F25@oracle.com> On Oct 4, 2011, at 5:12 PM, Matt Fowles wrote: > Tom~ > > On Tue, Oct 4, 2011 at 8:04 PM, Tom Rodriguez wrote: > > First up... given this output from PrintCompilation, what do the "!" > > and "n" and "%" mean? > > ! means the method is synchronized, n means it's a native method wrapper compile, and % means it's an OSR compile. > > Your answer and the website linked to disagree. According to the website: > > ! Method has exception handlers > s Method declared as synchronized > > Can you verify which is correct just so we don't have misinformation running around? Oops. I think I'd trust the written one more than my memory and a quick look at the sources confirms that. const char compile_type = is_osr_method ? '%' : ' '; const char sync_char = is_synchronized ? 's' : ' '; const char exception_char = has_exception_handler ? '!' : ' '; const char blocking_char = is_blocking ? 'b' : ' '; const char native_char = is_native ? 'n' : ' '; Thanks for correcting me. Personally I've never understood why we bothered to print anything besides n and %. tom > > Matt > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From vladimir.kozlov at oracle.com Tue Oct 4 18:57:53 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 05 Oct 2011 01:57:53 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6865265: JVM crashes with "missing exception handler" error Message-ID: <20111005015757.6FBF947BE2@hg.openjdk.java.net> Changeset: ec5ce9326985 Author: kvn Date: 2011-10-04 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ec5ce9326985 6865265: JVM crashes with "missing exception handler" error Summary: Retry the call to fast_exception_handler_bci_for() after it returned with a pending exception. Don't cache the exception handler pc computed by compute_compiled_exc_handler() if the handler is for another (nested) exception. Reviewed-by: kamg, kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/6865265/StackOverflowBug.java From kirk at kodewerk.com Wed Oct 5 01:22:18 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Wed, 5 Oct 2011 10:22:18 +0200 Subject: Help with JIT talk for tomorrow In-Reply-To: References: Message-ID: The ! means the method has exception handlers. I'm not sure that I understand Remi's answer. Here's some code from sharedRuntime.cpp. A number of other files mention PrintCompilation but it's late so I've not sorted out where the main compile is logged. If it's in compile.cpp I've completely missed it ;-) if (PrintCompilation) { ttyLocker ttyl; tty->print("--- n%s ", (method->is_synchronized() ? "s" : " ")); method->print_short_name(tty); if (method->is_static()) { tty->print(" (static)"); } tty->cr(); } Regards, Kirk On Oct 5, 2011, at 1:47 AM, Charles Oliver Nutter wrote: > Hey all...I'm updating and expanding my talk on C2 and will be posting > some questions. Hopefully there's someone out there who can answer > them :) > > First up... given this output from PrintCompilation, what do the "!" > and "n" and "%" mean? > > Also, in Java 7 there's now two numbers instead of one at the begining > of the line...what are they? > > 1401 70 java.util.concurrent.ConcurrentHashMap::hash (49 bytes) > 1412 71 java.lang.String::indexOf (7 bytes) > 1420 72 ! java.io.BufferedReader::readLine (304 bytes) > 1420 73 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (543 bytes) > 1422 42 java.util.zip.ZipCoder::getBytes (192 bytes) > made not entrant > 1435 74 n java.lang.Object::hashCode (0 bytes) > 1443 29 ! sun.misc.URLClassPath$JarLoader::getResource > (91 bytes) made zombie > 1443 25 sun.misc.URLClassPath::getResource (74 bytes) > made zombie > 1443 36 sun.misc.URLClassPath::getResource (74 bytes) > made not entrant > 1443 43 java.util.zip.ZipCoder::encoder (35 bytes) > made not entrant > 1449 75 java.lang.String::endsWith (15 bytes) > 1631 1 % sun.misc.URLClassPath::getResource @ 39 (74 bytes) > 1665 76 java.lang.ClassLoader::checkName (43 bytes) > > - Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111005/f01fab7d/attachment-0001.html From kirk at kodewerk.com Wed Oct 5 01:31:43 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Wed, 5 Oct 2011 10:31:43 +0200 Subject: Help with JIT talk for tomorrow In-Reply-To: References: Message-ID: The ! means the method has exception handlers. I'm not sure that I understand Remi's answer. Here's some code from sharedRuntime.cpp. A number of other files mention PrintCompilation but it's late so I've not sorted out where the main compile is logged. If it's in compile.cpp I've completely missed it ;-) if (PrintCompilation) { ttyLocker ttyl; tty->print("--- n%s ", (method->is_synchronized() ? "s" : " ")); method->print_short_name(tty); if (method->is_static()) { tty->print(" (static)"); } tty->cr(); } Regards, Kirk On Oct 5, 2011, at 1:47 AM, Charles Oliver Nutter wrote: > Hey all...I'm updating and expanding my talk on C2 and will be posting > some questions. Hopefully there's someone out there who can answer > them :) > > First up... given this output from PrintCompilation, what do the "!" > and "n" and "%" mean? > > Also, in Java 7 there's now two numbers instead of one at the begining > of the line...what are they? > > 1401 70 java.util.concurrent.ConcurrentHashMap::hash (49 bytes) > 1412 71 java.lang.String::indexOf (7 bytes) > 1420 72 ! java.io.BufferedReader::readLine (304 bytes) > 1420 73 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (543 bytes) > 1422 42 java.util.zip.ZipCoder::getBytes (192 bytes) > made not entrant > 1435 74 n java.lang.Object::hashCode (0 bytes) > 1443 29 ! sun.misc.URLClassPath$JarLoader::getResource > (91 bytes) made zombie > 1443 25 sun.misc.URLClassPath::getResource (74 bytes) > made zombie > 1443 36 sun.misc.URLClassPath::getResource (74 bytes) > made not entrant > 1443 43 java.util.zip.ZipCoder::encoder (35 bytes) > made not entrant > 1449 75 java.lang.String::endsWith (15 bytes) > 1631 1 % sun.misc.URLClassPath::getResource @ 39 (74 bytes) > 1665 76 java.lang.ClassLoader::checkName (43 bytes) > > - Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111005/e9f91948/attachment.html From matt.fowles at gmail.com Tue Oct 4 17:12:23 2011 From: matt.fowles at gmail.com (Matt Fowles) Date: Tue, 4 Oct 2011 20:12:23 -0400 Subject: Help with JIT talk for tomorrow In-Reply-To: <5798A261-2045-4E95-AC21-B06212A9CCB2@oracle.com> References: <5798A261-2045-4E95-AC21-B06212A9CCB2@oracle.com> Message-ID: Tom~ On Tue, Oct 4, 2011 at 8:04 PM, Tom Rodriguez wrote: > > First up... given this output from PrintCompilation, what do the "!" > > and "n" and "%" mean? > > ! means the method is synchronized, n means it's a native method wrapper > compile, and % means it's an OSR compile. Your answer and the website linked to disagree. According to the website: ! Method has exception handlers s Method declared as synchronized Can you verify which is correct just so we don't have misinformation running around? Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111004/38bd589d/attachment.html From headius at headius.com Wed Oct 5 15:14:34 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 5 Oct 2011 15:14:34 -0700 Subject: Help with JIT talk for tomorrow In-Reply-To: References: Message-ID: Thanks for the answers everyone. I updated slides quickly before my talk to mention the ms times, exception-handling, and OSR sigils. I'll continue revising the talk over time and adding information. Probably will add LogCompilation to the list of flags I cover, since it gives more information than PrintInlining. - Charlie On Wed, Oct 5, 2011 at 1:22 AM, Charles K Pepperdine wrote: > The ! means the method has exception handlers. I'm not sure that I > understand Remi's answer. Here's some code from sharedRuntime.cpp. A number > of other files mention PrintCompilation but it's late so I've not sorted out > where the main compile is logged. If it's in compile.cpp I've completely > missed it ;-) > > > ??if (PrintCompilation) { > ? ? ttyLocker ttyl; > ? ? tty->print("--- ? n%s ", (method->is_synchronized() ? "s" : " ")); > ? ? method->print_short_name(tty); > ? ? if (method->is_static()) { > ? ? ? tty->print(" (static)"); > ? ? } > ? ? tty->cr(); > ? } > Regards, > Kirk > On Oct 5, 2011, at 1:47 AM, Charles Oliver Nutter wrote: > > Hey all...I'm updating and expanding my talk on C2 and will be posting > some questions. Hopefully there's someone out there who can answer > them :) > > First up... given this output from PrintCompilation, what do the "!" > and "n" and "%" mean? > > Also, in Java 7 there's now two numbers instead of one at the begining > of the line...what are they? > > ??1401 ??70 ????????????java.util.concurrent.ConcurrentHashMap::hash (49 > bytes) > ??1412 ??71 ????????????java.lang.String::indexOf (7 bytes) > ??1420 ??72 ??! ????????java.io.BufferedReader::readLine (304 bytes) > ??1420 ??73 ????????????sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (543 > bytes) > ??1422 ??42 ????????????java.util.zip.ZipCoder::getBytes (192 bytes) > made not entrant > ??1435 ??74 ????n ??????java.lang.Object::hashCode (0 bytes) > ??1443 ??29 ??! ????????sun.misc.URLClassPath$JarLoader::getResource > (91 bytes) ??made zombie > ??1443 ??25 ????????????sun.misc.URLClassPath::getResource (74 bytes) > ?made zombie > ??1443 ??36 ????????????sun.misc.URLClassPath::getResource (74 bytes) > ?made not entrant > ??1443 ??43 ????????????java.util.zip.ZipCoder::encoder (35 bytes) > made not entrant > ??1449 ??75 ????????????java.lang.String::endsWith (15 bytes) > ??1631 ???1 % ??????????sun.misc.URLClassPath::getResource @ 39 (74 bytes) > ??1665 ??76 ????????????java.lang.ClassLoader::checkName (43 bytes) > > - Charlie > > From rednaxelafx at gmail.com Thu Oct 6 06:27:48 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 6 Oct 2011 21:27:48 +0800 Subject: Help with JIT talk for tomorrow In-Reply-To: References: Message-ID: <658A07FE-993B-429A-A5A9-98895C21BB1F@gmail.com> I tried to document PrintCompilation a while ago, here: https://gist.github.com/1165804#file_notes.md Hope it helps. Sorry for the late reply, we're in holiday this week here in China. Regards, Kris Mok On 2011-10-5, at 7:47, Charles Oliver Nutter wrote: > Hey all...I'm updating and expanding my talk on C2 and will be posting > some questions. Hopefully there's someone out there who can answer > them :) > > First up... given this output from PrintCompilation, what do the "!" > and "n" and "%" mean? > > Also, in Java 7 there's now two numbers instead of one at the begining > of the line...what are they? > > 1401 70 java.util.concurrent.ConcurrentHashMap::hash (49 bytes) > 1412 71 java.lang.String::indexOf (7 bytes) > 1420 72 ! java.io.BufferedReader::readLine (304 bytes) > 1420 73 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (543 bytes) > 1422 42 java.util.zip.ZipCoder::getBytes (192 bytes) > made not entrant > 1435 74 n java.lang.Object::hashCode (0 bytes) > 1443 29 ! sun.misc.URLClassPath$JarLoader::getResource > (91 bytes) made zombie > 1443 25 sun.misc.URLClassPath::getResource (74 bytes) > made zombie > 1443 36 sun.misc.URLClassPath::getResource (74 bytes) > made not entrant > 1443 43 java.util.zip.ZipCoder::encoder (35 bytes) > made not entrant > 1449 75 java.lang.String::endsWith (15 bytes) > 1631 1 % sun.misc.URLClassPath::getResource @ 39 (74 bytes) > 1665 76 java.lang.ClassLoader::checkName (43 bytes) > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From christian.thalinger at oracle.com Thu Oct 6 06:46:07 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 6 Oct 2011 15:46:07 +0200 Subject: review request(XS): 7096010 c2: running with +PrintOptoAssembly crashes the VM when $constanttablebase is used In-Reply-To: References: Message-ID: <9E70C58B-7AAC-4023-B6D0-75626735D83B@oracle.com> Oops. Thanks for fixing that. -- Chris On Sep 28, 2011, at 6:29 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7096010/webrev.00/ > > For $constanttablebase, st->print("%s") is called without an argument. > > Roland. From christian.thalinger at oracle.com Thu Oct 6 06:49:09 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 6 Oct 2011 15:49:09 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: <4E7C8763.3000101@gmx.de> References: <4E7C8763.3000101@gmx.de> Message-ID: On Sep 23, 2011, at 3:19 PM, Sebastian Sickelmann wrote: > Am 22.09.2011 12:23, schrieb Christian Thalinger: >> http://cr.openjdk.java.net/~twisti/7092712/ >> >> 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP >> Reviewed-by: >> >> The problem is that ciEnv::get_fake_invokedynamic_method_impl calls >> get_unloaded_method with java.lang.invoke.MethodHandle as the holder >> for unresolved call sites. >> >> Since the loader of j.l.i.MethodHandle is the boot class loader the >> resolving of e.g. signature classes is done with the boot class loader >> resulting in problems like: >> >> (dbx) p this->print() >> this->print() = (void) >> (dbx) p that->print() >> that->print() = (void) >> >> Later in the game a ciInstanceKlass lookup for NEW2 returns a >> ciInstanceKlass created during the signature resolving in >> get_unloaded_method with the boot class loader as loader resulting in >> the above situation. >> >> The fix is to always pass an accessor to get_unloaded_method and >> subsequently the ciMethod constructor. >> >> src/share/vm/ci/ciEnv.cpp >> src/share/vm/ci/ciEnv.hpp >> src/share/vm/ci/ciMethod.cpp >> src/share/vm/ci/ciMethod.hpp >> src/share/vm/ci/ciObjectFactory.cpp >> src/share/vm/ci/ciObjectFactory.hpp >> > It fixed it for me on my Testcase with (jdk8). > Thanks for that. > > I can't review it formally (because i don't understand the fix in a complete manner) but > should there be an automated test for this? Or is this not a common practice at hotspot-level? It is but I couldn't write a test case in plain Java to reproduce this error (using ASM is not an option here). > > Will there be a jdk7 backport? Yes, I think this fix should be backported to 7. -- Chris > > -- Sebastian From bertrand.delsart at oracle.com Thu Oct 6 07:21:06 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Thu, 06 Oct 2011 16:21:06 +0200 Subject: Request For Review (XS): 7096366, corruption of floating-point values with DeoptimizeALot on some big endian machines Message-ID: <4E8DB952.60604@oracle.com> Hi, Here is a fix for a deoptimization issue on some big endian machines (those which have no 32-bits float register and encode the floats in the low 32-bits of 64-bits register, like PPC e500v2) http://cr.openjdk.java.net/~bdelsart/7096366/00/webrev/ Fix should be safe for all platforms and automatically detect those that need the fix. It can only impact big endian machines which do not encode floats in registers as 64 bits. In that case, unless the doubles are using two float registers, there might be a confusion between the VMReg for the intended float and the VMreg for the double using the same register. This is identified by the fact that two successive float VMRregs correspond to the same FloatRegister and that we currently have the first one. The fix updates the VMReg to the second half, which should be the one corresponding to the float on big endian machines. Note that SPARC is a big endian machine with 32 bits encoding but this fix does not break anything since VMReg->next->register always differs from VMReg->register. Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From christian.thalinger at oracle.com Thu Oct 6 08:23:46 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 6 Oct 2011 17:23:46 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> Message-ID: <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> On Sep 29, 2011, at 3:44 AM, John Rose wrote: > On Sep 22, 2011, at 3:23 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7092712/ >> >> ... >> >> The fix is to always pass an accessor to get_unloaded_method and >> subsequently the ciMethod constructor. > > There's still a bug here: If you call get_unloaded_method twice on the same parameters, it will return the same ciMethod, which is good. > > But, if you pass a different accessor (along with the same other values) you will get the same ciMethod. If the two accessors are different enough, they can imply different resolved signature types, so this can potentially cause 7092712 to reoccur. I agree. > > I think you need to match the accessor argument in the matching loop of get_unloaded_method. > > Option 1. In the matching loop, after checking the symbolic signature, also check the resolved signature. You can do this by making a ciSignature (which resolves types relative to the accessor). Add an equals method to ciSignature. Consider adding equals(ciSymbol* sig, ciKlass* accessor), so that the second ciSignature does not need to be created. > > Option 2. Check the accessor argument against the signature._accessing_klass in the matching loop. To preserve existing behavior (for non-MH calls) either use null accessors for non-MH lookups and treat them specially (as wildcards) or else keep separate lists (of MH and non-MH unloaded methods). > > I think Option 1 is more precise, but Option 2 might be a more conservative change. Option 1 sounds like a clean way. But to compare the resolved signature we have to resolve the types anyway so maybe it's better to create the second ciSignature lazily when we need it. I updated the webrev. -- Chris > > (This unloaded method concept is very tricky, even kludgey.) > > -- John From asok.perumainar at oracle.com Thu Oct 6 12:00:49 2011 From: asok.perumainar at oracle.com (asok.perumainar at oracle.com) Date: Thu, 6 Oct 2011 12:00:49 -0700 (PDT) Subject: Auto Reply: hotspot-compiler-dev Digest, Vol 53, Issue 5 Message-ID: <44e36e79-9df8-4984-9d73-98a105139ff2@default> This is an auto-replied message. I am out of office today Thursday October 6th.I anticipate checking & responding to emails in the evening. For any urgent support requests please contact : Natalie Conklin natalie.conklin at oracle.com Regards, Asok From tom.rodriguez at oracle.com Thu Oct 6 12:28:15 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 6 Oct 2011 12:28:15 -0700 Subject: review for 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was Message-ID: http://cr.openjdk.java.net/~never/7093690 1 line changed: 0 ins; 0 del; 1 mod; 1095 unchg 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was Reviewed-by: The SA ricochet changes for 7051798 forgot to rebias stack pointers as is done in other calls to the SPARCFrame constructor. Tested with failing test case from report. From vladimir.kozlov at oracle.com Thu Oct 6 12:35:25 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 06 Oct 2011 12:35:25 -0700 Subject: review for 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was In-Reply-To: References: Message-ID: <4E8E02FD.4050804@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7093690 > 1 line changed: 0 ins; 0 del; 1 mod; 1095 unchg > > 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was > Reviewed-by: > > The SA ricochet changes for 7051798 forgot to rebias stack pointers as > is done in other calls to the SPARCFrame constructor. Tested with > failing test case from report. > From sebastian.sickelmann at gmx.de Thu Oct 6 21:52:51 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 07 Oct 2011 06:52:51 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> Message-ID: <4E8E85A3.10203@gmx.de> Am 06.10.2011 17:23, schrieb Christian Thalinger: > On Sep 29, 2011, at 3:44 AM, John Rose wrote: > >> On Sep 22, 2011, at 3:23 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7092712/ >>> >>> ... >>> >>> The fix is to always pass an accessor to get_unloaded_method and >>> subsequently the ciMethod constructor. >> There's still a bug here: If you call get_unloaded_method twice on the same parameters, it will return the same ciMethod, which is good. >> >> But, if you pass a different accessor (along with the same other values) you will get the same ciMethod. If the two accessors are different enough, they can imply different resolved signature types, so this can potentially cause 7092712 to reoccur. > I agree. > >> I think you need to match the accessor argument in the matching loop of get_unloaded_method. >> >> Option 1. In the matching loop, after checking the symbolic signature, also check the resolved signature. You can do this by making a ciSignature (which resolves types relative to the accessor). Add an equals method to ciSignature. Consider adding equals(ciSymbol* sig, ciKlass* accessor), so that the second ciSignature does not need to be created. >> >> Option 2. Check the accessor argument against the signature._accessing_klass in the matching loop. To preserve existing behavior (for non-MH calls) either use null accessors for non-MH lookups and treat them specially (as wildcards) or else keep separate lists (of MH and non-MH unloaded methods). >> >> I think Option 1 is more precise, but Option 2 might be a more conservative change. > Option 1 sounds like a clean way. But to compare the resolved signature we have to resolve the types anyway so maybe it's better to create the second ciSignature lazily when we need it. I updated the webrev. > > -- Chris > >> (This unloaded method concept is very tricky, even kludgey.) >> >> -- John I am sorry but the actually patch doesn't compile. I used rev 95607b70acb5 of [1] as base. Maybe i should use an older rev for testing this patch? -- Sebastian [1] http://hg.openjdk.java.net/hsx/hotspot-main/ From christian.thalinger at oracle.com Fri Oct 7 00:53:49 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 7 Oct 2011 09:53:49 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: <4E8E85A3.10203@gmx.de> References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> <4E8E85A3.10203@gmx.de> Message-ID: You're right. It seems I uploaded the wrong webrev. Now it should work. -- Christian On Oct 7, 2011, at 6:52 AM, Sebastian Sickelmann wrote: > Am 06.10.2011 17:23, schrieb Christian Thalinger: >> On Sep 29, 2011, at 3:44 AM, John Rose wrote: >> >>> On Sep 22, 2011, at 3:23 AM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/7092712/ >>>> >>>> ... >>>> >>>> The fix is to always pass an accessor to get_unloaded_method and >>>> subsequently the ciMethod constructor. >>> There's still a bug here: If you call get_unloaded_method twice on the same parameters, it will return the same ciMethod, which is good. >>> >>> But, if you pass a different accessor (along with the same other values) you will get the same ciMethod. If the two accessors are different enough, they can imply different resolved signature types, so this can potentially cause 7092712 to reoccur. >> I agree. >> >>> I think you need to match the accessor argument in the matching loop of get_unloaded_method. >>> >>> Option 1. In the matching loop, after checking the symbolic signature, also check the resolved signature. You can do this by making a ciSignature (which resolves types relative to the accessor). Add an equals method to ciSignature. Consider adding equals(ciSymbol* sig, ciKlass* accessor), so that the second ciSignature does not need to be created. >>> >>> Option 2. Check the accessor argument against the signature._accessing_klass in the matching loop. To preserve existing behavior (for non-MH calls) either use null accessors for non-MH lookups and treat them specially (as wildcards) or else keep separate lists (of MH and non-MH unloaded methods). >>> >>> I think Option 1 is more precise, but Option 2 might be a more conservative change. >> Option 1 sounds like a clean way. But to compare the resolved signature we have to resolve the types anyway so maybe it's better to create the second ciSignature lazily when we need it. I updated the webrev. >> >> -- Chris >> >>> (This unloaded method concept is very tricky, even kludgey.) >>> >>> -- John > I am sorry but the actually patch doesn't compile. I used rev 95607b70acb5 of [1] > as base. Maybe i should use an older rev for testing this patch? > > -- Sebastian > [1] http://hg.openjdk.java.net/hsx/hotspot-main/ From christian.thalinger at oracle.com Fri Oct 7 00:54:17 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 7 Oct 2011 09:54:17 +0200 Subject: review for 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was In-Reply-To: References: Message-ID: <81E72003-78A4-4526-BBFA-4FEE196B6684@oracle.com> Looks good. -- Christian On Oct 6, 2011, at 9:28 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7093690 > 1 line changed: 0 ins; 0 del; 1 mod; 1095 unchg > > 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was > Reviewed-by: > > The SA ricochet changes for 7051798 forgot to rebias stack pointers as > is done in other calls to the SPARCFrame constructor. Tested with > failing test case from report. > From bertrand.delsart at oracle.com Fri Oct 7 07:22:32 2011 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Fri, 07 Oct 2011 14:22:32 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7096366: PPC: corruption of floating-point values with DeoptimizeALot Message-ID: <20111007142236.4776747CB5@hg.openjdk.java.net> Changeset: eba73e0c7780 Author: bdelsart Date: 2011-10-07 13:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eba73e0c7780 7096366: PPC: corruption of floating-point values with DeoptimizeALot Summary: fix for a deoptimization found on PPC, which could impact other big endian platforms Reviewed-by: roland, dholmes ! src/share/vm/c1/c1_LinearScan.cpp From tom.rodriguez at oracle.com Fri Oct 7 10:38:37 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 7 Oct 2011 10:38:37 -0700 Subject: review for 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was In-Reply-To: <81E72003-78A4-4526-BBFA-4FEE196B6684@oracle.com> References: <81E72003-78A4-4526-BBFA-4FEE196B6684@oracle.com> Message-ID: Thanks! tom On Oct 7, 2011, at 12:54 AM, Christian Thalinger wrote: > Looks good. -- Christian > > On Oct 6, 2011, at 9:28 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7093690 >> 1 line changed: 0 ins; 0 del; 1 mod; 1095 unchg >> >> 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was >> Reviewed-by: >> >> The SA ricochet changes for 7051798 forgot to rebias stack pointers as >> is done in other calls to the SPARCFrame constructor. Tested with >> failing test case from report. >> > From sebastian.sickelmann at gmx.de Sat Oct 8 10:07:46 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 08 Oct 2011 19:07:46 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> <4E8E85A3.10203@gmx.de> Message-ID: <4E908362.8020103@gmx.de> Am 07.10.2011 09:53, schrieb Christian Thalinger: > You're right. It seems I uploaded the wrong webrev. Now it should work. It works again(compile and my testcase). Doesn't know how to test the thing John mentioned. So my result is again: works for me. Thanks -- Sebastian > -- Christian > > On Oct 7, 2011, at 6:52 AM, Sebastian Sickelmann wrote: > >> Am 06.10.2011 17:23, schrieb Christian Thalinger: >>> On Sep 29, 2011, at 3:44 AM, John Rose wrote: >>> >>>> On Sep 22, 2011, at 3:23 AM, Christian Thalinger wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/7092712/ >>>>> >>>>> ... >>>>> >>>>> The fix is to always pass an accessor to get_unloaded_method and >>>>> subsequently the ciMethod constructor. >>>> There's still a bug here: If you call get_unloaded_method twice on the same parameters, it will return the same ciMethod, which is good. >>>> >>>> But, if you pass a different accessor (along with the same other values) you will get the same ciMethod. If the two accessors are different enough, they can imply different resolved signature types, so this can potentially cause 7092712 to reoccur. >>> I agree. >>> >>>> I think you need to match the accessor argument in the matching loop of get_unloaded_method. >>>> >>>> Option 1. In the matching loop, after checking the symbolic signature, also check the resolved signature. You can do this by making a ciSignature (which resolves types relative to the accessor). Add an equals method to ciSignature. Consider adding equals(ciSymbol* sig, ciKlass* accessor), so that the second ciSignature does not need to be created. >>>> >>>> Option 2. Check the accessor argument against the signature._accessing_klass in the matching loop. To preserve existing behavior (for non-MH calls) either use null accessors for non-MH lookups and treat them specially (as wildcards) or else keep separate lists (of MH and non-MH unloaded methods). >>>> >>>> I think Option 1 is more precise, but Option 2 might be a more conservative change. >>> Option 1 sounds like a clean way. But to compare the resolved signature we have to resolve the types anyway so maybe it's better to create the second ciSignature lazily when we need it. I updated the webrev. >>> >>> -- Chris >>> >>>> (This unloaded method concept is very tricky, even kludgey.) >>>> >>>> -- John >> I am sorry but the actually patch doesn't compile. I used rev 95607b70acb5 of [1] >> as base. Maybe i should use an older rev for testing this patch? >> >> -- Sebastian >> [1] http://hg.openjdk.java.net/hsx/hotspot-main/ From CHRISTIAN.THALINGER at oracle.com Mon Oct 10 06:20:59 2011 From: CHRISTIAN.THALINGER at oracle.com (Christian Thalinger) Date: Mon, 10 Oct 2011 15:20:59 +0200 Subject: Request for reviews (S): 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed Message-ID: http://cr.openjdk.java.net/~twisti/7081938/ 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed Reviewed-by: MethodHandles::ricochet_frame_sender uses RicochetFrame::extended_sender_sp to create the frame for the ricochet frame. extended_sender_sp returns the _saved_args_base. In a debug VM there is another slot pushed below the saved_args_base in _adapter_opt_collect/filter/fold; this is MAGIC_NUMBER_2. The fix is to return a correct value for extended_sender_sp. It's possible that this bug results in crashes or program failures with a product build when the extra_slots in collect/filter/fold adapters is > 0. src/cpu/x86/vm/methodHandles_x86.hpp src/cpu/x86/vm/methodHandles_x86.cpp src/cpu/x86/vm/frame_x86.cpp From tom.rodriguez at oracle.com Mon Oct 10 11:16:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 10 Oct 2011 11:16:23 -0700 Subject: Request for reviews (S): 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed In-Reply-To: References: Message-ID: Looks good. tom On Oct 10, 2011, at 6:20 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7081938/ > > 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed > Reviewed-by: > > MethodHandles::ricochet_frame_sender uses > RicochetFrame::extended_sender_sp to create the frame for the ricochet > frame. extended_sender_sp returns the _saved_args_base. > > In a debug VM there is another slot pushed below the saved_args_base > in _adapter_opt_collect/filter/fold; this is MAGIC_NUMBER_2. > > The fix is to return a correct value for extended_sender_sp. > > It's possible that this bug results in crashes or program failures > with a product build when the extra_slots in collect/filter/fold > adapters is > 0. > > src/cpu/x86/vm/methodHandles_x86.hpp > src/cpu/x86/vm/methodHandles_x86.cpp > src/cpu/x86/vm/frame_x86.cpp > From CHRISTIAN.THALINGER at oracle.com Mon Oct 10 11:36:01 2011 From: CHRISTIAN.THALINGER at oracle.com (Christian Thalinger) Date: Mon, 10 Oct 2011 20:36:01 +0200 Subject: Request for reviews (S): 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed In-Reply-To: References: Message-ID: <92C82569-4D2F-4979-A057-A0579D2383EC@oracle.com> Thank you, Tom. -- Chris On Oct 10, 2011, at 8:16 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 10, 2011, at 6:20 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7081938/ >> >> 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed >> Reviewed-by: >> >> MethodHandles::ricochet_frame_sender uses >> RicochetFrame::extended_sender_sp to create the frame for the ricochet >> frame. extended_sender_sp returns the _saved_args_base. >> >> In a debug VM there is another slot pushed below the saved_args_base >> in _adapter_opt_collect/filter/fold; this is MAGIC_NUMBER_2. >> >> The fix is to return a correct value for extended_sender_sp. >> >> It's possible that this bug results in crashes or program failures >> with a product build when the extra_slots in collect/filter/fold >> adapters is > 0. >> >> src/cpu/x86/vm/methodHandles_x86.hpp >> src/cpu/x86/vm/methodHandles_x86.cpp >> src/cpu/x86/vm/frame_x86.cpp >> > From christian.thalinger at oracle.com Tue Oct 11 08:13:15 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Oct 2011 17:13:15 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> Message-ID: <41F0F740-E973-4852-8979-F2100474E515@oracle.com> On Oct 6, 2011, at 5:23 PM, Christian Thalinger wrote: > > On Sep 29, 2011, at 3:44 AM, John Rose wrote: > >> On Sep 22, 2011, at 3:23 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7092712/ >>> >>> ... >>> >>> The fix is to always pass an accessor to get_unloaded_method and >>> subsequently the ciMethod constructor. >> >> There's still a bug here: If you call get_unloaded_method twice on the same parameters, it will return the same ciMethod, which is good. >> >> But, if you pass a different accessor (along with the same other values) you will get the same ciMethod. If the two accessors are different enough, they can imply different resolved signature types, so this can potentially cause 7092712 to reoccur. > > I agree. > >> >> I think you need to match the accessor argument in the matching loop of get_unloaded_method. >> >> Option 1. In the matching loop, after checking the symbolic signature, also check the resolved signature. You can do this by making a ciSignature (which resolves types relative to the accessor). Add an equals method to ciSignature. Consider adding equals(ciSymbol* sig, ciKlass* accessor), so that the second ciSignature does not need to be created. >> >> Option 2. Check the accessor argument against the signature._accessing_klass in the matching loop. To preserve existing behavior (for non-MH calls) either use null accessors for non-MH lookups and treat them specially (as wildcards) or else keep separate lists (of MH and non-MH unloaded methods). >> >> I think Option 1 is more precise, but Option 2 might be a more conservative change. > > Option 1 sounds like a clean way. But to compare the resolved signature we have to resolve the types anyway so maybe it's better to create the second ciSignature lazily when we need it. I updated the webrev. John, can you re-review the changes please? -- Chris > > -- Chris > >> >> (This unloaded method concept is very tricky, even kludgey.) >> >> -- John > From Ulf.Zibis at gmx.de Tue Oct 11 08:59:51 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 11 Oct 2011 17:59:51 +0200 Subject: Missing evaluation on bugs 6914095, 6914113, 6933327, 6935994 Message-ID: <4E9467F7.9070400@gmx.de> Hi, some time ago I have submitted these bugs: 6914095 - HotSpot should reuse invariant loop parameter 6914113 - Copy int to byte[] in 1 step 6933327 - Use shifted addressing modes instead of shift instuctions 6935994 - Use as less bits as necessary I do not see, why they have been closed as "Will Not Fix". Can someone add content to the 'evaluation' section, or at least explain reasons here? Much thanks, -Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111011/5a394dee/attachment.html From christian.thalinger at oracle.com Tue Oct 11 09:01:59 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 11 Oct 2011 16:01:59 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed Message-ID: <20111011160205.45BA747F16@hg.openjdk.java.net> Changeset: 0abefdb54d21 Author: twisti Date: 2011-10-11 02:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0abefdb54d21 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed Reviewed-by: never, bdelsart ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp From vitalyd at gmail.com Tue Oct 11 09:30:45 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 11 Oct 2011 12:30:45 -0400 Subject: Missing evaluation on bugs 6914095, 6914113, 6933327, 6935994 In-Reply-To: <4E9467F7.9070400@gmx.de> References: <4E9467F7.9070400@gmx.de> Message-ID: On your last one, have you checked to see if it makes a difference? I believe using partial registers requires a prefix on the op, making the instruction larger. Also there are some partial register stalls that can be triggered. On Oct 11, 2011 12:00 PM, "Ulf Zibis" wrote: > Hi, > > some time ago I have submitted these bugs: > > 6914095 - > HotSpot should reuse invariant loop parameter > 6914113 - Copy > int to byte[] in 1 step > 6933327 - Use > shifted addressing modes instead of shift instuctions > 6935994 - Use > as less bits as necessary > > I do not see, why they have been closed as "Will Not Fix". > > Can someone add content to the 'evaluation' section, or at least explain > reasons here? > > Much thanks, > > -Ulf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111011/7776e33e/attachment.html From tom.rodriguez at oracle.com Tue Oct 11 09:43:21 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 11 Oct 2011 09:43:21 -0700 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: <41F0F740-E973-4852-8979-F2100474E515@oracle.com> References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> <41F0F740-E973-4852-8979-F2100474E515@oracle.com> Message-ID: <639397B9-5965-4FC3-82D9-49B5F2A39267@oracle.com> On Oct 11, 2011, at 8:13 AM, Christian Thalinger wrote: > > On Oct 6, 2011, at 5:23 PM, Christian Thalinger wrote: > >> >> On Sep 29, 2011, at 3:44 AM, John Rose wrote: >> >>> On Sep 22, 2011, at 3:23 AM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/7092712/ >>>> >>>> ... >>>> >>>> The fix is to always pass an accessor to get_unloaded_method and >>>> subsequently the ciMethod constructor. >>> >>> There's still a bug here: If you call get_unloaded_method twice on the same parameters, it will return the same ciMethod, which is good. >>> >>> But, if you pass a different accessor (along with the same other values) you will get the same ciMethod. If the two accessors are different enough, they can imply different resolved signature types, so this can potentially cause 7092712 to reoccur. >> >> I agree. >> >>> >>> I think you need to match the accessor argument in the matching loop of get_unloaded_method. >>> >>> Option 1. In the matching loop, after checking the symbolic signature, also check the resolved signature. You can do this by making a ciSignature (which resolves types relative to the accessor). Add an equals method to ciSignature. Consider adding equals(ciSymbol* sig, ciKlass* accessor), so that the second ciSignature does not need to be created. >>> >>> Option 2. Check the accessor argument against the signature._accessing_klass in the matching loop. To preserve existing behavior (for non-MH calls) either use null accessors for non-MH lookups and treat them specially (as wildcards) or else keep separate lists (of MH and non-MH unloaded methods). >>> >>> I think Option 1 is more precise, but Option 2 might be a more conservative change. >> >> Option 1 sounds like a clean way. But to compare the resolved signature we have to resolve the types anyway so maybe it's better to create the second ciSignature lazily when we need it. I updated the webrev. > > John, can you re-review the changes please? Having to allocate a signature for every compare is a bit ugly but I guess there isn't a better way to do that. Otherwise it looks good. tom > > -- Chris > >> >> -- Chris >> >>> >>> (This unloaded method concept is very tricky, even kludgey.) >>> >>> -- John >> > From christian.thalinger at oracle.com Tue Oct 11 09:46:06 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Oct 2011 18:46:06 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: <639397B9-5965-4FC3-82D9-49B5F2A39267@oracle.com> References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> <41F0F740-E973-4852-8979-F2100474E515@oracle.com> <639397B9-5965-4FC3-82D9-49B5F2A39267@oracle.com> Message-ID: On Oct 11, 2011, at 6:43 PM, Tom Rodriguez wrote: > > On Oct 11, 2011, at 8:13 AM, Christian Thalinger wrote: > >> >> On Oct 6, 2011, at 5:23 PM, Christian Thalinger wrote: >> >>> >>> On Sep 29, 2011, at 3:44 AM, John Rose wrote: >>> >>>> On Sep 22, 2011, at 3:23 AM, Christian Thalinger wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/7092712/ >>>>> >>>>> ... >>>>> >>>>> The fix is to always pass an accessor to get_unloaded_method and >>>>> subsequently the ciMethod constructor. >>>> >>>> There's still a bug here: If you call get_unloaded_method twice on the same parameters, it will return the same ciMethod, which is good. >>>> >>>> But, if you pass a different accessor (along with the same other values) you will get the same ciMethod. If the two accessors are different enough, they can imply different resolved signature types, so this can potentially cause 7092712 to reoccur. >>> >>> I agree. >>> >>>> >>>> I think you need to match the accessor argument in the matching loop of get_unloaded_method. >>>> >>>> Option 1. In the matching loop, after checking the symbolic signature, also check the resolved signature. You can do this by making a ciSignature (which resolves types relative to the accessor). Add an equals method to ciSignature. Consider adding equals(ciSymbol* sig, ciKlass* accessor), so that the second ciSignature does not need to be created. >>>> >>>> Option 2. Check the accessor argument against the signature._accessing_klass in the matching loop. To preserve existing behavior (for non-MH calls) either use null accessors for non-MH lookups and treat them specially (as wildcards) or else keep separate lists (of MH and non-MH unloaded methods). >>>> >>>> I think Option 1 is more precise, but Option 2 might be a more conservative change. >>> >>> Option 1 sounds like a clean way. But to compare the resolved signature we have to resolve the types anyway so maybe it's better to create the second ciSignature lazily when we need it. I updated the webrev. >> >> John, can you re-review the changes please? > > Having to allocate a signature for every compare is a bit ugly but I guess there isn't a better way to do that. Yeah, not needing the allocation would be nice but we need to resolve the signature types. > Otherwise it looks good. Thanks. -- Chris > > tom > >> >> -- Chris >> >>> >>> -- Chris >>> >>>> >>>> (This unloaded method concept is very tricky, even kludgey.) >>>> >>>> -- John >>> >> > From vladimir.kozlov at oracle.com Tue Oct 11 09:54:06 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Oct 2011 09:54:06 -0700 Subject: Missing evaluation on bugs 6914095, 6914113, 6933327, 6935994 In-Reply-To: References: <4E9467F7.9070400@gmx.de> Message-ID: <4E9474AE.9050903@oracle.com> These bugs have evaluations in Comments section which unfortunately is not visible outside. I moved my comments to Evaluation section and included them below. Vladimir Vitaly Davidovich wrote: > > On your last one, have you checked to see if it makes a difference? I > believe using partial registers requires a prefix on the op, making > the instruction larger. Also there are some partial register stalls > that can be triggered. > > On Oct 11, 2011 12:00 PM, "Ulf Zibis" > wrote: > > Hi, > > some time ago I have submitted these bugs: > > 6914095 > - > HotSpot should reuse invariant loop parameter > It would be nice if 32bit x86 had more registers. Unfortunately we have to reuse registers otherwise we will get more spills on stack which will cause more performance regression then keeping value in register. And x*c+c is very fast (few cycles) on modern cpus. *** (#3 of 3): 2010-11-09 15:31:21 PST vladimir.kozlov at oracle.com > > 6914113 > - > Copy int to byte[] in 1 step > Will not do this. C2 type system will not allow store int into byte array. Other platforms require address alignment to 4 bytes for int store. Also on platforms with different endian the result will be different. *** (#2 of 2): 2010-08-25 14:51:13 PDT vladimir.kozlov at oracle.com > 6933327 > - Use > shifted addressing modes instead of shift instuctions > Will not fix. Using addressing mode involves addess unit which may have negative effect if you have memory access instructions near this code. *** (#2 of 2): 2010-08-25 14:29:34 PDT vladimir.kozlov at oracle.com > > 6935994 > - Use > as less bits as necessary > Should not do this since the other part of register will not be initialized to 0. *** (#2 of 2): 2010-08-25 14:39:10 PDT vladimir.kozlov at oracle.com > > I do not see, why they have been closed as "Will Not Fix". > > Can someone add content to the 'evaluation' section, or at least > explain reasons here? > > Much thanks, > > -Ulf > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111011/96226613/attachment-0001.html From john.r.rose at oracle.com Tue Oct 11 11:29:28 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 11 Oct 2011 11:29:28 -0700 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: <41F0F740-E973-4852-8979-F2100474E515@oracle.com> References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> <41F0F740-E973-4852-8979-F2100474E515@oracle.com> Message-ID: On Oct 11, 2011, at 8:13 AM, Christian Thalinger wrote: >>> I think you need to match the accessor argument in the matching loop of get_unloaded_method. >>> >>> Option 1. In the matching loop, after checking the symbolic signature, also check the resolved signature. You can do this by making a ciSignature (which resolves types relative to the accessor). Add an equals method to ciSignature. Consider adding equals(ciSymbol* sig, ciKlass* accessor), so that the second ciSignature does not need to be created. >>> >>> Option 2. Check the accessor argument against the signature._accessing_klass in the matching loop. To preserve existing behavior (for non-MH calls) either use null accessors for non-MH lookups and treat them specially (as wildcards) or else keep separate lists (of MH and non-MH unloaded methods). >>> >>> I think Option 1 is more precise, but Option 2 might be a more conservative change. >> >> Option 1 sounds like a clean way. But to compare the resolved signature we have to resolve the types anyway so maybe it's better to create the second ciSignature lazily when we need it. I updated the webrev. > > John, can you re-review the changes please? In the ciSignature::equals method, why bother to resolve types when you first prove equality of accessing_klass? The code in the webrev is (I think) equivalent to this->ac_kl == that->ac_kl && this->symbol == that->symbol. Either drop the equality check on accessing_klass, or don't bother to resolve the types. (And if you don't resolve the types, you don't really need the temporary ciSignature, since it's just a ordered pair check.) Or am I missing something? -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111011/c5cefe7f/attachment.html From christian.thalinger at oracle.com Wed Oct 12 01:53:09 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 12 Oct 2011 10:53:09 +0200 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets In-Reply-To: <20110903205445.C6C6F4735B@hg.openjdk.java.net> References: <20110903205445.C6C6F4735B@hg.openjdk.java.net> Message-ID: I just noticed we missed to print statements in MethodHandleCompiler::fetch_counts. I can remove them with my 7092712 changes which should also go into HS22. -- Chris On Sep 3, 2011, at 10:54 PM, tom.rodriguez at oracle.com wrote: > Changeset: c26de9aef2ed > Author: never > Date: 2011-09-02 20:58 -0700 > URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c26de9aef2ed > > 7071307: MethodHandle bimorphic inlining should consider the frequency > Reviewed-by: twisti, roland, kvn, iveresov > > ! src/cpu/sparc/vm/methodHandles_sparc.cpp > ! src/cpu/x86/vm/methodHandles_x86.cpp > ! src/share/vm/ci/ciCallProfile.hpp > ! src/share/vm/ci/ciMethodHandle.cpp > ! src/share/vm/ci/ciMethodHandle.hpp > ! src/share/vm/ci/ciObject.cpp > ! src/share/vm/classfile/javaClasses.cpp > ! src/share/vm/classfile/javaClasses.hpp > ! src/share/vm/classfile/systemDictionary.hpp > ! src/share/vm/classfile/vmSymbols.hpp > ! src/share/vm/oops/methodDataOop.hpp > ! src/share/vm/opto/bytecodeInfo.cpp > ! src/share/vm/opto/callGenerator.cpp > ! src/share/vm/opto/idealGraphPrinter.cpp > ! src/share/vm/opto/idealGraphPrinter.hpp > ! src/share/vm/opto/matcher.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 > > Changeset: 7ffacbb338d4 > Author: never > Date: 2011-09-03 09:56 -0700 > URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7ffacbb338d4 > > Merge > > From christian.thalinger at oracle.com Wed Oct 12 04:39:35 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 12 Oct 2011 13:39:35 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> <41F0F740-E973-4852-8979-F2100474E515@oracle.com> Message-ID: <2312D14E-907E-4261-8BD0-5E856AA4C389@oracle.com> On Oct 11, 2011, at 8:29 PM, John Rose wrote: > On Oct 11, 2011, at 8:13 AM, Christian Thalinger wrote: > >>>> I think you need to match the accessor argument in the matching loop of get_unloaded_method. >>>> >>>> Option 1. In the matching loop, after checking the symbolic signature, also check the resolved signature. You can do this by making a ciSignature (which resolves types relative to the accessor). Add an equals method to ciSignature. Consider adding equals(ciSymbol* sig, ciKlass* accessor), so that the second ciSignature does not need to be created. >>>> >>>> Option 2. Check the accessor argument against the signature._accessing_klass in the matching loop. To preserve existing behavior (for non-MH calls) either use null accessors for non-MH lookups and treat them specially (as wildcards) or else keep separate lists (of MH and non-MH unloaded methods). >>>> >>>> I think Option 1 is more precise, but Option 2 might be a more conservative change. >>> >>> Option 1 sounds like a clean way. But to compare the resolved signature we have to resolve the types anyway so maybe it's better to create the second ciSignature lazily when we need it. I updated the webrev. >> >> John, can you re-review the changes please? > > In the ciSignature::equals method, why bother to resolve types when you first prove equality of accessing_klass? > > The code in the webrev is (I think) equivalent to this->ac_kl == that->ac_kl && this->symbol == that->symbol. > > Either drop the equality check on accessing_klass, or don't bother to resolve the types. > > (And if you don't resolve the types, you don't really need the temporary ciSignature, since it's just a ordered pair check.) > > Or am I missing something? Type resolving happens in the ciSignature constructor. So when we are in equals everything is already resolved. But as we talked on IM yesterday we can short-circuit the ciSignature creation in ciObjectFactory::get_unloaded_method . I added some debug output to see how often the short-circuiting triggers and it triggers much more often than creating the ciSignature. I removed the accessing class check in ciSignature::equals (see the method comment) but added a short-cut bailout on a signature pointer-compare. Additionally I removed two debug output statements in src/share/vm/prims/methodHandleWalk.cpp that we missed. Webrev is updated: http://cr.openjdk.java.net/~twisti/7092712/ -- Chris > > -- John From tom.rodriguez at oracle.com Wed Oct 12 10:34:20 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 12 Oct 2011 10:34:20 -0700 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets In-Reply-To: References: <20110903205445.C6C6F4735B@hg.openjdk.java.net> Message-ID: <083A2900-AFCD-4904-BB20-20BB7A55A2EE@oracle.com> Darn. I'll file a new bug to remove it from hs23. I'll try to get that approved for hs22 instead of slipping it in. Thanks for noticing this. You pointed it out in the review but I forgot to remove it before I pushed. tom On Oct 12, 2011, at 1:53 AM, Christian Thalinger wrote: > I just noticed we missed to print statements in MethodHandleCompiler::fetch_counts. I can remove them with my 7092712 changes which should also go into HS22. > > -- Chris > > On Sep 3, 2011, at 10:54 PM, tom.rodriguez at oracle.com wrote: > >> Changeset: c26de9aef2ed >> Author: never >> Date: 2011-09-02 20:58 -0700 >> URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c26de9aef2ed >> >> 7071307: MethodHandle bimorphic inlining should consider the frequency >> Reviewed-by: twisti, roland, kvn, iveresov >> >> ! src/cpu/sparc/vm/methodHandles_sparc.cpp >> ! src/cpu/x86/vm/methodHandles_x86.cpp >> ! src/share/vm/ci/ciCallProfile.hpp >> ! src/share/vm/ci/ciMethodHandle.cpp >> ! src/share/vm/ci/ciMethodHandle.hpp >> ! src/share/vm/ci/ciObject.cpp >> ! src/share/vm/classfile/javaClasses.cpp >> ! src/share/vm/classfile/javaClasses.hpp >> ! src/share/vm/classfile/systemDictionary.hpp >> ! src/share/vm/classfile/vmSymbols.hpp >> ! src/share/vm/oops/methodDataOop.hpp >> ! src/share/vm/opto/bytecodeInfo.cpp >> ! src/share/vm/opto/callGenerator.cpp >> ! src/share/vm/opto/idealGraphPrinter.cpp >> ! src/share/vm/opto/idealGraphPrinter.hpp >> ! src/share/vm/opto/matcher.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 >> >> Changeset: 7ffacbb338d4 >> Author: never >> Date: 2011-09-03 09:56 -0700 >> URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7ffacbb338d4 >> >> Merge >> >> > From tom.rodriguez at oracle.com Wed Oct 12 10:42:55 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 12 Oct 2011 10:42:55 -0700 Subject: review for 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp Message-ID: <16CC9A5B-CEC9-4D10-B34C-C8EA46EEF8C0@oracle.com> http://cr.openjdk.java.net/~never/7100165 1 line changed: 0 ins; 1 del; 0 mod; 2090 unchg 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp Reviewed-by: Left over printing code that should have been deleted. From vladimir.kozlov at oracle.com Wed Oct 12 10:50:14 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Oct 2011 10:50:14 -0700 Subject: review for 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp In-Reply-To: <16CC9A5B-CEC9-4D10-B34C-C8EA46EEF8C0@oracle.com> References: <16CC9A5B-CEC9-4D10-B34C-C8EA46EEF8C0@oracle.com> Message-ID: <4E95D356.2000604@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7100165 > 1 line changed: 0 ins; 1 del; 0 mod; 2090 unchg > > 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp > Reviewed-by: > > Left over printing code that should have been deleted. > From john.r.rose at oracle.com Wed Oct 12 12:40:14 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 12 Oct 2011 12:40:14 -0700 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: <2312D14E-907E-4261-8BD0-5E856AA4C389@oracle.com> References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> <41F0F740-E973-4852-8979-F2100474E515@oracle.com> <2312D14E-907E-4261-8BD0-5E856AA4C389@oracle.com> Message-ID: <9B151D87-543A-4032-B9AF-7844AFEDC7F9@oracle.com> Ship it! -- John On Oct 12, 2011, at 4:39 AM, Christian Thalinger wrote: > Type resolving happens in the ciSignature constructor. So when we are in equals everything is already resolved. > > But as we talked on IM yesterday we can short-circuit the ciSignature creation in ciObjectFactory::get_unloaded_method > . I added some debug output to see how often the short-circuiting triggers and it triggers much more often than creating the ciSignature. > > I removed the accessing class check in ciSignature::equals (see the method comment) but added a short-cut bailout on a signature pointer-compare. > > Additionally I removed two debug output statements in src/share/vm/prims/methodHandleWalk.cpp that we missed. > > Webrev is updated: > > http://cr.openjdk.java.net/~twisti/7092712/ > > -- Chris From christian.thalinger at oracle.com Wed Oct 12 13:57:58 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 12 Oct 2011 22:57:58 +0200 Subject: review for 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp In-Reply-To: <16CC9A5B-CEC9-4D10-B34C-C8EA46EEF8C0@oracle.com> References: <16CC9A5B-CEC9-4D10-B34C-C8EA46EEF8C0@oracle.com> Message-ID: <254C2912-0F91-43CA-8044-0087FAF5840A@oracle.com> Looks good. -- Chris On Oct 12, 2011, at 7:42 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7100165 > 1 line changed: 0 ins; 1 del; 0 mod; 2090 unchg > > 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp > Reviewed-by: > > Left over printing code that should have been deleted. > From christian.thalinger at oracle.com Wed Oct 12 13:58:14 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 12 Oct 2011 22:58:14 +0200 Subject: Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP In-Reply-To: <9B151D87-543A-4032-B9AF-7844AFEDC7F9@oracle.com> References: <5C1FF7E7-4755-4EC2-8983-9B2085B89AA1@oracle.com> <09A81B48-BEF2-4CD1-943C-576EC4CFA694@oracle.com> <41F0F740-E973-4852-8979-F2100474E515@oracle.com> <2312D14E-907E-4261-8BD0-5E856AA4C389@oracle.com> <9B151D87-543A-4032-B9AF-7844AFEDC7F9@oracle.com> Message-ID: <903907C1-F7C4-4CC5-BCBF-F9C7CE5AC64D@oracle.com> Thank you, John. -- Chris On Oct 12, 2011, at 9:40 PM, John Rose wrote: > Ship it! -- John > > On Oct 12, 2011, at 4:39 AM, Christian Thalinger wrote: > >> Type resolving happens in the ciSignature constructor. So when we are in equals everything is already resolved. >> >> But as we talked on IM yesterday we can short-circuit the ciSignature creation in ciObjectFactory::get_unloaded_method >> . I added some debug output to see how often the short-circuiting triggers and it triggers much more often than creating the ciSignature. >> >> I removed the accessing class check in ciSignature::equals (see the method comment) but added a short-cut bailout on a signature pointer-compare. >> >> Additionally I removed two debug output statements in src/share/vm/prims/methodHandleWalk.cpp that we missed. >> >> Webrev is updated: >> >> http://cr.openjdk.java.net/~twisti/7092712/ >> >> -- Chris > From tom.rodriguez at oracle.com Wed Oct 12 14:01:07 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 12 Oct 2011 14:01:07 -0700 Subject: review for 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp In-Reply-To: <254C2912-0F91-43CA-8044-0087FAF5840A@oracle.com> References: <16CC9A5B-CEC9-4D10-B34C-C8EA46EEF8C0@oracle.com> <254C2912-0F91-43CA-8044-0087FAF5840A@oracle.com> Message-ID: Thanks Chris and Vladimir. tom On Oct 12, 2011, at 1:57 PM, Christian Thalinger wrote: > Looks good. -- Chris > > On Oct 12, 2011, at 7:42 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7100165 >> 1 line changed: 0 ins; 1 del; 0 mod; 2090 unchg >> >> 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp >> Reviewed-by: >> >> Left over printing code that should have been deleted. >> > From christian.thalinger at oracle.com Thu Oct 13 07:23:10 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 13 Oct 2011 14:23:10 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP Message-ID: <20111013142318.B13ED47FDD@hg.openjdk.java.net> Changeset: 5eb9169b1a14 Author: twisti Date: 2011-10-12 21:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5eb9169b1a14 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP Reviewed-by: jrose, never ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp From Ulf.Zibis at gmx.de Thu Oct 13 13:58:42 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 13 Oct 2011 22:58:42 +0200 Subject: Missing evaluation on bugs 6914095, 6914113, 6933327, 6935994 In-Reply-To: <4E9474AE.9050903@oracle.com> References: <4E9467F7.9070400@gmx.de> <4E9474AE.9050903@oracle.com> Message-ID: <4E975102.6050804@gmx.de> Am 11.10.2011 18:54, schrieb Vladimir Kozlov: > These bugs have evaluations in Comments section which unfortunately is not visible outside. I > moved my comments to Evaluation section and included them below. Much thanks, + for your fast answer! >> 6914095 - HotSpot should reuse >> invariant loop parameter >> >> > It would be nice if 32bit x86 had more registers. Unfortunately we have to reuse registers > otherwise we will get more spills on stack which will cause more performance regression then > keeping value in register. And x*c+c is very fast (few cycles) on modern cpus. > *** (#3 of 3): 2010-11-09 15:31:21 PST vladimir.kozlov at oracle.com Yes, this would hold, if x is held in register while looping. But in my code, even for the inner loop, x is spilled to stack, here: 0xc(%esp) So I still think, it would be better to alternatively spill x*c+c to the stack in the inner loop, and access x only in the outer loop. Or do I miss something? >> 6914113 - Copy int to byte[] in >> 1 step >> > Will not do this. C2 type system will not allow store int into byte array. Other platforms require > address alignment to 4 bytes for int store. Also on platforms with different endian the result > will be different. > *** (#2 of 2): 2010-08-25 14:51:13 PDT vladimir.kozlov at oracle.com In java.nio.Bits I see code like: static void putIntB(ByteBuffer bb, int bi, int x) { bb._put(bi + 0, int3(x)); bb._put(bi + 1, int2(x)); bb._put(bi + 2, int1(x)); bb._put(bi + 3, int0(x)); } AFAIK, this code becomes intrinsified to native "Copy int to byte[] in 1 step" by the VM. Correct me, if I'm wrong. What I want is, that if Hotspot detects such pattern (compiled in the bytecode), preferably in a loop, it would (1) use an aligned byte array, if necessary, and (2) then inline the existing intrinsification. Endianess should be no problem, as I already see different endian versions. >> 6933327 - Use shifted addressing >> modes instead of shift instuctions >> > Will not fix. Using addressing mode involves addess unit which may have negative effect if you > have memory access instructions near this code. > *** (#2 of 2): 2010-08-25 14:29:34 PDT vladimir.kozlov at oracle.com What is "memory access instructions _near this code_" ? >> 6935994 - Use as less bits as >> necessary >> > Should not do this since the other part of register will not be initialized to 0. > *** (#2 of 2): 2010-08-25 14:39:10 PDT vladimir.kozlov at oracle.com But what in case of java type byte only 8 bits come to usage? Much thanks, -Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111013/7e749af3/attachment.html From Ulf.Zibis at gmx.de Thu Oct 13 14:01:20 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 13 Oct 2011 23:01:20 +0200 Subject: Missing evaluation on bugs 6914095, 6914113, 6933327, 6935994 In-Reply-To: References: <4E9467F7.9070400@gmx.de> Message-ID: <4E9751A0.2040500@gmx.de> Am 11.10.2011 18:30, schrieb Vitaly Davidovich: > > On your last one, have you checked to see if it makes a difference? I believe using partial > registers requires a prefix on the op, making the instruction larger. Also there are some partial > register stalls that can be triggered. > How should I check this? I can't force Hotspot to compile like this to compare the effect. -Ulf > On Oct 11, 2011 12:00 PM, "Ulf Zibis" > wrote: > > Hi, > > some time ago I have submitted these bugs: > > 6914095 - HotSpot should reuse > invariant loop parameter > 6914113 - Copy int to byte[] in 1 > step > 6933327 - Use shifted addressing > modes instead of shift instuctions > 6935994 - Use as less bits as > necessary > > I do not see, why they have been closed as "Will Not Fix". > > Can someone add content to the 'evaluation' section, or at least explain reasons here? > > Much thanks, > > -Ulf > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111013/eb1766d5/attachment.html From vitalyd at gmail.com Thu Oct 13 14:15:59 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 13 Oct 2011 17:15:59 -0400 Subject: Missing evaluation on bugs 6914095, 6914113, 6933327, 6935994 In-Reply-To: <4E975102.6050804@gmx.de> References: <4E9467F7.9070400@gmx.de> <4E9474AE.9050903@oracle.com> <4E975102.6050804@gmx.de> Message-ID: Don't mean to speak on Vladimir's behalf but I think he's saying that if you have read/write to mem instructions close to this code then you can create a stall by occupying the memory unit of the CPU by using it to compute the address. As for trying this out, I was thinking you could write a small program in C/C++ with inline assembly that would compare your suggestion with current hotspot generated assembly. On Oct 13, 2011 4:58 PM, "Ulf Zibis" wrote: > Am 11.10.2011 18:54, schrieb Vladimir Kozlov: > > These bugs have evaluations in Comments section which unfortunately is not > visible outside. I moved my comments to Evaluation section and included them > below. > > Much thanks, + for your fast answer! > > 6914095 - >> HotSpot should reuse invariant loop parameter >> > > It would be nice if 32bit x86 had more registers. Unfortunately we have > to reuse registers otherwise we will get more spills on stack which will > cause more performance regression then keeping value in register. And x*c+c > is very fast (few cycles) on modern cpus. > *** (#3 of 3): 2010-11-09 15:31:21 PST vladimir.kozlov at oracle.com > > Yes, this would hold, if x is held in register while looping. > But in my code, even for the inner loop, x is spilled to stack, here: > 0xc(%esp) > So I still think, it would be better to alternatively spill x*c+c to the > stack in the inner loop, and access x only in the outer loop. > Or do I miss something? > > 6914113 - Copy >> int to byte[] in 1 step >> > Will not do this. C2 type system will not allow store int into byte > array. Other platforms require address alignment to 4 bytes for int store. > Also on platforms with different endian the result will be different. > *** (#2 of 2): 2010-08-25 14:51:13 PDT vladimir.kozlov at oracle.com > > In java.nio.Bits I see code like: > static void putIntB(ByteBuffer bb, int bi, int x) { > bb._put(bi + 0, int3(x)); > bb._put(bi + 1, int2(x)); > bb._put(bi + 2, int1(x)); > bb._put(bi + 3, int0(x)); > } > AFAIK, this code becomes intrinsified to native "Copy int to byte[] in 1 > step" by the VM. Correct me, if I'm wrong. > What I want is, that if Hotspot detects such pattern (compiled in the > bytecode), preferably in a loop, it would (1) use an aligned byte array, if > necessary, and (2) then inline the existing intrinsification. Endianess > should be no problem, as I already see different endian versions. > > 6933327 - Use >> shifted addressing modes instead of shift instuctions >> > Will not fix. Using addressing mode involves addess unit which may have > negative effect if you have memory access instructions near this code. > *** (#2 of 2): 2010-08-25 14:29:34 PDT vladimir.kozlov at oracle.com > > What is "memory access instructions _near this code_" ? > > 6935994 - Use >> as less bits as necessary >> > Should not do this since the other part of register will not be > initialized to 0. > *** (#2 of 2): 2010-08-25 14:39:10 PDT vladimir.kozlov at oracle.com > > But what in case of java type byte only 8 bits come to usage? > > > Much thanks, > > -Ulf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111013/345283d3/attachment-0001.html From vladimir.kozlov at oracle.com Thu Oct 13 16:24:04 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Oct 2011 16:24:04 -0700 Subject: Request for reviews (XS): 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Message-ID: <4E977314.20808@oracle.com> http://cr.openjdk.java.net/~kvn/7100757/webrev 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. Added regression test. Thanks, Vladimir From tom.rodriguez at oracle.com Thu Oct 13 17:10:26 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 13 Oct 2011 17:10:26 -0700 Subject: Request for reviews (XS): 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc In-Reply-To: <4E977314.20808@oracle.com> References: <4E977314.20808@oracle.com> Message-ID: <4DD74EE8-247B-44FA-9E2D-7C8EC8E8AA8C@oracle.com> Looks good. tom On Oct 13, 2011, at 4:24 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7100757/webrev > > 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc > > Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. > > Added regression test. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Oct 13 17:37:31 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Oct 2011 17:37:31 -0700 Subject: Request for reviews (XS): 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc In-Reply-To: <4DD74EE8-247B-44FA-9E2D-7C8EC8E8AA8C@oracle.com> References: <4E977314.20808@oracle.com> <4DD74EE8-247B-44FA-9E2D-7C8EC8E8AA8C@oracle.com> Message-ID: <4E97844B.5050805@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 13, 2011, at 4:24 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7100757/webrev >> >> 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc >> >> Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. >> >> Added regression test. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Thu Oct 13 21:25:54 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 14 Oct 2011 04:25:54 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp Message-ID: <20111014042603.4749447FEF@hg.openjdk.java.net> Changeset: a786fdc79c5f Author: never Date: 2011-10-13 14:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a786fdc79c5f 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp Reviewed-by: kvn, twisti ! src/share/vm/prims/methodHandleWalk.cpp From christian.thalinger at oracle.com Fri Oct 14 02:01:13 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 14 Oct 2011 11:01:13 +0200 Subject: Request for reviews (XS): 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc In-Reply-To: <4E977314.20808@oracle.com> References: <4E977314.20808@oracle.com> Message-ID: Looks good. Thanks for fixing this. -- Chris On Oct 14, 2011, at 1:24 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7100757/webrev > > 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc > > Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. > > Added regression test. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Oct 14 09:00:01 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Oct 2011 09:00:01 -0700 Subject: Request for reviews (XS): 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc In-Reply-To: References: <4E977314.20808@oracle.com> Message-ID: <4E985C81.4030202@oracle.com> Thank you, Christian Vladimir On 10/14/11 2:01 AM, Christian Thalinger wrote: > Looks good. Thanks for fixing this. -- Chris > > On Oct 14, 2011, at 1:24 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7100757/webrev >> >> 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc >> >> Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. >> >> Added regression test. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Fri Oct 14 20:46:53 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 15 Oct 2011 03:46:53 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Message-ID: <20111015034700.924A447007@hg.openjdk.java.net> Changeset: 4bac06a82bc3 Author: kvn Date: 2011-10-14 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4bac06a82bc3 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Summary: Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/7100757/Test7100757.java From igor.veresov at oracle.com Sun Oct 16 10:08:10 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sun, 16 Oct 2011 17:08:10 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 32 new changesets Message-ID: <20111016170914.52D5C47015@hg.openjdk.java.net> Changeset: 3f0cf875af83 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3f0cf875af83 Added tag jdk8-b06 for changeset 0db80d8e77fc ! .hgtags Changeset: 0663e7617095 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0663e7617095 Added tag jdk8-b07 for changeset 3f0cf875af83 ! .hgtags Changeset: da883b9e6d37 Author: jcoomes Date: 2011-09-30 18:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/da883b9e6d37 Merge ! .hgtags - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 49ed7eacfd16 Author: jcoomes Date: 2011-09-30 18:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/49ed7eacfd16 Added tag hs23-b01 for changeset da883b9e6d37 ! .hgtags Changeset: 95607b70acb5 Author: jcoomes Date: 2011-09-30 22:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/95607b70acb5 7096124: Bump the hs23 build number to 02 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 4f93f0d00802 Author: tonyp Date: 2011-09-20 09:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4f93f0d00802 7059019: G1: add G1 support to the SA Summary: Extend the SA to recognize the G1CollectedHeap and implement any code that's needed by our serviceability tools (jmap, jinfo, jstack, etc.) that depend on the SA. Reviewed-by: never, poonam, johnc ! agent/make/Makefile + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegion.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeapName.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! make/sa.files ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 663cb89032b1 Author: johnc Date: 2011-09-20 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/663cb89032b1 7092412: G1: Some roots not marked during an initial mark that gets an evacuation failure Summary: As a result of the changes for 7080389, an evacuation failure during an initial mark pause may result in some root objects not being marked. Pass whether the caller is a root scanning closure into the evacuation failure handling code so that the thread that successfully forwards an object to itself also marks the object. Reviewed-by: ysr, brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp Changeset: 114e52976463 Author: tonyp Date: 2011-09-21 01:27 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/114e52976463 7045232: G1: pool names are inconsistent with other collectors (don't have 'Space') Summary: Make sure the eden and survivor pools have "Space" in their name. Reviewed-by: jmasa, ysr ! src/share/vm/services/g1MemoryPool.cpp Changeset: 1847b501ae74 Author: johnc Date: 2011-09-21 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1847b501ae74 7068215: G1: Print reference processing time during remark Summary: Displays the elapsed time taken to perform reference processing during remark as part of the PrintGCDetails output. Reviewed-by: ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: d912b598c6c3 Author: tonyp Date: 2011-09-21 13:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d912b598c6c3 7091032: G1: assert failure when NewRatio is used Summary: The desired min / max heap sizes are miscalculated at initialization when NewRatio is used. The changeset also includes an additional small change to turn a print statement into a warning. Reviewed-by: johnc, jmasa, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 5cc33133bc6d Author: johnc Date: 2011-09-21 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5cc33133bc6d 7092245: G1: Wrong format specifier in G1PrintRegionLivenessInfo header output Summary: Cast HeapRegion::GrainBytes to size_t in output statement. Reviewed-by: ysr, brutisso, pbk, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: f0ecbe78fc7b Author: tonyp Date: 2011-09-22 07:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f0ecbe78fc7b 7092238: G1: Uninitialized field gc_efficiency in G1PrintRegionLivenessInfo output Reviewed-by: jcoomes, johnc ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 4dfb2df418f2 Author: johnc Date: 2011-09-22 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4dfb2df418f2 6484982: G1: process references during evacuation pauses Summary: G1 now uses two reference processors - one is used by concurrent marking and the other is used by STW GCs (both full and incremental evacuation pauses). In an evacuation pause, the reference processor is embedded into the closures used to scan objects. Doing so causes causes reference objects to be 'discovered' by the reference processor. At the end of the evacuation pause, these discovered reference objects are processed - preserving (and copying) referent objects (and their reachable graphs) as appropriate. Reviewed-by: ysr, jwilhelm, brutisso, stefank, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/thread.cpp Changeset: 8229bd737950 Author: tonyp Date: 2011-09-23 16:07 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8229bd737950 7075646: G1: fix inconsistencies in the monitoring data Summary: Fixed a few inconsistencies in the monitoring data, in particular when reported from jstat. Reviewed-by: jmasa, brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: e807478bf9ca Author: brutisso Date: 2011-09-26 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e807478bf9ca 7091366: re-enable quicksort tests Summary: Added extern "C" to make it build with JDK6 compilers Reviewed-by: jwilhelm, kvn ! src/share/vm/utilities/quickSort.cpp Changeset: 273b46400613 Author: johnc Date: 2011-09-28 10:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/273b46400613 7086533: G1: assert(!_g1->is_obj_dead(obj)): We should not be preserving dead objs: g1CollectedHeap.cpp:3835 Summary: Some objects may not be marked in the event of an evacuation failure in a partially young GC, during a marking cycle. Avoid this situation by not allowing partially young GCs during a marking cycle. Reviewed-by: tonyp, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 811ec3d0833b Author: johnc Date: 2011-10-03 12:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/811ec3d0833b 7097053: G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 Summary: During remembered set scanning, the reference processor could discover a reference object whose referent was in the process of being copied and so may not be completely initialized. Do not perform reference discovery during remembered set scanning. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 81aa07130d30 Author: tonyp Date: 2011-10-03 19:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/81aa07130d30 7097048: G1: extend the G1 SA changes to print per-heap space information Reviewed-by: brutisso, johnc ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: c63b928b212b Author: stefank Date: 2011-09-12 16:09 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c63b928b212b 7021322: assert(object_end <= top()) failed: Object crosses promotion LAB boundary Summary: Pass the same object size value to both allocate and unallocate_object Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp Changeset: 65a8ff39a6da Author: johnc Date: 2011-10-05 08:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/65a8ff39a6da 7095194: G1: HeapRegion::GrainBytes, GrainWords, and CardsPerRegion should be size_t Summary: Declare GrainBytes, GrainWords, and CardsPerRegion as size_t. Reviewed-by: jcoomes, tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: fd65bc7c09b6 Author: tonyp Date: 2011-10-06 13:28 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fd65bc7c09b6 Merge ! agent/make/Makefile ! make/sa.files ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 246daf2c601d Author: brutisso Date: 2011-09-28 08:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/246daf2c601d 7005808: G1: re-enable ReduceInitialCardMarks for G1 Summary: Remove the extra guard to allow G1 to use ReduceInitialCardMarks Reviewed-by: jmasa, tonyp, johnc, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: b9390528617c Author: ysr Date: 2011-10-06 18:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b9390528617c 7095236: G1: _markedRegions never contains NULL regions Summary: Removed the code for skipping over NULL regions in _markedRegions, replacing it with an assertion that a NULL region is never encountered; removed dead methods, remove() and remove_region(), and inlined a simplified addRegion() directly into fillCache(). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp Changeset: f32dae5d5677 Author: ysr Date: 2011-10-10 08:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f32dae5d5677 Merge Changeset: 3f24f946bc2d Author: brutisso Date: 2011-10-11 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3f24f946bc2d 7099454: /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script Summary: Also reviewed by mikael.gerdin at oracle.com; Changed to the `` syntax instead. Also changed "source" to ".". Reviewed-by: never, stefank, dsamersoff, rottenha ! src/os/posix/launcher/launcher.script Changeset: d1bdeef3e3e2 Author: johnc Date: 2011-10-12 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1bdeef3e3e2 7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76 Summary: There is a race between one thread successfully forwarding and copying the klass mirror for the SoftReference class (including the static master clock) and another thread attempting to use the master clock while attempting to discover a soft reference object. Maintain a shadow copy of the soft reference master clock and use the shadow during reference discovery and reference processing. Reviewed-by: tonyp, brutisso, ysr ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 7c20d272643f Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7c20d272643f Added tag jdk8-b08 for changeset 49ed7eacfd16 ! .hgtags Changeset: edd5f85e2de7 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/edd5f85e2de7 Added tag jdk8-b09 for changeset 7c20d272643f ! .hgtags Changeset: e4f412d2b75d Author: jcoomes Date: 2011-10-14 18:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e4f412d2b75d Merge ! .hgtags Changeset: d815de2e85e5 Author: jcoomes Date: 2011-10-14 18:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d815de2e85e5 Added tag hs23-b02 for changeset e4f412d2b75d ! .hgtags Changeset: bc257a801090 Author: jcoomes Date: 2011-10-14 21:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bc257a801090 7101096: Bump the hs23 build number to 03 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 11d17c7d2ee6 Author: iveresov Date: 2011-10-16 02:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/11d17c7d2ee6 Merge From jobrien at performanceguy.com Mon Oct 17 09:14:25 2011 From: jobrien at performanceguy.com (John O'Brien) Date: Mon, 17 Oct 2011 09:14:25 -0700 Subject: Stability of UseCodeCacheFlushing option Message-ID: Hi All, Is the useCodeCacheFlushing option working well. I read the thread below and wonder if there are remaining issues? How bad are they? Do I just need to go ahead and try it out? Is the best option to size a very large codeCache? Regards, John Tom Rodriguez tom.rodriguez at oracle.com Thu Mar 3 12:14:32 PST 2011 Previous message: inspecting the code cache Next message: Request for review(M): 7020403: Add AdvancedCompilationPolicy for tiered Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] ________________________________ >>> Thanks for that information. I've been using PrintCompilation to >> watch what was going on. I've gotten a question from a client that >> claims that a method had seemingly been squeezed out of the cache. I'm >> not sure what would cause a method to be squeezed out but I guess it >> would have to be made not entrant before hand. But that got me >> interested in poking about to see what information one could squeeze >> out of the JVM wrt the code cache. >> >> Code will never get "squeezed" out in the current system. We generate >> code as needed and only get rid of it when it gets invalidated or if it >> references classes which get unloaded. If the code cache fills up you >> might not be able to compile something that needs code though. >> >> tom >> >> >>> >>> TIA, >>> Kirk >>> > > Does -XX:+UseCodeCacheFlushing enable this clearing of invalidated code? > Or does that do something different? No that's something different. The clearing of the code is done by something called the sweeper and you can't disable it. UseCodeCacheFlushing implements an LRU-ish policy for keeping the code cache from filling up. It's currently not enabled by default because we've seen some hard to track down problems when using it with very long running programs. They may not actually be the fault of the flushing itself but the extra pressure it puts on the concurrent sweeping that actually reclaims them. It should become the default once we track down the sweeping issue. tom > > > Thanks, > > David > > > From tom.rodriguez at oracle.com Mon Oct 17 11:02:15 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 17 Oct 2011 11:02:15 -0700 Subject: Stability of UseCodeCacheFlushing option In-Reply-To: References: Message-ID: There are no known issues. We're going to be turning it on by default in hs23, so if you're interested in trying it out we'd love to know how it works for you. tom On Oct 17, 2011, at 9:14 AM, John O'Brien wrote: > Hi All, > > Is the useCodeCacheFlushing option working well. I read the thread > below and wonder if there are remaining issues? > How bad are they? Do I just need to go ahead and try it out? > > Is the best option to size a very large codeCache? > > Regards, > John > > > > > Tom Rodriguez tom.rodriguez at oracle.com > Thu Mar 3 12:14:32 PST 2011 > > Previous message: inspecting the code cache > Next message: Request for review(M): 7020403: Add > AdvancedCompilationPolicy for tiered > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > ________________________________ > >>>> Thanks for that information. I've been using PrintCompilation to >>> watch what was going on. I've gotten a question from a client that >>> claims that a method had seemingly been squeezed out of the cache. I'm >>> not sure what would cause a method to be squeezed out but I guess it >>> would have to be made not entrant before hand. But that got me >>> interested in poking about to see what information one could squeeze >>> out of the JVM wrt the code cache. >>> >>> Code will never get "squeezed" out in the current system. We generate >>> code as needed and only get rid of it when it gets invalidated or if it >>> references classes which get unloaded. If the code cache fills up you >>> might not be able to compile something that needs code though. >>> >>> tom >>> >>> >>>> >>>> TIA, >>>> Kirk >>>> >> >> Does -XX:+UseCodeCacheFlushing enable this clearing of invalidated code? >> Or does that do something different? > > No that's something different. The clearing of the code is done by > something called the sweeper and you can't disable it. > UseCodeCacheFlushing implements an LRU-ish policy for keeping the code > cache from filling up. It's currently not enabled by default because > we've seen some hard to track down problems when using it with very > long running programs. They may not actually be the fault of the > flushing itself but the extra pressure it puts on the concurrent > sweeping that actually reclaims them. It should become the default > once we track down the sweeping issue. > > tom > >> >> >> Thanks, >> >> David >> >> >> From jobrien at performanceguy.com Mon Oct 17 12:32:06 2011 From: jobrien at performanceguy.com (John O'Brien) Date: Mon, 17 Oct 2011 12:32:06 -0700 Subject: Stability of UseCodeCacheFlushing option In-Reply-To: References: Message-ID: Excellent, will get back to my team and let you know. afaik we plan to use it very soon. On Mon, Oct 17, 2011 at 11:02 AM, Tom Rodriguez wrote: > There are no known issues. ?We're going to be turning it on by default in hs23, so if you're interested in trying it out we'd love to know how it works for you. > > tom > > On Oct 17, 2011, at 9:14 AM, John O'Brien wrote: > >> Hi All, >> >> Is the useCodeCacheFlushing option working well. I read the thread >> below and wonder if there are remaining issues? >> How bad are they? Do I just need to go ahead and try it out? >> >> Is the best option to size a very large codeCache? >> >> Regards, >> John >> >> >> >> >> Tom Rodriguez tom.rodriguez at oracle.com >> Thu Mar 3 12:14:32 PST 2011 >> >> Previous message: inspecting the code cache >> Next message: Request for review(M): 7020403: Add >> AdvancedCompilationPolicy for tiered >> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] >> >> ________________________________ >> >>>>> Thanks for that information. I've been using PrintCompilation to >>>> watch what was going on. I've gotten a question from a client that >>>> claims that a method had seemingly been squeezed out of the cache. I'm >>>> not sure what would cause a method to be squeezed out but I guess it >>>> would have to be made not entrant before hand. But that got me >>>> interested in poking about to see what information one could squeeze >>>> out of the JVM wrt the code cache. >>>> >>>> Code will never get "squeezed" out in the current system. ?We generate >>>> code as needed and only get rid of it when it gets invalidated or if it >>>> references classes which get unloaded. ?If the code cache fills up you >>>> might not be able to compile something that needs code though. >>>> >>>> tom >>>> >>>> >>>>> >>>>> TIA, >>>>> Kirk >>>>> >>> >>> Does -XX:+UseCodeCacheFlushing enable this clearing of invalidated code? >>> Or does that do something different? >> >> No that's something different. ?The clearing of the code is done by >> something called the sweeper and you can't disable it. >> UseCodeCacheFlushing implements an LRU-ish policy for keeping the code >> cache from filling up. ?It's currently not enabled by default because >> we've seen some hard to track down problems when using it with very >> long running programs. ?They may not actually be the fault of the >> flushing itself but the extra pressure it puts on the concurrent >> sweeping that actually reclaims them. ?It should become the default >> once we track down the sweeping issue. >> >> tom >> >>> >>> >>> Thanks, >>> >>> David >>> >>> >>> > > From tom.rodriguez at oracle.com Mon Oct 17 17:24:30 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 18 Oct 2011 00:24:30 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was Message-ID: <20111018002435.2956F47034@hg.openjdk.java.net> Changeset: 8187c94a9a87 Author: never Date: 2011-10-17 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8187c94a9a87 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java From tom.rodriguez at oracle.com Tue Oct 18 00:36:14 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 18 Oct 2011 07:36:14 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7098528: crash with java -XX:+ExtendedDTraceProbes Message-ID: <20111018073618.11E7147038@hg.openjdk.java.net> Changeset: e5928e7dab26 Author: never Date: 2011-10-17 21:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e5928e7dab26 7098528: crash with java -XX:+ExtendedDTraceProbes Reviewed-by: kvn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp From christian.thalinger at oracle.com Tue Oct 18 01:51:34 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Oct 2011 10:51:34 +0200 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop Message-ID: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> http://cr.openjdk.java.net/~twisti/7090904/ 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop Reviewed-by: A couple of JRuby junit tests crash in various forms (mostly GC related) when running on 64-bit Linux. Although it looks like a GC related problem it actually is a deoptimization bug. Tom already had a fix ready but we were unable to write a test case to prove the correctness of the fix. An assert added in AbstractInterpreter::layout_activation shows that the JRuby crashes are indeed an incarnation of this deoptimization bug. The bug itself is in the deoptimization logic that calculates the size of parameter space in the caller frame. Method handle invokes may involve fairly arbitrary chains of calls so it's impossible to know how much actual space the caller has for locals. The fix is to always assume zero parameters for method handle call sites. Extensive testing with JRuby junit tests. src/share/vm/runtime/deoptimization.cpp src/cpu/x86/vm/templateInterpreter_x86_32.cpp src/cpu/x86/vm/templateInterpreter_x86_64.cpp src/share/vm/interpreter/bytecodeTracer.cpp src/share/vm/runtime/frame.cpp src/share/vm/runtime/frame.hpp src/share/vm/runtime/thread.cpp From vladimir.kozlov at oracle.com Tue Oct 18 11:25:46 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Oct 2011 11:25:46 -0700 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> Message-ID: <4E9DC4AA.1090600@oracle.com> Christian, In deoptimization.cpp add parenthesis: ! if (index == array->frames() - 1 && caller_was_method_handle) { --- ! if ((index == array->frames() - 1) && caller_was_method_handle) { I think you need move the check inside assert: + if (caller->is_interpreted_frame()) { + assert(locals < caller->fp() + frame::interpreter_frame_initial_sp_offset, "bad placement"); + } --- + assert(!caller->is_interpreted_frame() || + (locals < caller->fp() + frame::interpreter_frame_initial_sp_offset), "bad placement"); Why assert was not added to sparc? You did not explain changes in bytecodeTracer.cpp and in frame.cpp (frame::describe()). They seems unrelated to this fix. Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7090904/ > > 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop > Reviewed-by: > > A couple of JRuby junit tests crash in various forms (mostly GC > related) when running on 64-bit Linux. Although it looks like a GC > related problem it actually is a deoptimization bug. > > Tom already had a fix ready but we were unable to write a test case to > prove the correctness of the fix. An assert added in > AbstractInterpreter::layout_activation shows that the JRuby crashes > are indeed an incarnation of this deoptimization bug. > > The bug itself is in the deoptimization logic that calculates the size > of parameter space in the caller frame. Method handle invokes may > involve fairly arbitrary chains of calls so it's impossible to know > how much actual space the caller has for locals. > > The fix is to always assume zero parameters for method handle call > sites. > > Extensive testing with JRuby junit tests. > > src/share/vm/runtime/deoptimization.cpp > src/cpu/x86/vm/templateInterpreter_x86_32.cpp > src/cpu/x86/vm/templateInterpreter_x86_64.cpp > src/share/vm/interpreter/bytecodeTracer.cpp > src/share/vm/runtime/frame.cpp > src/share/vm/runtime/frame.hpp > src/share/vm/runtime/thread.cpp > From tom.rodriguez at oracle.com Tue Oct 18 12:02:26 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 Oct 2011 12:02:26 -0700 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: <4E9DC4AA.1090600@oracle.com> References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> <4E9DC4AA.1090600@oracle.com> Message-ID: <4B9788DF-399F-499C-800A-FC1A969FAAAD@oracle.com> On Oct 18, 2011, at 11:25 AM, Vladimir Kozlov wrote: > Christian, > > In deoptimization.cpp add parenthesis: > > ! if (index == array->frames() - 1 && caller_was_method_handle) { > --- > ! if ((index == array->frames() - 1) && caller_was_method_handle) { > > > I think you need move the check inside assert: > > + if (caller->is_interpreted_frame()) { > + assert(locals < caller->fp() + frame::interpreter_frame_initial_sp_offset, "bad placement"); > + } > --- > + assert(!caller->is_interpreted_frame() || > + (locals < caller->fp() + frame::interpreter_frame_initial_sp_offset), "bad placement"); > > > Why assert was not added to sparc? I believe sparc already has equivalent assertions. Christian, did you try the jruby tests on sparc looking for similar issues? Are we able to run +DeoptimizeALot now or at there still more issues? > > You did not explain changes in bytecodeTracer.cpp and in frame.cpp (frame::describe()). They seems unrelated to this fix. They were changes I made while diagnosing the problem I was seeing. The frame.cpp are about allowing describe be called on a different thread and not producing garbage fp values for compiled frames. The bytecodeTracer.cpp fixes printing of invokedynamic bytecodes. Previously it would always complain about the index being wrong but now it actually prints it like an invoke call site. tom > > Thanks, > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7090904/ >> 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop >> Reviewed-by: >> A couple of JRuby junit tests crash in various forms (mostly GC >> related) when running on 64-bit Linux. Although it looks like a GC >> related problem it actually is a deoptimization bug. >> Tom already had a fix ready but we were unable to write a test case to >> prove the correctness of the fix. An assert added in >> AbstractInterpreter::layout_activation shows that the JRuby crashes >> are indeed an incarnation of this deoptimization bug. >> The bug itself is in the deoptimization logic that calculates the size >> of parameter space in the caller frame. Method handle invokes may >> involve fairly arbitrary chains of calls so it's impossible to know >> how much actual space the caller has for locals. >> The fix is to always assume zero parameters for method handle call >> sites. >> Extensive testing with JRuby junit tests. >> src/share/vm/runtime/deoptimization.cpp >> src/cpu/x86/vm/templateInterpreter_x86_32.cpp >> src/cpu/x86/vm/templateInterpreter_x86_64.cpp >> src/share/vm/interpreter/bytecodeTracer.cpp >> src/share/vm/runtime/frame.cpp >> src/share/vm/runtime/frame.hpp >> src/share/vm/runtime/thread.cpp From tom.rodriguez at oracle.com Tue Oct 18 12:02:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 Oct 2011 12:02:32 -0700 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> Message-ID: On Oct 18, 2011, at 1:51 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7090904/ > > 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop > Reviewed-by: > > A couple of JRuby junit tests crash in various forms (mostly GC > related) when running on 64-bit Linux. Although it looks like a GC > related problem it actually is a deoptimization bug. > > Tom already had a fix ready but we were unable to write a test case to > prove the correctness of the fix. An assert added in > AbstractInterpreter::layout_activation shows that the JRuby crashes > are indeed an incarnation of this deoptimization bug. > > The bug itself is in the deoptimization logic that calculates the size > of parameter space in the caller frame. Method handle invokes may > involve fairly arbitrary chains of calls so it's impossible to know > how much actual space the caller has for locals. I think we need to check for MethodHandle.invoke in addition to invokeExact. tom > > The fix is to always assume zero parameters for method handle call > sites. > > Extensive testing with JRuby junit tests. > > src/share/vm/runtime/deoptimization.cpp > src/cpu/x86/vm/templateInterpreter_x86_32.cpp > src/cpu/x86/vm/templateInterpreter_x86_64.cpp > src/share/vm/interpreter/bytecodeTracer.cpp > src/share/vm/runtime/frame.cpp > src/share/vm/runtime/frame.hpp > src/share/vm/runtime/thread.cpp > From vladimir.kozlov at oracle.com Tue Oct 18 12:09:08 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Oct 2011 12:09:08 -0700 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: <4B9788DF-399F-499C-800A-FC1A969FAAAD@oracle.com> References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> <4E9DC4AA.1090600@oracle.com> <4B9788DF-399F-499C-800A-FC1A969FAAAD@oracle.com> Message-ID: <4E9DCED4.6000909@oracle.com> Thank you, Tom, for explaining changes in those files. They look good. Vladimir Tom Rodriguez wrote: > On Oct 18, 2011, at 11:25 AM, Vladimir Kozlov wrote: > >> Christian, >> >> In deoptimization.cpp add parenthesis: >> >> ! if (index == array->frames() - 1 && caller_was_method_handle) { >> --- >> ! if ((index == array->frames() - 1) && caller_was_method_handle) { >> >> >> I think you need move the check inside assert: >> >> + if (caller->is_interpreted_frame()) { >> + assert(locals < caller->fp() + frame::interpreter_frame_initial_sp_offset, "bad placement"); >> + } >> --- >> + assert(!caller->is_interpreted_frame() || >> + (locals < caller->fp() + frame::interpreter_frame_initial_sp_offset), "bad placement"); >> >> >> Why assert was not added to sparc? > > I believe sparc already has equivalent assertions. Christian, did you try the jruby tests on sparc looking for similar issues? Are we able to run +DeoptimizeALot now or at there still more issues? > >> You did not explain changes in bytecodeTracer.cpp and in frame.cpp (frame::describe()). They seems unrelated to this fix. > > They were changes I made while diagnosing the problem I was seeing. The frame.cpp are about allowing describe be called on a different thread and not producing garbage fp values for compiled frames. The bytecodeTracer.cpp fixes printing of invokedynamic bytecodes. Previously it would always complain about the index being wrong but now it actually prints it like an invoke call site. > > tom > >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7090904/ >>> 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop >>> Reviewed-by: >>> A couple of JRuby junit tests crash in various forms (mostly GC >>> related) when running on 64-bit Linux. Although it looks like a GC >>> related problem it actually is a deoptimization bug. >>> Tom already had a fix ready but we were unable to write a test case to >>> prove the correctness of the fix. An assert added in >>> AbstractInterpreter::layout_activation shows that the JRuby crashes >>> are indeed an incarnation of this deoptimization bug. >>> The bug itself is in the deoptimization logic that calculates the size >>> of parameter space in the caller frame. Method handle invokes may >>> involve fairly arbitrary chains of calls so it's impossible to know >>> how much actual space the caller has for locals. >>> The fix is to always assume zero parameters for method handle call >>> sites. >>> Extensive testing with JRuby junit tests. >>> src/share/vm/runtime/deoptimization.cpp >>> src/cpu/x86/vm/templateInterpreter_x86_32.cpp >>> src/cpu/x86/vm/templateInterpreter_x86_64.cpp >>> src/share/vm/interpreter/bytecodeTracer.cpp >>> src/share/vm/runtime/frame.cpp >>> src/share/vm/runtime/frame.hpp >>> src/share/vm/runtime/thread.cpp > From john.r.rose at oracle.com Tue Oct 18 12:44:21 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 18 Oct 2011 12:44:21 -0700 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> Message-ID: On Oct 18, 2011, at 12:02 PM, Tom Rodriguez wrote: > I think we need to check for MethodHandle.invoke in addition to invokeExact. Yes, and use methodOopDesc::is_method_handle_invoke_name. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111018/1342433b/attachment.html From tom.rodriguez at oracle.com Tue Oct 18 12:48:13 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 Oct 2011 12:48:13 -0700 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> Message-ID: On Oct 18, 2011, at 12:44 PM, John Rose wrote: > On Oct 18, 2011, at 12:02 PM, Tom Rodriguez wrote: > >> I think we need to check for MethodHandle.invoke in addition to invokeExact. > > Yes, and use methodOopDesc::is_method_handle_invoke_name. Even better. tom > > -- John From christian.thalinger at oracle.com Tue Oct 18 13:08:29 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Oct 2011 22:08:29 +0200 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: <4B9788DF-399F-499C-800A-FC1A969FAAAD@oracle.com> References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> <4E9DC4AA.1090600@oracle.com> <4B9788DF-399F-499C-800A-FC1A969FAAAD@oracle.com> Message-ID: <5A90EB36-4CBF-46E4-80CA-00830E9BFDE7@oracle.com> On Oct 18, 2011, at 9:02 PM, Tom Rodriguez wrote: > > On Oct 18, 2011, at 11:25 AM, Vladimir Kozlov wrote: > >> Christian, >> >> In deoptimization.cpp add parenthesis: >> >> ! if (index == array->frames() - 1 && caller_was_method_handle) { >> --- >> ! if ((index == array->frames() - 1) && caller_was_method_handle) { >> >> >> I think you need move the check inside assert: >> >> + if (caller->is_interpreted_frame()) { >> + assert(locals < caller->fp() + frame::interpreter_frame_initial_sp_offset, "bad placement"); >> + } >> --- >> + assert(!caller->is_interpreted_frame() || >> + (locals < caller->fp() + frame::interpreter_frame_initial_sp_offset), "bad placement"); >> >> >> Why assert was not added to sparc? > > I believe sparc already has equivalent assertions. Christian, did you try the jruby tests on sparc looking for similar issues? Are we able to run +DeoptimizeALot now or at there still more issues? It's not so easy to run the tests on Solaris (because a couple/a lot of them fail because of file system operations). I think SPARc is good but I will check that again tomorrow. DeoptimizeALot now works. There is one bug left with test_respond_to which seems to be a different bug (7094138). -- Chris > >> >> You did not explain changes in bytecodeTracer.cpp and in frame.cpp (frame::describe()). They seems unrelated to this fix. > > They were changes I made while diagnosing the problem I was seeing. The frame.cpp are about allowing describe be called on a different thread and not producing garbage fp values for compiled frames. The bytecodeTracer.cpp fixes printing of invokedynamic bytecodes. Previously it would always complain about the index being wrong but now it actually prints it like an invoke call site. > > tom > >> >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7090904/ >>> 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop >>> Reviewed-by: >>> A couple of JRuby junit tests crash in various forms (mostly GC >>> related) when running on 64-bit Linux. Although it looks like a GC >>> related problem it actually is a deoptimization bug. >>> Tom already had a fix ready but we were unable to write a test case to >>> prove the correctness of the fix. An assert added in >>> AbstractInterpreter::layout_activation shows that the JRuby crashes >>> are indeed an incarnation of this deoptimization bug. >>> The bug itself is in the deoptimization logic that calculates the size >>> of parameter space in the caller frame. Method handle invokes may >>> involve fairly arbitrary chains of calls so it's impossible to know >>> how much actual space the caller has for locals. >>> The fix is to always assume zero parameters for method handle call >>> sites. >>> Extensive testing with JRuby junit tests. >>> src/share/vm/runtime/deoptimization.cpp >>> src/cpu/x86/vm/templateInterpreter_x86_32.cpp >>> src/cpu/x86/vm/templateInterpreter_x86_64.cpp >>> src/share/vm/interpreter/bytecodeTracer.cpp >>> src/share/vm/runtime/frame.cpp >>> src/share/vm/runtime/frame.hpp >>> src/share/vm/runtime/thread.cpp > From christian.thalinger at oracle.com Tue Oct 18 13:08:54 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Oct 2011 22:08:54 +0200 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> Message-ID: <980DF307-9D47-4DEE-B94A-F639081E6136@oracle.com> On Oct 18, 2011, at 9:48 PM, Tom Rodriguez wrote: > > On Oct 18, 2011, at 12:44 PM, John Rose wrote: > >> On Oct 18, 2011, at 12:02 PM, Tom Rodriguez wrote: >> >>> I think we need to check for MethodHandle.invoke in addition to invokeExact. >> >> Yes, and use methodOopDesc::is_method_handle_invoke_name. > > Even better. Right, I will change that. -- Chris > > tom > >> >> -- John > From christian.thalinger at oracle.com Tue Oct 18 13:12:29 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Oct 2011 22:12:29 +0200 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: <4E9DC4AA.1090600@oracle.com> References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> <4E9DC4AA.1090600@oracle.com> Message-ID: <6E633723-F9A5-47AF-83EC-504802BDD323@oracle.com> On Oct 18, 2011, at 8:25 PM, Vladimir Kozlov wrote: > Christian, > > In deoptimization.cpp add parenthesis: > > ! if (index == array->frames() - 1 && caller_was_method_handle) { > --- > ! if ((index == array->frames() - 1) && caller_was_method_handle) { OK. > > > I think you need move the check inside assert: > > + if (caller->is_interpreted_frame()) { > + assert(locals < caller->fp() + frame::interpreter_frame_initial_sp_offset, "bad placement"); > + } > --- > + assert(!caller->is_interpreted_frame() || > + (locals < caller->fp() + frame::interpreter_frame_initial_sp_offset), "bad placement"); Why do you think that? I very easy to read with the if. -- Chris > > > Why assert was not added to sparc? > > You did not explain changes in bytecodeTracer.cpp and in frame.cpp (frame::describe()). They seems unrelated to this fix. > > Thanks, > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7090904/ >> 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop >> Reviewed-by: >> A couple of JRuby junit tests crash in various forms (mostly GC >> related) when running on 64-bit Linux. Although it looks like a GC >> related problem it actually is a deoptimization bug. >> Tom already had a fix ready but we were unable to write a test case to >> prove the correctness of the fix. An assert added in >> AbstractInterpreter::layout_activation shows that the JRuby crashes >> are indeed an incarnation of this deoptimization bug. >> The bug itself is in the deoptimization logic that calculates the size >> of parameter space in the caller frame. Method handle invokes may >> involve fairly arbitrary chains of calls so it's impossible to know >> how much actual space the caller has for locals. >> The fix is to always assume zero parameters for method handle call >> sites. >> Extensive testing with JRuby junit tests. >> src/share/vm/runtime/deoptimization.cpp >> src/cpu/x86/vm/templateInterpreter_x86_32.cpp >> src/cpu/x86/vm/templateInterpreter_x86_64.cpp >> src/share/vm/interpreter/bytecodeTracer.cpp >> src/share/vm/runtime/frame.cpp >> src/share/vm/runtime/frame.hpp >> src/share/vm/runtime/thread.cpp From vladimir.kozlov at oracle.com Tue Oct 18 14:16:17 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Oct 2011 14:16:17 -0700 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: <6E633723-F9A5-47AF-83EC-504802BDD323@oracle.com> References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> <4E9DC4AA.1090600@oracle.com> <6E633723-F9A5-47AF-83EC-504802BDD323@oracle.com> Message-ID: <4E9DECA1.5000000@oracle.com> Christian Thalinger wrote: >> I think you need move the check inside assert: >> >> + if (caller->is_interpreted_frame()) { >> + assert(locals < caller->fp() + frame::interpreter_frame_initial_sp_offset, "bad placement"); >> + } >> --- >> + assert(!caller->is_interpreted_frame() || >> + (locals < caller->fp() + frame::interpreter_frame_initial_sp_offset), "bad placement"); > > Why do you think that? I very easy to read with the if. I don't trust C++ compilers to eliminate is_interpreted_frame() call in product VM even if the body of 'if' statement is empty. You can enclose it with #ifdef ASSERT if you want to keep 'if'. Vladimir > > -- Chris > >> >> Why assert was not added to sparc? >> >> You did not explain changes in bytecodeTracer.cpp and in frame.cpp (frame::describe()). They seems unrelated to this fix. >> >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7090904/ >>> 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop >>> Reviewed-by: >>> A couple of JRuby junit tests crash in various forms (mostly GC >>> related) when running on 64-bit Linux. Although it looks like a GC >>> related problem it actually is a deoptimization bug. >>> Tom already had a fix ready but we were unable to write a test case to >>> prove the correctness of the fix. An assert added in >>> AbstractInterpreter::layout_activation shows that the JRuby crashes >>> are indeed an incarnation of this deoptimization bug. >>> The bug itself is in the deoptimization logic that calculates the size >>> of parameter space in the caller frame. Method handle invokes may >>> involve fairly arbitrary chains of calls so it's impossible to know >>> how much actual space the caller has for locals. >>> The fix is to always assume zero parameters for method handle call >>> sites. >>> Extensive testing with JRuby junit tests. >>> src/share/vm/runtime/deoptimization.cpp >>> src/cpu/x86/vm/templateInterpreter_x86_32.cpp >>> src/cpu/x86/vm/templateInterpreter_x86_64.cpp >>> src/share/vm/interpreter/bytecodeTracer.cpp >>> src/share/vm/runtime/frame.cpp >>> src/share/vm/runtime/frame.hpp >>> src/share/vm/runtime/thread.cpp > From john.r.rose at oracle.com Tue Oct 18 14:49:20 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 18 Oct 2011 14:49:20 -0700 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: <4E9DECA1.5000000@oracle.com> References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> <4E9DC4AA.1090600@oracle.com> <6E633723-F9A5-47AF-83EC-504802BDD323@oracle.com> <4E9DECA1.5000000@oracle.com> Message-ID: On Oct 18, 2011, at 2:16 PM, Vladimir Kozlov wrote: > I don't trust C++ compilers to eliminate is_interpreted_frame() call in product VM even if the body of 'if' statement is empty. You can enclose it with #ifdef ASSERT if you want to keep 'if'. Right; that's what I would do. At some point the body of the assert gets so hairy that you have to break down and write #ifdef ASSERT, to contain the debug code. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111018/049ce661/attachment.html From christian.thalinger at oracle.com Wed Oct 19 00:26:14 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 19 Oct 2011 09:26:14 +0200 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: <4E9DECA1.5000000@oracle.com> References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> <4E9DC4AA.1090600@oracle.com> <6E633723-F9A5-47AF-83EC-504802BDD323@oracle.com> <4E9DECA1.5000000@oracle.com> Message-ID: On Oct 18, 2011, at 11:16 PM, Vladimir Kozlov wrote: > Christian Thalinger wrote: >>> I think you need move the check inside assert: >>> >>> + if (caller->is_interpreted_frame()) { >>> + assert(locals < caller->fp() + frame::interpreter_frame_initial_sp_offset, "bad placement"); >>> + } >>> --- >>> + assert(!caller->is_interpreted_frame() || >>> + (locals < caller->fp() + frame::interpreter_frame_initial_sp_offset), "bad placement"); >> Why do you think that? I very easy to read with the if. > > I don't trust C++ compilers to eliminate is_interpreted_frame() call in product VM even if the body of 'if' statement is empty. You can enclose it with #ifdef ASSERT if you want to keep 'if'. :-) Well, I would trust them since it's the simplest optimization of all but I'll add an #ifdef ASSERT. Thanks for the review. -- Chris > > Vladimir > >> -- Chris >>> >>> Why assert was not added to sparc? >>> >>> You did not explain changes in bytecodeTracer.cpp and in frame.cpp (frame::describe()). They seems unrelated to this fix. >>> >>> Thanks, >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/7090904/ >>>> 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop >>>> Reviewed-by: >>>> A couple of JRuby junit tests crash in various forms (mostly GC >>>> related) when running on 64-bit Linux. Although it looks like a GC >>>> related problem it actually is a deoptimization bug. >>>> Tom already had a fix ready but we were unable to write a test case to >>>> prove the correctness of the fix. An assert added in >>>> AbstractInterpreter::layout_activation shows that the JRuby crashes >>>> are indeed an incarnation of this deoptimization bug. >>>> The bug itself is in the deoptimization logic that calculates the size >>>> of parameter space in the caller frame. Method handle invokes may >>>> involve fairly arbitrary chains of calls so it's impossible to know >>>> how much actual space the caller has for locals. >>>> The fix is to always assume zero parameters for method handle call >>>> sites. >>>> Extensive testing with JRuby junit tests. >>>> src/share/vm/runtime/deoptimization.cpp >>>> src/cpu/x86/vm/templateInterpreter_x86_32.cpp >>>> src/cpu/x86/vm/templateInterpreter_x86_64.cpp >>>> src/share/vm/interpreter/bytecodeTracer.cpp >>>> src/share/vm/runtime/frame.cpp >>>> src/share/vm/runtime/frame.hpp >>>> src/share/vm/runtime/thread.cpp From christian.thalinger at oracle.com Wed Oct 19 08:39:36 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 19 Oct 2011 17:39:36 +0200 Subject: Request for reviews (M): 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop In-Reply-To: References: <0DF93243-11D0-41E0-9005-4F2E07898DEE@oracle.com> <4E9DC4AA.1090600@oracle.com> <6E633723-F9A5-47AF-83EC-504802BDD323@oracle.com> <4E9DECA1.5000000@oracle.com> Message-ID: <7B64FD03-B461-4F8B-A681-B717C29BF70B@oracle.com> I updated the webrev with all review comments and did another round of testing. SPARC looks good so far (at least 32-bit; 64-bit doesn't work because of a JRuby bug). -- Chris On Oct 19, 2011, at 9:26 AM, Christian Thalinger wrote: > > On Oct 18, 2011, at 11:16 PM, Vladimir Kozlov wrote: > >> Christian Thalinger wrote: >>>> I think you need move the check inside assert: >>>> >>>> + if (caller->is_interpreted_frame()) { >>>> + assert(locals < caller->fp() + frame::interpreter_frame_initial_sp_offset, "bad placement"); >>>> + } >>>> --- >>>> + assert(!caller->is_interpreted_frame() || >>>> + (locals < caller->fp() + frame::interpreter_frame_initial_sp_offset), "bad placement"); >>> Why do you think that? I very easy to read with the if. >> >> I don't trust C++ compilers to eliminate is_interpreted_frame() call in product VM even if the body of 'if' statement is empty. You can enclose it with #ifdef ASSERT if you want to keep 'if'. > > :-) Well, I would trust them since it's the simplest optimization of all but I'll add an #ifdef ASSERT. Thanks for the review. > > -- Chris > >> >> Vladimir >> >>> -- Chris >>>> >>>> Why assert was not added to sparc? >>>> >>>> You did not explain changes in bytecodeTracer.cpp and in frame.cpp (frame::describe()). They seems unrelated to this fix. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/7090904/ >>>>> 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop >>>>> Reviewed-by: >>>>> A couple of JRuby junit tests crash in various forms (mostly GC >>>>> related) when running on 64-bit Linux. Although it looks like a GC >>>>> related problem it actually is a deoptimization bug. >>>>> Tom already had a fix ready but we were unable to write a test case to >>>>> prove the correctness of the fix. An assert added in >>>>> AbstractInterpreter::layout_activation shows that the JRuby crashes >>>>> are indeed an incarnation of this deoptimization bug. >>>>> The bug itself is in the deoptimization logic that calculates the size >>>>> of parameter space in the caller frame. Method handle invokes may >>>>> involve fairly arbitrary chains of calls so it's impossible to know >>>>> how much actual space the caller has for locals. >>>>> The fix is to always assume zero parameters for method handle call >>>>> sites. >>>>> Extensive testing with JRuby junit tests. >>>>> src/share/vm/runtime/deoptimization.cpp >>>>> src/cpu/x86/vm/templateInterpreter_x86_32.cpp >>>>> src/cpu/x86/vm/templateInterpreter_x86_64.cpp >>>>> src/share/vm/interpreter/bytecodeTracer.cpp >>>>> src/share/vm/runtime/frame.cpp >>>>> src/share/vm/runtime/frame.hpp >>>>> src/share/vm/runtime/thread.cpp > From vladimir.kozlov at oracle.com Wed Oct 19 14:59:07 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 19 Oct 2011 21:59:07 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations Message-ID: <20111019215912.DA00E47098@hg.openjdk.java.net> Changeset: 16f9fa2bf76c Author: kvn Date: 2011-10-19 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/16f9fa2bf76c 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations Summary: replace the call to memmove by a simple copy loop Reviewed-by: dholmes, kvn, never Contributed-by: axel.siebenborn at sap.com, volker.simonis at gmail.com ! src/cpu/sparc/vm/copy_sparc.hpp ! src/os_cpu/windows_x86/vm/copy_windows_x86.inline.hpp + test/runtime/7100935/TestConjointAtomicArraycopy.java + test/runtime/7100935/TestShortArraycopy.java From christian.thalinger at oracle.com Thu Oct 20 05:32:43 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 20 Oct 2011 14:32:43 +0200 Subject: Request for review (M): 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely Message-ID: <3D22FEEA-2AF5-4007-A600-26337B6C1685@oracle.com> http://cr.openjdk.java.net/~twisti/7102657/ 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely Reviewed-by: The current logic for invokedynamic in LIRGenerator::do_Invoke doesn't actually initiate a deoptimization. We need some new logic to do that. src/share/vm/c1/c1_Runtime1.cpp src/share/vm/c1/c1_Runtime1.hpp src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp src/cpu/sparc/vm/c1_Runtime1_sparc.cpp src/cpu/x86/vm/c1_CodeStubs_x86.cpp src/cpu/x86/vm/c1_Runtime1_x86.cpp From tom.rodriguez at oracle.com Thu Oct 20 09:52:15 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 20 Oct 2011 09:52:15 -0700 Subject: Request for review (M): 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely In-Reply-To: <3D22FEEA-2AF5-4007-A600-26337B6C1685@oracle.com> References: <3D22FEEA-2AF5-4007-A600-26337B6C1685@oracle.com> Message-ID: <508D8A9E-BBA5-4595-88AE-F4BB9D8CA205@oracle.com> On Oct 20, 2011, at 5:32 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7102657/ > > 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely > Reviewed-by: > > The current logic for invokedynamic in LIRGenerator::do_Invoke doesn't > actually initiate a deoptimization. We need some new logic to do > that. c1_Runtime.cpp: This comment isn't true: + // It's possible the nmethod was invalidated in the last + // safepoint, but if it's still alive then make it not_entrant. You've just come from the compiled code so it's required that the caller exists. Can you change this test to an assert? Also I know you copied this comment: + // Bypass VM_DeoptimizeFrame and deoptimize the frame directly. but it's no really right in any place it's used. It corresponds to the old code where you could pick how to call the deopt code. I modified it a while back so that there's only one way and that interface chooses how to call into the deoptimization code. Can you just correct it to "// Deoptimize the caller frame". In the stubs, you don't need to explicit logic to dispatch to the deopt blob. The normal return generated by ~StubFrame will return to the deopt blob because the deoptimize call has rewritten the return address. That's how all stubs that get deoptimized end up returning to the deopt blob. Otherwise it looks good. tom > > src/share/vm/c1/c1_Runtime1.cpp > src/share/vm/c1/c1_Runtime1.hpp > src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp > src/cpu/sparc/vm/c1_Runtime1_sparc.cpp > src/cpu/x86/vm/c1_CodeStubs_x86.cpp > src/cpu/x86/vm/c1_Runtime1_x86.cpp > From tom.rodriguez at oracle.com Thu Oct 20 13:00:28 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 20 Oct 2011 13:00:28 -0700 Subject: review for 7103261: crash with jittester on sparc Message-ID: <083040C5-F807-4A8A-A715-573DF166D302@oracle.com> http://cr.openjdk.java.net/~never/7103261 108 lines changed: 107 ins; 0 del; 1 mod; 3376 unchg 7103261: crash with jittester on sparc Summary: Reviewed-by: The changes for 6985015 rearranged the logic for recording implicit exceptions but save the offset of the faulting instruction twice instead of just for the first one. This means the implicit exception is in on the second instruction instead of the first. The original test was very complicated so I wrote a simpler one that exercises all the implicit null for fields. From igor.veresov at oracle.com Thu Oct 20 13:53:47 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 20 Oct 2011 13:53:47 -0700 Subject: review for 7103261: crash with jittester on sparc In-Reply-To: <083040C5-F807-4A8A-A715-573DF166D302@oracle.com> References: <083040C5-F807-4A8A-A715-573DF166D302@oracle.com> Message-ID: <11A4F95BDDB84AFE96460B8D7EA3CBE3@oracle.com> Looks good. Thank you for fixing that. I guess that's my copy-paste error.. igor On Thursday, October 20, 2011 at 1:00 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7103261 > 108 lines changed: 107 ins; 0 del; 1 mod; 3376 unchg > > 7103261: crash with jittester on sparc > Summary: > Reviewed-by: > > The changes for 6985015 rearranged the logic for recording implicit > exceptions but save the offset of the faulting instruction twice > instead of just for the first one. This means the implicit exception > is in on the second instruction instead of the first. The original > test was very complicated so I wrote a simpler one that exercises all > the implicit null for fields. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111020/87c32170/attachment.html From vladimir.kozlov at oracle.com Thu Oct 20 17:37:39 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Oct 2011 17:37:39 -0700 Subject: review for 7103261: crash with jittester on sparc In-Reply-To: <083040C5-F807-4A8A-A715-573DF166D302@oracle.com> References: <083040C5-F807-4A8A-A715-573DF166D302@oracle.com> Message-ID: <4EA0BED3.5030406@oracle.com> Good. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7103261 > 108 lines changed: 107 ins; 0 del; 1 mod; 3376 unchg > > 7103261: crash with jittester on sparc > Summary: > Reviewed-by: > > The changes for 6985015 rearranged the logic for recording implicit > exceptions but save the offset of the faulting instruction twice > instead of just for the first one. This means the implicit exception > is in on the second instruction instead of the first. The original > test was very complicated so I wrote a simpler one that exercises all > the implicit null for fields. > From tom.rodriguez at oracle.com Thu Oct 20 17:49:15 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 20 Oct 2011 17:49:15 -0700 Subject: review for 7103261: crash with jittester on sparc In-Reply-To: <4EA0BED3.5030406@oracle.com> References: <083040C5-F807-4A8A-A715-573DF166D302@oracle.com> <4EA0BED3.5030406@oracle.com> Message-ID: <6153A7CF-2337-4F12-BD03-16CE6A2E47C0@oracle.com> Thanks Igor and Vladimir. tom On Oct 20, 2011, at 5:37 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7103261 >> 108 lines changed: 107 ins; 0 del; 1 mod; 3376 unchg >> 7103261: crash with jittester on sparc >> Summary: >> Reviewed-by: >> The changes for 6985015 rearranged the logic for recording implicit >> exceptions but save the offset of the faulting instruction twice >> instead of just for the first one. This means the implicit exception >> is in on the second instruction instead of the first. The original >> test was very complicated so I wrote a simpler one that exercises all >> the implicit null for fields. From tom.rodriguez at oracle.com Thu Oct 20 17:55:30 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 20 Oct 2011 17:55:30 -0700 Subject: review for 7103380: assertion failure with -XX:+PrintNativeNMethods Message-ID: http://cr.openjdk.java.net/~never/7103380 11 lines changed: 10 ins; 0 del; 1 mod; 1028 unchg 7103380: assertion failure with -XX:+PrintNativeNMethods Reviewed-by: Running with -XX:+PrintNativeNMethods I hit the assert: # assert(limit == NULL || limit <= nm->code_end()) failed: in bounds The problem is that old instructions in the code buffer after the real code, so the disassembler attempts to disassemble off the end of the buffer. This is because alignment of the end CodeSections is performed by looking at the predecessor of the current section. Fixing the alignment to always align the beginning and end seems to fan out causing other problems. Instead I added some logic similar to the existing fill logic to fill any remaining space in the destination. The reason native wrappers fall afoul of this is that the don't have a stub section. Tested with -XX:+PrintNativeNMethods. From igor.veresov at oracle.com Thu Oct 20 18:26:02 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 20 Oct 2011 18:26:02 -0700 Subject: review for 7103380: assertion failure with -XX:+PrintNativeNMethods In-Reply-To: References: Message-ID: <3348EA69395149899F0D510B0996E529@oracle.com> Looks good. igor On Thursday, October 20, 2011 at 5:55 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7103380 > 11 lines changed: 10 ins; 0 del; 1 mod; 1028 unchg > > 7103380: assertion failure with -XX:+PrintNativeNMethods > Reviewed-by: > > Running with -XX:+PrintNativeNMethods I hit the assert: > > # assert(limit == NULL || limit <= nm->code_end()) failed: in bounds > > The problem is that old instructions in the code buffer after the real > code, so the disassembler attempts to disassemble off the end of the > buffer. This is because alignment of the end CodeSections is > performed by looking at the predecessor of the current section. > Fixing the alignment to always align the beginning and end seems to > fan out causing other problems. Instead I added some logic similar to > the existing fill logic to fill any remaining space in the > destination. The reason native wrappers fall afoul of this is that > the don't have a stub section. Tested with -XX:+PrintNativeNMethods. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111020/2aee7c91/attachment.html From vladimir.kozlov at oracle.com Thu Oct 20 19:05:21 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Oct 2011 19:05:21 -0700 Subject: review for 7103380: assertion failure with -XX:+PrintNativeNMethods In-Reply-To: References: Message-ID: <4EA0D361.5010709@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7103380 > 11 lines changed: 10 ins; 0 del; 1 mod; 1028 unchg > > 7103380: assertion failure with -XX:+PrintNativeNMethods > Reviewed-by: > > Running with -XX:+PrintNativeNMethods I hit the assert: > > # assert(limit == NULL || limit <= nm->code_end()) failed: in bounds > > The problem is that old instructions in the code buffer after the real > code, so the disassembler attempts to disassemble off the end of the > buffer. This is because alignment of the end CodeSections is > performed by looking at the predecessor of the current section. > Fixing the alignment to always align the beginning and end seems to > fan out causing other problems. Instead I added some logic similar to > the existing fill logic to fill any remaining space in the > destination. The reason native wrappers fall afoul of this is that > the don't have a stub section. Tested with -XX:+PrintNativeNMethods. > From christian.thalinger at oracle.com Fri Oct 21 01:22:42 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 21 Oct 2011 10:22:42 +0200 Subject: Request for review (M): 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely In-Reply-To: <508D8A9E-BBA5-4595-88AE-F4BB9D8CA205@oracle.com> References: <3D22FEEA-2AF5-4007-A600-26337B6C1685@oracle.com> <508D8A9E-BBA5-4595-88AE-F4BB9D8CA205@oracle.com> Message-ID: <4729339B-97EF-435A-91D6-B8F0175388A4@oracle.com> On Oct 20, 2011, at 6:52 PM, Tom Rodriguez wrote: > > On Oct 20, 2011, at 5:32 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7102657/ >> >> 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely >> Reviewed-by: >> >> The current logic for invokedynamic in LIRGenerator::do_Invoke doesn't >> actually initiate a deoptimization. We need some new logic to do >> that. > > c1_Runtime.cpp: > > This comment isn't true: > > + // It's possible the nmethod was invalidated in the last > + // safepoint, but if it's still alive then make it not_entrant. > > You've just come from the compiled code so it's required that the caller exists. Can you change this test to an assert? Done. > > Also I know you copied this comment: > > + // Bypass VM_DeoptimizeFrame and deoptimize the frame directly. > > but it's no really right in any place it's used. It corresponds to the old code where you could pick how to call the deopt code. I modified it a while back so that there's only one way and that interface chooses how to call into the deoptimization code. Can you just correct it to "// Deoptimize the caller frame". I also changed the comment from where I copied it. > > In the stubs, you don't need to explicit logic to dispatch to the deopt blob. The normal return generated by ~StubFrame will return to the deopt blob because the deoptimize call has rewritten the return address. That's how all stubs that get deoptimized end up returning to the deopt blob. Hmm. I changed the stub to return instead of dispatching to the deopt blob and that produces wrong results with my test case. Are you sure the return address gets rewritten correctly? > > Otherwise it looks good. Thanks. -- Chris > > tom > >> >> src/share/vm/c1/c1_Runtime1.cpp >> src/share/vm/c1/c1_Runtime1.hpp >> src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp >> src/cpu/sparc/vm/c1_Runtime1_sparc.cpp >> src/cpu/x86/vm/c1_CodeStubs_x86.cpp >> src/cpu/x86/vm/c1_Runtime1_x86.cpp >> > From christian.thalinger at oracle.com Fri Oct 21 02:17:53 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 21 Oct 2011 11:17:53 +0200 Subject: Request for reviews (XS): 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check Message-ID: <63A3CABB-5681-40F2-8F6A-A77E68F03BF2@oracle.com> http://cr.openjdk.java.net/~twisti/7094138/ 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check Reviewed-by: InterpreterRuntime::resolve_get_put and MHN_setCallSiteTargetNormal/MHN_setCallSiteTargetVolatile are calling Universe::flush_dependents_on under the Compile_lock to make sure the CallSite target values don't change during a compile in flight. But both arguments for call_site and target are not held in a Handle but a plain oop. This can result in stale oops. Tested with JRuby test_respond_to.rb. src/share/vm/interpreter/interpreterRuntime.cpp src/share/vm/prims/methodHandles.cpp From igor.veresov at oracle.com Fri Oct 21 03:58:31 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 21 Oct 2011 03:58:31 -0700 Subject: Request for reviews (XS): 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check In-Reply-To: <63A3CABB-5681-40F2-8F6A-A77E68F03BF2@oracle.com> References: <63A3CABB-5681-40F2-8F6A-A77E68F03BF2@oracle.com> Message-ID: Looks good. igor On Friday, October 21, 2011 at 2:17 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7094138/ > > 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check > Reviewed-by: > > InterpreterRuntime::resolve_get_put and > MHN_setCallSiteTargetNormal/MHN_setCallSiteTargetVolatile are calling > Universe::flush_dependents_on under the Compile_lock to make sure the > CallSite target values don't change during a compile in flight. But > both arguments for call_site and target are not held in a Handle but a > plain oop. This can result in stale oops. > > Tested with JRuby test_respond_to.rb. > > src/share/vm/interpreter/interpreterRuntime.cpp > src/share/vm/prims/methodHandles.cpp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111021/ff679518/attachment.html From tom.rodriguez at oracle.com Fri Oct 21 11:18:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Oct 2011 11:18:57 -0700 Subject: Request for review (M): 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely In-Reply-To: <4729339B-97EF-435A-91D6-B8F0175388A4@oracle.com> References: <3D22FEEA-2AF5-4007-A600-26337B6C1685@oracle.com> <508D8A9E-BBA5-4595-88AE-F4BB9D8CA205@oracle.com> <4729339B-97EF-435A-91D6-B8F0175388A4@oracle.com> Message-ID: On Oct 21, 2011, at 1:22 AM, Christian Thalinger wrote: > > On Oct 20, 2011, at 6:52 PM, Tom Rodriguez wrote: > >> >> On Oct 20, 2011, at 5:32 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7102657/ >>> >>> 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely >>> Reviewed-by: >>> >>> The current logic for invokedynamic in LIRGenerator::do_Invoke doesn't >>> actually initiate a deoptimization. We need some new logic to do >>> that. >> >> c1_Runtime.cpp: >> >> This comment isn't true: >> >> + // It's possible the nmethod was invalidated in the last >> + // safepoint, but if it's still alive then make it not_entrant. >> >> You've just come from the compiled code so it's required that the caller exists. Can you change this test to an assert? > > Done. > >> >> Also I know you copied this comment: >> >> + // Bypass VM_DeoptimizeFrame and deoptimize the frame directly. >> >> but it's no really right in any place it's used. It corresponds to the old code where you could pick how to call the deopt code. I modified it a while back so that there's only one way and that interface chooses how to call into the deoptimization code. Can you just correct it to "// Deoptimize the caller frame". > > I also changed the comment from where I copied it. > >> >> In the stubs, you don't need to explicit logic to dispatch to the deopt blob. The normal return generated by ~StubFrame will return to the deopt blob because the deoptimize call has rewritten the return address. That's how all stubs that get deoptimized end up returning to the deopt blob. > > Hmm. I changed the stub to return instead of dispatching to the deopt blob and that produces wrong results with my test case. Are you sure the return address gets rewritten correctly? I didn't notice that you were explicitly requesting unpack_with_reexecution. That's why you need to dispatch it directly. Sorry for misleading you. It would actually work correctly if we took advantage of the reexecute bit in the PcDesc but that would require tweaking the debug info generation process for C1 since we currently don't use it. You'd have to add a should_reexecute field in CodeEmitInfo and propagate that into IRScopeDebugInfo, so that it can be picked up when actually building the PcDesc. Anyway, we can keep your original code if you want. tom > >> >> Otherwise it looks good. > > Thanks. > > -- Chris > >> >> tom >> >>> >>> src/share/vm/c1/c1_Runtime1.cpp >>> src/share/vm/c1/c1_Runtime1.hpp >>> src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp >>> src/cpu/sparc/vm/c1_Runtime1_sparc.cpp >>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp >>> src/cpu/x86/vm/c1_Runtime1_x86.cpp >>> >> > From tom.rodriguez at oracle.com Fri Oct 21 11:20:26 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Oct 2011 11:20:26 -0700 Subject: Request for reviews (XS): 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check In-Reply-To: <63A3CABB-5681-40F2-8F6A-A77E68F03BF2@oracle.com> References: <63A3CABB-5681-40F2-8F6A-A77E68F03BF2@oracle.com> Message-ID: <06776BDA-E4FF-467C-A886-8236096670AF@oracle.com> Looks good. We should see if we can get this into 7u2. tom On Oct 21, 2011, at 2:17 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7094138/ > > 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check > Reviewed-by: > > InterpreterRuntime::resolve_get_put and > MHN_setCallSiteTargetNormal/MHN_setCallSiteTargetVolatile are calling > Universe::flush_dependents_on under the Compile_lock to make sure the > CallSite target values don't change during a compile in flight. But > both arguments for call_site and target are not held in a Handle but a > plain oop. This can result in stale oops. > > Tested with JRuby test_respond_to.rb. > > src/share/vm/interpreter/interpreterRuntime.cpp > src/share/vm/prims/methodHandles.cpp > From christian.thalinger at oracle.com Fri Oct 21 11:30:53 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 21 Oct 2011 20:30:53 +0200 Subject: Request for reviews (XS): 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check In-Reply-To: <06776BDA-E4FF-467C-A886-8236096670AF@oracle.com> References: <63A3CABB-5681-40F2-8F6A-A77E68F03BF2@oracle.com> <06776BDA-E4FF-467C-A886-8236096670AF@oracle.com> Message-ID: On Oct 21, 2011, at 8:20 PM, Tom Rodriguez wrote: > Looks good. We should see if we can get this into 7u2. Yes, I agree. -- Chris > > tom > > On Oct 21, 2011, at 2:17 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7094138/ >> >> 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check >> Reviewed-by: >> >> InterpreterRuntime::resolve_get_put and >> MHN_setCallSiteTargetNormal/MHN_setCallSiteTargetVolatile are calling >> Universe::flush_dependents_on under the Compile_lock to make sure the >> CallSite target values don't change during a compile in flight. But >> both arguments for call_site and target are not held in a Handle but a >> plain oop. This can result in stale oops. >> >> Tested with JRuby test_respond_to.rb. >> >> src/share/vm/interpreter/interpreterRuntime.cpp >> src/share/vm/prims/methodHandles.cpp >> > From igor.veresov at oracle.com Fri Oct 21 12:09:57 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 21 Oct 2011 19:09:57 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 4 new changesets Message-ID: <20111021191009.5E7E7470C9@hg.openjdk.java.net> Changeset: 2ef3386478e6 Author: dholmes Date: 2011-10-10 21:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2ef3386478e6 7096278: Update the VM name to indicate it is an embedded build Reviewed-by: kvn, never, jcoomes, bobv ! src/share/vm/runtime/vm_version.cpp Changeset: 436b4a3231bf Author: dcubed Date: 2011-10-13 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/436b4a3231bf 7098194: integrate macosx-port changes Summary: Integrate bsd-port/hotspot and macosx-port/hotspot changes as of 2011.09.29. Reviewed-by: kvn, dholmes, never, phh Contributed-by: Christos Zoulas , Greg Lewis , Kurt Miller , Alexander Strange , Mike Swingler , Roger Hoover , Victor Hernandez , Pratik Solanki ! .hgignore + agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/symtab.c ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/Makefile ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/sa.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/top.make ! make/bsd/makefiles/vm.make ! make/defs.make - make/templates/bsd-header ! src/cpu/x86/vm/jni_x86.h + src/os/bsd/dtrace/generateJvmOffsets.cpp + src/os/bsd/dtrace/generateJvmOffsets.h + src/os/bsd/dtrace/generateJvmOffsetsMain.c + src/os/bsd/dtrace/hotspot.d + src/os/bsd/dtrace/hotspot_jni.d + src/os/bsd/dtrace/hs_private.d + src/os/bsd/dtrace/jhelper.d + src/os/bsd/dtrace/jvm_dtrace.c + src/os/bsd/dtrace/jvm_dtrace.h + src/os/bsd/dtrace/libjvm_db.c + src/os/bsd/dtrace/libjvm_db.h ! src/os/bsd/vm/dtraceJSDT_bsd.cpp ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/dtrace.hpp + src/share/vm/utilities/dtrace_usdt2_disabled.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/hashtable.cpp Changeset: 23a1c8de9d51 Author: dholmes Date: 2011-10-17 01:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/23a1c8de9d51 Merge - make/templates/bsd-header ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp Changeset: 1179647ee175 Author: iveresov Date: 2011-10-21 00:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1179647ee175 Merge From vladimir.kozlov at oracle.com Fri Oct 21 16:23:50 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Oct 2011 16:23:50 -0700 Subject: Request for reviews (S): 7097546: Optimize use of CMOVE instructions Message-ID: <4EA1FF06.3040906@oracle.com> http://cr.openjdk.java.net/~kvn/7097546/webrev 7097546: Optimize use of CMOVE instructions Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Don't generated CMoveD/CmoveF: it is expensive to compute both float/double values + cmove. Note, on x86 when SSE>=2 (all modern cpus) CMoveD/CMoveF mach instructions are implemented as jmp+move. Don't generated CMove when BlockLayoutByFrequency optimization moves infrequent branch from hot path. Added Cmove mach instructions with jmp+move to x86 when there is no HW cmove instruction. Main part of changes in loopopts.cpp is coding style correction. Print size of compiled method and compilation time when PrintCompilation and PrintInlining are specified on command line. I thought first to print it with just PrintCompilation but it will double output. No effect on refworkload but it will help later for 6890673 fix. Verified with microbenchmark I wrote (attached to the bug report). Thanks, Vladimir From tom.rodriguez at oracle.com Fri Oct 21 18:10:46 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Oct 2011 18:10:46 -0700 Subject: review for 7103784: enable some flags by default Message-ID: <021FDB54-76F5-43B0-9DAD-47F08C64C773@oracle.com> http://cr.openjdk.java.net/~never/7103784 3 lines changed: 0 ins; 0 del; 3 mod; 4396 unchg 7103784: enable some flags by default Reviewed-by: Enable UseCodeCacheFlushing, UseRDPCForConstantTableBase and OptimizeStringConcat by default. UseCodeCacheFlushing and OptimizeStringConcat are tested by various settings in our nightlies so there should only be minor issues. UseRDPCForConstantTableBase has been tested and was only off because the performance was unclear but we believe it performs well on newer hardware. From vladimir.kozlov at oracle.com Fri Oct 21 18:41:16 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Oct 2011 18:41:16 -0700 Subject: review for 7103784: enable some flags by default In-Reply-To: <021FDB54-76F5-43B0-9DAD-47F08C64C773@oracle.com> References: <021FDB54-76F5-43B0-9DAD-47F08C64C773@oracle.com> Message-ID: <4EA21F3C.6040103@oracle.com> What about EliminateAutoBox and OptimizeFill? Should we remove corresponding AggressiveOpts code in arguments.cpp? Thanks, Vladimir On 10/21/11 6:10 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7103784 > 3 lines changed: 0 ins; 0 del; 3 mod; 4396 unchg > > 7103784: enable some flags by default > Reviewed-by: > > Enable UseCodeCacheFlushing, UseRDPCForConstantTableBase and > OptimizeStringConcat by default. UseCodeCacheFlushing and > OptimizeStringConcat are tested by various settings in our nightlies > so there should only be minor issues. UseRDPCForConstantTableBase has > been tested and was only off because the performance was unclear but > we believe it performs well on newer hardware. > From john.coomes at oracle.com Sat Oct 22 22:41:26 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:41:26 +0000 Subject: hg: hsx/hotspot-comp: 12 new changesets Message-ID: <20111023054126.9960A470D7@hg.openjdk.java.net> Changeset: b910aac18c77 Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/b910aac18c77 Added tag jdk8-b04 for changeset 0b66a233bfb9 ! .hgtags Changeset: 28cf2aec4dd7 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/28cf2aec4dd7 Added tag jdk8-b05 for changeset b910aac18c77 ! .hgtags Changeset: 0db7ae9f2b10 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/0db7ae9f2b10 Added tag jdk8-b06 for changeset 28cf2aec4dd7 ! .hgtags Changeset: cf76aa4189e4 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/cf76aa4189e4 Added tag jdk8-b07 for changeset 0db7ae9f2b10 ! .hgtags Changeset: b1d357ebf0cb Author: weijun Date: 2011-09-08 09:06 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/b1d357ebf0cb 7087428: move client tests out of jdk_misc Reviewed-by: ohair, alanb ! make/jprt.properties Changeset: 123873564c23 Author: lana Date: 2011-09-13 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/123873564c23 Merge Changeset: 39edfd9d8ff0 Author: lana Date: 2011-09-23 23:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/39edfd9d8ff0 Merge Changeset: 2f1af0e3e8f7 Author: lana Date: 2011-09-26 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2f1af0e3e8f7 Merge Changeset: fb1bc13260d7 Author: lana Date: 2011-10-03 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/fb1bc13260d7 Merge Changeset: 8adb70647b5a Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8adb70647b5a Added tag jdk8-b08 for changeset fb1bc13260d7 ! .hgtags Changeset: a6c4c248e8fa Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a6c4c248e8fa Added tag jdk8-b09 for changeset 8adb70647b5a ! .hgtags Changeset: 1defbc57940a Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/1defbc57940a Added tag jdk8-b10 for changeset a6c4c248e8fa ! .hgtags From john.coomes at oracle.com Sat Oct 22 22:41:35 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:41:35 +0000 Subject: hg: hsx/hotspot-comp/corba: 7 new changesets Message-ID: <20111023054141.A04A3470D8@hg.openjdk.java.net> Changeset: cc1b599b986a Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/cc1b599b986a Added tag jdk8-b04 for changeset 60a68d688e24 ! .hgtags Changeset: 45c43dde7ba7 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/45c43dde7ba7 Added tag jdk8-b05 for changeset cc1b599b986a ! .hgtags Changeset: 3d61f0856f34 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/3d61f0856f34 Added tag jdk8-b06 for changeset 45c43dde7ba7 ! .hgtags Changeset: 0d52b1c87aa8 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/0d52b1c87aa8 Added tag jdk8-b07 for changeset 3d61f0856f34 ! .hgtags Changeset: a891732c1a83 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/a891732c1a83 Added tag jdk8-b08 for changeset 0d52b1c87aa8 ! .hgtags Changeset: cda87f7fefce Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/cda87f7fefce Added tag jdk8-b09 for changeset a891732c1a83 ! .hgtags Changeset: 0199e4fef5cc Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/0199e4fef5cc Added tag jdk8-b10 for changeset cda87f7fefce ! .hgtags From john.coomes at oracle.com Sat Oct 22 22:41:51 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:41:51 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 7 new changesets Message-ID: <20111023054151.A964F470D9@hg.openjdk.java.net> Changeset: ff0a3d78e7a2 Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/ff0a3d78e7a2 Added tag jdk8-b04 for changeset acbcadef0b21 ! .hgtags Changeset: d7b8192e7277 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/d7b8192e7277 Added tag jdk8-b05 for changeset ff0a3d78e7a2 ! .hgtags Changeset: c114306576dc Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/c114306576dc Added tag jdk8-b06 for changeset d7b8192e7277 ! .hgtags Changeset: de4794dd69c4 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/de4794dd69c4 Added tag jdk8-b07 for changeset c114306576dc ! .hgtags Changeset: 93554324c014 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/93554324c014 Added tag jdk8-b08 for changeset de4794dd69c4 ! .hgtags Changeset: d21a4d5141c0 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/d21a4d5141c0 Added tag jdk8-b09 for changeset 93554324c014 ! .hgtags Changeset: d1b7a4f6dd20 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/d1b7a4f6dd20 Added tag jdk8-b10 for changeset d21a4d5141c0 ! .hgtags From john.coomes at oracle.com Sat Oct 22 22:42:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:42:00 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 7 new changesets Message-ID: <20111023054200.ECFF4470DA@hg.openjdk.java.net> Changeset: 7d5d91fddbce Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/7d5d91fddbce Added tag jdk8-b04 for changeset 3f6f08163331 ! .hgtags Changeset: acffff22a946 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/acffff22a946 Added tag jdk8-b05 for changeset 7d5d91fddbce ! .hgtags Changeset: 134b0debf7b0 Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/134b0debf7b0 Added tag jdk8-b06 for changeset acffff22a946 ! .hgtags Changeset: 1c9d4f59acf8 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/1c9d4f59acf8 Added tag jdk8-b07 for changeset 134b0debf7b0 ! .hgtags Changeset: 70172e57cf29 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/70172e57cf29 Added tag jdk8-b08 for changeset 1c9d4f59acf8 ! .hgtags Changeset: 8e7fdc8e3c75 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/8e7fdc8e3c75 Added tag jdk8-b09 for changeset 70172e57cf29 ! .hgtags Changeset: a12ab897a249 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/a12ab897a249 Added tag jdk8-b10 for changeset 8e7fdc8e3c75 ! .hgtags From john.coomes at oracle.com Sat Oct 22 22:43:43 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:43:43 +0000 Subject: hg: hsx/hotspot-comp/jdk: 68 new changesets Message-ID: <20111023055541.BEB0A470E4@hg.openjdk.java.net> Changeset: b92341e9ae56 Author: bae Date: 2011-09-19 05:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b92341e9ae56 7088287: libpng need to be updated. Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/libpng/LICENSE ! src/share/native/sun/awt/libpng/README ! src/share/native/sun/awt/libpng/png.c ! src/share/native/sun/awt/libpng/png.h ! src/share/native/sun/awt/libpng/pngconf.h + src/share/native/sun/awt/libpng/pngdebug.h ! src/share/native/sun/awt/libpng/pngerror.c - src/share/native/sun/awt/libpng/pnggccrd.c ! src/share/native/sun/awt/libpng/pngget.c + src/share/native/sun/awt/libpng/pnginfo.h + src/share/native/sun/awt/libpng/pnglibconf.h ! src/share/native/sun/awt/libpng/pngmem.c ! src/share/native/sun/awt/libpng/pngpread.c + src/share/native/sun/awt/libpng/pngpriv.h ! src/share/native/sun/awt/libpng/pngread.c ! src/share/native/sun/awt/libpng/pngrio.c ! src/share/native/sun/awt/libpng/pngrtran.c ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/awt/libpng/pngset.c + src/share/native/sun/awt/libpng/pngstruct.h ! src/share/native/sun/awt/libpng/pngtest.c ! src/share/native/sun/awt/libpng/pngtrans.c - src/share/native/sun/awt/libpng/pngvcrd.c ! src/share/native/sun/awt/libpng/pngwio.c ! src/share/native/sun/awt/libpng/pngwrite.c ! src/share/native/sun/awt/libpng/pngwtran.c ! src/share/native/sun/awt/libpng/pngwutil.c ! src/share/native/sun/awt/splashscreen/splashscreen_png.c Changeset: bbf4e1faf859 Author: lana Date: 2011-09-23 16:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bbf4e1faf859 Merge Changeset: c662c8cf25d6 Author: lana Date: 2011-09-26 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c662c8cf25d6 Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 3487d0d48662 Author: rupashka Date: 2011-09-15 16:43 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3487d0d48662 7090007: Missing style.css in nimbus/doc-files/properties.html Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html Changeset: 16c3dcad4252 Author: rupashka Date: 2011-09-21 17:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/16c3dcad4252 7032018: The file list in JFileChooser does not have an accessible name Reviewed-by: rupashka Contributed-by: Charles Lee ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/sun/swing/FilePane.java Changeset: 44040ece133c Author: lana Date: 2011-09-23 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/44040ece133c Merge Changeset: 44f50834b79c Author: rupashka Date: 2011-09-26 17:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/44f50834b79c 7088744: SwingUtilities.isMiddleMouseButton does not work with ALT/Meta keys Reviewed-by: alexp ! src/share/classes/javax/swing/SwingUtilities.java + test/javax/swing/SwingUtilities/7088744/bug7088744.java Changeset: d72ac458b2b7 Author: anthony Date: 2011-09-26 17:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d72ac458b2b7 7081670: Disposing an AppContext can lead to a spinning EventDispatchThread Reviewed-by: art, anthony, dholmes Contributed-by: Clemens Eisserer ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java Changeset: 7fd192952459 Author: denis Date: 2011-09-26 18:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7fd192952459 7080289: AWTKeystroke class registers a subclass factory during deserialization Reviewed-by: serb ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: aac4041609bb Author: lana Date: 2011-09-26 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/aac4041609bb Merge Changeset: e0c1282a0ead Author: coffeys Date: 2011-09-13 11:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e0c1282a0ead 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java + test/java/io/etc/FileDescriptorSharing.java Changeset: 04672e957da0 Author: mchung Date: 2011-09-14 08:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/04672e957da0 6915797: Remove sun.tools.jar.JarImageSource that is not used 7090178: Move java.util.XMLUtils to another package to avoid split package Reviewed-by: alanb, sherman ! make/java/java/FILES_java.gmk ! make/sun/Makefile + make/sun/util/Makefile ! src/share/classes/java/util/Properties.java - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java + src/share/classes/sun/util/xml/XMLUtils.java Changeset: 2a8072c7cf99 Author: darcy Date: 2011-09-14 11:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2a8072c7cf99 6879143: java.math.BigInteger misses the xxxValueExact methods Reviewed-by: alanb ! src/share/classes/java/math/BigInteger.java + test/java/math/BigInteger/TestValueExact.java Changeset: 84da01e00e6c Author: darcy Date: 2011-09-14 13:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/84da01e00e6c 7088500: there is no @since tag on SafeVarargs Reviewed-by: mduigou ! src/share/classes/java/lang/SafeVarargs.java Changeset: 52bc200b14e5 Author: mbankal Date: 2011-09-14 21:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/52bc200b14e5 7049963: DISTINGUISHED NAMES FOR CERT ARE ESCAPED IN JROCKIT 1.6(NOT COMPATIBLE WITH JROC Reviewed-by: mullan ! src/share/classes/sun/security/x509/AVA.java Changeset: 1260be51581f Author: mbankal Date: 2011-09-14 22:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1260be51581f Merge Changeset: f114bddac6d6 Author: peytoia Date: 2011-09-15 14:45 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f114bddac6d6 7090844: Support a timezone whose offset is changed more than once in the future Reviewed-by: okutsu ! make/tools/src/build/tools/javazic/Mappings.java Changeset: 5e403e9fa34a Author: peytoia Date: 2011-09-15 15:02 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5e403e9fa34a 7090843: (tz) Support tzdata2011j Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 9281d65f911a Author: michaelm Date: 2011-09-15 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9281d65f911a 7073491: -Dsun.net.maxDatagramSockets=1 does not work correctly with system.gc() Reviewed-by: ngmr ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java Changeset: 34fc7bbbb465 Author: michaelm Date: 2011-09-15 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/34fc7bbbb465 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: 75d763111eec Author: chegar Date: 2011-09-16 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/75d763111eec 7090158: Networking Libraries don't build with javac -Werror Summary: Minor changes to networking java files to remove warnings Reviewed-by: chegar, weijun, hawtin Contributed-by: kurchi.subhra.hazra at oracle.com, sasha_bu at hotmail.com ! make/com/sun/net/httpserver/Makefile ! make/com/sun/net/ssl/Makefile ! make/java/net/Makefile ! make/javax/Makefile ! make/javax/others/Makefile ! make/sun/net/Makefile ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/ssl/SSLSecurity.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/Inet4AddressImpl.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/Inet6AddressImpl.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/Proxy.java ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/share/classes/sun/misc/REException.java ! src/share/classes/sun/net/TransferProtocolClient.java ! src/share/classes/sun/net/ftp/FtpClientProvider.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/SSLStreams.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/classes/sun/net/idn/UCharacterEnums.java ! src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java ! src/share/classes/sun/net/www/HeaderParser.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/MimeTable.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/protocol/gopher/GopherClient.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/Negotiator.java ! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/solaris/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/solaris/classes/java/net/PlainDatagramSocketImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: ccf2a19d7d87 Author: alanb Date: 2011-09-18 12:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ccf2a19d7d87 7091935: (fs) Polling based WatchService not used on Linux Reviewed-by: forax ! make/java/nio/Makefile Changeset: 418628a08ae7 Author: darcy Date: 2011-09-18 18:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/418628a08ae7 7091682: Move sun.misc.FpUtils code into java.lang.Math Reviewed-by: alanb ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! src/share/classes/sun/misc/FpUtils.java ! test/java/lang/Double/ToHexString.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/HypotTests.java ! test/java/lang/Math/IeeeRecommendedTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Rint.java Changeset: e3d78fe803d4 Author: michaelm Date: 2011-09-19 15:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e3d78fe803d4 7091369: DatagramSocket/Limit.java failing on 8 and 7u2 Reviewed-by: chegar, alanb ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java Changeset: 8fe6d94683af Author: weijun Date: 2011-09-20 12:40 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8fe6d94683af 7091290: fails to build jdk8 b05 Embedded build Reviewed-by: xuelei, dholmes ! src/share/classes/org/ietf/jgss/Oid.java Changeset: c77b41652266 Author: mduigou Date: 2011-09-20 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c77b41652266 7074264: Switches to packages tree view and adds unit tests to sources Reviewed-by: igor ! make/netbeans/README ! make/netbeans/common/closed-share-view.ent ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/netbeans/common/jtreg-view.ent ! make/netbeans/common/sample-view.ent ! make/netbeans/common/share-view.ent ! make/netbeans/common/unix-view.ent ! make/netbeans/common/windows-view.ent ! make/netbeans/j2se/nbproject/project.xml Changeset: 9b2fc8a11421 Author: darcy Date: 2011-09-20 18:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9b2fc8a11421 6268216: Boolean.getBoolean() throws SecurityException Reviewed-by: mduigou ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java Changeset: 029ba13aa0df Author: dcubed Date: 2011-09-20 19:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/029ba13aa0df 7085944: 3/3 FDS: gdb does not find debug symbols for libjsig link Summary: Add support for importing .debuginfo files from HSX. Reviewed-by: phh ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/redist/Makefile ! make/java/redist/sajdi/Makefile Changeset: d177eecda07e Author: dholmes Date: 2011-09-20 22:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d177eecda07e 7012206: ~20 tools tests failing due to -XX:-UsePerfData default in Java SE Embedded Summary: Explicitly enable UsePerfData for the tools that require it to be enabled Reviewed-by: alanb, ohair ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jmap/Basic.sh ! test/sun/tools/jps/jps-Defaults.sh ! test/sun/tools/jps/jps-V_2.sh ! test/sun/tools/jps/jps-Vm_2.sh ! test/sun/tools/jps/jps-Vvm.sh ! test/sun/tools/jps/jps-Vvml.sh ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-help.sh ! test/sun/tools/jps/jps-l_1.sh ! test/sun/tools/jps/jps-l_2.sh ! test/sun/tools/jps/jps-lm.sh ! test/sun/tools/jps/jps-m.sh ! test/sun/tools/jps/jps-m_2.sh ! test/sun/tools/jps/jps-q.sh ! test/sun/tools/jps/jps-v_1.sh ! test/sun/tools/jps/jps-vm_1.sh ! test/sun/tools/jstack/Basic.sh ! test/sun/tools/jstat/jstatClassOutput1.sh ! test/sun/tools/jstat/jstatClassloadOutput1.sh ! test/sun/tools/jstat/jstatCompilerOutput1.sh ! test/sun/tools/jstat/jstatFileURITest1.sh ! test/sun/tools/jstat/jstatGcCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcCauseOutput1.sh ! test/sun/tools/jstat/jstatGcNewCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcNewOutput1.sh ! test/sun/tools/jstat/jstatGcOldCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcOldOutput1.sh ! test/sun/tools/jstat/jstatGcOutput1.sh ! test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh ! test/sun/tools/jstat/jstatHelp.sh ! test/sun/tools/jstat/jstatLineCounts1.sh ! test/sun/tools/jstat/jstatLineCounts2.sh ! test/sun/tools/jstat/jstatLineCounts3.sh ! test/sun/tools/jstat/jstatLineCounts4.sh ! test/sun/tools/jstat/jstatOptions1.sh ! test/sun/tools/jstat/jstatPrintCompilationOutput1.sh ! test/sun/tools/jstat/jstatSnap1.sh ! test/sun/tools/jstat/jstatSnap2.sh ! test/sun/tools/jstat/jstatTimeStamp1.sh ! test/sun/tools/jstatd/jstatdDefaults.sh ! test/sun/tools/jstatd/jstatdExternalRegistry.sh ! test/sun/tools/jstatd/jstatdPort.sh ! test/sun/tools/jstatd/jstatdServerName.sh Changeset: 61a8c602cace Author: michaelm Date: 2011-09-21 14:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/61a8c602cace 7079012: test/java/net/NetworkInterface/NetParamsTest.java fails with SocketException getting mac address Reviewed-by: chegar, alanb ! src/solaris/native/java/net/NetworkInterface.c ! test/ProblemList.txt Changeset: e7c2bf7d9d33 Author: michaelm Date: 2011-09-21 14:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e7c2bf7d9d33 Merge Changeset: daf87c7be6a1 Author: weijun Date: 2011-09-22 12:05 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/daf87c7be6a1 7092627: use agentvm mode instead of samevm in regtests Reviewed-by: alanb, dsamersoff ! test/Makefile ! test/com/sun/jdi/sde/MangleStepTest.java ! test/java/util/logging/ParentLoggersTest.java Changeset: 6b6b6ee2afd9 Author: darcy Date: 2011-09-21 23:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6b6b6ee2afd9 7092404: Add Math.nextDown and Double.isFinite Reviewed-by: mduigou ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FpUtils.java ! test/java/lang/Double/ParseHexFloatingPoint.java ! test/java/lang/Math/CeilAndFloorTests.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/HypotTests.java ! test/java/lang/Math/IeeeRecommendedTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Rint.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java Changeset: 8dab38c07b6b Author: dl Date: 2011-09-23 14:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8dab38c07b6b 7091003: ScheduledExecutorService never executes Runnable with corePoolSize of zero Reviewed-by: dholmes, chegar ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java + test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCorePoolSize.java Changeset: 651a7afae763 Author: lana Date: 2011-09-23 23:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/651a7afae763 Merge Changeset: 2116952e4459 Author: weijun Date: 2011-09-26 17:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2116952e4459 7094842: test/javax/security/auth/Subject/{Synch.java,Synch2.java,Synch3.java} loop forever in agentvm mode Reviewed-by: alanb ! test/javax/security/auth/Subject/Synch.java ! test/javax/security/auth/Subject/Synch2.java ! test/javax/security/auth/Subject/Synch3.java Changeset: 8876d1dec4d7 Author: chegar Date: 2011-09-26 15:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8876d1dec4d7 7094141: test/sun/misc/JarIndex/metaInfFilenames/Basic.java no longer compiles Reviewed-by: alanb ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java Changeset: 1c825eac6c04 Author: lana Date: 2011-09-26 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1c825eac6c04 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: f38b39ed9ed0 Author: lana Date: 2011-10-03 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f38b39ed9ed0 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 1c023bcd0c5a Author: jcoomes Date: 2011-10-04 12:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1c023bcd0c5a Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: f1ec21b81421 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f1ec21b81421 Added tag jdk8-b08 for changeset 1c023bcd0c5a ! .hgtags Changeset: 7539cc99befe Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7539cc99befe Added tag jdk8-b09 for changeset f1ec21b81421 ! .hgtags Changeset: 1be72d104f9b Author: dbuck Date: 2011-09-26 15:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1be72d104f9b 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth Summary: Added Xflush() call after splash screen is updated to ensure update is no stuck in client side buffer until JVM starts up. See JET review request 4154 for details. Reviewed-by: kevinw, anthony ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: cfe25bac6951 Author: bagiras Date: 2011-09-27 13:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cfe25bac6951 7073337: Crash after playing Java game on Pogo Reviewed-by: art, uta ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: fcdb588d77ef Author: rupashka Date: 2011-10-05 18:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fcdb588d77ef 7072167: The "root" field in BufferStrategyPaintManager leaks memory Reviewed-by: alexp ! src/share/classes/javax/swing/BufferStrategyPaintManager.java Changeset: 98901d41e1e2 Author: rupashka Date: 2011-10-11 15:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/98901d41e1e2 7076791: closed/javax/swing/JColorChooser/Test6827032.java failed on windows Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JColorChooser/Test6827032.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 58190ab77d2e Author: lana Date: 2011-10-12 12:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/58190ab77d2e Merge Changeset: 7f1aca641910 Author: chegar Date: 2011-09-26 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7f1aca641910 7084030: DatagramSocket.getLocalAddress inconsistent on XP/2003 when IPv6 enabled and socket is connected Summary: Use family of connected IP address to retrieve desired local address of the datagram socket Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c + test/java/net/DatagramSocket/ChangingAddress.java Changeset: 62e1389fdb0a Author: mullan Date: 2011-09-26 17:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/62e1389fdb0a 7088502: Security libraries don't build with javac -Werror Summary: Changes to files in src/share/classes/com/sun/org/apache/xml/internal/security and its subpackages to remove warnings Reviewed-by: mullan Contributed-by: kurchi.subhra.hazra at oracle.com ! make/com/sun/org/apache/xml/Makefile ! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizerSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/NameSpaceSymbTable.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/KeyStoreResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/SingleCertificateResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInputDebugger.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHere.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/InclusiveNamespaces.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/HelperNodeList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncBufferedOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java Changeset: 79582fcc8329 Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/79582fcc8329 7089889: Krb5LoginModule.login() throws an exception if used without a keytab Reviewed-by: xuelei, valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java + test/sun/security/krb5/auto/NoInitNoKeytab.java Changeset: 9b951304bd0a Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9b951304bd0a 7077640: gss wrap for cfx doesn't handle rrc != 0 Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/RRC.java Changeset: 8d88e694441c Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8d88e694441c 7077646: gssapi wrap for CFX per-message tokens always set FLAG_ACCEPTOR_SUBKEY Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java + test/sun/security/krb5/auto/AcceptorSubKey.java Changeset: 74f5fef1d961 Author: chegar Date: 2011-10-04 13:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/74f5fef1d961 6953455: CookieStore.add() cannot handle null URI parameter, contrary to the API Reviewed-by: chegar, mduigou Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/InMemoryCookieStore.java + test/java/net/CookieHandler/NullUriCookieTest.java Changeset: 24741fe639a8 Author: chegar Date: 2011-10-04 16:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/24741fe639a8 7095949: java/net/URLConnection/RedirectLimit.java and Redirect307Test fail intermittently Reviewed-by: alanb ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java Changeset: 2bc80ba6f4a4 Author: okutsu Date: 2011-10-05 15:13 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2bc80ba6f4a4 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11 6984762: Invalid close of file descriptor '-1' in findZoneinfoFile Reviewed-by: coffeys, ohair, naoto, peytoia ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/java/Makefile ! src/solaris/native/java/util/TimeZone_md.c Changeset: ff5e57dc1fb3 Author: chegar Date: 2011-10-06 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ff5e57dc1fb3 7090499: missing rawtypes warnings in anonymous inner class Summary: Fix anonymous inner classes with raw types currently being built in the jdk with -Werror Reviewed-by: mcimadamore, alanb ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java Changeset: b8a1d30d6c65 Author: naoto Date: 2011-10-06 17:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b8a1d30d6c65 7098394: JDK8 TL repo build fails in src/solaris/native/java/util/TimeZone_md.c Reviewed-by: chegar ! src/solaris/native/java/util/TimeZone_md.c Changeset: 2edaef22de23 Author: vinnie Date: 2011-10-07 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2edaef22de23 7094377: Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. Reviewed-by: chegar ! src/share/classes/com/sun/jndi/ldap/Connection.java + test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java Changeset: 1e89a13d9d8f Author: chegar Date: 2011-10-10 10:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1e89a13d9d8f 7098719: -Dsun.net.maxDatagramSockets and Socket constructor does not work correctly with System.gc() Reviewed-by: michaelm ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java Changeset: 2a36b8741363 Author: chegar Date: 2011-10-10 15:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2a36b8741363 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface Reviewed-by: mcimadamore ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java Changeset: dd55467dd1f2 Author: ngmr Date: 2011-10-10 14:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dd55467dd1f2 7099119: Remove unused dlinfo local variable in launcher code Reviewed-by: ohair, chegar, ngmr Contributed-by: Steve Poole ! src/solaris/bin/java_md.c Changeset: 5f336e0d4d97 Author: ngmr Date: 2011-10-10 16:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5f336e0d4d97 Merge Changeset: 5bfe2de1157b Author: chegar Date: 2011-10-11 12:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5bfe2de1157b 7099488: TwoStacksPlainSocketImpl should invoke super.create(stream), typo in fix for 7098719 Reviewed-by: coffeys ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java Changeset: ffa762153af4 Author: xuelei Date: 2011-09-28 15:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ffa762153af4 7092375: Security Libraries don't build with javac -Werror Summary: Changes to security related java and make files to remove warnings Reviewed-by: xuelei Contributed-by: kurchi.subhra.hazra at oracle.com ! make/java/security/Makefile ! make/javax/Makefile ! make/javax/others/Makefile + make/javax/security/Makefile ! make/org/ietf/jgss/Makefile ! make/sun/security/other/Makefile ! src/share/classes/java/security/Signature.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/auth/x500/X500Principal.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/CertificateParsingException.java ! src/share/classes/javax/security/cert/X509Certificate.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/smartcardio/TerminalFactory.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/x509/X509CertImpl.java Changeset: 829c3a8d23fa Author: naoto Date: 2011-10-12 12:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/829c3a8d23fa 7027061: Testcase failure: java/util/Locale/Bug6989440.java - java.util.ConcurrentModificationException Reviewed-by: dholmes, chegar ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! test/java/util/Locale/Bug6989440.java Changeset: eac5d48a6c8e Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/eac5d48a6c8e Merge Changeset: 4788745572ef Author: lana Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4788745572ef Merge Changeset: 7ab0d613cd1a Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7ab0d613cd1a Added tag jdk8-b10 for changeset 4788745572ef ! .hgtags From tom.rodriguez at oracle.com Sun Oct 23 12:22:34 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Sun, 23 Oct 2011 12:22:34 -0700 Subject: review for 7103784: enable some flags by default In-Reply-To: <4EA21F3C.6040103@oracle.com> References: <021FDB54-76F5-43B0-9DAD-47F08C64C773@oracle.com> <4EA21F3C.6040103@oracle.com> Message-ID: <0620E9DF-C247-40A2-98D4-436D05F5C63F@oracle.com> On Oct 21, 2011, at 6:41 PM, Vladimir Kozlov wrote: > What about EliminateAutoBox and OptimizeFill? Should we remove corresponding AggressiveOpts code in arguments.cpp? I added OptimizeFill to this webrev and removed the code to turn it on from arguments.cpp. I filed a bug a while to turn on EliminateAutoBox but I also wanted to move some code out from under that flag that wasn't strictly part of that functionality. That's http://cr.openjdk.java.net/~never/6934604. I'd like to push that after we see how the nightlies look after turning on the others. tom > > Thanks, > Vladimir > > On 10/21/11 6:10 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7103784 >> 3 lines changed: 0 ins; 0 del; 3 mod; 4396 unchg >> >> 7103784: enable some flags by default >> Reviewed-by: >> >> Enable UseCodeCacheFlushing, UseRDPCForConstantTableBase and >> OptimizeStringConcat by default. UseCodeCacheFlushing and >> OptimizeStringConcat are tested by various settings in our nightlies >> so there should only be minor issues. UseRDPCForConstantTableBase has >> been tested and was only off because the performance was unclear but >> we believe it performs well on newer hardware. >> From vladimir.kozlov at oracle.com Sun Oct 23 15:01:18 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 23 Oct 2011 15:01:18 -0700 Subject: review for 7103784: enable some flags by default In-Reply-To: <0620E9DF-C247-40A2-98D4-436D05F5C63F@oracle.com> References: <021FDB54-76F5-43B0-9DAD-47F08C64C773@oracle.com> <4EA21F3C.6040103@oracle.com> <0620E9DF-C247-40A2-98D4-436D05F5C63F@oracle.com> Message-ID: <4EA48EAE.4010404@oracle.com> On 10/23/11 12:22 PM, Tom Rodriguez wrote: > > On Oct 21, 2011, at 6:41 PM, Vladimir Kozlov wrote: > >> What about EliminateAutoBox and OptimizeFill? Should we remove corresponding AggressiveOpts code in arguments.cpp? > > I added OptimizeFill to this webrev and removed the code to turn it on from arguments.cpp. Looks good. Could you, please, also remove EA code from arguments.cpp since it is ON by default for long time already. > > I filed a bug a while to turn on EliminateAutoBox but I also wanted to move some code out from under that flag that wasn't strictly part of that functionality. That's http://cr.openjdk.java.net/~never/6934604. I'd like to push that after we see how the nightlies look after turning on the others. I agree to push EAB after this push. Changes looks good. Thanks, Vladimir > > tom > >> >> Thanks, >> Vladimir >> >> On 10/21/11 6:10 PM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7103784 >>> 3 lines changed: 0 ins; 0 del; 3 mod; 4396 unchg >>> >>> 7103784: enable some flags by default >>> Reviewed-by: >>> >>> Enable UseCodeCacheFlushing, UseRDPCForConstantTableBase and >>> OptimizeStringConcat by default. UseCodeCacheFlushing and >>> OptimizeStringConcat are tested by various settings in our nightlies >>> so there should only be minor issues. UseRDPCForConstantTableBase has >>> been tested and was only off because the performance was unclear but >>> we believe it performs well on newer hardware. >>> > From tom.rodriguez at oracle.com Sun Oct 23 23:17:48 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Mon, 24 Oct 2011 06:17:48 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7103784: enable some flags by default Message-ID: <20111024061751.C9101470EC@hg.openjdk.java.net> Changeset: 5bda8dae4e14 Author: never Date: 2011-10-23 20:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5bda8dae4e14 7103784: enable some flags by default Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From christian.thalinger at oracle.com Mon Oct 24 02:13:54 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 24 Oct 2011 11:13:54 +0200 Subject: Request for reviews (XS): 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check In-Reply-To: References: <63A3CABB-5681-40F2-8F6A-A77E68F03BF2@oracle.com> <06776BDA-E4FF-467C-A886-8236096670AF@oracle.com> Message-ID: <330B588A-CDDE-4375-8E81-2A6A1F3786D7@oracle.com> I just remembered that there's also some code in Unsafe: http://cr.openjdk.java.net/~twisti/7094138/src/share/vm/prims/unsafe.cpp.udiff.html I really need to get 7087357 in... -- Chris On Oct 21, 2011, at 8:30 PM, Christian Thalinger wrote: > > On Oct 21, 2011, at 8:20 PM, Tom Rodriguez wrote: > >> Looks good. We should see if we can get this into 7u2. > > Yes, I agree. -- Chris > >> >> tom >> >> On Oct 21, 2011, at 2:17 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7094138/ >>> >>> 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check >>> Reviewed-by: >>> >>> InterpreterRuntime::resolve_get_put and >>> MHN_setCallSiteTargetNormal/MHN_setCallSiteTargetVolatile are calling >>> Universe::flush_dependents_on under the Compile_lock to make sure the >>> CallSite target values don't change during a compile in flight. But >>> both arguments for call_site and target are not held in a Handle but a >>> plain oop. This can result in stale oops. >>> >>> Tested with JRuby test_respond_to.rb. >>> >>> src/share/vm/interpreter/interpreterRuntime.cpp >>> src/share/vm/prims/methodHandles.cpp >>> >> > From tom.rodriguez at oracle.com Mon Oct 24 05:00:16 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Mon, 24 Oct 2011 12:00:16 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20111024120023.9B397470F4@hg.openjdk.java.net> Changeset: 754110e02bd5 Author: never Date: 2011-10-23 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/754110e02bd5 7103380: assertion failure with -XX:+PrintNativeNMethods Reviewed-by: kvn, iveresov ! src/share/vm/asm/codeBuffer.cpp Changeset: 42783d1414b2 Author: never Date: 2011-10-23 23:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/42783d1414b2 Merge - make/templates/bsd-header From christian.thalinger at oracle.com Mon Oct 24 05:52:34 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 24 Oct 2011 14:52:34 +0200 Subject: Request for review (M): 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely In-Reply-To: References: <3D22FEEA-2AF5-4007-A600-26337B6C1685@oracle.com> <508D8A9E-BBA5-4595-88AE-F4BB9D8CA205@oracle.com> <4729339B-97EF-435A-91D6-B8F0175388A4@oracle.com> Message-ID: On Oct 21, 2011, at 8:18 PM, Tom Rodriguez wrote: > > On Oct 21, 2011, at 1:22 AM, Christian Thalinger wrote: > >> >> On Oct 20, 2011, at 6:52 PM, Tom Rodriguez wrote: >> >>> >>> On Oct 20, 2011, at 5:32 AM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/7102657/ >>>> >>>> 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely >>>> Reviewed-by: >>>> >>>> The current logic for invokedynamic in LIRGenerator::do_Invoke doesn't >>>> actually initiate a deoptimization. We need some new logic to do >>>> that. >>> >>> c1_Runtime.cpp: >>> >>> This comment isn't true: >>> >>> + // It's possible the nmethod was invalidated in the last >>> + // safepoint, but if it's still alive then make it not_entrant. >>> >>> You've just come from the compiled code so it's required that the caller exists. Can you change this test to an assert? >> >> Done. >> >>> >>> Also I know you copied this comment: >>> >>> + // Bypass VM_DeoptimizeFrame and deoptimize the frame directly. >>> >>> but it's no really right in any place it's used. It corresponds to the old code where you could pick how to call the deopt code. I modified it a while back so that there's only one way and that interface chooses how to call into the deoptimization code. Can you just correct it to "// Deoptimize the caller frame". >> >> I also changed the comment from where I copied it. >> >>> >>> In the stubs, you don't need to explicit logic to dispatch to the deopt blob. The normal return generated by ~StubFrame will return to the deopt blob because the deoptimize call has rewritten the return address. That's how all stubs that get deoptimized end up returning to the deopt blob. >> >> Hmm. I changed the stub to return instead of dispatching to the deopt blob and that produces wrong results with my test case. Are you sure the return address gets rewritten correctly? > > I didn't notice that you were explicitly requesting unpack_with_reexecution. That's why you need to dispatch it directly. Sorry for misleading you. It would actually work correctly if we took advantage of the reexecute bit in the PcDesc but that would require tweaking the debug info generation process for C1 since we currently don't use it. You'd have to add a should_reexecute field in CodeEmitInfo and propagate that into IRScopeDebugInfo, so that it can be picked up when actually building the PcDesc. Anyway, we can keep your original code if you want. I think it would be nice to use the reexecute bit but I'd like to postpone this to another CR. Thanks for the review. -- Chris > > tom > >> >>> >>> Otherwise it looks good. >> >> Thanks. >> >> -- Chris >> >>> >>> tom >>> >>>> >>>> src/share/vm/c1/c1_Runtime1.cpp >>>> src/share/vm/c1/c1_Runtime1.hpp >>>> src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp >>>> src/cpu/sparc/vm/c1_Runtime1_sparc.cpp >>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp >>>> src/cpu/x86/vm/c1_Runtime1_x86.cpp >>>> >>> >> > From john.coomes at oracle.com Mon Oct 24 10:53:58 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Mon, 24 Oct 2011 17:53:58 +0000 Subject: hg: hsx/hotspot-comp/langtools: 38 new changesets Message-ID: <20111024175517.E9273470FE@hg.openjdk.java.net> Changeset: 5304c2a17d4b Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5304c2a17d4b Added tag jdk8-b04 for changeset 5df63fd8fa64 ! .hgtags Changeset: 4e754e4b0a52 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4e754e4b0a52 Added tag jdk8-b05 for changeset 5304c2a17d4b ! .hgtags Changeset: b86277584776 Author: mcimadamore Date: 2011-08-31 16:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b86277584776 7085024: internal error; cannot instantiate Foo Summary: Types.isConvertible does not handle erroneous types correctly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/7085024/T7085024.java + test/tools/javac/7085024/T7085024.out Changeset: d0257833498e Author: mcimadamore Date: 2011-08-31 16:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d0257833498e 7079713: javac hangs when compiling a class that references a cyclically inherited class Summary: Types.membersClosure needs to handle pathological cases of cyclic inheritance Reviewed-by: jjg, jjh ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/7079713/TestCircularClassfile.java Changeset: f85d980faaf8 Author: jjg Date: 2011-08-31 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f85d980faaf8 7074416: Regression: JSR199: javac doesn't unwrap clientcodewrapper objects Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/javax/tools/JavaCompiler.java ! test/tools/javac/TryWithResources/UnusedResourcesTest.java ! test/tools/javac/diags/Example.java ! test/tools/javac/processing/errors/TestSuppression.java Changeset: 04f983e3e825 Author: ksrini Date: 2011-09-01 09:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/04f983e3e825 7073631: (javac) javac parser improvements for error position reporting Summary: JavacParser improvements for NetBeans, improved by LangTools. Reviewed-by: mcimadamore, jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! test/tools/javac/TryWithResources/BadTwr.out ! test/tools/javac/TryWithResources/DuplicateResourceDecl.out ! test/tools/javac/TryWithResources/ResourceInterface.out ! test/tools/javac/TryWithResources/TwrFlow.out ! test/tools/javac/TryWithResources/TwrLint.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/diags/examples/EmptyCharLiteral.java + test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: a45d78d26450 Author: jjh Date: 2011-09-01 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a45d78d26450 7086071: tools/javac/7079713/TestCircularClassfile.java fails on windows Summary: delete file before renaming another file to it Reviewed-by: jjg ! test/tools/javac/7079713/TestCircularClassfile.java Changeset: 02b8381781ab Author: ksrini Date: 2011-09-02 07:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/02b8381781ab 7024096: Stack trace has invalid line numbers Reviewed-by: jjg, darcy Contributed-by: bruce.chapman.nz at gmail.com ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/jvm/T7024096.java Changeset: ec27e5befa53 Author: mcimadamore Date: 2011-09-02 17:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ec27e5befa53 7086261: javac doesn't report error as expected, it only reports ClientCodeWrapper$DiagnosticSourceUnwrapper Summary: Missing override for toString() in ClientCodeUnwrapper.DiagnosticSourceUnwrapper Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java + test/tools/javac/api/7086261/T7086261.java Changeset: 1ee9f9a91e9c Author: jjg Date: 2011-09-09 17:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1ee9f9a91e9c 7073508: Regression: NullPointerException at com.sun.tools.javac.code.Lint$AugmentVisitor.augment Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/annotations/T7043371.java + test/tools/javac/annotations/T7073477.java Changeset: 9aca3534ddf4 Author: lana Date: 2011-09-10 21:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9aca3534ddf4 Merge Changeset: edd7d9bd32dd Author: jjg Date: 2011-09-12 11:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/edd7d9bd32dd 7068451: Regression: javac compiles fixed sources against previous, not current, version of generated sources Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java + test/tools/javac/file/T7068451.java Changeset: f1431cace56e Author: jjg Date: 2011-09-12 11:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f1431cace56e Merge Changeset: d2422276f9da Author: lana Date: 2011-09-19 19:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d2422276f9da Merge Changeset: 116980ecec5c Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/116980ecec5c Added tag jdk8-b06 for changeset d2422276f9da ! .hgtags Changeset: 9268bd271c6f Author: katleman Date: 2011-09-29 18:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9268bd271c6f Added tag jdk8-b07 for changeset 116980ecec5c ! .hgtags Changeset: ed338593b0b6 Author: mcimadamore Date: 2011-09-13 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ed338593b0b6 7086595: Error message bug: name of initializer is 'null' Summary: Implementation of MethodSymbol.location() should take into account static/instance initializers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/7086595/T7086595.java + test/tools/javac/7086595/T7086595.out ! test/tools/javac/Diagnostics/6860795/T6860795.out ! test/tools/javac/LocalClasses_2.out ! test/tools/javac/NestedInnerClassNames.out ! test/tools/javac/TryWithResources/BadTwr.out ! test/tools/javac/TryWithResources/DuplicateResourceDecl.out + test/tools/javac/diags/examples/AlreadyDefinedClinit.java + test/tools/javac/diags/examples/KindnameInstanceInit.java + test/tools/javac/diags/examples/KindnameStaticInit.java ! test/tools/javac/generics/6910550/T6910550d.out Changeset: f595d8bc0599 Author: mcimadamore Date: 2011-09-13 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f595d8bc0599 7003595: IncompatibleClassChangeError with unreferenced local class with subclass Summary: Compiler omits unreferenced local inner classes from the InnerClasses attribute Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/7003595/T7003595.java + test/tools/javac/7003595/T7003595b.java Changeset: 3a2200681d69 Author: mcimadamore Date: 2011-09-13 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/3a2200681d69 7086601: Error message bug: cause for method mismatch is 'null' Summary: Inference error during lub() does not set 'cause' for method resolution diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IncompatibleUpperBounds.java + test/tools/javac/generics/inference/7086601/T7086601a.java + test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/generics/inference/7086601/T7086601b.java Changeset: ca2e2b85f437 Author: mchung Date: 2011-09-13 16:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ca2e2b85f437 7090297: Remove com.sun.tools.javac.Launcher from tools.jar Reviewed-by: jjg - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: 0f3da6af9799 Author: jjg Date: 2011-09-14 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0f3da6af9799 7080267: Call to toString() from an ExpressionStatementTree doesn't take in consideration the ";" at the end Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/tree/TestToString.java Changeset: 1807fc3fd33c Author: jjg Date: 2011-09-14 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1807fc3fd33c 7090249: IllegalStateException from Trees.getScope when called from JSR 199 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + test/tools/javac/api/TestGetScope.java Changeset: a6e2c1840ea1 Author: jjg Date: 2011-09-14 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a6e2c1840ea1 7090700: fix for 7080267 breaks two tests Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/tree/JCTree.java Changeset: 826ae6a2f27d Author: jjg Date: 2011-09-14 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/826ae6a2f27d 7068437: Regression: Filer.getResource(SOURCE_OUTPUT, ...) no longer works in JDK 7 w/o -s Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java + test/tools/javac/file/T7068437.java Changeset: c0835c8489b0 Author: mcimadamore Date: 2011-09-16 14:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c0835c8489b0 7086586: Inference producing null type argument Summary: Inference should fail in 15.12.2.7 when inference variables with 'nulltype' upper bounds are found Reviewed-by: dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/generics/inference/6638712/T6638712a.out + test/tools/javac/generics/inference/7086586/T7086586.java + test/tools/javac/generics/inference/7086586/T7086586.out + test/tools/javac/generics/inference/7086586/T7086586b.java Changeset: dea82aa3ca4f Author: jjg Date: 2011-09-16 16:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/dea82aa3ca4f 7091528: javadoc attempts to parse .class files Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java + test/tools/javadoc/parser/7091528/T7091528.java + test/tools/javadoc/parser/7091528/p/C1.java + test/tools/javadoc/parser/7091528/p/q/C2.java Changeset: ac964af3b5e7 Author: jjg Date: 2011-09-20 12:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ac964af3b5e7 7030473: Remove dead field JCCompilationUnit.flags Reviewed-by: dlsmith ! src/share/classes/com/sun/tools/javac/tree/JCTree.java Changeset: b0d5f00e69f7 Author: jjg Date: 2011-09-21 21:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b0d5f00e69f7 7092965: javac should not close processorClassLoader before end of compilation Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/processing/loader/testClose/TestClose.java + test/tools/javac/processing/loader/testClose/TestClose2.java Changeset: 497571d34112 Author: jjg Date: 2011-09-22 09:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/497571d34112 7075721: javac should have public enum for exit codes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java ! test/tools/javac/lib/CompileFail.java ! test/tools/javac/util/context/T7021650.java Changeset: 0c6f79fc8441 Author: lana Date: 2011-09-23 23:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0c6f79fc8441 Merge Changeset: 28573d605b01 Author: lana Date: 2011-09-26 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/28573d605b01 Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: e8acc2d6c32f Author: lana Date: 2011-10-03 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e8acc2d6c32f Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: b7a7e47c8d3d Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b7a7e47c8d3d Added tag jdk8-b08 for changeset e8acc2d6c32f ! .hgtags Changeset: 510d09ddc861 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/510d09ddc861 Added tag jdk8-b09 for changeset b7a7e47c8d3d ! .hgtags Changeset: 47147081d5b4 Author: mcimadamore Date: 2011-10-06 18:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/47147081d5b4 7090499: missing rawtypes warnings in anonymous inner class Summary: javac does not detect raw types inside anonymous inner classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/warnings/7090499/T7090499.java + test/tools/javac/warnings/7090499/T7090499.out Changeset: 5010ffc61eda Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5010ffc61eda Merge Changeset: f6c783e18bdf Author: lana Date: 2011-10-17 19:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f6c783e18bdf Merge Changeset: 4bf01f1c4e34 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4bf01f1c4e34 Added tag jdk8-b10 for changeset f6c783e18bdf ! .hgtags From igor.veresov at oracle.com Mon Oct 24 12:34:39 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 24 Oct 2011 12:34:39 -0700 Subject: Request for reviews (XS): 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check In-Reply-To: <330B588A-CDDE-4375-8E81-2A6A1F3786D7@oracle.com> References: <63A3CABB-5681-40F2-8F6A-A77E68F03BF2@oracle.com> <06776BDA-E4FF-467C-A886-8236096670AF@oracle.com> <330B588A-CDDE-4375-8E81-2A6A1F3786D7@oracle.com> Message-ID: <496549AAA06A4467B92FDE8577694EF9@oracle.com> Good. igor On Monday, October 24, 2011 at 2:13 AM, Christian Thalinger wrote: > I just remembered that there's also some code in Unsafe: > > http://cr.openjdk.java.net/~twisti/7094138/src/share/vm/prims/unsafe.cpp.udiff.html > > I really need to get 7087357 in... > > -- Chris > > On Oct 21, 2011, at 8:30 PM, Christian Thalinger wrote: > > > > > On Oct 21, 2011, at 8:20 PM, Tom Rodriguez wrote: > > > > > Looks good. We should see if we can get this into 7u2. > > > > Yes, I agree. -- Chris > > > > > > > > tom > > > > > > On Oct 21, 2011, at 2:17 AM, Christian Thalinger wrote: > > > > > > > http://cr.openjdk.java.net/~twisti/7094138/ > > > > > > > > 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check > > > > Reviewed-by: > > > > > > > > InterpreterRuntime::resolve_get_put and > > > > MHN_setCallSiteTargetNormal/MHN_setCallSiteTargetVolatile are calling > > > > Universe::flush_dependents_on under the Compile_lock to make sure the > > > > CallSite target values don't change during a compile in flight. But > > > > both arguments for call_site and target are not held in a Handle but a > > > > plain oop. This can result in stale oops. > > > > > > > > Tested with JRuby test_respond_to.rb. > > > > > > > > src/share/vm/interpreter/interpreterRuntime.cpp > > > > src/share/vm/prims/methodHandles.cpp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111024/c5c53593/attachment.html From christian.thalinger at oracle.com Mon Oct 24 14:52:40 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 24 Oct 2011 21:52:40 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop Message-ID: <20111024215244.EDBB047105@hg.openjdk.java.net> Changeset: b20d64f83668 Author: twisti Date: 2011-10-24 07:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b20d64f83668 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop Reviewed-by: kvn, never, jrose ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp From tom.rodriguez at oracle.com Mon Oct 24 16:48:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 24 Oct 2011 16:48:32 -0700 Subject: dependencies bug Message-ID: <99A9FEDC-9E74-4F72-BA79-F304C081335A@oracle.com> While testing the metadata compiler changes in CTW I hit an assertion failure in dependencies, so this is probably a question for John. We have the following classes: public interface javasoft.sqe.tests.vm.invokeinterface.invokeinterface019.invokeinterface01901.invokeinterface01901i{ public abstract int f1(int, float); } public class javasoft.sqe.tests.vm.invokeinterface.invokeinterface019.invokeinterface01901.invokeinterface019c extends java.lang.Object implements javasoft.sqe.tests.vm.invokeinterface.invokeinterface019.invokeinterface01901.invokeinterface01901i{ public int f1(int, float); public javasoft.sqe.tests.vm.invokeinterface.invokeinterface019.invokeinterface01901.invokeinterface019c(); } public class javasoft.sqe.tests.vm.invokeinterface.invokeinterface019.invokeinterface01901.invokeinterface019d extends javasoft.sqe.tests.vm.invokeinterface.invokeinterface019.invokeinterface01901.invokeinterface019c{ public static int f1(int, float); public javasoft.sqe.tests.vm.invokeinterface.invokeinterface019.invokeinterface01901.invokeinterface019d(); } Note that the subclass has a static method with the same name and signature as the super. javac would never allow this but it's a legal class file. We've got a piece of code roughly like this: invokeinterface019c i = new invokeinterface019d(); i.f1(0, 0); We head down into CHA to bind the method f1 and call check_method_context, where it looks up the method in invokeinterface019d using just the name and signature, which returns the static method. We then assert because the methods aren't the same. check_method_context appears to be slightly sloppy about it's checking so I'm assuming it should have a guard like this: diff -r 8d6869d5ef1a src/share/vm/code/dependencies.cpp --- a/src/share/vm/code/dependencies.cpp +++ b/src/share/vm/code/dependencies.cpp @@ -795,6 +795,9 @@ if (!(lm->is_public() || lm->is_protected())) // Method is [package-]private, so the override story is complex. return true; // Must punt the assertion to true. + if (lm->is_static()) + // Static doesn't override non-static + return true; // Punt if ( !Dependencies::is_concrete_method(lm) && !Dependencies::is_concrete_method(m) && Klass::cast(lm->method_holder())->is_subtype_of(m->method_holder())) The other interesting bit is that the reason this showed up in the metadata repo is because separation of oops and metadata exposed this mistake, which was fixed: diff -r 42783d1414b2 src/share/vm/oops/constantPoolKlass.cpp --- a/src/share/vm/oops/constantPoolKlass.cpp +++ b/src/share/vm/oops/constantPoolKlass.cpp @@ -532,7 +532,7 @@ if (cp->tag_at(i).is_unresolved_klass()) { // This will force loading of the class klassOop klass = cp->klass_at(i, CHECK); - if (klass->is_instance()) { + if (klass->klass_part()->oop_is_instance()) { // Force initialization of class instanceKlass::cast(klass)->initialize(CHECK); } The previous code would never succeed because a klass is never an instance, so we weren't actually preloading any classes in the constant pool. tom From christian.thalinger at oracle.com Mon Oct 24 23:32:22 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 25 Oct 2011 08:32:22 +0200 Subject: Request for reviews (XS): 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object; )I Message-ID: http://cr.openjdk.java.net/~twisti/7101642/ 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I Reviewed-by: In some cases JSR 292 code crashes on SPARC when using TieredCompilation. But this bug is actually not related to TieredCompilation. In SharedRuntime::fixup_callers_callsite there is a bailout on method handle call sites since we cannot fixup these call sites as the executed method handle adapters are doing the required MethodHandle chain work. fixup_callers_callsite gets passed in a caller_pc which is then passed on to nmethod::is_method_handle_return. But is_method_handle_return takes a return PC. On the other architectures these two addresses are the same but on SPARC it's different (frame::pc_return_offset = 2). The fix is to adjust caller_pc by frame::pc_return_offset and pass this value (return_pc) to nmethod::is_method_handle_return. Tested with failing test case reported in the CR. src/share/vm/runtime/sharedRuntime.cpp From vladimir.kozlov at oracle.com Mon Oct 24 23:53:01 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 24 Oct 2011 23:53:01 -0700 Subject: Request for reviews (XS): 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object; )I In-Reply-To: References: Message-ID: <4EA65CCD.9020306@oracle.com> Looks good. Thanks, Vladimir On 10/24/11 11:32 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7101642/ > > 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I > Reviewed-by: > > In some cases JSR 292 code crashes on SPARC when using > TieredCompilation. But this bug is actually not related to > TieredCompilation. > > In SharedRuntime::fixup_callers_callsite there is a bailout on method > handle call sites since we cannot fixup these call sites as the > executed method handle adapters are doing the required MethodHandle > chain work. fixup_callers_callsite gets passed in a caller_pc which > is then passed on to nmethod::is_method_handle_return. But > is_method_handle_return takes a return PC. On the other architectures > these two addresses are the same but on SPARC it's different > (frame::pc_return_offset = 2). > > The fix is to adjust caller_pc by frame::pc_return_offset and pass > this value (return_pc) to nmethod::is_method_handle_return. > > Tested with failing test case reported in the CR. > > src/share/vm/runtime/sharedRuntime.cpp > From christian.thalinger at oracle.com Tue Oct 25 00:16:24 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 25 Oct 2011 09:16:24 +0200 Subject: Request for reviews (XS): 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object; )I In-Reply-To: <4EA65CCD.9020306@oracle.com> References: <4EA65CCD.9020306@oracle.com> Message-ID: Thank you, Vladimir. -- Chris On Oct 25, 2011, at 8:53 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/24/11 11:32 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7101642/ >> >> 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I >> Reviewed-by: >> >> In some cases JSR 292 code crashes on SPARC when using >> TieredCompilation. But this bug is actually not related to >> TieredCompilation. >> >> In SharedRuntime::fixup_callers_callsite there is a bailout on method >> handle call sites since we cannot fixup these call sites as the >> executed method handle adapters are doing the required MethodHandle >> chain work. fixup_callers_callsite gets passed in a caller_pc which >> is then passed on to nmethod::is_method_handle_return. But >> is_method_handle_return takes a return PC. On the other architectures >> these two addresses are the same but on SPARC it's different >> (frame::pc_return_offset = 2). >> >> The fix is to adjust caller_pc by frame::pc_return_offset and pass >> this value (return_pc) to nmethod::is_method_handle_return. >> >> Tested with failing test case reported in the CR. >> >> src/share/vm/runtime/sharedRuntime.cpp >> From igor.veresov at oracle.com Tue Oct 25 00:43:58 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 25 Oct 2011 00:43:58 -0700 Subject: Request for reviews (XS): 7101642: JSR 292: SIGSEGV in =?utf-8?Q?java.lang.invoke.MethodHandleImpl=24FieldAccessor.getFieldI(Ljava/lang/Object; _?=)I In-Reply-To: <4EA65CCD.9020306@oracle.com> References: <4EA65CCD.9020306@oracle.com> Message-ID: <094078A87C6E41DA8D4C7DA6015ADB10@oracle.com> Looks good! igor On Monday, October 24, 2011 at 11:53 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/24/11 11:32 PM, Christian Thalinger wrote: > > http://cr.openjdk.java.net/~twisti/7101642/ > > > > 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I > > Reviewed-by: > > > > In some cases JSR 292 code crashes on SPARC when using > > TieredCompilation. But this bug is actually not related to > > TieredCompilation. > > > > In SharedRuntime::fixup_callers_callsite there is a bailout on method > > handle call sites since we cannot fixup these call sites as the > > executed method handle adapters are doing the required MethodHandle > > chain work. fixup_callers_callsite gets passed in a caller_pc which > > is then passed on to nmethod::is_method_handle_return. But > > is_method_handle_return takes a return PC. On the other architectures > > these two addresses are the same but on SPARC it's different > > (frame::pc_return_offset = 2). > > > > The fix is to adjust caller_pc by frame::pc_return_offset and pass > > this value (return_pc) to nmethod::is_method_handle_return. > > > > Tested with failing test case reported in the CR. > > > > src/share/vm/runtime/sharedRuntime.cpp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111025/ae67f442/attachment-0001.html From christian.thalinger at oracle.com Tue Oct 25 00:53:40 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 25 Oct 2011 09:53:40 +0200 Subject: Request for reviews (XS): 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check In-Reply-To: <496549AAA06A4467B92FDE8577694EF9@oracle.com> References: <63A3CABB-5681-40F2-8F6A-A77E68F03BF2@oracle.com> <06776BDA-E4FF-467C-A886-8236096670AF@oracle.com> <330B588A-CDDE-4375-8E81-2A6A1F3786D7@oracle.com> <496549AAA06A4467B92FDE8577694EF9@oracle.com> Message-ID: <4FA84B6D-455A-491E-8F04-ECDB8947DF19@oracle.com> Thank you, Igor. -- Chris On Oct 24, 2011, at 9:34 PM, Igor Veresov wrote: > Good. > > igor > On Monday, October 24, 2011 at 2:13 AM, Christian Thalinger wrote: > >> I just remembered that there's also some code in Unsafe: >> >> http://cr.openjdk.java.net/~twisti/7094138/src/share/vm/prims/unsafe.cpp.udiff.html >> >> I really need to get 7087357 in... >> >> -- Chris >> >> On Oct 21, 2011, at 8:30 PM, Christian Thalinger wrote: >> >>> >>> On Oct 21, 2011, at 8:20 PM, Tom Rodriguez wrote: >>> >>>> Looks good. We should see if we can get this into 7u2. >>> >>> Yes, I agree. -- Chris >>> >>>> >>>> tom >>>> >>>> On Oct 21, 2011, at 2:17 AM, Christian Thalinger wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/7094138/ >>>>> >>>>> 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check >>>>> Reviewed-by: >>>>> >>>>> InterpreterRuntime::resolve_get_put and >>>>> MHN_setCallSiteTargetNormal/MHN_setCallSiteTargetVolatile are calling >>>>> Universe::flush_dependents_on under the Compile_lock to make sure the >>>>> CallSite target values don't change during a compile in flight. But >>>>> both arguments for call_site and target are not held in a Handle but a >>>>> plain oop. This can result in stale oops. >>>>> >>>>> Tested with JRuby test_respond_to.rb. >>>>> >>>>> src/share/vm/interpreter/interpreterRuntime.cpp >>>>> src/share/vm/prims/methodHandles.cpp > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111025/e20533fd/attachment.html From christian.thalinger at oracle.com Tue Oct 25 00:56:11 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 25 Oct 2011 09:56:11 +0200 Subject: =?us-ascii?Q?Re=3A_Request_for_reviews_=28XS=29=3A_7101642=3A_JS?= =?us-ascii?Q?R_292=3A_SIGSEGV_in_=3D=3Futf-8=3FQ=3Fjava=2Elang?= =?us-ascii?Q?=2Einvoke=2EMethodHandleImpl=3D24FieldAccessor=2Ege?= =?us-ascii?Q?tFieldI=28Ljava/lang/Object=3B_=5F=3F=3D=29I?= In-Reply-To: <094078A87C6E41DA8D4C7DA6015ADB10@oracle.com> References: <4EA65CCD.9020306@oracle.com> <094078A87C6E41DA8D4C7DA6015ADB10@oracle.com> Message-ID: Thank you, Igor. -- Chris On Oct 25, 2011, at 9:43 AM, Igor Veresov wrote: > Looks good! > > igor > On Monday, October 24, 2011 at 11:53 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Thanks, >> Vladimir >> >> On 10/24/11 11:32 PM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7101642/ >>> >>> 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I >>> Reviewed-by: >>> >>> In some cases JSR 292 code crashes on SPARC when using >>> TieredCompilation. But this bug is actually not related to >>> TieredCompilation. >>> >>> In SharedRuntime::fixup_callers_callsite there is a bailout on method >>> handle call sites since we cannot fixup these call sites as the >>> executed method handle adapters are doing the required MethodHandle >>> chain work. fixup_callers_callsite gets passed in a caller_pc which >>> is then passed on to nmethod::is_method_handle_return. But >>> is_method_handle_return takes a return PC. On the other architectures >>> these two addresses are the same but on SPARC it's different >>> (frame::pc_return_offset = 2). >>> >>> The fix is to adjust caller_pc by frame::pc_return_offset and pass >>> this value (return_pc) to nmethod::is_method_handle_return. >>> >>> Tested with failing test case reported in the CR. >>> >>> src/share/vm/runtime/sharedRuntime.cpp > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111025/bef53f59/attachment.html From john.r.rose at oracle.com Tue Oct 25 01:01:01 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 25 Oct 2011 01:01:01 -0700 Subject: dependencies bug In-Reply-To: <99A9FEDC-9E74-4F72-BA79-F304C081335A@oracle.com> References: <99A9FEDC-9E74-4F72-BA79-F304C081335A@oracle.com> Message-ID: <4FE5B38B-5DDF-40DD-A802-BFA3D258316B@oracle.com> On Oct 24, 2011, at 4:48 PM, Tom Rodriguez wrote: > Note that the subclass has a static method with the same name and signature as the super. javac would never allow this but it's a legal class file. We've got a piece of code roughly like this: > > invokeinterface019c i = new invokeinterface019d(); > i.f1(0, 0); > > We head down into CHA to bind the method f1 and call check_method_context, where it looks up the method in invokeinterface019d using just the name and signature, which returns the static method. We then assert because the methods aren't the same. check_method_context appears to be slightly sloppy about it's checking so I'm assuming it should have a guard like this: > > diff -r 8d6869d5ef1a src/share/vm/code/dependencies.cpp > --- a/src/share/vm/code/dependencies.cpp > +++ b/src/share/vm/code/dependencies.cpp > @@ -795,6 +795,9 @@ > if (!(lm->is_public() || lm->is_protected())) > // Method is [package-]private, so the override story is complex. > return true; // Must punt the assertion to true. > + if (lm->is_static()) > + // Static doesn't override non-static > + return true; // Punt > if ( !Dependencies::is_concrete_method(lm) > && !Dependencies::is_concrete_method(m) > && Klass::cast(lm->method_holder())->is_subtype_of(m->method_holder())) Yes, that's a reasonable detuning of the assert. But I think it would be better if you were to make the two overloadings of Dependencies::is_concrete_method be consistent. (I think that would fix the same assertion bug.) The first occurrence of is_abstract is_concrete_method(methodOop m) was probably a typo for is_static. > The other interesting bit is that the reason this showed up in the metadata repo is because separation of oops and metadata exposed this mistake, which was fixed: > > diff -r 42783d1414b2 src/share/vm/oops/constantPoolKlass.cpp > --- a/src/share/vm/oops/constantPoolKlass.cpp > +++ b/src/share/vm/oops/constantPoolKlass.cpp > @@ -532,7 +532,7 @@ > if (cp->tag_at(i).is_unresolved_klass()) { > // This will force loading of the class > klassOop klass = cp->klass_at(i, CHECK); > - if (klass->is_instance()) { > + if (klass->klass_part()->oop_is_instance()) { > // Force initialization of class > instanceKlass::cast(klass)->initialize(CHECK); > } > > The previous code would never succeed because a klass is never an instance, so we weren't actually preloading any classes in the constant pool. Wow. That's turn-of-the-century dead code. Ancient zombies from the crypt. -- John From christian.thalinger at oracle.com Tue Oct 25 03:09:03 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 25 Oct 2011 10:09:03 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check Message-ID: <20111025100907.929D14710B@hg.openjdk.java.net> Changeset: 12d38ffcba2a Author: twisti Date: 2011-10-25 00:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/12d38ffcba2a 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check Reviewed-by: iveresov, never ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp From christian.thalinger at oracle.com Tue Oct 25 06:21:50 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 25 Oct 2011 13:21:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object; )I Message-ID: <20111025132154.5026047111@hg.openjdk.java.net> Changeset: 2ec638646e86 Author: twisti Date: 2011-10-25 04:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2ec638646e86 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I Reviewed-by: kvn, iveresov ! src/share/vm/runtime/sharedRuntime.cpp From tom.rodriguez at oracle.com Tue Oct 25 08:21:37 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 25 Oct 2011 08:21:37 -0700 Subject: dependencies bug In-Reply-To: <4FE5B38B-5DDF-40DD-A802-BFA3D258316B@oracle.com> References: <99A9FEDC-9E74-4F72-BA79-F304C081335A@oracle.com> <4FE5B38B-5DDF-40DD-A802-BFA3D258316B@oracle.com> Message-ID: On Oct 25, 2011, at 1:01 AM, John Rose wrote: > On Oct 24, 2011, at 4:48 PM, Tom Rodriguez wrote: > >> Note that the subclass has a static method with the same name and signature as the super. javac would never allow this but it's a legal class file. We've got a piece of code roughly like this: >> >> invokeinterface019c i = new invokeinterface019d(); >> i.f1(0, 0); >> >> We head down into CHA to bind the method f1 and call check_method_context, where it looks up the method in invokeinterface019d using just the name and signature, which returns the static method. We then assert because the methods aren't the same. check_method_context appears to be slightly sloppy about it's checking so I'm assuming it should have a guard like this: >> >> diff -r 8d6869d5ef1a src/share/vm/code/dependencies.cpp >> --- a/src/share/vm/code/dependencies.cpp >> +++ b/src/share/vm/code/dependencies.cpp >> @@ -795,6 +795,9 @@ >> if (!(lm->is_public() || lm->is_protected())) >> // Method is [package-]private, so the override story is complex. >> return true; // Must punt the assertion to true. >> + if (lm->is_static()) >> + // Static doesn't override non-static >> + return true; // Punt >> if ( !Dependencies::is_concrete_method(lm) >> && !Dependencies::is_concrete_method(m) >> && Klass::cast(lm->method_holder())->is_subtype_of(m->method_holder())) > > Yes, that's a reasonable detuning of the assert. But I think it would be better if you were to make the two overloadings of Dependencies::is_concrete_method be consistent. (I think that would fix the same assertion bug.) The first occurrence of is_abstract is_concrete_method(methodOop m) was probably a typo for is_static. That makes sense. I'll do that. Thanks! tom > >> The other interesting bit is that the reason this showed up in the metadata repo is because separation of oops and metadata exposed this mistake, which was fixed: >> >> diff -r 42783d1414b2 src/share/vm/oops/constantPoolKlass.cpp >> --- a/src/share/vm/oops/constantPoolKlass.cpp >> +++ b/src/share/vm/oops/constantPoolKlass.cpp >> @@ -532,7 +532,7 @@ >> if (cp->tag_at(i).is_unresolved_klass()) { >> // This will force loading of the class >> klassOop klass = cp->klass_at(i, CHECK); >> - if (klass->is_instance()) { >> + if (klass->klass_part()->oop_is_instance()) { >> // Force initialization of class >> instanceKlass::cast(klass)->initialize(CHECK); >> } >> >> The previous code would never succeed because a klass is never an instance, so we weren't actually preloading any classes in the constant pool. > > Wow. That's turn-of-the-century dead code. Ancient zombies from the crypt. > > -- John From vladimir.kozlov at oracle.com Tue Oct 25 10:21:31 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Oct 2011 10:21:31 -0700 Subject: Request for reviews (S): 7059039: EA: don't change non escaping state of NULL pointer Message-ID: <4EA6F01B.6000909@oracle.com> http://cr.openjdk.java.net/~kvn/7059039/webrev 7059039: EA: don't change non-escaping state of NULL pointer NULL pointers do not escape but escape state propagation may change it leading to worser results. Thanks, Vladimir From tom.rodriguez at oracle.com Tue Oct 25 10:28:55 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 25 Oct 2011 17:28:55 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc Message-ID: <20111025172901.AE70647113@hg.openjdk.java.net> Changeset: a6eef545f1a2 Author: never Date: 2011-10-25 08:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a6eef545f1a2 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc Reviewed-by: never Contributed-by: Omair Majid ! src/share/vm/opto/addnode.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/interfaceSupport.hpp From tom.rodriguez at oracle.com Tue Oct 25 11:00:39 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 25 Oct 2011 11:00:39 -0700 Subject: Request for reviews (S): 7059039: EA: don't change non escaping state of NULL pointer In-Reply-To: <4EA6F01B.6000909@oracle.com> References: <4EA6F01B.6000909@oracle.com> Message-ID: <5F0359BB-EB69-4922-BC9B-D643433B1049@oracle.com> Looks good. tom On Oct 25, 2011, at 10:21 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7059039/webrev > > 7059039: EA: don't change non-escaping state of NULL pointer > > NULL pointers do not escape but escape state propagation may change it leading to worser results. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Oct 25 11:10:05 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Oct 2011 11:10:05 -0700 Subject: Request for reviews (S): 7059039: EA: don't change non escaping state of NULL pointer In-Reply-To: <5F0359BB-EB69-4922-BC9B-D643433B1049@oracle.com> References: <4EA6F01B.6000909@oracle.com> <5F0359BB-EB69-4922-BC9B-D643433B1049@oracle.com> Message-ID: <4EA6FB7D.5000902@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 25, 2011, at 10:21 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7059039/webrev >> >> 7059039: EA: don't change non-escaping state of NULL pointer >> >> NULL pointers do not escape but escape state propagation may change it leading to worser results. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Tue Oct 25 16:36:54 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 25 Oct 2011 16:36:54 -0700 Subject: Request for reviews (S): 7097546: Optimize use of CMOVE instructions In-Reply-To: <4EA1FF06.3040906@oracle.com> References: <4EA1FF06.3040906@oracle.com> Message-ID: Looks good. tom On Oct 21, 2011, at 4:23 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7097546/webrev > > 7097546: Optimize use of CMOVE instructions > > Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Don't generated CMoveD/CmoveF: it is expensive to compute both float/double values + cmove. Note, on x86 when SSE>=2 (all modern cpus) CMoveD/CMoveF mach instructions are implemented as jmp+move. Don't generated CMove when BlockLayoutByFrequency optimization moves infrequent branch from hot path. Added Cmove mach instructions with jmp+move to x86 when there is no HW cmove instruction. > > Main part of changes in loopopts.cpp is coding style correction. > > Print size of compiled method and compilation time when PrintCompilation and PrintInlining are specified on command line. I thought first to print it with just PrintCompilation but it will double output. > > No effect on refworkload but it will help later for 6890673 fix. Verified with microbenchmark I wrote (attached to the bug report). > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Oct 25 16:36:59 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Oct 2011 16:36:59 -0700 Subject: Request for reviews (S): 7097546: Optimize use of CMOVE instructions In-Reply-To: References: <4EA1FF06.3040906@oracle.com> Message-ID: <4EA7481B.3050806@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 21, 2011, at 4:23 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7097546/webrev >> >> 7097546: Optimize use of CMOVE instructions >> >> Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Don't generated CMoveD/CmoveF: it is expensive to compute both float/double values + cmove. Note, on x86 when SSE>=2 (all modern cpus) CMoveD/CMoveF mach instructions are implemented as jmp+move. Don't generated CMove when BlockLayoutByFrequency optimization moves infrequent branch from hot path. Added Cmove mach instructions with jmp+move to x86 when there is no HW cmove instruction. >> >> Main part of changes in loopopts.cpp is coding style correction. >> >> Print size of compiled method and compilation time when PrintCompilation and PrintInlining are specified on command line. I thought first to print it with just PrintCompilation but it will double output. >> >> No effect on refworkload but it will help later for 6890673 fix. Verified with microbenchmark I wrote (attached to the bug report). >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Tue Oct 25 18:24:06 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 26 Oct 2011 01:24:06 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7059039: EA: don't change non-escaping state of NULL pointer Message-ID: <20111026012411.5A77647122@hg.openjdk.java.net> Changeset: e69a66a1457b Author: kvn Date: 2011-10-25 12:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e69a66a1457b 7059039: EA: don't change non-escaping state of NULL pointer Summary: NULL pointers do not escape but escape state propagation may change it leading to worser results. Reviewed-by: never ! src/share/vm/opto/escape.cpp From bengt.rutisson at oracle.com Wed Oct 26 06:18:10 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 26 Oct 2011 15:18:10 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Message-ID: <4EA80892.3040706@oracle.com> Hi all, Can I get a couple of reviews to this fairly small change? http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ Sorry for the wide distribution, but the bug is reported on GC, I think the actual change (in arrayOop.hpp) is runtime responsibility and the method that is being changed is used on a few occasions in C2. So, I figured I'd like everyone to know that this is about to go in. CR: 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 Background arrayOopDesc::max_array_length() returns the maximum length an array can have based on the type of the array elements. This is passed on through the allcocation path as a word size. When we need to expand the heap we have to convert the word size to a byte size. The problem is that on 32 bit platforms this conversion may overflow a size_t. Which will result in that we call expand() with a much smaller size than required size or even with a size of 0. Here is a small reproducer that will trigger the assert mentioned in the CR if we run it with -XX:+UseG1GC: public class LargeObj { public static void main(String[] args) { int[] a = new int[2147483639]; } } It is not only G1 that has this problem. ParallelGC has the same issue, it just doesn't have an assert to detect it. It can be argued that the GCs should check for overflows, but I think that since arrayOopDesc::max_array_length() will catch the problem earlier and solve it for all GCs this is a better place to fix the problem. I added some unit tests to test the new implementation. To make sure that these tests are run I had to update some more files. The actual change is in arrayOop.hpp. The rest of the files have just been changed to allow the unit tests to run. A few questions: (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that we don't overflow a size_t. This is only needed on 32 bit platforms. I prefer this general code compared to #ifndef _LP64. Any thoughts? (2) I made the unit tests run as JPRT make targets. I guess it can also be done as jtreg tests, but that way it would only be executed for PIT etc. Any thoughts on this? Thanks, Bengt From vladimir.kozlov at oracle.com Wed Oct 26 08:44:54 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Oct 2011 08:44:54 -0700 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA80892.3040706@oracle.com> References: <4EA80892.3040706@oracle.com> Message-ID: <4EA82AF6.1090809@oracle.com> Hi Bengt, I thought VM should throw OOM exception in such cases (as your example) since you can't allocate such arrays in 32-bit VM. Does the size check for OOM happened after heap resize calculation? Is SIZE_MAX defined on all platforms? You still have problem with short[] and char[] since 2*max_jint+header_size will overflow. Also max_array_length() puts unneeded limitation on double[] and long[] max length in 64 but VM, it should be max_jint. I think we can do something like next: const size_t max_words_per_size_t = align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), MinObjAlignment); const size_t max_elements_per_size_t = HeapWordSize * max_words_per_size_t / type2aelembytes(type); if ((size_t)max_jint < max_elements_per_size_t); return max_jint ; return (int32_t)max_elements_per_size_t; check_overflow() should use julong type for expressions instead of size_t to catch overflow: +bool arrayOopDesc::check_overflow(BasicType type) { + julong length = (julong)max_array_length(type); + julong bytes_per_element = (julong)type2aelembytes(type); + julong bytes = length * bytes_per_element + (julong)header_size_in_bytes(); + return (julong)(size_t)bytes == bytes; +} Rename check_overflow() to check_max_length_overflow() or something. I don't think we need incorrect old_max_array_length() method and corresponding checks for LP64. Initialization and execution of additional JPRT tests will increase jobs time. I think you could add InternalVMTests to existing client and server tests: < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version --- > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version regards, Vladimir On 10/26/11 6:18 AM, Bengt Rutisson wrote: > > Hi all, > > Can I get a couple of reviews to this fairly small change? > http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ > > Sorry for the wide distribution, but the bug is reported on GC, I think the actual change (in arrayOop.hpp) is runtime > responsibility and the method that is being changed is used on a few occasions in C2. So, I figured I'd like everyone to > know that this is about to go in. > > CR: > 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise > http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 > > Background > arrayOopDesc::max_array_length() returns the maximum length an array can have based on the type of the array elements. > This is passed on through the allcocation path as a word size. When we need to expand the heap we have to convert the > word size to a byte size. The problem is that on 32 bit platforms this conversion may overflow a size_t. Which will > result in that we call expand() with a much smaller size than required size or even with a size of 0. > > Here is a small reproducer that will trigger the assert mentioned in the CR if we run it with -XX:+UseG1GC: > > public class LargeObj { > public static void main(String[] args) { > int[] a = new int[2147483639]; > } > } > > It is not only G1 that has this problem. ParallelGC has the same issue, it just doesn't have an assert to detect it. It > can be argued that the GCs should check for overflows, but I think that since arrayOopDesc::max_array_length() will > catch the problem earlier and solve it for all GCs this is a better place to fix the problem. > > I added some unit tests to test the new implementation. To make sure that these tests are run I had to update some more > files. The actual change is in arrayOop.hpp. The rest of the files have just been changed to allow the unit tests to run. > > A few questions: > > (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that we don't overflow a size_t. This is only needed on > 32 bit platforms. I prefer this general code compared to #ifndef _LP64. Any thoughts? > > (2) I made the unit tests run as JPRT make targets. I guess it can also be done as jtreg tests, but that way it would > only be executed for PIT etc. Any thoughts on this? > > Thanks, > Bengt From vladimir.kozlov at oracle.com Wed Oct 26 09:47:23 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 26 Oct 2011 16:47:23 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7097546: Optimize use of CMOVE instructions Message-ID: <20111026164728.DE45C47135@hg.openjdk.java.net> Changeset: d8cb48376797 Author: kvn Date: 2011-10-26 06:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d8cb48376797 7097546: Optimize use of CMOVE instructions Summary: Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.hpp From tom.rodriguez at oracle.com Wed Oct 26 14:26:16 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 Oct 2011 14:26:16 -0700 Subject: review for 7105305: assert check_method_context proper context Message-ID: This may causes some other CTW issues but I will file separate bugs for those, unless they have a simple fix I can include here. http://cr.openjdk.java.net/~never/7105305 6 lines changed: 2 ins; 0 del; 4 mod; 2198 unchg 7105305: assert check_method_context proper context Reviewed-by: preload_and_initialize_all_classes intends to initialize all instanceKlasses but is using the wrong check. Fixing that exposes a bug in the dependencies where the is_concrete_method isn't checking for is_static. The fix is to make it consistent with the ciMethod variant. Tested with full CTW. From vladimir.kozlov at oracle.com Wed Oct 26 14:57:58 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Oct 2011 14:57:58 -0700 Subject: review for 7105305: assert check_method_context proper context In-Reply-To: References: Message-ID: <4EA88266.8070101@oracle.com> Looks good. I think it was typo in is_concrete_method(). Vladimir Tom Rodriguez wrote: > This may causes some other CTW issues but I will file separate bugs for those, unless they have a simple fix I can include here. > > http://cr.openjdk.java.net/~never/7105305 > 6 lines changed: 2 ins; 0 del; 4 mod; 2198 unchg > > 7105305: assert check_method_context proper context > Reviewed-by: > > preload_and_initialize_all_classes intends to initialize all > instanceKlasses but is using the wrong check. Fixing that exposes a > bug in the dependencies where the is_concrete_method isn't checking > for is_static. The fix is to make it consistent with the ciMethod > variant. Tested with full CTW. > From john.r.rose at oracle.com Wed Oct 26 15:20:05 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 26 Oct 2011 15:20:05 -0700 Subject: review for 7105305: assert check_method_context proper context In-Reply-To: References: Message-ID: On Oct 26, 2011, at 2:26 PM, Tom Rodriguez wrote: > This may causes some other CTW issues but I will file separate bugs for those, unless they have a simple fix I can include here. Good. Besides uncovering new CTW bugs, I think there's a risk in initializing CTW classes eagerly: It might cause CTW to give up on processing a class C if its referent D fails to initialize. This could reduce coverage, since perhaps C used to load and get compiled, where now D's failed initialization will cause C to be skipped. I suggest adding a print statement to the path where D's initialization fails, so we can track whether coverage gets reduced. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111026/c2dc437a/attachment.html From tom.rodriguez at oracle.com Wed Oct 26 15:45:36 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 Oct 2011 15:45:36 -0700 Subject: review for 7105305: assert check_method_context proper context In-Reply-To: References: Message-ID: <6E5F6AF4-6E53-4AE5-B928-DE8979F24E2C@oracle.com> On Oct 26, 2011, at 3:20 PM, John Rose wrote: > On Oct 26, 2011, at 2:26 PM, Tom Rodriguez wrote: > >> This may causes some other CTW issues but I will file separate bugs for those, unless they have a simple fix I can include here. > > Good. Thanks for identifying the real fix. > > Besides uncovering new CTW bugs, I think there's a risk in initializing CTW classes eagerly: It might cause CTW to give up on processing a class C if its referent D fails to initialize. This could reduce coverage, since perhaps C used to load and get compiled, where now D's failed initialization will cause C to be skipped. It doesn't work that way: constantPoolKlass::preload_and_initialize_all_classes(k->constants(), THREAD); if (HAS_PENDING_EXCEPTION) { // If something went wrong in preloading we just ignore it clear_pending_exception_if_not_oom(CHECK); tty->print_cr("Preloading failed for (%d) %s", _compile_the_world_counter, buffer); } Previously we would load the class and we might throw exceptions and that wouldn't stop compiles either. We just have more opportunities to throw exceptions that we will just ignore. tom > > I suggest adding a print statement to the path where D's initialization fails, so we can track whether coverage gets reduced. > > -- John From tom.rodriguez at oracle.com Wed Oct 26 15:46:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 Oct 2011 15:46:23 -0700 Subject: review for 7105305: assert check_method_context proper context In-Reply-To: <4EA88266.8070101@oracle.com> References: <4EA88266.8070101@oracle.com> Message-ID: <8FFB6030-8222-4DD4-8BB0-3128BCFE25CB@oracle.com> Thanks! tom On Oct 26, 2011, at 2:57 PM, Vladimir Kozlov wrote: > Looks good. I think it was typo in is_concrete_method(). > > Vladimir > > Tom Rodriguez wrote: >> This may causes some other CTW issues but I will file separate bugs for those, unless they have a simple fix I can include here. >> http://cr.openjdk.java.net/~never/7105305 >> 6 lines changed: 2 ins; 0 del; 4 mod; 2198 unchg >> 7105305: assert check_method_context proper context >> Reviewed-by: >> preload_and_initialize_all_classes intends to initialize all >> instanceKlasses but is using the wrong check. Fixing that exposes a >> bug in the dependencies where the is_concrete_method isn't checking >> for is_static. The fix is to make it consistent with the ciMethod >> variant. Tested with full CTW. From john.r.rose at oracle.com Wed Oct 26 15:52:15 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 26 Oct 2011 15:52:15 -0700 Subject: review for 7105305: assert check_method_context proper context In-Reply-To: <6E5F6AF4-6E53-4AE5-B928-DE8979F24E2C@oracle.com> References: <6E5F6AF4-6E53-4AE5-B928-DE8979F24E2C@oracle.com> Message-ID: <5C1E9DEA-5ADE-4BD4-9F1A-C3827050BEE0@oracle.com> On Oct 26, 2011, at 3:45 PM, Tom Rodriguez wrote: > Previously we would load the class and we might throw exceptions and that wouldn't stop compiles either. We just have more opportunities to throw exceptions that we will just ignore. Right; go for it. -- John From igor.veresov at oracle.com Wed Oct 26 16:24:48 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 26 Oct 2011 16:24:48 -0700 Subject: review(XXS): 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation Message-ID: C1 fills printable_bci when attaching an instruction to a basic block, but canonicalization happens before that. We need to initialize it for proper printing of the canonicalized instruction. Webrev: http://cr.openjdk.java.net/~iveresov/7104177/webrev.00/ igor From vladimir.kozlov at oracle.com Wed Oct 26 17:12:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Oct 2011 17:12:42 -0700 Subject: review(XXS): 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation In-Reply-To: References: Message-ID: <4EA8A1FA.1020509@oracle.com> Looks good. Vladimir Igor Veresov wrote: > C1 fills printable_bci when attaching an instruction to a basic block, but canonicalization happens before that. > We need to initialize it for proper printing of the canonicalized instruction. > > Webrev: http://cr.openjdk.java.net/~iveresov/7104177/webrev.00/ > > igor > From tom.rodriguez at oracle.com Wed Oct 26 17:34:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 Oct 2011 17:34:32 -0700 Subject: review(XXS): 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation In-Reply-To: References: Message-ID: Looks good. tom On Oct 26, 2011, at 4:24 PM, Igor Veresov wrote: > C1 fills printable_bci when attaching an instruction to a basic block, but canonicalization happens before that. > We need to initialize it for proper printing of the canonicalized instruction. > > Webrev: http://cr.openjdk.java.net/~iveresov/7104177/webrev.00/ > > igor > From vladimir.kozlov at oracle.com Wed Oct 26 18:00:52 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Oct 2011 18:00:52 -0700 Subject: Request for reviews (XS): 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" .... Message-ID: <4EA8AD44.1010906@oracle.com> http://cr.openjdk.java.net/~kvn/7105364/webrev 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" .... Optimized build is broken. MethodHandleChain::print() is defined only for debug builds but it is called from NOT_PRODUCT code in ciMethodHandle::print_chain_impl(). Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. Thanks, Vladimir From igor.veresov at oracle.com Wed Oct 26 18:13:26 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 26 Oct 2011 18:13:26 -0700 Subject: review(XXS): 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation In-Reply-To: References: Message-ID: <805F4019979D40FB9900034F97177B0B@oracle.com> Thanks Vladimir and Tom! igor On Wednesday, October 26, 2011 at 5:34 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 26, 2011, at 4:24 PM, Igor Veresov wrote: > > > C1 fills printable_bci when attaching an instruction to a basic block, but canonicalization happens before that. > > We need to initialize it for proper printing of the canonicalized instruction. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7104177/webrev.00/ > > > > igor From tom.rodriguez at oracle.com Wed Oct 26 18:38:40 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 Oct 2011 18:38:40 -0700 Subject: Request for reviews (XS): 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" .... In-Reply-To: <4EA8AD44.1010906@oracle.com> References: <4EA8AD44.1010906@oracle.com> Message-ID: <6A598059-3087-4AFF-935F-DA545D57233A@oracle.com> Looks good. Can you eliminate the outputStream argument too since it's not used anywhere? Thanks! tom On Oct 26, 2011, at 6:00 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7105364/webrev > > 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" .... > > Optimized build is broken. MethodHandleChain::print() is defined only for debug builds but it is called from NOT_PRODUCT code in ciMethodHandle::print_chain_impl(). > > Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. > > Thanks, > Vladimir From david.holmes at oracle.com Wed Oct 26 19:07:12 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Oct 2011 12:07:12 +1000 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA82AF6.1090809@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> Message-ID: <4EA8BCD0.5040107@oracle.com> On 27/10/2011 1:44 AM, Vladimir Kozlov wrote: > Hi Bengt, > > I thought VM should throw OOM exception in such cases (as your example) > since you can't allocate such arrays in 32-bit VM. Does the size check > for OOM happened after heap resize calculation? I was wondering something similar. We have a hard-wired maximum array size (which has fortunately grown larger and larger over time). BTW: one email to hotspot-dev might be more effective than three to hotspot-*-dev. David ----- > Is SIZE_MAX defined on all platforms? > > You still have problem with short[] and char[] since > 2*max_jint+header_size will overflow. Also max_array_length() puts > unneeded limitation on double[] and long[] max length in 64 but VM, it > should be max_jint. I think we can do something like next: > > const size_t max_words_per_size_t = > align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), > MinObjAlignment); > const size_t max_elements_per_size_t = HeapWordSize * > max_words_per_size_t / type2aelembytes(type); > if ((size_t)max_jint < max_elements_per_size_t); > return max_jint ; > return (int32_t)max_elements_per_size_t; > > > check_overflow() should use julong type for expressions instead of > size_t to catch overflow: > > +bool arrayOopDesc::check_overflow(BasicType type) { > + julong length = (julong)max_array_length(type); > + julong bytes_per_element = (julong)type2aelembytes(type); > + julong bytes = length * bytes_per_element + > (julong)header_size_in_bytes(); > + return (julong)(size_t)bytes == bytes; > +} > > Rename check_overflow() to check_max_length_overflow() or something. > > I don't think we need incorrect old_max_array_length() method and > corresponding checks for LP64. > > Initialization and execution of additional JPRT tests will increase jobs > time. I think you could add InternalVMTests to existing client and > server tests: > > < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version > --- > > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) > -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version > > regards, > Vladimir > > On 10/26/11 6:18 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I get a couple of reviews to this fairly small change? >> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >> >> Sorry for the wide distribution, but the bug is reported on GC, I >> think the actual change (in arrayOop.hpp) is runtime >> responsibility and the method that is being changed is used on a few >> occasions in C2. So, I figured I'd like everyone to >> know that this is about to go in. >> >> CR: >> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >> call this otherwise >> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >> >> Background >> arrayOopDesc::max_array_length() returns the maximum length an array >> can have based on the type of the array elements. >> This is passed on through the allcocation path as a word size. When we >> need to expand the heap we have to convert the >> word size to a byte size. The problem is that on 32 bit platforms this >> conversion may overflow a size_t. Which will >> result in that we call expand() with a much smaller size than required >> size or even with a size of 0. >> >> Here is a small reproducer that will trigger the assert mentioned in >> the CR if we run it with -XX:+UseG1GC: >> >> public class LargeObj { >> public static void main(String[] args) { >> int[] a = new int[2147483639]; >> } >> } >> >> It is not only G1 that has this problem. ParallelGC has the same >> issue, it just doesn't have an assert to detect it. It >> can be argued that the GCs should check for overflows, but I think >> that since arrayOopDesc::max_array_length() will >> catch the problem earlier and solve it for all GCs this is a better >> place to fix the problem. >> >> I added some unit tests to test the new implementation. To make sure >> that these tests are run I had to update some more >> files. The actual change is in arrayOop.hpp. The rest of the files >> have just been changed to allow the unit tests to run. >> >> A few questions: >> >> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >> we don't overflow a size_t. This is only needed on >> 32 bit platforms. I prefer this general code compared to #ifndef >> _LP64. Any thoughts? >> >> (2) I made the unit tests run as JPRT make targets. I guess it can >> also be done as jtreg tests, but that way it would >> only be executed for PIT etc. Any thoughts on this? >> >> Thanks, >> Bengt From vladimir.kozlov at oracle.com Wed Oct 26 19:20:34 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Oct 2011 19:20:34 -0700 Subject: Request for reviews (XS): 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" .... In-Reply-To: <6A598059-3087-4AFF-935F-DA545D57233A@oracle.com> References: <4EA8AD44.1010906@oracle.com> <6A598059-3087-4AFF-935F-DA545D57233A@oracle.com> Message-ID: <4EA8BFF2.3070207@oracle.com> Thank you, Tom Tom Rodriguez wrote: > Looks good. Can you eliminate the outputStream argument too since it's not used anywhere? Thanks! Done. thanks, Vladimir > > tom > > On Oct 26, 2011, at 6:00 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7105364/webrev >> >> 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" .... >> >> Optimized build is broken. MethodHandleChain::print() is defined only for debug builds but it is called from NOT_PRODUCT code in ciMethodHandle::print_chain_impl(). >> >> Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. >> >> Thanks, >> Vladimir > From christian.thalinger at oracle.com Thu Oct 27 01:01:46 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 27 Oct 2011 10:01:46 +0200 Subject: Request for reviews (XS): 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" .... In-Reply-To: <4EA8AD44.1010906@oracle.com> References: <4EA8AD44.1010906@oracle.com> Message-ID: Looks good. Thanks for fixing it. -- Chris On Oct 27, 2011, at 3:00 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7105364/webrev > > 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" .... > > Optimized build is broken. MethodHandleChain::print() is defined only for debug builds but it is called from NOT_PRODUCT code in ciMethodHandle::print_chain_impl(). > > Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. > > Thanks, > Vladimir From andreas.schoesser at sap.com Thu Oct 27 02:52:22 2011 From: andreas.schoesser at sap.com (Schoesser, Andreas) Date: Thu, 27 Oct 2011 11:52:22 +0200 Subject: AMD64: JVM crashes during uncommon_trap_blob and deopt_blob Message-ID: Hi all, we experienced crashes of the JVM during uncommon traps and deoptimization on x64. Cause: The uncommon trap and deoptimization blobs call into the VM (Deoptimization::unpack_frames) with an 8-byte aligned stack pointer. The ABI requires 16-byte alignment. In our case, the runtime eventually called the Windows API function "RtlCaptureContext". This issues an "fxsave" instruction which requires a 16-byte aligned buffer which in turn is only guaranteed if it's stack frame is 16-byte aligned. The 8-byte aligned stack frame lead to an EXCEPTION_ACCESS_VIOLATION and the JVM crashed. You can easily reproduce this when turning on "create user stack database" using the Microsoft GFlags tool on Windows x64. This will trigger "RtlCaptureContext" quite often. Running the hotspot "compiler" test suite will immediately fail. There's already a BugID for it: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636110 and the bug seems also to be known "outside" for a while: http://jpassing.com/2008/05/11/the-case-of-the-mysterious-jvm-x64-crashes/ I have a suggestion for a fix which I filed as a WebRev: http://www.sapjvm.com/asc/webrevs/unaligned_stack/webrev/ The fix aligns the stack pointer as required by x64 ABI before calling into the VM. It fixes the uncommon_trap_blob as well as the deopt_blob. Few adjustments have to be made: Since due to the aligned SP the runtime cannot easily retrieve the return PC any more we have to store it into the last java frame as well and adapt the call site's oop map accordingly. The deoptimization blob does SP-relative addressing after the runtime call, so we have to restore the unaligned SP before doing this using the stored value. Best regards, Andreas From christian.thalinger at oracle.com Thu Oct 27 04:17:34 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 27 Oct 2011 13:17:34 +0200 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: <057D94D2-C037-4EF9-92E6-E399F1DCC47D@oracle.com> References: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> <127D2E6D-2616-4BD4-AA74-F94BB781F839@oracle.com> <057D94D2-C037-4EF9-92E6-E399F1DCC47D@oracle.com> Message-ID: <33D83CD3-A55B-488E-9B8F-F17B0C58352F@oracle.com> I'm about to push the JDK changes to hsx/hotspot-main/jdk. To have some testing coverage I added a test case and I'd like to have at least one review of that: http://cr.openjdk.java.net/~twisti/7085860-jdk/ -- Chris On Sep 8, 2011, at 9:39 PM, John Rose wrote: > On Sep 8, 2011, at 9:03 AM, Tom Rodriguez wrote: > >> That looks good. One thing that occurred to me is that reading of the target field within the JVM must be done as if it were volatile, since we don't actually know what type of call site we're reading from. You could put a check in CallSite::target but I think you just always read it as volatile. I suspect the invokedynamic call site assembly also needs to do any required barriers. > > Nice catch. > > Maybe change "target" to "target_non_volatile", to emphasize the different uses of the target field. > > -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111027/416d48b8/attachment-0001.html From christian.thalinger at oracle.com Thu Oct 27 04:29:25 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 27 Oct 2011 13:29:25 +0200 Subject: Request for reviews (S): 7087357: JSR 292: remove obsolete code after 7085860 In-Reply-To: <92956E60-9E78-4C77-9435-FE1EA1A046C8@oracle.com> References: <1FF0F50A-D589-4496-95C1-8008AF89DA6D@oracle.com> <92956E60-9E78-4C77-9435-FE1EA1A046C8@oracle.com> Message-ID: <47672D85-A9EC-41B2-AA85-19386A7A7FA2@oracle.com> I forgot that we ignore exceptions when registering CallSite methods in JVM_RegisterMethodHandleMethods. This was required during the transition period. But after this change we have to fail on exceptions: http://cr.openjdk.java.net/~twisti/7087357/src/share/vm/prims/methodHandles.cpp.udiff.html -- Chris On Sep 15, 2011, at 10:12 AM, Christian Thalinger wrote: > Thank you, Tom. -- Christian > > On Sep 14, 2011, at 7:17 PM, Tom Rodriguez wrote: > >> Looks good. >> >> tom >> >> On Sep 14, 2011, at 7:00 AM, Christian Thalinger wrote: >> >>> This fix will NOT be pushed before the changes of 7085860 have been propagated to all repositories! But I want to do the review now so I can push as soon as the propagation is finished. >>> >>> http://cr.openjdk.java.net/~twisti/7087357/ >>> >>> 7087357: JSR 292: remove obsolete code after 7085860 >>> Reviewed-by: >>> >>> These changes: >>> >>> 7071653: JSR 292: call site change notification should be pushed not pulled >>> 7079673: JSR 292: C1 should inline bytecoded method handle adapters >>> 7085404: JSR 292: VolatileCallSites should have push notification too >>> >>> added code which can be removed if the JDK changes of 7085860 have >>> landed. >>> >>> src/share/vm/classfile/javaClasses.cpp >>> src/share/vm/interpreter/interpreterRuntime.cpp >>> src/share/vm/prims/unsafe.cpp >>> >> > From bengt.rutisson at oracle.com Thu Oct 27 04:44:07 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 27 Oct 2011 13:44:07 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA82AF6.1090809@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> Message-ID: <4EA94407.6080709@oracle.com> Hi Vladimir, Thanks for looking at this change! On 2011-10-26 17:44, Vladimir Kozlov wrote: > Hi Bengt, > > I thought VM should throw OOM exception in such cases (as your > example) since you can't allocate such arrays in 32-bit VM. Does the > size check for OOM happened after heap resize calculation? You are right. The VM will throw an OOME both before and after my change. But for different reasons. With my change we will detect already in typeArrayKlass::allocate_common() that length <= max_length() and throw an OOME. Before this change we could pass that test and go on in the allocation path. This would result in a size_t overflow when we want to expand the heap. We would do a lot of extra work to expand to the wrong size. Then the allocation would fail and we would throw OOME. I think it is better to detect this early and avoid the extra work. This way the assert that G1 does (which I think makes sense) will hold. We already have the length check so I assume that this was the intention from the beginning. > Is SIZE_MAX defined on all platforms? I did try to look around the hotspot code for any uses of max size_t but I could not find it. So, I reverted to looking at standard ways of doing it. SIZE_MAX seems to be defined on all our platforms, since my code passes JPRT. And it seems to be part of the C99 standard: http://en.wikipedia.org/wiki/Size_t I thought it would be better to rely on this than for example "(size_t)-1". But I am happy to use any other define. > You still have problem with short[] and char[] since > 2*max_jint+header_size will overflow. Right. I did add some unit tests to catch this (but as you point out below those tests did not detect this overflow). Thanks for catching it. I will fix it and send out an updated webrev. > Also max_array_length() puts unneeded limitation on double[] and > long[] max length in 64 but VM, it should be max_jint. I think we can > do something like next: > > const size_t max_words_per_size_t = > align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), > MinObjAlignment); > const size_t max_elements_per_size_t = HeapWordSize * > max_words_per_size_t / type2aelembytes(type); > if ((size_t)max_jint < max_elements_per_size_t); > return max_jint ; > return (int32_t)max_elements_per_size_t; I did not intend for my change to limit anything for 64 bits. That's why I added the MIN2((size_t)max_jint, max_words_per_size_t) statement and included the old calculation in the unit tests to verify that nothing has changed on 64 bits. I can change the code as you suggest, but I would like to understand what the problem is with my code first. I think it handles 64 bits correctly. > check_overflow() should use julong type for expressions instead of > size_t to catch overflow: > > +bool arrayOopDesc::check_overflow(BasicType type) { > + julong length = (julong)max_array_length(type); > + julong bytes_per_element = (julong)type2aelembytes(type); > + julong bytes = length * bytes_per_element + > (julong)header_size_in_bytes(); > + return (julong)(size_t)bytes == bytes; > +} Right. This is why I didn't catch the problem above. Thanks. I'll fix. > Rename check_overflow() to check_max_length_overflow() or something. Done. > I don't think we need incorrect old_max_array_length() method and > corresponding checks for LP64. Ok. I'll keep it for some more testing to make sure that I don't unintentionally change anything for 64 bit. But I'll remove it before I push. > Initialization and execution of additional JPRT tests will increase > jobs time. I think you could add InternalVMTests to existing client > and server tests: > > < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version > --- > > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) > -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version > I see your point regarding the increased job times. But I think it is much clearer to have the internal unit tests as a separate target. That way they can be included and excluded with a JPRT command line. Also, I don't really like the IgnoreUnrecognizedVMOptions solution. I would like to be more explicit about that this is only a (fast)debug build flag. Thanks, Bengt > regards, > Vladimir > > On 10/26/11 6:18 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I get a couple of reviews to this fairly small change? >> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >> >> Sorry for the wide distribution, but the bug is reported on GC, I >> think the actual change (in arrayOop.hpp) is runtime >> responsibility and the method that is being changed is used on a few >> occasions in C2. So, I figured I'd like everyone to >> know that this is about to go in. >> >> CR: >> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >> call this otherwise >> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >> >> Background >> arrayOopDesc::max_array_length() returns the maximum length an array >> can have based on the type of the array elements. >> This is passed on through the allcocation path as a word size. When >> we need to expand the heap we have to convert the >> word size to a byte size. The problem is that on 32 bit platforms >> this conversion may overflow a size_t. Which will >> result in that we call expand() with a much smaller size than >> required size or even with a size of 0. >> >> Here is a small reproducer that will trigger the assert mentioned in >> the CR if we run it with -XX:+UseG1GC: >> >> public class LargeObj { >> public static void main(String[] args) { >> int[] a = new int[2147483639]; >> } >> } >> >> It is not only G1 that has this problem. ParallelGC has the same >> issue, it just doesn't have an assert to detect it. It >> can be argued that the GCs should check for overflows, but I think >> that since arrayOopDesc::max_array_length() will >> catch the problem earlier and solve it for all GCs this is a better >> place to fix the problem. >> >> I added some unit tests to test the new implementation. To make sure >> that these tests are run I had to update some more >> files. The actual change is in arrayOop.hpp. The rest of the files >> have just been changed to allow the unit tests to run. >> >> A few questions: >> >> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >> we don't overflow a size_t. This is only needed on >> 32 bit platforms. I prefer this general code compared to #ifndef >> _LP64. Any thoughts? >> >> (2) I made the unit tests run as JPRT make targets. I guess it can >> also be done as jtreg tests, but that way it would >> only be executed for PIT etc. Any thoughts on this? >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Thu Oct 27 04:47:20 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 27 Oct 2011 13:47:20 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA8BCD0.5040107@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA8BCD0.5040107@oracle.com> Message-ID: <4EA944C8.1050003@oracle.com> Hi David, On 2011-10-27 04:07, David Holmes wrote: > On 27/10/2011 1:44 AM, Vladimir Kozlov wrote: >> Hi Bengt, >> >> I thought VM should throw OOM exception in such cases (as your example) >> since you can't allocate such arrays in 32-bit VM. Does the size check >> for OOM happened after heap resize calculation? > > I was wondering something similar. We have a hard-wired maximum array > size (which has fortunately grown larger and larger over time). Was my explanation to Vladimir good enough? > BTW: one email to hotspot-dev might be more effective than three to > hotspot-*-dev. I was back and forth beteween hotspot-dev and the three specific lists. Didn't really know what would be best. I'll try hotspot-dev next time. Thanks, Bengt > > David > ----- > >> Is SIZE_MAX defined on all platforms? >> >> You still have problem with short[] and char[] since >> 2*max_jint+header_size will overflow. Also max_array_length() puts >> unneeded limitation on double[] and long[] max length in 64 but VM, it >> should be max_jint. I think we can do something like next: >> >> const size_t max_words_per_size_t = >> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >> MinObjAlignment); >> const size_t max_elements_per_size_t = HeapWordSize * >> max_words_per_size_t / type2aelembytes(type); >> if ((size_t)max_jint < max_elements_per_size_t); >> return max_jint ; >> return (int32_t)max_elements_per_size_t; >> >> >> check_overflow() should use julong type for expressions instead of >> size_t to catch overflow: >> >> +bool arrayOopDesc::check_overflow(BasicType type) { >> + julong length = (julong)max_array_length(type); >> + julong bytes_per_element = (julong)type2aelembytes(type); >> + julong bytes = length * bytes_per_element + >> (julong)header_size_in_bytes(); >> + return (julong)(size_t)bytes == bytes; >> +} >> >> Rename check_overflow() to check_max_length_overflow() or something. >> >> I don't think we need incorrect old_max_array_length() method and >> corresponding checks for LP64. >> >> Initialization and execution of additional JPRT tests will increase jobs >> time. I think you could add InternalVMTests to existing client and >> server tests: >> >> < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version >> --- >> > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) >> -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version >> >> regards, >> Vladimir >> >> On 10/26/11 6:18 AM, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Can I get a couple of reviews to this fairly small change? >>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >>> >>> Sorry for the wide distribution, but the bug is reported on GC, I >>> think the actual change (in arrayOop.hpp) is runtime >>> responsibility and the method that is being changed is used on a few >>> occasions in C2. So, I figured I'd like everyone to >>> know that this is about to go in. >>> >>> CR: >>> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >>> call this otherwise >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >>> >>> Background >>> arrayOopDesc::max_array_length() returns the maximum length an array >>> can have based on the type of the array elements. >>> This is passed on through the allcocation path as a word size. When we >>> need to expand the heap we have to convert the >>> word size to a byte size. The problem is that on 32 bit platforms this >>> conversion may overflow a size_t. Which will >>> result in that we call expand() with a much smaller size than required >>> size or even with a size of 0. >>> >>> Here is a small reproducer that will trigger the assert mentioned in >>> the CR if we run it with -XX:+UseG1GC: >>> >>> public class LargeObj { >>> public static void main(String[] args) { >>> int[] a = new int[2147483639]; >>> } >>> } >>> >>> It is not only G1 that has this problem. ParallelGC has the same >>> issue, it just doesn't have an assert to detect it. It >>> can be argued that the GCs should check for overflows, but I think >>> that since arrayOopDesc::max_array_length() will >>> catch the problem earlier and solve it for all GCs this is a better >>> place to fix the problem. >>> >>> I added some unit tests to test the new implementation. To make sure >>> that these tests are run I had to update some more >>> files. The actual change is in arrayOop.hpp. The rest of the files >>> have just been changed to allow the unit tests to run. >>> >>> A few questions: >>> >>> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >>> we don't overflow a size_t. This is only needed on >>> 32 bit platforms. I prefer this general code compared to #ifndef >>> _LP64. Any thoughts? >>> >>> (2) I made the unit tests run as JPRT make targets. I guess it can >>> also be done as jtreg tests, but that way it would >>> only be executed for PIT etc. Any thoughts on this? >>> >>> Thanks, >>> Bengt From bengt.rutisson at oracle.com Thu Oct 27 05:36:23 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 27 Oct 2011 14:36:23 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA82AF6.1090809@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> Message-ID: <4EA95047.9070902@oracle.com> Hi again, Vladimir Inline... On 2011-10-26 17:44, Vladimir Kozlov wrote: > Hi Bengt, > > I thought VM should throw OOM exception in such cases (as your > example) since you can't allocate such arrays in 32-bit VM. Does the > size check for OOM happened after heap resize calculation? > > Is SIZE_MAX defined on all platforms? > > You still have problem with short[] and char[] since > 2*max_jint+header_size will overflow. Also max_array_length() puts > unneeded limitation on double[] and long[] max length in 64 but VM, it > should be max_jint. I think we can do something like next: > > const size_t max_words_per_size_t = > align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), > MinObjAlignment); > const size_t max_elements_per_size_t = HeapWordSize * > max_words_per_size_t / type2aelembytes(type); > if ((size_t)max_jint < max_elements_per_size_t); > return max_jint ; > return (int32_t)max_elements_per_size_t; I think I misunderstood this before. You mean that the whole max length calculation can be replaced by the code above. I like this, so I changed the implementation to do as you suggested. Two comments. This actually changes the implementation for 64 bits. We will always use max_jint (even for double, long, etc) where we used to use an aligned value with the header subtracted. I think this is more correct, but is is different than before. Also an alernative to your implementation would be: #ifdef _LP64 return max_jint; #endif const size_t max_words_per_size_t = align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), MinObjAlignment); const size_t max_elements_per_size_t = HeapWordSize * max_words_per_size_t / type2aelembytes(type); return (int32_t)max_elements_per_size_t; That would be a little clearer and a bit more efficient, but it looks a little awkward to have an #ifdef here. What would you prefer? Bengt > > > check_overflow() should use julong type for expressions instead of > size_t to catch overflow: > > +bool arrayOopDesc::check_overflow(BasicType type) { > + julong length = (julong)max_array_length(type); > + julong bytes_per_element = (julong)type2aelembytes(type); > + julong bytes = length * bytes_per_element + > (julong)header_size_in_bytes(); > + return (julong)(size_t)bytes == bytes; > +} > > Rename check_overflow() to check_max_length_overflow() or something. > > I don't think we need incorrect old_max_array_length() method and > corresponding checks for LP64. > > Initialization and execution of additional JPRT tests will increase > jobs time. I think you could add InternalVMTests to existing client > and server tests: > > < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version > --- > > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) > -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version > > regards, > Vladimir > > On 10/26/11 6:18 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I get a couple of reviews to this fairly small change? >> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >> >> Sorry for the wide distribution, but the bug is reported on GC, I >> think the actual change (in arrayOop.hpp) is runtime >> responsibility and the method that is being changed is used on a few >> occasions in C2. So, I figured I'd like everyone to >> know that this is about to go in. >> >> CR: >> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >> call this otherwise >> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >> >> Background >> arrayOopDesc::max_array_length() returns the maximum length an array >> can have based on the type of the array elements. >> This is passed on through the allcocation path as a word size. When >> we need to expand the heap we have to convert the >> word size to a byte size. The problem is that on 32 bit platforms >> this conversion may overflow a size_t. Which will >> result in that we call expand() with a much smaller size than >> required size or even with a size of 0. >> >> Here is a small reproducer that will trigger the assert mentioned in >> the CR if we run it with -XX:+UseG1GC: >> >> public class LargeObj { >> public static void main(String[] args) { >> int[] a = new int[2147483639]; >> } >> } >> >> It is not only G1 that has this problem. ParallelGC has the same >> issue, it just doesn't have an assert to detect it. It >> can be argued that the GCs should check for overflows, but I think >> that since arrayOopDesc::max_array_length() will >> catch the problem earlier and solve it for all GCs this is a better >> place to fix the problem. >> >> I added some unit tests to test the new implementation. To make sure >> that these tests are run I had to update some more >> files. The actual change is in arrayOop.hpp. The rest of the files >> have just been changed to allow the unit tests to run. >> >> A few questions: >> >> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >> we don't overflow a size_t. This is only needed on >> 32 bit platforms. I prefer this general code compared to #ifndef >> _LP64. Any thoughts? >> >> (2) I made the unit tests run as JPRT make targets. I guess it can >> also be done as jtreg tests, but that way it would >> only be executed for PIT etc. Any thoughts on this? >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Thu Oct 27 05:37:57 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 27 Oct 2011 14:37:57 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA94407.6080709@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA94407.6080709@oracle.com> Message-ID: <4EA950A5.5020408@oracle.com> Hi again, An updated webrev based on comments from Stefan and Vladimir http://cr.openjdk.java.net/~brutisso/7102044/webrev.02/ Bengt On 2011-10-27 13:44, Bengt Rutisson wrote: > > Hi Vladimir, > > Thanks for looking at this change! > > On 2011-10-26 17:44, Vladimir Kozlov wrote: >> Hi Bengt, >> >> I thought VM should throw OOM exception in such cases (as your >> example) since you can't allocate such arrays in 32-bit VM. Does the >> size check for OOM happened after heap resize calculation? > > You are right. The VM will throw an OOME both before and after my > change. But for different reasons. > > With my change we will detect already in > typeArrayKlass::allocate_common() that length <= max_length() and > throw an OOME. Before this change we could pass that test and go on in > the allocation path. This would result in a size_t overflow when we > want to expand the heap. We would do a lot of extra work to expand to > the wrong size. Then the allocation would fail and we would throw OOME. > > I think it is better to detect this early and avoid the extra work. > This way the assert that G1 does (which I think makes sense) will > hold. We already have the length check so I assume that this was the > intention from the beginning. > >> Is SIZE_MAX defined on all platforms? > > I did try to look around the hotspot code for any uses of max size_t > but I could not find it. So, I reverted to looking at standard ways of > doing it. SIZE_MAX seems to be defined on all our platforms, since my > code passes JPRT. And it seems to be part of the C99 standard: > > http://en.wikipedia.org/wiki/Size_t > > I thought it would be better to rely on this than for example > "(size_t)-1". But I am happy to use any other define. > >> You still have problem with short[] and char[] since >> 2*max_jint+header_size will overflow. > > Right. I did add some unit tests to catch this (but as you point out > below those tests did not detect this overflow). Thanks for catching > it. I will fix it and send out an updated webrev. > >> Also max_array_length() puts unneeded limitation on double[] and >> long[] max length in 64 but VM, it should be max_jint. I think we can >> do something like next: >> >> const size_t max_words_per_size_t = >> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >> MinObjAlignment); >> const size_t max_elements_per_size_t = HeapWordSize * >> max_words_per_size_t / type2aelembytes(type); >> if ((size_t)max_jint < max_elements_per_size_t); >> return max_jint ; >> return (int32_t)max_elements_per_size_t; > > I did not intend for my change to limit anything for 64 bits. That's > why I added the MIN2((size_t)max_jint, max_words_per_size_t) statement > and included the old calculation in the unit tests to verify that > nothing has changed on 64 bits. > > I can change the code as you suggest, but I would like to understand > what the problem is with my code first. I think it handles 64 bits > correctly. > >> check_overflow() should use julong type for expressions instead of >> size_t to catch overflow: >> >> +bool arrayOopDesc::check_overflow(BasicType type) { >> + julong length = (julong)max_array_length(type); >> + julong bytes_per_element = (julong)type2aelembytes(type); >> + julong bytes = length * bytes_per_element + >> (julong)header_size_in_bytes(); >> + return (julong)(size_t)bytes == bytes; >> +} > > Right. This is why I didn't catch the problem above. Thanks. I'll fix. > >> Rename check_overflow() to check_max_length_overflow() or something. > > Done. > >> I don't think we need incorrect old_max_array_length() method and >> corresponding checks for LP64. > > Ok. I'll keep it for some more testing to make sure that I don't > unintentionally change anything for 64 bit. But I'll remove it before > I push. > >> Initialization and execution of additional JPRT tests will increase >> jobs time. I think you could add InternalVMTests to existing client >> and server tests: >> >> < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version >> --- >> > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) >> -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version >> > > I see your point regarding the increased job times. But I think it is > much clearer to have the internal unit tests as a separate target. > That way they can be included and excluded with a JPRT command line. > > Also, I don't really like the IgnoreUnrecognizedVMOptions solution. I > would like to be more explicit about that this is only a (fast)debug > build flag. > > Thanks, > Bengt > >> regards, >> Vladimir >> >> On 10/26/11 6:18 AM, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Can I get a couple of reviews to this fairly small change? >>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >>> >>> Sorry for the wide distribution, but the bug is reported on GC, I >>> think the actual change (in arrayOop.hpp) is runtime >>> responsibility and the method that is being changed is used on a few >>> occasions in C2. So, I figured I'd like everyone to >>> know that this is about to go in. >>> >>> CR: >>> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >>> call this otherwise >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >>> >>> Background >>> arrayOopDesc::max_array_length() returns the maximum length an array >>> can have based on the type of the array elements. >>> This is passed on through the allcocation path as a word size. When >>> we need to expand the heap we have to convert the >>> word size to a byte size. The problem is that on 32 bit platforms >>> this conversion may overflow a size_t. Which will >>> result in that we call expand() with a much smaller size than >>> required size or even with a size of 0. >>> >>> Here is a small reproducer that will trigger the assert mentioned in >>> the CR if we run it with -XX:+UseG1GC: >>> >>> public class LargeObj { >>> public static void main(String[] args) { >>> int[] a = new int[2147483639]; >>> } >>> } >>> >>> It is not only G1 that has this problem. ParallelGC has the same >>> issue, it just doesn't have an assert to detect it. It >>> can be argued that the GCs should check for overflows, but I think >>> that since arrayOopDesc::max_array_length() will >>> catch the problem earlier and solve it for all GCs this is a better >>> place to fix the problem. >>> >>> I added some unit tests to test the new implementation. To make sure >>> that these tests are run I had to update some more >>> files. The actual change is in arrayOop.hpp. The rest of the files >>> have just been changed to allow the unit tests to run. >>> >>> A few questions: >>> >>> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >>> we don't overflow a size_t. This is only needed on >>> 32 bit platforms. I prefer this general code compared to #ifndef >>> _LP64. Any thoughts? >>> >>> (2) I made the unit tests run as JPRT make targets. I guess it can >>> also be done as jtreg tests, but that way it would >>> only be executed for PIT etc. Any thoughts on this? >>> >>> Thanks, >>> Bengt > From christian.thalinger at oracle.com Thu Oct 27 07:11:22 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 27 Oct 2011 14:11:22 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely Message-ID: <20111027141132.D120147169@hg.openjdk.java.net> Changeset: cec1757a0134 Author: twisti Date: 2011-10-27 04:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cec1757a0134 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely Reviewed-by: never, bdelsart ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/opto/runtime.cpp From vladimir.kozlov at oracle.com Thu Oct 27 08:13:21 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Oct 2011 08:13:21 -0700 Subject: Request for reviews (XS): 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" .... In-Reply-To: References: <4EA8AD44.1010906@oracle.com> Message-ID: <4EA97511.90905@oracle.com> Thank you, Christian Vladimir On 10/27/11 1:01 AM, Christian Thalinger wrote: > Looks good. Thanks for fixing it. -- Chris > > On Oct 27, 2011, at 3:00 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7105364/webrev >> >> 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" .... >> >> Optimized build is broken. MethodHandleChain::print() is defined only for debug builds but it is called from NOT_PRODUCT code in ciMethodHandle::print_chain_impl(). >> >> Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. >> >> Thanks, >> Vladimir > From christian.thalinger at oracle.com Thu Oct 27 10:55:49 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 27 Oct 2011 19:55:49 +0200 Subject: Request for reviews (XS): 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes Message-ID: http://cr.openjdk.java.net/~twisti/7104561/ 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes Reviewed-by: Before 7063629 Compile::shorten_branches was not used on SPARC. Now all architectures call that method and we need to take care of that fact in MachConstantNode::constant_offset when called from Compile::scratch_emit_size. From tom.rodriguez at oracle.com Thu Oct 27 11:05:18 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 27 Oct 2011 11:05:18 -0700 Subject: Request for reviews (XS): 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes In-Reply-To: References: Message-ID: <57BD2EF2-4F33-4A5E-9689-3C6BECDBFFC2@oracle.com> Looks good. Do you want to turn it on too? tom On Oct 27, 2011, at 10:55 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7104561/ > > 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes > Reviewed-by: > > Before 7063629 Compile::shorten_branches was not used on SPARC. Now > all architectures call that method and we need to take care of that > fact in MachConstantNode::constant_offset when called from > Compile::scratch_emit_size. From vladimir.kozlov at oracle.com Thu Oct 27 11:48:50 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Oct 2011 11:48:50 -0700 Subject: Request for reviews (XS): 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes In-Reply-To: References: Message-ID: <4EA9A792.8090706@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7104561/ > > 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes > Reviewed-by: > > Before 7063629 Compile::shorten_branches was not used on SPARC. Now > all architectures call that method and we need to take care of that > fact in MachConstantNode::constant_offset when called from > Compile::scratch_emit_size. From christian.thalinger at oracle.com Thu Oct 27 11:55:53 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 27 Oct 2011 20:55:53 +0200 Subject: Request for reviews (XS): 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes In-Reply-To: <57BD2EF2-4F33-4A5E-9689-3C6BECDBFFC2@oracle.com> References: <57BD2EF2-4F33-4A5E-9689-3C6BECDBFFC2@oracle.com> Message-ID: <9865C924-DCC0-4B7E-A67C-D3E56F552DB8@oracle.com> On Oct 27, 2011, at 8:05 PM, Tom Rodriguez wrote: > Looks good. Do you want to turn it on too? Yeah, good idea. -- Chris > > tom > > On Oct 27, 2011, at 10:55 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7104561/ >> >> 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes >> Reviewed-by: >> >> Before 7063629 Compile::shorten_branches was not used on SPARC. Now >> all architectures call that method and we need to take care of that >> fact in MachConstantNode::constant_offset when called from >> Compile::scratch_emit_size. > From vladimir.kozlov at oracle.com Thu Oct 27 13:58:31 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 27 Oct 2011 20:58:31 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" Message-ID: <20111027205833.0655B4717E@hg.openjdk.java.net> Changeset: e0658a9b3f87 Author: kvn Date: 2011-10-27 09:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e0658a9b3f87 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" Summary: Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. Reviewed-by: never, twisti ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp From vladimir.kozlov at oracle.com Thu Oct 27 16:49:09 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Oct 2011 16:49:09 -0700 Subject: Request for reviews (XS): 7105611: Set::print() is broken Message-ID: <4EA9EDF5.90806@oracle.com> http://cr.openjdk.java.net/~kvn/7105611/webrev 7105611: Set::print() is broken Set::print() is broken after 7013538 changes when I redesigned VectorSetI iterator. Call to VectorSet::print() hits ShouldNotCallThis() in VectorSet::iterate(). Note, Set::print() is not used in VM code, it is only used for debugging. Reimplemented class VSetI_ to restore Set::print(). Thanks, Vladimir From tom.rodriguez at oracle.com Thu Oct 27 17:23:11 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 27 Oct 2011 17:23:11 -0700 Subject: Request for reviews (XS): 7105611: Set::print() is broken In-Reply-To: <4EA9EDF5.90806@oracle.com> References: <4EA9EDF5.90806@oracle.com> Message-ID: Looks ok. tom On Oct 27, 2011, at 4:49 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7105611/webrev > > 7105611: Set::print() is broken > > Set::print() is broken after 7013538 changes when I redesigned VectorSetI iterator. Call to VectorSet::print() hits ShouldNotCallThis() in VectorSet::iterate(). Note, Set::print() is not used in VM code, it is only used for debugging. > > Reimplemented class VSetI_ to restore Set::print(). > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Oct 27 17:21:11 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Oct 2011 17:21:11 -0700 Subject: Request for reviews (XS): 7105611: Set::print() is broken In-Reply-To: References: <4EA9EDF5.90806@oracle.com> Message-ID: <4EA9F577.8090300@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks ok. > > tom > > On Oct 27, 2011, at 4:49 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7105611/webrev >> >> 7105611: Set::print() is broken >> >> Set::print() is broken after 7013538 changes when I redesigned VectorSetI iterator. Call to VectorSet::print() hits ShouldNotCallThis() in VectorSet::iterate(). Note, Set::print() is not used in VM code, it is only used for debugging. >> >> Reimplemented class VSetI_ to restore Set::print(). >> >> Thanks, >> Vladimir > From igor.veresov at oracle.com Thu Oct 27 18:23:27 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 28 Oct 2011 01:23:27 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation Message-ID: <20111028012335.CEC484718B@hg.openjdk.java.net> Changeset: 34535d2cb362 Author: iveresov Date: 2011-10-27 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/34535d2cb362 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation Summary: Initialize printable_bci of instruction when passed to Canonicalizer Reviewed-by: kvn, never ! src/share/vm/c1/c1_Canonicalizer.hpp From john.coomes at oracle.com Thu Oct 27 20:41:02 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:41:02 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b11 for changeset 1defbc57940a Message-ID: <20111028034102.5D1E147192@hg.openjdk.java.net> Changeset: 8e2104d565ba Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8e2104d565ba Added tag jdk8-b11 for changeset 1defbc57940a ! .hgtags From john.coomes at oracle.com Thu Oct 27 20:41:11 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:41:11 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b11 for changeset 0199e4fef5cc Message-ID: <20111028034113.EEEF147193@hg.openjdk.java.net> Changeset: 31d70911b712 Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/31d70911b712 Added tag jdk8-b11 for changeset 0199e4fef5cc ! .hgtags From john.coomes at oracle.com Thu Oct 27 20:41:22 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:41:22 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b11 for changeset d1b7a4f6dd20 Message-ID: <20111028034123.1D72C47194@hg.openjdk.java.net> Changeset: ca977d167697 Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/ca977d167697 Added tag jdk8-b11 for changeset d1b7a4f6dd20 ! .hgtags From john.coomes at oracle.com Thu Oct 27 20:41:32 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:41:32 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b11 for changeset a12ab897a249 Message-ID: <20111028034132.329B547195@hg.openjdk.java.net> Changeset: e6eed2ff5d5f Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/e6eed2ff5d5f Added tag jdk8-b11 for changeset a12ab897a249 ! .hgtags From john.coomes at oracle.com Thu Oct 27 20:41:43 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:41:43 +0000 Subject: hg: hsx/hotspot-comp/jdk: Added tag jdk8-b11 for changeset 7ab0d613cd1a Message-ID: <20111028034221.2988947196@hg.openjdk.java.net> Changeset: e1f4b4b4b96e Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e1f4b4b4b96e Added tag jdk8-b11 for changeset 7ab0d613cd1a ! .hgtags From john.coomes at oracle.com Thu Oct 27 20:42:31 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:42:31 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b11 for changeset 4bf01f1c4e34 Message-ID: <20111028034237.5192947197@hg.openjdk.java.net> Changeset: 8ff85191a7ac Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8ff85191a7ac Added tag jdk8-b11 for changeset 4bf01f1c4e34 ! .hgtags From vladimir.kozlov at oracle.com Thu Oct 27 21:01:12 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 28 Oct 2011 04:01:12 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7105611: Set::print() is broken Message-ID: <20111028040117.8A3B9471A8@hg.openjdk.java.net> Changeset: f350490a45fd Author: kvn Date: 2011-10-27 18:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f350490a45fd 7105611: Set::print() is broken Summary: Reimplemented class VSetI_ to restore Set::print(). Reviewed-by: never ! src/share/vm/libadt/vectset.cpp ! src/share/vm/libadt/vectset.hpp From christian.thalinger at oracle.com Fri Oct 28 02:08:00 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 28 Oct 2011 11:08:00 +0200 Subject: Request for reviews (XS): 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes In-Reply-To: <9865C924-DCC0-4B7E-A67C-D3E56F552DB8@oracle.com> References: <57BD2EF2-4F33-4A5E-9689-3C6BECDBFFC2@oracle.com> <9865C924-DCC0-4B7E-A67C-D3E56F552DB8@oracle.com> Message-ID: <59D8003A-FA82-4453-9DAA-524F3BD2D106@oracle.com> On Oct 27, 2011, at 8:55 PM, Christian Thalinger wrote: > > On Oct 27, 2011, at 8:05 PM, Tom Rodriguez wrote: > >> Looks good. Do you want to turn it on too? > > Yeah, good idea. -- Chris That would be this additional change then: http://cr.openjdk.java.net/~twisti/7104561/src/cpu/sparc/vm/vm_version_sparc.cpp.udiff.html -- Chris > >> >> tom >> >> On Oct 27, 2011, at 10:55 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7104561/ >>> >>> 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes >>> Reviewed-by: >>> >>> Before 7063629 Compile::shorten_branches was not used on SPARC. Now >>> all architectures call that method and we need to take care of that >>> fact in MachConstantNode::constant_offset when called from >>> Compile::scratch_emit_size. >> > From luchsh at linux.vnet.ibm.com Fri Oct 28 00:08:09 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 28 Oct 2011 15:08:09 +0800 Subject: JDK8 vm crash on Solaris 11 Express Message-ID: <4EAA54D9.6060601@linux.vnet.ibm.com> Hello, I got a vm crash issue from my newly built JDK8 on Solaris 11 Express 2010.11 and SolarisStudio12.2. This happens for every java program including JDK tools and demos. But it seems to be from client VM only since if I specify "-server" parameter to the Java launcher, the crash issue will disappear. Have you guys ever experienced this problem? can anybody help me on that? Here's the error message when running demo jfc/Fond2DTest. ----------------------------------------------------- # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xd0328888, pid=14921, tid=7 # # JRE version: 8.0 # Java VM: OpenJDK Client VM (23.0-b03 mixed mode solaris-x86 ) # Problematic frame: # V [libjvm.so+0x328888] Interval*LinearScan::split_child_at_op_id(Interval*,int,LIR_OpVisitState::OprMode)+0x54 # # Core dump written. Default location: /home/luchsh/jdk8/build/solaris-i586/j2sdk-image/core or core.14921 # # An error report file with more information is saved as: # /home/luchsh/jdk8/build/solaris-i586/j2sdk-image/hs_err_pid14921.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # ----------------------------------------------------------------------- Here's some lines of hs_err_pid14921.log. ----------------------------------------------------------------------- Stack: [0xb96fe000,0xb977e000], sp=0xb977d290, free space=508k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x328888] Interval*LinearScan::split_child_at_op_id(Interval*,int,LIR_OpVisitState::OprMode)+0x54 V [libjvm.so+0x328c23] void LinearScan::resolve_collect_mappings(BlockBegin*,BlockBegin*,MoveResolver&)+0xeb V [libjvm.so+0x32926d] void LinearScan::resolve_data_flow()+0x459 V [libjvm.so+0x32c984] void LinearScan::do_linear_scan()+0x94 V [libjvm.so+0x238e6e] void Compilation::emit_lir()+0x2c6 V [libjvm.so+0x2c6708] Compilation::Compilation(AbstractCompiler*,ciEnv*,ciMethod*,int,BufferBlob*)+0x46c V [libjvm.so+0x22115c] void Compiler::compile_method(ciEnv*,ciMethod*,int)+0x148 V [libjvm.so+0x21c28d] void CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc05 V [libjvm.so+0x21481c] void CompileBroker::compiler_thread_loop()+0x9dc V [libjvm.so+0x213e38] void compiler_thread_entry(JavaThread*,Thread*)+0x18 V [libjvm.so+0x1fd947] void JavaThread::thread_main_inner()+0xb3 V [libjvm.so+0x1fd88a] void JavaThread::run()+0x1c2 V [libjvm.so+0x5d4570] java_start+0x10c C [libc.so.1+0xbd673] _thrp_setup+0x9b C [libc.so.1+0xbd920] _lwp_start+0x0 Current CompileTask: C1: 4028 3 java.lang.String::hashCode (67 bytes) --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x08169800 JavaThread "Service Thread" daemon [_thread_blocked, id=8, stack(0xb96ad000,0xb96fd000)] =>0x08168000 JavaThread "C1 CompilerThread0" daemon [_thread_in_native, id=7, stack(0xb96fe000,0xb977e000)] 0x08165c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=6, stack(0xb977f000,0xb97cf000)] 0x08129c00 JavaThread "Finalizer" daemon [_thread_blocked, id=5, stack(0xcd815000,0xcd865000)] 0x08125000 JavaThread "Reference Handler" daemon [_thread_blocked, id=4, stack(0xcd866000,0xcd8b6000)] 0x08066000 JavaThread "main" [_thread_in_native, id=2, stack(0xcfe8f000,0xcfedf000)] Other Threads: 0x0811f400 VMThread [stack: 0xcd8b7000,0xcd937000] [id=3] 0x0816d400 WatcherThread [stack: 0xb962c000,0xb96ac000] [id=9] VM state:not at safepoint (normal execution) --------------------------------------- Thank you! From vladimir.kozlov at oracle.com Fri Oct 28 08:40:18 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 28 Oct 2011 08:40:18 -0700 Subject: Request for reviews (XS): 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes In-Reply-To: <59D8003A-FA82-4453-9DAA-524F3BD2D106@oracle.com> References: <57BD2EF2-4F33-4A5E-9689-3C6BECDBFFC2@oracle.com> <9865C924-DCC0-4B7E-A67C-D3E56F552DB8@oracle.com> <59D8003A-FA82-4453-9DAA-524F3BD2D106@oracle.com> Message-ID: <4EAACCE2.10004@oracle.com> Good. Thanks, Vladimir On 10/28/11 2:08 AM, Christian Thalinger wrote: > > On Oct 27, 2011, at 8:55 PM, Christian Thalinger wrote: > >> >> On Oct 27, 2011, at 8:05 PM, Tom Rodriguez wrote: >> >>> Looks good. Do you want to turn it on too? >> >> Yeah, good idea. -- Chris > > That would be this additional change then: > > http://cr.openjdk.java.net/~twisti/7104561/src/cpu/sparc/vm/vm_version_sparc.cpp.udiff.html > > -- Chris > >> >>> >>> tom >>> >>> On Oct 27, 2011, at 10:55 AM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/7104561/ >>>> >>>> 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes >>>> Reviewed-by: >>>> >>>> Before 7063629 Compile::shorten_branches was not used on SPARC. Now >>>> all architectures call that method and we need to take care of that >>>> fact in MachConstantNode::constant_offset when called from >>>> Compile::scratch_emit_size. >>> >> > From tom.rodriguez at oracle.com Fri Oct 28 10:20:21 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 28 Oct 2011 10:20:21 -0700 Subject: JDK8 vm crash on Solaris 11 Express In-Reply-To: <4EAA54D9.6060601@linux.vnet.ibm.com> References: <4EAA54D9.6060601@linux.vnet.ibm.com> Message-ID: On Oct 28, 2011, at 12:08 AM, Jonathan Lu wrote: > Hello, > > I got a vm crash issue from my newly built JDK8 on Solaris 11 Express 2010.11 and SolarisStudio12.2. This happens for every java program including JDK tools and demos. But it seems to be from client VM only since if I specify "-server" parameter to the Java launcher, the crash issue will disappear. > > Have you guys ever experienced this problem? can anybody help me on that? There's some issue building with the 12.2 tools. 7019374 was filed about this. At the time I tried building with 12.2 and didn't see a problem. CC -V reported this on the version I used: CC: Sun C++ 5.11 SunOS_i386 145731-01 2010/12/28 What does it report for your version? If it's older than that then you should try to get the latest version of the tool or just use 12.1, which is the officially supported version. tom > > Here's the error message when running demo jfc/Fond2DTest. > ----------------------------------------------------- > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0xd0328888, pid=14921, tid=7 > # > # JRE version: 8.0 > # Java VM: OpenJDK Client VM (23.0-b03 mixed mode solaris-x86 ) > # Problematic frame: > # V [libjvm.so+0x328888] Interval*LinearScan::split_child_at_op_id(Interval*,int,LIR_OpVisitState::OprMode)+0x54 > # > # Core dump written. Default location: /home/luchsh/jdk8/build/solaris-i586/j2sdk-image/core or core.14921 > # > # An error report file with more information is saved as: > # /home/luchsh/jdk8/build/solaris-i586/j2sdk-image/hs_err_pid14921.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > ----------------------------------------------------------------------- > > Here's some lines of hs_err_pid14921.log. > ----------------------------------------------------------------------- > Stack: [0xb96fe000,0xb977e000], sp=0xb977d290, free space=508k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x328888] Interval*LinearScan::split_child_at_op_id(Interval*,int,LIR_OpVisitState::OprMode)+0x54 > V [libjvm.so+0x328c23] void LinearScan::resolve_collect_mappings(BlockBegin*,BlockBegin*,MoveResolver&)+0xeb > V [libjvm.so+0x32926d] void LinearScan::resolve_data_flow()+0x459 > V [libjvm.so+0x32c984] void LinearScan::do_linear_scan()+0x94 > V [libjvm.so+0x238e6e] void Compilation::emit_lir()+0x2c6 > V [libjvm.so+0x2c6708] Compilation::Compilation(AbstractCompiler*,ciEnv*,ciMethod*,int,BufferBlob*)+0x46c > V [libjvm.so+0x22115c] void Compiler::compile_method(ciEnv*,ciMethod*,int)+0x148 > V [libjvm.so+0x21c28d] void CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc05 > V [libjvm.so+0x21481c] void CompileBroker::compiler_thread_loop()+0x9dc > V [libjvm.so+0x213e38] void compiler_thread_entry(JavaThread*,Thread*)+0x18 > V [libjvm.so+0x1fd947] void JavaThread::thread_main_inner()+0xb3 > V [libjvm.so+0x1fd88a] void JavaThread::run()+0x1c2 > V [libjvm.so+0x5d4570] java_start+0x10c > C [libc.so.1+0xbd673] _thrp_setup+0x9b > C [libc.so.1+0xbd920] _lwp_start+0x0 > > > Current CompileTask: > C1: 4028 3 java.lang.String::hashCode (67 bytes) > > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x08169800 JavaThread "Service Thread" daemon [_thread_blocked, id=8, stack(0xb96ad000,0xb96fd000)] > =>0x08168000 JavaThread "C1 CompilerThread0" daemon [_thread_in_native, id=7, stack(0xb96fe000,0xb977e000)] > 0x08165c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=6, stack(0xb977f000,0xb97cf000)] > 0x08129c00 JavaThread "Finalizer" daemon [_thread_blocked, id=5, stack(0xcd815000,0xcd865000)] > 0x08125000 JavaThread "Reference Handler" daemon [_thread_blocked, id=4, stack(0xcd866000,0xcd8b6000)] > 0x08066000 JavaThread "main" [_thread_in_native, id=2, stack(0xcfe8f000,0xcfedf000)] > > Other Threads: > 0x0811f400 VMThread [stack: 0xcd8b7000,0xcd937000] [id=3] > 0x0816d400 WatcherThread [stack: 0xb962c000,0xb96ac000] [id=9] > > VM state:not at safepoint (normal execution) > > --------------------------------------- > > > Thank you! > From tom.rodriguez at oracle.com Fri Oct 28 13:54:42 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 28 Oct 2011 13:54:42 -0700 Subject: Request for reviews (XS): 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes In-Reply-To: <59D8003A-FA82-4453-9DAA-524F3BD2D106@oracle.com> References: <57BD2EF2-4F33-4A5E-9689-3C6BECDBFFC2@oracle.com> <9865C924-DCC0-4B7E-A67C-D3E56F552DB8@oracle.com> <59D8003A-FA82-4453-9DAA-524F3BD2D106@oracle.com> Message-ID: Looks good. tom On Oct 28, 2011, at 2:08 AM, Christian Thalinger wrote: > > On Oct 27, 2011, at 8:55 PM, Christian Thalinger wrote: > >> >> On Oct 27, 2011, at 8:05 PM, Tom Rodriguez wrote: >> >>> Looks good. Do you want to turn it on too? >> >> Yeah, good idea. -- Chris > > That would be this additional change then: > > http://cr.openjdk.java.net/~twisti/7104561/src/cpu/sparc/vm/vm_version_sparc.cpp.udiff.html > > -- Chris > >> >>> >>> tom >>> >>> On Oct 27, 2011, at 10:55 AM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/7104561/ >>>> >>>> 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes >>>> Reviewed-by: >>>> >>>> Before 7063629 Compile::shorten_branches was not used on SPARC. Now >>>> all architectures call that method and we need to take care of that >>>> fact in MachConstantNode::constant_offset when called from >>>> Compile::scratch_emit_size. >>> >> > From tom.rodriguez at oracle.com Fri Oct 28 15:07:20 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 28 Oct 2011 15:07:20 -0700 Subject: AMD64: JVM crashes during uncommon_trap_blob and deopt_blob In-Reply-To: References: Message-ID: <995C578C-FEDA-4313-A2FC-B2728F4AA216@oracle.com> On Oct 27, 2011, at 2:52 AM, Schoesser, Andreas wrote: > Hi all, > > we experienced crashes of the JVM during uncommon traps and deoptimization on x64. > > Cause: The uncommon trap and deoptimization blobs call into the VM (Deoptimization::unpack_frames) with an 8-byte aligned stack pointer. The ABI requires 16-byte alignment. > In our case, the runtime eventually called the Windows API function "RtlCaptureContext". This issues an "fxsave" instruction which requires a 16-byte aligned buffer which in turn is only guaranteed if it's stack frame is 16-byte aligned. The 8-byte aligned stack frame lead to an EXCEPTION_ACCESS_VIOLATION and the JVM crashed. > > You can easily reproduce this when turning on "create user stack database" using the Microsoft GFlags tool on Windows x64. This will trigger "RtlCaptureContext" quite often. Running the hotspot "compiler" test suite will immediately fail. > > There's already a BugID for it: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636110 > > and the bug seems also to be known "outside" for a while: > http://jpassing.com/2008/05/11/the-case-of-the-mysterious-jvm-x64-crashes/ > > I have a suggestion for a fix which I filed as a WebRev: > http://www.sapjvm.com/asc/webrevs/unaligned_stack/webrev/ > > The fix aligns the stack pointer as required by x64 ABI before calling into the VM. It fixes the uncommon_trap_blob as well as the deopt_blob. Few adjustments have to be made: > Since due to the aligned SP the runtime cannot easily retrieve the return PC any more we have to store it into the last java frame as well and adapt the call site's oop map accordingly. The deoptimization blob does SP-relative addressing after the runtime call, so we have to restore the unaligned SP before doing this using the stored value. Thanks for sending this in. I think your change looks good, though the imprecision of the last_pc slightly bugs me. We could conceivably fix it up after emitting the actual call but that seems too clever for this problem. I'll take your bits and run some of our deopt tests on it and see how it looks. tom > > Best regards, > Andreas > > From tom.rodriguez at oracle.com Fri Oct 28 17:40:37 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 29 Oct 2011 00:40:37 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7103261: crash with jittester on sparc Message-ID: <20111029004045.5E119471C6@hg.openjdk.java.net> Changeset: eba044a722a4 Author: never Date: 2011-10-28 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eba044a722a4 7103261: crash with jittester on sparc Reviewed-by: iveresov, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp + test/compiler/7103261/Test7103261.java From christian.thalinger at oracle.com Mon Oct 31 03:19:01 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 31 Oct 2011 11:19:01 +0100 Subject: Request for reviews (XS): 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes In-Reply-To: References: <57BD2EF2-4F33-4A5E-9689-3C6BECDBFFC2@oracle.com> <9865C924-DCC0-4B7E-A67C-D3E56F552DB8@oracle.com> <59D8003A-FA82-4453-9DAA-524F3BD2D106@oracle.com> Message-ID: Thank you, Tom and Vladimir. -- Chris On Oct 28, 2011, at 10:54 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 28, 2011, at 2:08 AM, Christian Thalinger wrote: > >> >> On Oct 27, 2011, at 8:55 PM, Christian Thalinger wrote: >> >>> >>> On Oct 27, 2011, at 8:05 PM, Tom Rodriguez wrote: >>> >>>> Looks good. Do you want to turn it on too? >>> >>> Yeah, good idea. -- Chris >> >> That would be this additional change then: >> >> http://cr.openjdk.java.net/~twisti/7104561/src/cpu/sparc/vm/vm_version_sparc.cpp.udiff.html >> >> -- Chris >> >>> >>>> >>>> tom >>>> >>>> On Oct 27, 2011, at 10:55 AM, Christian Thalinger wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/7104561/ >>>>> >>>>> 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes >>>>> Reviewed-by: >>>>> >>>>> Before 7063629 Compile::shorten_branches was not used on SPARC. Now >>>>> all architectures call that method and we need to take care of that >>>>> fact in MachConstantNode::constant_offset when called from >>>>> Compile::scratch_emit_size. >>>> >>> >> > From christian.thalinger at oracle.com Mon Oct 31 09:00:07 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 31 Oct 2011 16:00:07 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes Message-ID: <20111031160013.92B3F471D9@hg.openjdk.java.net> Changeset: e3b0dcc327b9 Author: twisti Date: 2011-10-31 03:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e3b0dcc327b9 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes Reviewed-by: never, kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/opto/machnode.cpp From vladimir.kozlov at oracle.com Mon Oct 31 11:08:34 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 31 Oct 2011 11:08:34 -0700 Subject: Request for reviews (XXXS): 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java Message-ID: <4EAEE422.2050202@oracle.com> http://cr.openjdk.java.net/~kvn/7106907/webrev 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java Use -Xss224k instead of -Xss128k. Thanks, Vladimir From christian.thalinger at oracle.com Mon Oct 31 11:27:50 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 31 Oct 2011 19:27:50 +0100 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: <33D83CD3-A55B-488E-9B8F-F17B0C58352F@oracle.com> References: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> <127D2E6D-2616-4BD4-AA74-F94BB781F839@oracle.com> <057D94D2-C037-4EF9-92E6-E399F1DCC47D@oracle.com> <33D83CD3-A55B-488E-9B8F-F17B0C58352F@oracle.com> Message-ID: <1D80A29E-22C3-4930-A4CC-BD5DF9CAA2B6@oracle.com> Could someone have a quick look just to be sure that the test is okay? -- Chris On Oct 27, 2011, at 1:17 PM, Christian Thalinger wrote: > I'm about to push the JDK changes to hsx/hotspot-main/jdk. To have some testing coverage I added a test case and I'd like to have at least one review of that: > > http://cr.openjdk.java.net/~twisti/7085860-jdk/ > > -- Chris > > On Sep 8, 2011, at 9:39 PM, John Rose wrote: > >> On Sep 8, 2011, at 9:03 AM, Tom Rodriguez wrote: >> >>> That looks good. One thing that occurred to me is that reading of the target field within the JVM must be done as if it were volatile, since we don't actually know what type of call site we're reading from. You could put a check in CallSite::target but I think you just always read it as volatile. I suspect the invokedynamic call site assembly also needs to do any required barriers. >> >> Nice catch. >> >> Maybe change "target" to "target_non_volatile", to emphasize the different uses of the target field. >> >> -- John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111031/64d8170a/attachment.html From tom.rodriguez at oracle.com Mon Oct 31 12:03:21 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 31 Oct 2011 12:03:21 -0700 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: <1D80A29E-22C3-4930-A4CC-BD5DF9CAA2B6@oracle.com> References: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> <127D2E6D-2616-4BD4-AA74-F94BB781F839@oracle.com> <057D94D2-C037-4EF9-92E6-E399F1DCC47D@oracle.com> <33D83CD3-A55B-488E-9B8F-F17B0C58352F@oracle.com> <1D80A29E-22C3-4930-A4CC-BD5DF9CAA2B6@oracle.com> Message-ID: The test looks fine. tom On Oct 31, 2011, at 11:27 AM, Christian Thalinger wrote: > Could someone have a quick look just to be sure that the test is okay? > > -- Chris > > On Oct 27, 2011, at 1:17 PM, Christian Thalinger wrote: > >> I'm about to push the JDK changes to hsx/hotspot-main/jdk. To have some testing coverage I added a test case and I'd like to have at least one review of that: >> >> http://cr.openjdk.java.net/~twisti/7085860-jdk/ >> >> -- Chris >> >> On Sep 8, 2011, at 9:39 PM, John Rose wrote: >> >>> On Sep 8, 2011, at 9:03 AM, Tom Rodriguez wrote: >>> >>>> That looks good. One thing that occurred to me is that reading of the target field within the JVM must be done as if it were volatile, since we don't actually know what type of call site we're reading from. You could put a check in CallSite::target but I think you just always read it as volatile. I suspect the invokedynamic call site assembly also needs to do any required barriers. >>> >>> Nice catch. >>> >>> Maybe change "target" to "target_non_volatile", to emphasize the different uses of the target field. >>> >>> -- John >> > From christian.thalinger at oracle.com Mon Oct 31 12:06:56 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 31 Oct 2011 20:06:56 +0100 Subject: Request for reviews (M): 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods In-Reply-To: References: <65EFB949-B6ED-4A90-81D7-D23F46EBD03D@oracle.com> <127D2E6D-2616-4BD4-AA74-F94BB781F839@oracle.com> <057D94D2-C037-4EF9-92E6-E399F1DCC47D@oracle.com> <33D83CD3-A55B-488E-9B8F-F17B0C58352F@oracle.com> <1D80A29E-22C3-4930-A4CC-BD5DF9CAA2B6@oracle.com> Message-ID: Thank you, Tom. -- Chris On Oct 31, 2011, at 8:03 PM, Tom Rodriguez wrote: > The test looks fine. > > tom > > On Oct 31, 2011, at 11:27 AM, Christian Thalinger wrote: > >> Could someone have a quick look just to be sure that the test is okay? >> >> -- Chris >> >> On Oct 27, 2011, at 1:17 PM, Christian Thalinger wrote: >> >>> I'm about to push the JDK changes to hsx/hotspot-main/jdk. To have some testing coverage I added a test case and I'd like to have at least one review of that: >>> >>> http://cr.openjdk.java.net/~twisti/7085860-jdk/ >>> >>> -- Chris >>> >>> On Sep 8, 2011, at 9:39 PM, John Rose wrote: >>> >>>> On Sep 8, 2011, at 9:03 AM, Tom Rodriguez wrote: >>>> >>>>> That looks good. One thing that occurred to me is that reading of the target field within the JVM must be done as if it were volatile, since we don't actually know what type of call site we're reading from. You could put a check in CallSite::target but I think you just always read it as volatile. I suspect the invokedynamic call site assembly also needs to do any required barriers. >>>> >>>> Nice catch. >>>> >>>> Maybe change "target" to "target_non_volatile", to emphasize the different uses of the target field. >>>> >>>> -- John >>> >> > From tom.rodriguez at oracle.com Mon Oct 31 15:36:24 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 31 Oct 2011 15:36:24 -0700 Subject: Request for reviews (XXXS): 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java In-Reply-To: <4EAEE422.2050202@oracle.com> References: <4EAEE422.2050202@oracle.com> Message-ID: Looks good. tom On Oct 31, 2011, at 11:08 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7106907/webrev > > 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java > > Use -Xss224k instead of -Xss128k. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Mon Oct 31 15:35:56 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 31 Oct 2011 15:35:56 -0700 Subject: Request for reviews (XXXS): 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java In-Reply-To: References: <4EAEE422.2050202@oracle.com> Message-ID: <4EAF22CC.2020608@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 31, 2011, at 11:08 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7106907/webrev >> >> 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java >> >> Use -Xss224k instead of -Xss128k. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Mon Oct 31 17:25:34 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 31 Oct 2011 17:25:34 -0700 Subject: review for 7105305: assert check_method_context proper context In-Reply-To: <6E5F6AF4-6E53-4AE5-B928-DE8979F24E2C@oracle.com> References: <6E5F6AF4-6E53-4AE5-B928-DE8979F24E2C@oracle.com> Message-ID: <236817EF-6D1F-475C-A94A-8C1607949FCD@oracle.com> On Oct 26, 2011, at 3:45 PM, Tom Rodriguez wrote: > > On Oct 26, 2011, at 3:20 PM, John Rose wrote: > >> On Oct 26, 2011, at 2:26 PM, Tom Rodriguez wrote: >> >>> This may causes some other CTW issues but I will file separate bugs for those, unless they have a simple fix I can include here. >> >> Good. > > Thanks for identifying the real fix. I was reverifying the fix since I'd done my testing on something that I though was equivalent, but I realized this doesn't work. if ( !Dependencies::is_concrete_method(lm) && !Dependencies::is_concrete_method(m) && Klass::cast(lm->method_holder())->is_subtype_of(m->method_holder())) // Method m is overridden by lm, but both are non-concrete. return true; In the failing case one method is static and the other isn't so changing is_concrete_method doesn't solve the problem. I think it needs a separate guard, like so: @@ -795,6 +795,10 @@ if (!(lm->is_public() || lm->is_protected())) // Method is [package-]private, so the override story is complex. return true; // Must punt the assertion to true. + if (lm->is_static()) { + // Static methods don't override non-static so punt + return true; + } if ( !Dependencies::is_concrete_method(lm) && !Dependencies::is_concrete_method(m) && Klass::cast(lm->method_holder())->is_subtype_of(m->method_holder())) That's what I'd originally tested which is why I was reverifying John's suggested fix. It seemed trivially equivalent at first glance but the && means it doesn't work. I don't think it can be converted to || without breaking the original intent of the test. tom > >> >> Besides uncovering new CTW bugs, I think there's a risk in initializing CTW classes eagerly: It might cause CTW to give up on processing a class C if its referent D fails to initialize. This could reduce coverage, since perhaps C used to load and get compiled, where now D's failed initialization will cause C to be skipped. > > It doesn't work that way: > > constantPoolKlass::preload_and_initialize_all_classes(k->constants(), THREAD); > if (HAS_PENDING_EXCEPTION) { > // If something went wrong in preloading we just ignore it > clear_pending_exception_if_not_oom(CHECK); > tty->print_cr("Preloading failed for (%d) %s", _compile_the_world_counter, buffer); > } > > Previously we would load the class and we might throw exceptions and that wouldn't stop compiles either. We just have more opportunities to throw exceptions that we will just ignore. > > tom > >> >> I suggest adding a print statement to the path where D's initialization fails, so we can track whether coverage gets reduced. >> >> -- John > From volker.simonis at gmail.com Mon Oct 31 17:30:59 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 1 Nov 2011 01:30:59 +0100 Subject: Request for reviews (XXXS): 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java In-Reply-To: <4EAEE422.2050202@oracle.com> References: <4EAEE422.2050202@oracle.com> Message-ID: Hi Vladimir, the Test was just intended to provoke a stack overflow as fast as possible. Just out of curiosity: why did the test fail? It didn't see that the min_stack requirements changed. Is it because you run the tests on a machine with big page sizes? Otherwise the change is of course ok. Regards, Volker On Monday, October 31, 2011, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7106907/webrev > > 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java > > Use -Xss224k instead of -Xss128k. > > Thanks, > Vladimir > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111101/adfe3613/attachment.html From vladimir.kozlov at oracle.com Mon Oct 31 17:45:53 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 31 Oct 2011 17:45:53 -0700 Subject: Request for reviews (XXXS): 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java In-Reply-To: References: <4EAEE422.2050202@oracle.com> Message-ID: <4EAF4141.2000500@oracle.com> Hi Volker, It is known requirement from long time ago to have larger min stack size for 64 bit VM since it has bigger pointers: % jdk/1.6/bin/java -d64 -Xss128k -version The stack size specified is too small, Specify at least 224k Could not create the Java virtual machine. % jdk/1.6/bin/java -d64 -Xss224k -version java version "1.6.0" Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-b105, mixed mode) It was my mistake that I did not run this test with 64 bit VM when I applied your fix. Regards, Vladimir Volker Simonis wrote: > Hi Vladimir, > the Test was just intended to provoke a stack overflow as fast as possible. > Just out of curiosity: why did the test fail? It didn't see that the > min_stack requirements > changed. Is it because you run the tests on a machine with big page sizes? > > Otherwise the change is of course ok. > > Regards, > Volker > > On Monday, October 31, 2011, Vladimir Kozlov > wrote: > > http://cr.openjdk.java.net/~kvn/7106907/webrev > > > > 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java > > > > Use -Xss224k instead of -Xss128k. > > > > Thanks, > > Vladimir > > From vladimir.kozlov at oracle.com Mon Oct 31 18:11:03 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 01 Nov 2011 01:11:03 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java Message-ID: <20111101011105.81233471E9@hg.openjdk.java.net> Changeset: 71699e9d8673 Author: kvn Date: 2011-10-31 15:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/71699e9d8673 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java Summary: Use -Xss224k instead of -Xss128k. Reviewed-by: never ! test/compiler/6865265/StackOverflowBug.java From chuanshenglu at gmail.com Mon Oct 31 19:29:43 2011 From: chuanshenglu at gmail.com (Jonathan Lu) Date: Tue, 01 Nov 2011 10:29:43 +0800 Subject: JDK8 vm crash on Solaris 11 Express In-Reply-To: References: <4EAA54D9.6060601@linux.vnet.ibm.com> Message-ID: <4EAF5997.3010604@gmail.com> On 10/29/2011 01:20 AM, Tom Rodriguez wrote: > On Oct 28, 2011, at 12:08 AM, Jonathan Lu wrote: > >> Hello, >> >> I got a vm crash issue from my newly built JDK8 on Solaris 11 Express 2010.11 and SolarisStudio12.2. This happens for every java program including JDK tools and demos. But it seems to be from client VM only since if I specify "-server" parameter to the Java launcher, the crash issue will disappear. >> >> Have you guys ever experienced this problem? can anybody help me on that? > There's some issue building with the 12.2 tools. 7019374 was filed about this. At the time I tried building with 12.2 and didn't see a problem. CC -V reported this on the version I used: > > CC: Sun C++ 5.11 SunOS_i386 145731-01 2010/12/28 > > What does it report for your version? If it's older than that then you should try to get the latest version of the tool or just use 12.1, which is the officially supported version. > Hi Tom, CC -V reports this on my Solaris box CC: Sun C++ 5.11 SunOS_i386 2010/08/13 Seems older than your tools, so I think I will try version 12.1 tools to build it again. Thank you! > tom > >> Here's the error message when running demo jfc/Fond2DTest. >> ----------------------------------------------------- >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0xd0328888, pid=14921, tid=7 >> # >> # JRE version: 8.0 >> # Java VM: OpenJDK Client VM (23.0-b03 mixed mode solaris-x86 ) >> # Problematic frame: >> # V [libjvm.so+0x328888] Interval*LinearScan::split_child_at_op_id(Interval*,int,LIR_OpVisitState::OprMode)+0x54 >> # >> # Core dump written. Default location: /home/luchsh/jdk8/build/solaris-i586/j2sdk-image/core or core.14921 >> # >> # An error report file with more information is saved as: >> # /home/luchsh/jdk8/build/solaris-i586/j2sdk-image/hs_err_pid14921.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> ----------------------------------------------------------------------- >> >> Here's some lines of hs_err_pid14921.log. >> ----------------------------------------------------------------------- >> Stack: [0xb96fe000,0xb977e000], sp=0xb977d290, free space=508k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x328888] Interval*LinearScan::split_child_at_op_id(Interval*,int,LIR_OpVisitState::OprMode)+0x54 >> V [libjvm.so+0x328c23] void LinearScan::resolve_collect_mappings(BlockBegin*,BlockBegin*,MoveResolver&)+0xeb >> V [libjvm.so+0x32926d] void LinearScan::resolve_data_flow()+0x459 >> V [libjvm.so+0x32c984] void LinearScan::do_linear_scan()+0x94 >> V [libjvm.so+0x238e6e] void Compilation::emit_lir()+0x2c6 >> V [libjvm.so+0x2c6708] Compilation::Compilation(AbstractCompiler*,ciEnv*,ciMethod*,int,BufferBlob*)+0x46c >> V [libjvm.so+0x22115c] void Compiler::compile_method(ciEnv*,ciMethod*,int)+0x148 >> V [libjvm.so+0x21c28d] void CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc05 >> V [libjvm.so+0x21481c] void CompileBroker::compiler_thread_loop()+0x9dc >> V [libjvm.so+0x213e38] void compiler_thread_entry(JavaThread*,Thread*)+0x18 >> V [libjvm.so+0x1fd947] void JavaThread::thread_main_inner()+0xb3 >> V [libjvm.so+0x1fd88a] void JavaThread::run()+0x1c2 >> V [libjvm.so+0x5d4570] java_start+0x10c >> C [libc.so.1+0xbd673] _thrp_setup+0x9b >> C [libc.so.1+0xbd920] _lwp_start+0x0 >> >> >> Current CompileTask: >> C1: 4028 3 java.lang.String::hashCode (67 bytes) >> >> >> --------------- P R O C E S S --------------- >> >> Java Threads: ( => current thread ) >> 0x08169800 JavaThread "Service Thread" daemon [_thread_blocked, id=8, stack(0xb96ad000,0xb96fd000)] >> =>0x08168000 JavaThread "C1 CompilerThread0" daemon [_thread_in_native, id=7, stack(0xb96fe000,0xb977e000)] >> 0x08165c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=6, stack(0xb977f000,0xb97cf000)] >> 0x08129c00 JavaThread "Finalizer" daemon [_thread_blocked, id=5, stack(0xcd815000,0xcd865000)] >> 0x08125000 JavaThread "Reference Handler" daemon [_thread_blocked, id=4, stack(0xcd866000,0xcd8b6000)] >> 0x08066000 JavaThread "main" [_thread_in_native, id=2, stack(0xcfe8f000,0xcfedf000)] >> >> Other Threads: >> 0x0811f400 VMThread [stack: 0xcd8b7000,0xcd937000] [id=3] >> 0x0816d400 WatcherThread [stack: 0xb962c000,0xb96ac000] [id=9] >> >> VM state:not at safepoint (normal execution) >> >> --------------------------------------- >> >> >> Thank you! >>