From tom.rodriguez at oracle.com Tue Jan 3 09:43:44 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 3 Jan 2012 09:43:44 -0800 Subject: Request for reviews (L): 7125896: Eliminate nested locks In-Reply-To: <4EFE0F99.4050706@oracle.com> References: <4EFCD989.502@oracle.com> <4EFE0F99.4050706@oracle.com> Message-ID: <7BCC0C0F-A296-4903-8C61-A3078D375BA4@oracle.com> On Dec 30, 2011, at 11:23 AM, Vladimir Kozlov wrote: > Christian Thalinger wrote: >> I think the changes are good. The only thing I don't like is the raw use of _slot: >> + (BoxLockNode::boxnode(lock->box_node())->_slot == >> + BoxLockNode::boxnode(unlock->box_node())->_slot)) { > > Agree. I changed _slot (and other BoxLock fields) to private and replaced above code with new BoxLock's method call: > > BoxLockNode::same_slot(lock->box_node(), unlock->box_node()) > > I also did some methods renaming and updated webrev. The new is_nested flag is kind of weird since it's only set if it's been eliminated. It's really just a flag for the new kind of elimination, isn't it? The sequence of flag settings suggests that maybe it should be an enum instead of individual flags. + alock->set_eliminated(); + alock->clear_coarsened(); + alock->clear_nested(); Can you factor out some of the new code in macro.cpp. Each piece if fairly complex but relatively independent and breaking it up would make it clearer I think. Why can't the BoxLockNode be modified in place instead of being replaced? They are no longer shared between lock regions. Actually if sharing of them is disabled then you can always just modify them in place can't you? eliminating the cloning in ciTyepFlow could have performance implications. I assume it's rare? tom > > Thanks, > Vladimir > >> -- Chris >> On Dec 29, 2011, at 10:20 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7125896/webrev >>> >>> 7125896: Eliminate nested locks >>> >>> Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Commoning (GVN) of BoxLock nodes is switched off because nested locks elimination requires separate BoxLock node for each locked region to generated correct debug info for deoptimization. As result there could be merges (and Phi nodes) of BoxLock nodes. One such merge generated by ciTypeFlow (cloning loop head) is avoided but there could be other cases so new code is added to handle it. >>> >>> New code is under new product flag EliminateNestedLocks. >>> >>> Also added missed KILL effect for box register in fastlock and fastunlock mach nodes definitions. >>> >>> Tested with full CTW, nsk, jtreg tests, refworkload. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Tue Jan 3 11:49:02 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Jan 2012 11:49:02 -0800 Subject: Request for reviews (L): 7125896: Eliminate nested locks In-Reply-To: <7BCC0C0F-A296-4903-8C61-A3078D375BA4@oracle.com> References: <4EFCD989.502@oracle.com> <4EFE0F99.4050706@oracle.com> <7BCC0C0F-A296-4903-8C61-A3078D375BA4@oracle.com> Message-ID: <4F035BAE.2030808@oracle.com> Thank you, Tom Tom Rodriguez wrote: > > The new is_nested flag is kind of weird since it's only set if it's been eliminated. It's really just a flag for the new kind of elimination, isn't it? The sequence of flag settings suggests that maybe it should be an enum instead of individual flags. Converted to enum. > > Can you factor out some of the new code in macro.cpp. Each piece if fairly complex but relatively independent and breaking it up would make it clearer I think. I will try. > > Why can't the BoxLockNode be modified in place instead of being replaced? They are no longer shared between lock regions. Actually if sharing of them is disabled then you can always just modify them in place can't you? BoxLockNode could be merged so lock->box_node() could be PhiNode or it could be used by PhiNode. I do modify original BoxLockNode for nested case where merged cases are excluded. For eliminated by EA case I could do cloning only for merged cases but it needs additional checks so I decided to do it always. But if merged cases are very rare then cloning should be avoided for not merged BoxLock, I will check. > > eliminating the cloning in ciTyepFlow could have performance implications. I assume it's rare? I ran refworkload on x86 and SPARC, there was no change in scores. For normal loop's head cloning cases monitorenter can not be in first loop's block (there will be condition there). The case I hit was "while(true) { synchronize(o);" where there is no condition. So it is not common case. Also LockNode is Call node and we don't do much loop optimizations for loops with calls inside. Thanks, Vladimir > > tom > >> Thanks, >> Vladimir >> >>> -- Chris >>> On Dec 29, 2011, at 10:20 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7125896/webrev >>>> >>>> 7125896: Eliminate nested locks >>>> >>>> Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Commoning (GVN) of BoxLock nodes is switched off because nested locks elimination requires separate BoxLock node for each locked region to generated correct debug info for deoptimization. As result there could be merges (and Phi nodes) of BoxLock nodes. One such merge generated by ciTypeFlow (cloning loop head) is avoided but there could be other cases so new code is added to handle it. >>>> >>>> New code is under new product flag EliminateNestedLocks. >>>> >>>> Also added missed KILL effect for box register in fastlock and fastunlock mach nodes definitions. >>>> >>>> Tested with full CTW, nsk, jtreg tests, refworkload. >>>> >>>> Thanks, >>>> Vladimir > From tom.rodriguez at oracle.com Tue Jan 3 12:07:39 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 3 Jan 2012 12:07:39 -0800 Subject: Request for reviews (L): 7125896: Eliminate nested locks In-Reply-To: <4F035BAE.2030808@oracle.com> References: <4EFCD989.502@oracle.com> <4EFE0F99.4050706@oracle.com> <7BCC0C0F-A296-4903-8C61-A3078D375BA4@oracle.com> <4F035BAE.2030808@oracle.com> Message-ID: <10E67586-61B3-4AF9-9022-AF087CE5A4C0@oracle.com> On Jan 3, 2012, at 11:49 AM, Vladimir Kozlov wrote: > Thank you, Tom > > Tom Rodriguez wrote: >> The new is_nested flag is kind of weird since it's only set if it's been eliminated. It's really just a flag for the new kind of elimination, isn't it? The sequence of flag settings suggests that maybe it should be an enum instead of individual flags. > > Converted to enum. > >> Can you factor out some of the new code in macro.cpp. Each piece if fairly complex but relatively independent and breaking it up would make it clearer I think. > > I will try. > >> Why can't the BoxLockNode be modified in place instead of being replaced? They are no longer shared between lock regions. Actually if sharing of them is disabled then you can always just modify them in place can't you? > > BoxLockNode could be merged so lock->box_node() could be PhiNode or it could be used by PhiNode. Why does that happen? OSR? Does lock elimination require that the Phis be collapsed? > I do modify original BoxLockNode for nested case where merged cases are excluded. For eliminated by EA case I could do cloning only for merged cases but it needs additional checks so I decided to do it always. But if merged cases are very rare then cloning should be avoided for not merged BoxLock, I will check. At a minimum, can't the explicit iteration over all the users can be replaced with igvn.replace_node(oldbox, newbox)? The explicit iteration seems like overkill. > >> eliminating the cloning in ciTyepFlow could have performance implications. I assume it's rare? > > I ran refworkload on x86 and SPARC, there was no change in scores. For normal loop's head cloning cases monitorenter can not be in first loop's block (there will be condition there). The case I hit was "while(true) { synchronize(o);" where there is no condition. So it is not common case. Also LockNode is Call node and we don't do much loop optimizations for loops with calls inside. Ok. tom > > Thanks, > Vladimir > >> tom >>> Thanks, >>> Vladimir >>> >>>> -- Chris >>>> On Dec 29, 2011, at 10:20 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7125896/webrev >>>>> >>>>> 7125896: Eliminate nested locks >>>>> >>>>> Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Commoning (GVN) of BoxLock nodes is switched off because nested locks elimination requires separate BoxLock node for each locked region to generated correct debug info for deoptimization. As result there could be merges (and Phi nodes) of BoxLock nodes. One such merge generated by ciTypeFlow (cloning loop head) is avoided but there could be other cases so new code is added to handle it. >>>>> >>>>> New code is under new product flag EliminateNestedLocks. >>>>> >>>>> Also added missed KILL effect for box register in fastlock and fastunlock mach nodes definitions. >>>>> >>>>> Tested with full CTW, nsk, jtreg tests, refworkload. >>>>> >>>>> Thanks, >>>>> Vladimir From tom.rodriguez at oracle.com Tue Jan 3 12:19:50 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 3 Jan 2012 12:19:50 -0800 Subject: Crash in C2 with 7u2b13 In-Reply-To: References: Message-ID: <6AE9CE8B-1787-480B-B0DC-1CDFF139A36E@oracle.com> On Dec 31, 2011, at 12:10 PM, Charles Oliver Nutter wrote: > Got this report from a JRuby user, so I figured I'd toss it on this > list and see if I should report it (or if one of you want to look into > it directly): > > http://jira.codehaus.org/browse/JRUBY-6297 > > It's crashing in one of the compiler threads in > ciMethod::resolve_invoke, as far as I can tell. I have no simple > reproduction at the moment :( It's hard to conclude anything from the hs_err other than it looks like an unexpected NULL. Try a fastdebug build to maybe get more info or keep looking for a reproducible test case. tom > > - Charlie From john.coomes at oracle.com Tue Jan 3 12:51:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Tue, 03 Jan 2012 20:51:49 +0000 Subject: hg: hsx/hotspot-comp/langtools: 12 new changesets Message-ID: <20120103205217.B684747863@hg.openjdk.java.net> Changeset: 4822dfe0922b Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4822dfe0922b 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: 3809292620c9 Author: jjg Date: 2011-12-13 11:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/3809292620c9 7120736: refactor javac option handling Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! test/tools/javac/diags/examples/UnsupportedEncoding.java Changeset: 4e4fed1d02f9 Author: jjg Date: 2011-12-13 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4e4fed1d02f9 7121164: renamed files not committed Reviewed-by: ksrini - src/share/classes/com/sun/tools/javac/main/JavacOption.java + src/share/classes/com/sun/tools/javac/main/Option.java + src/share/classes/com/sun/tools/javac/main/OptionHelper.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java Changeset: 4261dc8af622 Author: jjg Date: 2011-12-14 16:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4261dc8af622 7111022: javac no long prints last round of processing 7121323: Sqe tests using -Xstdout option fail with an invalid flag error message Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/4846262/Test.sh + test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java ! test/tools/javac/util/T6597678.java Changeset: 281eeedf9755 Author: jjg Date: 2011-12-14 17:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/281eeedf9755 7121681: compiler message file broken for javac -fullversion Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/main/Option.java Changeset: 42ffceeceeca Author: jjg Date: 2011-12-14 21:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/42ffceeceeca 7121682: remove obsolete import Reviewed-by: jjh ! test/tools/javac/api/T6838467.java Changeset: ab2a880cc23b Author: lana Date: 2011-12-15 19:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ab2a880cc23b Merge Changeset: 6b773fdeb633 Author: jjg Date: 2011-12-16 13:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6b773fdeb633 7121961: javadoc is missing a resource property Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties Changeset: a7a2720c7897 Author: jjh Date: 2011-12-16 16:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a7a2720c7897 7122342: testPrintProcessorInfo/TestWithXstdout.java failed for JDK8 nightly build at 12/16/2011 Summary: Do not pass empty args to javac Reviewed-by: jjg ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java Changeset: 1ae5988e201b Author: mcimadamore Date: 2011-12-19 12:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1ae5988e201b 7120463: Fix method reference parser support in order to avoid ambiguities Summary: Add lookahead routine to disambiguate between method reference in method context and binary expression Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/lambda/MethodReferenceParserTest.java Changeset: 77b2c066084c Author: lana Date: 2011-12-23 16:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/77b2c066084c Merge - src/share/classes/com/sun/tools/javac/main/JavacOption.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java Changeset: ffd294128a48 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ffd294128a48 Added tag jdk8-b19 for changeset 77b2c066084c ! .hgtags From vladimir.kozlov at oracle.com Tue Jan 3 14:28:53 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Jan 2012 14:28:53 -0800 Subject: Request for reviews (L): 7125896: Eliminate nested locks In-Reply-To: <10E67586-61B3-4AF9-9022-AF087CE5A4C0@oracle.com> References: <4EFCD989.502@oracle.com> <4EFE0F99.4050706@oracle.com> <7BCC0C0F-A296-4903-8C61-A3078D375BA4@oracle.com> <4F035BAE.2030808@oracle.com> <10E67586-61B3-4AF9-9022-AF087CE5A4C0@oracle.com> Message-ID: <4F038125.7070803@oracle.com> Tom Rodriguez wrote: >> >>> Why can't the BoxLockNode be modified in place instead of being replaced? They are no longer shared between lock regions. Actually if sharing of them is disabled then you can always just modify them in place can't you? >> BoxLockNode could be merged so lock->box_node() could be PhiNode or it could be used by PhiNode. > > Why does that happen? OSR? Not necessary OSR but some weird bytecode (there was bug recently with huge method which had a lot inlining, looping and strange merge points). Compiler also does partial peeling and split Ifs which may create Phis, I think. I ran full CTW and compiler regression tests and did not hit BoxLockNode merge case so it could be very rare case. But I want to be careful. > Does lock elimination require that the Phis be collapsed? No, that is why it clones BoxLockNode. > >> I do modify original BoxLockNode for nested case where merged cases are excluded. For eliminated by EA case I could do cloning only for merged cases but it needs additional checks so I decided to do it always. But if merged cases are very rare then cloning should be avoided for not merged BoxLock, I will check. > > At a minimum, can't the explicit iteration over all the users can be replaced with igvn.replace_node(oldbox, newbox)? The explicit iteration seems like overkill. I want to play it safe and replace BoxLock only for related users (same box and object and not Phi). It is matching old elimination code so I will move it to separate method and will use in both cases. Thanks, Vladimir > >>> eliminating the cloning in ciTyepFlow could have performance implications. I assume it's rare? >> I ran refworkload on x86 and SPARC, there was no change in scores. For normal loop's head cloning cases monitorenter can not be in first loop's block (there will be condition there). The case I hit was "while(true) { synchronize(o);" where there is no condition. So it is not common case. Also LockNode is Call node and we don't do much loop optimizations for loops with calls inside. > > Ok. > > tom > >> Thanks, >> Vladimir >> >>> tom >>>> Thanks, >>>> Vladimir >>>> >>>>> -- Chris >>>>> On Dec 29, 2011, at 10:20 PM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7125896/webrev >>>>>> >>>>>> 7125896: Eliminate nested locks >>>>>> >>>>>> Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Commoning (GVN) of BoxLock nodes is switched off because nested locks elimination requires separate BoxLock node for each locked region to generated correct debug info for deoptimization. As result there could be merges (and Phi nodes) of BoxLock nodes. One such merge generated by ciTypeFlow (cloning loop head) is avoided but there could be other cases so new code is added to handle it. >>>>>> >>>>>> New code is under new product flag EliminateNestedLocks. >>>>>> >>>>>> Also added missed KILL effect for box register in fastlock and fastunlock mach nodes definitions. >>>>>> >>>>>> Tested with full CTW, nsk, jtreg tests, refworkload. >>>>>> >>>>>> Thanks, >>>>>> Vladimir > From tom.rodriguez at oracle.com Tue Jan 3 15:23:02 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 3 Jan 2012 15:23:02 -0800 Subject: Request for reviews (L): 7125896: Eliminate nested locks In-Reply-To: <4F038125.7070803@oracle.com> References: <4EFCD989.502@oracle.com> <4EFE0F99.4050706@oracle.com> <7BCC0C0F-A296-4903-8C61-A3078D375BA4@oracle.com> <4F035BAE.2030808@oracle.com> <10E67586-61B3-4AF9-9022-AF087CE5A4C0@oracle.com> <4F038125.7070803@oracle.com> Message-ID: <60BFEF9E-7F40-48C3-B523-68700AEE67B4@oracle.com> On Jan 3, 2012, at 2:28 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >>> >>>> Why can't the BoxLockNode be modified in place instead of being replaced? They are no longer shared between lock regions. Actually if sharing of them is disabled then you can always just modify them in place can't you? >>> BoxLockNode could be merged so lock->box_node() could be PhiNode or it could be used by PhiNode. >> Why does that happen? OSR? > > Not necessary OSR but some weird bytecode (there was bug recently with huge method which had a lot inlining, looping and strange merge points). Compiler also does partial peeling and split Ifs which may create Phis, I think. > > I ran full CTW and compiler regression tests and did not hit BoxLockNode merge case so it could be very rare case. But I want to be careful. I'm ok with careful but I'm having trouble understanding how it can even happen in normal ideal. The existing locking code in macro.cpp doesn't appear to handle it. Phis of BoxLocks shouldn't be possible unless the Phis were just never reprocessed. All locking in compiled code is required to be block structured so the slot of the BoxLockNodes must match if they feed into a Phi and GVN should common them up to be equivalent, so the Phi should just collapse. BoxLocks are used with mach nodes too so during code generation your might get Phis for BoxLocks. Maybe that's why the logic is there. I think the macro.cpp code should assert that it never sees a Phi. This would also simplify all that logic quite a bit since you could just modify the BoxLock in place. Why isn't the eliminated flag taken from the BoxLock instead of being stored on the AbstractLock? tom > >> Does lock elimination require that the Phis be collapsed? > > No, that is why it clones BoxLockNode. > >>> I do modify original BoxLockNode for nested case where merged cases are excluded. For eliminated by EA case I could do cloning only for merged cases but it needs additional checks so I decided to do it always. But if merged cases are very rare then cloning should be avoided for not merged BoxLock, I will check. >> At a minimum, can't the explicit iteration over all the users can be replaced with igvn.replace_node(oldbox, newbox)? The explicit iteration seems like overkill. > > I want to play it safe and replace BoxLock only for related users (same box and object and not Phi). It is matching old elimination code so I will move it to separate method and will use in both cases. > > Thanks, > Vladimir > >>>> eliminating the cloning in ciTyepFlow could have performance implications. I assume it's rare? >>> I ran refworkload on x86 and SPARC, there was no change in scores. For normal loop's head cloning cases monitorenter can not be in first loop's block (there will be condition there). The case I hit was "while(true) { synchronize(o);" where there is no condition. So it is not common case. Also LockNode is Call node and we don't do much loop optimizations for loops with calls inside. >> Ok. >> tom >>> Thanks, >>> Vladimir >>> >>>> tom >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> -- Chris >>>>>> On Dec 29, 2011, at 10:20 PM, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/7125896/webrev >>>>>>> >>>>>>> 7125896: Eliminate nested locks >>>>>>> >>>>>>> Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Commoning (GVN) of BoxLock nodes is switched off because nested locks elimination requires separate BoxLock node for each locked region to generated correct debug info for deoptimization. As result there could be merges (and Phi nodes) of BoxLock nodes. One such merge generated by ciTypeFlow (cloning loop head) is avoided but there could be other cases so new code is added to handle it. >>>>>>> >>>>>>> New code is under new product flag EliminateNestedLocks. >>>>>>> >>>>>>> Also added missed KILL effect for box register in fastlock and fastunlock mach nodes definitions. >>>>>>> >>>>>>> Tested with full CTW, nsk, jtreg tests, refworkload. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir From headius at headius.com Tue Jan 3 15:24:01 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 3 Jan 2012 17:24:01 -0600 Subject: Crash in C2 with 7u2b13 In-Reply-To: <6AE9CE8B-1787-480B-B0DC-1CDFF139A36E@oracle.com> References: <6AE9CE8B-1787-480B-B0DC-1CDFF139A36E@oracle.com> Message-ID: I had another user report the same thing, and it only happens with invokedynamic use (in JRuby) turned on. They are able to reproduce it regularly, so I'll have them try a fastdebug build and see how that goes. - Charlie On Tue, Jan 3, 2012 at 2:19 PM, Tom Rodriguez wrote: > > On Dec 31, 2011, at 12:10 PM, Charles Oliver Nutter wrote: > >> Got this report from a JRuby user, so I figured I'd toss it on this >> list and see if I should report it (or if one of you want to look into >> it directly): >> >> http://jira.codehaus.org/browse/JRUBY-6297 >> >> It's crashing in one of the compiler threads in >> ciMethod::resolve_invoke, as far as I can tell. I have no simple >> reproduction at the moment :( > > It's hard to conclude anything from the hs_err other than it looks like an unexpected NULL. ?Try a fastdebug build to maybe get more info or keep looking for a reproducible test case. > > tom > >> >> - Charlie > From vladimir.kozlov at oracle.com Tue Jan 3 15:58:12 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Jan 2012 15:58:12 -0800 Subject: Request for reviews (L): 7125896: Eliminate nested locks In-Reply-To: <60BFEF9E-7F40-48C3-B523-68700AEE67B4@oracle.com> References: <4EFCD989.502@oracle.com> <4EFE0F99.4050706@oracle.com> <7BCC0C0F-A296-4903-8C61-A3078D375BA4@oracle.com> <4F035BAE.2030808@oracle.com> <10E67586-61B3-4AF9-9022-AF087CE5A4C0@oracle.com> <4F038125.7070803@oracle.com> <60BFEF9E-7F40-48C3-B523-68700AEE67B4@oracle.com> Message-ID: <4F039614.6040203@oracle.com> Tom Rodriguez wrote: > On Jan 3, 2012, at 2:28 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>>>> Why can't the BoxLockNode be modified in place instead of being replaced? They are no longer shared between lock regions. Actually if sharing of them is disabled then you can always just modify them in place can't you? >>>> BoxLockNode could be merged so lock->box_node() could be PhiNode or it could be used by PhiNode. >>> Why does that happen? OSR? >> Not necessary OSR but some weird bytecode (there was bug recently with huge method which had a lot inlining, looping and strange merge points). Compiler also does partial peeling and split Ifs which may create Phis, I think. >> >> I ran full CTW and compiler regression tests and did not hit BoxLockNode merge case so it could be very rare case. But I want to be careful. > > I'm ok with careful but I'm having trouble understanding how it can even happen in normal ideal. The existing locking code in macro.cpp doesn't appear to handle it. Phis of BoxLocks shouldn't be possible unless the Phis were just never reprocessed. All locking in compiled code is required to be block structured so the slot of the BoxLockNodes must match if they feed into a Phi and GVN should common them up to be equivalent, so the Phi should just collapse. You forgot that BoxLockNode commoning is switched off for EliminateNestedLocks, it is main reason for Phis. Phis are generated for monitorexit (unlocks) when monitorenter (locks) code is merged (as was in loop head cloning case and could be in other cases). Yes, in current code BoxLockNode are commoned with the same slot (but could be for different objects) so it could bei used by eliminated and not eliminated locks. That is why elimination code clones BoxLockNode only for eliminated locks. > > BoxLocks are used with mach nodes too so during code generation your might get Phis for BoxLocks. Maybe that's why the logic is there. I think the macro.cpp code should assert that it never sees a Phi. This would also simplify all that logic quite a bit since you could just modify the BoxLock in place. Why isn't the eliminated flag taken from the BoxLock instead of being stored on the AbstractLock? Because in current code the same BoxLockNode could be referenced by eliminated and not eliminated locks. Vladimir > > tom > >>> Does lock elimination require that the Phis be collapsed? >> No, that is why it clones BoxLockNode. >> >>>> I do modify original BoxLockNode for nested case where merged cases are excluded. For eliminated by EA case I could do cloning only for merged cases but it needs additional checks so I decided to do it always. But if merged cases are very rare then cloning should be avoided for not merged BoxLock, I will check. >>> At a minimum, can't the explicit iteration over all the users can be replaced with igvn.replace_node(oldbox, newbox)? The explicit iteration seems like overkill. >> I want to play it safe and replace BoxLock only for related users (same box and object and not Phi). It is matching old elimination code so I will move it to separate method and will use in both cases. >> >> Thanks, >> Vladimir >> >>>>> eliminating the cloning in ciTyepFlow could have performance implications. I assume it's rare? >>>> I ran refworkload on x86 and SPARC, there was no change in scores. For normal loop's head cloning cases monitorenter can not be in first loop's block (there will be condition there). The case I hit was "while(true) { synchronize(o);" where there is no condition. So it is not common case. Also LockNode is Call node and we don't do much loop optimizations for loops with calls inside. >>> Ok. >>> tom >>>> Thanks, >>>> Vladimir >>>> >>>>> tom >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> -- Chris >>>>>>> On Dec 29, 2011, at 10:20 PM, Vladimir Kozlov wrote: >>>>>>>> http://cr.openjdk.java.net/~kvn/7125896/webrev >>>>>>>> >>>>>>>> 7125896: Eliminate nested locks >>>>>>>> >>>>>>>> Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Commoning (GVN) of BoxLock nodes is switched off because nested locks elimination requires separate BoxLock node for each locked region to generated correct debug info for deoptimization. As result there could be merges (and Phi nodes) of BoxLock nodes. One such merge generated by ciTypeFlow (cloning loop head) is avoided but there could be other cases so new code is added to handle it. >>>>>>>> >>>>>>>> New code is under new product flag EliminateNestedLocks. >>>>>>>> >>>>>>>> Also added missed KILL effect for box register in fastlock and fastunlock mach nodes definitions. >>>>>>>> >>>>>>>> Tested with full CTW, nsk, jtreg tests, refworkload. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir > From christian.thalinger at oracle.com Tue Jan 3 11:42:33 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 3 Jan 2012 20:42:33 +0100 Subject: Crash in C2 with 7u2b13 In-Reply-To: References: Message-ID: <35486BFF-952D-4CCE-B7A1-DA3870DDB6BC@oracle.com> Hmm. Not very useful without a core file or being able to reproduce it. -- Chris On Dec 31, 2011, at 9:10 PM, Charles Oliver Nutter wrote: > Got this report from a JRuby user, so I figured I'd toss it on this > list and see if I should report it (or if one of you want to look into > it directly): > > http://jira.codehaus.org/browse/JRUBY-6297 > > It's crashing in one of the compiler threads in > ciMethod::resolve_invoke, as far as I can tell. I have no simple > reproduction at the moment :( > > - Charlie From headius at headius.com Wed Jan 4 09:46:42 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 4 Jan 2012 11:46:42 -0600 Subject: Crash in C2 with 7u2b13 In-Reply-To: References: <6AE9CE8B-1787-480B-B0DC-1CDFF139A36E@oracle.com> Message-ID: Ok, the second user to report it started up the same application on a fastdebug build...and it didn't even boot all the way before crashing. Here's the log output: https://gist.github.com/935107b210befb41812a - Charlie On Tue, Jan 3, 2012 at 5:24 PM, Charles Oliver Nutter wrote: > I had another user report the same thing, and it only happens with > invokedynamic use (in JRuby) turned on. They are able to reproduce it > regularly, so I'll have them try a fastdebug build and see how that > goes. > > - Charlie > > On Tue, Jan 3, 2012 at 2:19 PM, Tom Rodriguez wrote: >> >> On Dec 31, 2011, at 12:10 PM, Charles Oliver Nutter wrote: >> >>> Got this report from a JRuby user, so I figured I'd toss it on this >>> list and see if I should report it (or if one of you want to look into >>> it directly): >>> >>> http://jira.codehaus.org/browse/JRUBY-6297 >>> >>> It's crashing in one of the compiler threads in >>> ciMethod::resolve_invoke, as far as I can tell. I have no simple >>> reproduction at the moment :( >> >> It's hard to conclude anything from the hs_err other than it looks like an unexpected NULL. ?Try a fastdebug build to maybe get more info or keep looking for a reproducible test case. >> >> tom >> >>> >>> - Charlie >> From tom.rodriguez at oracle.com Wed Jan 4 10:30:08 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 4 Jan 2012 10:30:08 -0800 Subject: Crash in C2 with 7u2b13 In-Reply-To: References: <6AE9CE8B-1787-480B-B0DC-1CDFF139A36E@oracle.com> Message-ID: On Jan 4, 2012, at 9:46 AM, Charles Oliver Nutter wrote: > Ok, the second user to report it started up the same application on a > fastdebug build...and it didn't even boot all the way before crashing. > Here's the log output: > > https://gist.github.com/935107b210befb41812a That makes some sense. That looks a bit like 7094138 which is fixed in hs23 which will be 7u4. That may explain the later crash during compilation though there's no guarantee. Stale oops can lead to almost any kind of crash. They could try testing with the latest 1.8 to confirm that there aren't other issues. The fix should have appeared in 1.8b15 and we're on b19 now. tom > > - Charlie > > On Tue, Jan 3, 2012 at 5:24 PM, Charles Oliver Nutter > wrote: >> I had another user report the same thing, and it only happens with >> invokedynamic use (in JRuby) turned on. They are able to reproduce it >> regularly, so I'll have them try a fastdebug build and see how that >> goes. >> >> - Charlie >> >> On Tue, Jan 3, 2012 at 2:19 PM, Tom Rodriguez wrote: >>> >>> On Dec 31, 2011, at 12:10 PM, Charles Oliver Nutter wrote: >>> >>>> Got this report from a JRuby user, so I figured I'd toss it on this >>>> list and see if I should report it (or if one of you want to look into >>>> it directly): >>>> >>>> http://jira.codehaus.org/browse/JRUBY-6297 >>>> >>>> It's crashing in one of the compiler threads in >>>> ciMethod::resolve_invoke, as far as I can tell. I have no simple >>>> reproduction at the moment :( >>> >>> It's hard to conclude anything from the hs_err other than it looks like an unexpected NULL. Try a fastdebug build to maybe get more info or keep looking for a reproducible test case. >>> >>> tom >>> >>>> >>>> - Charlie >>> From headius at headius.com Wed Jan 4 12:51:36 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 4 Jan 2012 14:51:36 -0600 Subject: Crash in C2 with 7u2b13 In-Reply-To: References: <6AE9CE8B-1787-480B-B0DC-1CDFF139A36E@oracle.com> Message-ID: I'll see if I can get them testing on a 1.8 build as well. They ran into other crashes, plus the dreaded NoClassDefFound bug I think has lingered into u2 indy logic. It's perhaps the largest Ruby app server, based on JBoss, so they're a good target for us to get running. - Charlie On Wed, Jan 4, 2012 at 12:30 PM, Tom Rodriguez wrote: > > On Jan 4, 2012, at 9:46 AM, Charles Oliver Nutter wrote: > >> Ok, the second user to report it started up the same application on a >> fastdebug build...and it didn't even boot all the way before crashing. >> Here's the log output: >> >> https://gist.github.com/935107b210befb41812a > > That makes some sense. ?That looks a bit like 7094138 which is fixed in hs23 which will be 7u4. ?That may explain the later crash during compilation though there's no guarantee. ?Stale oops can lead to almost any kind of crash. ?They could try testing with the latest 1.8 to confirm that there aren't other issues. ?The fix should have appeared in 1.8b15 and we're on b19 now. > > tom > >> >> - Charlie >> >> On Tue, Jan 3, 2012 at 5:24 PM, Charles Oliver Nutter >> wrote: >>> I had another user report the same thing, and it only happens with >>> invokedynamic use (in JRuby) turned on. They are able to reproduce it >>> regularly, so I'll have them try a fastdebug build and see how that >>> goes. >>> >>> - Charlie >>> >>> On Tue, Jan 3, 2012 at 2:19 PM, Tom Rodriguez wrote: >>>> >>>> On Dec 31, 2011, at 12:10 PM, Charles Oliver Nutter wrote: >>>> >>>>> Got this report from a JRuby user, so I figured I'd toss it on this >>>>> list and see if I should report it (or if one of you want to look into >>>>> it directly): >>>>> >>>>> http://jira.codehaus.org/browse/JRUBY-6297 >>>>> >>>>> It's crashing in one of the compiler threads in >>>>> ciMethod::resolve_invoke, as far as I can tell. I have no simple >>>>> reproduction at the moment :( >>>> >>>> It's hard to conclude anything from the hs_err other than it looks like an unexpected NULL. ?Try a fastdebug build to maybe get more info or keep looking for a reproducible test case. >>>> >>>> tom >>>> >>>>> >>>>> - Charlie >>>> > From vladimir.kozlov at oracle.com Wed Jan 4 19:54:52 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 04 Jan 2012 19:54:52 -0800 Subject: Request for reviews (S): 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM Message-ID: <4F051F0C.9040000@oracle.com> http://cr.openjdk.java.net/~kvn/7110824/webrev 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM PhaseChaitin::yank_if_dead() can't handle nodes which load from constant table because MachConstantBase node could be spilled and Phi nodes are generated for it. In failing case loadConP_load node has Phi node as input and it is yanked since there is an other copy of the same constant load. Change yank_if_dead() to recursive method to remove all dead inputs. Tested with full CTW and failing test. Thanks, Vladimir From tom.rodriguez at oracle.com Thu Jan 5 09:54:27 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 5 Jan 2012 09:54:27 -0800 Subject: Request for reviews (S): 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM In-Reply-To: <4F051F0C.9040000@oracle.com> References: <4F051F0C.9040000@oracle.com> Message-ID: <5BAA294C-47FD-4B2B-A10D-A1781A26333F@oracle.com> On Jan 4, 2012, at 7:54 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7110824/webrev > > 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM > > PhaseChaitin::yank_if_dead() can't handle nodes which load from constant table because MachConstantBase node could be spilled and Phi nodes are generated for it. In failing case loadConP_load node has Phi node as input and it is yanked since there is an other copy of the same constant load. > > Change yank_if_dead() to recursive method to remove all dead inputs. The change seems fine though the limited logic would protect us from bad graph shapes and I'm a little concerned that it will now just blindly trim anything away that it sees without complaining. We'd probably die at a later point in that case but it will be a bit more mysterious. An assert could check that we only start yanking certain node type but I don't know how long that list would be. Would that be overkill? tom > > Tested with full CTW and failing test. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Jan 5 10:25:14 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 05 Jan 2012 10:25:14 -0800 Subject: Request for reviews (L): 7125896: Eliminate nested locks In-Reply-To: <3A0EDC34-C07D-4A40-9480-56BA5402EBF7@oracle.com> References: <4EFCD989.502@oracle.com> <4EFE0F99.4050706@oracle.com> <7BCC0C0F-A296-4903-8C61-A3078D375BA4@oracle.com> <4F035BAE.2030808@oracle.com> <10E67586-61B3-4AF9-9022-AF087CE5A4C0@oracle.com> <4F038125.7070803@oracle.com> <60BFEF9E-7F40-48C3-B523-68700AEE67B4@oracle.com> <4F039614.6040203@oracle.com> <90511F8E-2008-4E4D-8AC9-C57D01937A38@oracle.com> <4F03B44A.3030705@oracle.com> <3F9BAC38-A58E-4936-BC4C-752716158C83@oracle.com> <4F04E6AF.8080208@oracle.com> <3A0EDC34-C07D-4A40-9480-56BA5402EBF7@oracle.com> Message-ID: <4F05EB0A.3080000@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > On Jan 4, 2012, at 3:54 PM, Vladimir Kozlov wrote: >> >> I updated webrev: >> >> http://cr.openjdk.java.net/~kvn/7125896/webrev.01 > > I think that looks good. Thanks for refactoring it. > > tom > >> New changes: >> >> - Added new enum field AbstractLockNode::_kind (I tried to avoid _type name) and corresponding methods instead of boolean fields. >> - Added new method LockNode::is_nested_lock_region() to find if it is nested. >> - Added new method BoxLockNode::is_simple_lock_region() to check if Box node is used to lock only one object and to avoid replacing this Box with clone in macro.cpp. >> - Added new method PhaseMacroExpand::mark_eliminated_box() to move EA eliminated marking code from mark_eliminated_locking_nodes(). >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> On Jan 3, 2012, at 6:07 PM, Vladimir Kozlov wrote: >>>> Tom Rodriguez wrote: >>>>>>>> I ran full CTW and compiler regression tests and did not hit BoxLockNode merge case so it could be very rare case. But I want to be careful. >>>>>>> I'm ok with careful but I'm having trouble understanding how it can even happen in normal ideal. The existing locking code in macro.cpp doesn't appear to handle it. Phis of BoxLocks shouldn't be possible unless the Phis were just never reprocessed. All locking in compiled code is required to be block structured so the slot of the BoxLockNodes must match if they feed into a Phi and GVN should common them up to be equivalent, so the Phi should just collapse. >>>>>> You forgot that BoxLockNode commoning is switched off for EliminateNestedLocks, it is main reason for Phis. Phis are generated for monitorexit (unlocks) when monitorenter (locks) code is merged (as was in loop head cloning case and could be in other cases). >>>>> How would that result in Phis? The unlock pulls a box from the JVMState, which I guess could have Phis but again they should all have collapsed since they must refer to the same lock operation and BoxLock. >>>> No, Box and Lock nodes are different since they are generated on different paths and are not commoning (I had to change code in Parse::ensure_phi() for BoxLockNode). To be clear we are talking about this case: >>>> >>>> if (a) { >>>> monitorenter(obj) >>>> } else { >>>> monitorenter(obj) >>>> } >>>> monitorexit(obj) >>> I assumed we wouldn't compile things like that but I guess that's technically block structured. The monitor matching logic really accepts that as block structured? I think it should reject it to simplify the compiler. There's no benefit to accepting code like that since it could always be restructured to properly pair. >>>>>> Yes, in current code BoxLockNode are commoned with the same slot (but could be for different objects) so it could bei used by eliminated and not eliminated locks. That is why elimination code clones BoxLockNode only for eliminated locks. >>>>>> >>>>>>> BoxLocks are used with mach nodes too so during code generation your might get Phis for BoxLocks. Maybe that's why the logic is there. I think the macro.cpp code should assert that it never sees a Phi. This would also simplify all that logic quite a bit since you could just modify the BoxLock in place. Why isn't the eliminated flag taken from the BoxLock instead of being stored on the AbstractLock? >>>>>> Because in current code the same BoxLockNode could be referenced by eliminated and not eliminated locks. >>>>> That's true with commoning of BoxLocks enabled but with it turned off they should follow the block structure and could be eliminated and referenced as a group. >>>> In above case you have several Box and Phi nodes associated with one locking region. So you can't mark only one Box node. >>>> >>>>> I actually think not commoning the BoxLocks should be the only behaviour instead of making it conditional on EliminateNestedLocks, though I have a vague memory of some code that relies on commoning of them for some purpose. I can't seem to find it though. >>>> Commoning simplified all compiler optimizations since you need only compare Box nodes. Now I have to look through Phi to find Box nodes and compare their slots. For example, look on lock coarsening code changes. >>> Why do you have to compare their slots? As far as I can see, BoxLock is created for monitorenter and the unlock pulls the box from the JVMState, guaranteeing that a single BoxLock corresponds to a single lock region, which seems like a nice property. Am I missing something? I guess it's just the example above? >>> Anyway, I'm ok with your original code with a little refactoring. It just seemed like the whole thing could more simple once commoning was eliminated. I guess that's not true. >>> tom >>>> Vladimir >>>> >>>>> tom >>>>>> Vladimir >>>>>> >>>>>>> tom >>>>>>>>> Does lock elimination require that the Phis be collapsed? >>>>>>>> No, that is why it clones BoxLockNode. >>>>>>>> >>>>>>>>>> I do modify original BoxLockNode for nested case where merged cases are excluded. For eliminated by EA case I could do cloning only for merged cases but it needs additional checks so I decided to do it always. But if merged cases are very rare then cloning should be avoided for not merged BoxLock, I will check. >>>>>>>>> At a minimum, can't the explicit iteration over all the users can be replaced with igvn.replace_node(oldbox, newbox)? The explicit iteration seems like overkill. >>>>>>>> I want to play it safe and replace BoxLock only for related users (same box and object and not Phi). It is matching old elimination code so I will move it to separate method and will use in both cases. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>>>> eliminating the cloning in ciTyepFlow could have performance implications. I assume it's rare? >>>>>>>>>> I ran refworkload on x86 and SPARC, there was no change in scores. For normal loop's head cloning cases monitorenter can not be in first loop's block (there will be condition there). The case I hit was "while(true) { synchronize(o);" where there is no condition. So it is not common case. Also LockNode is Call node and we don't do much loop optimizations for loops with calls inside. >>>>>>>>> Ok. >>>>>>>>> tom >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> tom >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>>> -- Chris >>>>>>>>>>>>> On Dec 29, 2011, at 10:20 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/7125896/webrev >>>>>>>>>>>>>> >>>>>>>>>>>>>> 7125896: Eliminate nested locks >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Commoning (GVN) of BoxLock nodes is switched off because nested locks elimination requires separate BoxLock node for each locked region to generated correct debug info for deoptimization. As result there could be merges (and Phi nodes) of BoxLock nodes. One such merge generated by ciTypeFlow (cloning loop head) is avoided but there could be other cases so new code is added to handle it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> New code is under new product flag EliminateNestedLocks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also added missed KILL effect for box register in fastlock and fastunlock mach nodes definitions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tested with full CTW, nsk, jtreg tests, refworkload. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir > From vladimir.kozlov at oracle.com Thu Jan 5 11:36:03 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 05 Jan 2012 11:36:03 -0800 Subject: Request for reviews (S): 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM In-Reply-To: <5BAA294C-47FD-4B2B-A10D-A1781A26333F@oracle.com> References: <4F051F0C.9040000@oracle.com> <5BAA294C-47FD-4B2B-A10D-A1781A26333F@oracle.com> Message-ID: <4F05FBA3.7010101@oracle.com> How about this?: http://cr.openjdk.java.net/~kvn/7110824/webrev Normal load constant nodes have only one (root) input so I look for 2 inputs loads and allow multiple inputs only in that case. Should I use guarantee instead of assert? Thanks, Vladimir Tom Rodriguez wrote: > On Jan 4, 2012, at 7:54 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7110824/webrev >> >> 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM >> >> PhaseChaitin::yank_if_dead() can't handle nodes which load from constant table because MachConstantBase node could be spilled and Phi nodes are generated for it. In failing case loadConP_load node has Phi node as input and it is yanked since there is an other copy of the same constant load. >> >> Change yank_if_dead() to recursive method to remove all dead inputs. > > The change seems fine though the limited logic would protect us from bad graph shapes and I'm a little concerned that it will now just blindly trim anything away that it sees without complaining. We'd probably die at a later point in that case but it will be a bit more mysterious. An assert could check that we only start yanking certain node type but I don't know how long that list would be. Would that be overkill? > > tom > >> Tested with full CTW and failing test. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Thu Jan 5 11:54:31 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 5 Jan 2012 11:54:31 -0800 Subject: Request for reviews (S): 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM In-Reply-To: <4F05FBA3.7010101@oracle.com> References: <4F051F0C.9040000@oracle.com> <5BAA294C-47FD-4B2B-A10D-A1781A26333F@oracle.com> <4F05FBA3.7010101@oracle.com> Message-ID: <444B082F-E06C-47A2-B90A-0A08B12D07F7@oracle.com> On Jan 5, 2012, at 11:36 AM, Vladimir Kozlov wrote: > How about this?: > > http://cr.openjdk.java.net/~kvn/7110824/webrev > > Normal load constant nodes have only one (root) input so I look for 2 inputs loads and allow multiple inputs only in that case. Should I use guarantee instead of assert? Could you do the same thing with the flag but only have it true for the initial call and false for the recursive ones and then the function would start with something like: assert(!first_yank || old->is_Con() || old->req() < 3, "unexpected node"); I'm not sure that assert is complete but I think it captures the cases we're expecting. I'm just not sure it adds value. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Jan 4, 2012, at 7:54 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7110824/webrev >>> >>> 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM >>> >>> PhaseChaitin::yank_if_dead() can't handle nodes which load from constant table because MachConstantBase node could be spilled and Phi nodes are generated for it. In failing case loadConP_load node has Phi node as input and it is yanked since there is an other copy of the same constant load. >>> >>> Change yank_if_dead() to recursive method to remove all dead inputs. >> The change seems fine though the limited logic would protect us from bad graph shapes and I'm a little concerned that it will now just blindly trim anything away that it sees without complaining. We'd probably die at a later point in that case but it will be a bit more mysterious. An assert could check that we only start yanking certain node type but I don't know how long that list would be. Would that be overkill? >> tom >>> Tested with full CTW and failing test. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Thu Jan 5 12:18:54 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 05 Jan 2012 12:18:54 -0800 Subject: Request for reviews (S): 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM In-Reply-To: <444B082F-E06C-47A2-B90A-0A08B12D07F7@oracle.com> References: <4F051F0C.9040000@oracle.com> <5BAA294C-47FD-4B2B-A10D-A1781A26333F@oracle.com> <4F05FBA3.7010101@oracle.com> <444B082F-E06C-47A2-B90A-0A08B12D07F7@oracle.com> Message-ID: <4F0605AE.3020508@oracle.com> Tom Rodriguez wrote: > On Jan 5, 2012, at 11:36 AM, Vladimir Kozlov wrote: > >> How about this?: >> >> http://cr.openjdk.java.net/~kvn/7110824/webrev >> >> Normal load constant nodes have only one (root) input so I look for 2 inputs loads and allow multiple inputs only in that case. Should I use guarantee instead of assert? > > Could you do the same thing with the flag but only have it true for the initial call and false for the recursive ones and then the function would start with something like: > > assert(!first_yank || old->is_Con() || old->req() < 3, "unexpected node"); So you want to put check only for original old node and allow input to be Phi node for any original old node? It is different from existing code. My assert check allows this (Phis) only if original old node was load from constant table node so it is more strict. Vladimir > > I'm not sure that assert is complete but I think it captures the cases we're expecting. I'm just not sure it adds value. > > tom > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> On Jan 4, 2012, at 7:54 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7110824/webrev >>>> >>>> 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM >>>> >>>> PhaseChaitin::yank_if_dead() can't handle nodes which load from constant table because MachConstantBase node could be spilled and Phi nodes are generated for it. In failing case loadConP_load node has Phi node as input and it is yanked since there is an other copy of the same constant load. >>>> >>>> Change yank_if_dead() to recursive method to remove all dead inputs. >>> The change seems fine though the limited logic would protect us from bad graph shapes and I'm a little concerned that it will now just blindly trim anything away that it sees without complaining. We'd probably die at a later point in that case but it will be a bit more mysterious. An assert could check that we only start yanking certain node type but I don't know how long that list would be. Would that be overkill? >>> tom >>>> Tested with full CTW and failing test. >>>> >>>> Thanks, >>>> Vladimir > From tom.rodriguez at oracle.com Thu Jan 5 12:30:13 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 5 Jan 2012 12:30:13 -0800 Subject: Request for reviews (S): 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM In-Reply-To: <4F0605AE.3020508@oracle.com> References: <4F051F0C.9040000@oracle.com> <5BAA294C-47FD-4B2B-A10D-A1781A26333F@oracle.com> <4F05FBA3.7010101@oracle.com> <444B082F-E06C-47A2-B90A-0A08B12D07F7@oracle.com> <4F0605AE.3020508@oracle.com> Message-ID: <91D8A5FE-0D3E-4822-ACC6-BFE11FA13A66@oracle.com> On Jan 5, 2012, at 12:18 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> On Jan 5, 2012, at 11:36 AM, Vladimir Kozlov wrote: >>> How about this?: >>> >>> http://cr.openjdk.java.net/~kvn/7110824/webrev >>> >>> Normal load constant nodes have only one (root) input so I look for 2 inputs loads and allow multiple inputs only in that case. Should I use guarantee instead of assert? >> Could you do the same thing with the flag but only have it true for the initial call and false for the recursive ones and then the function would start with something like: >> assert(!first_yank || old->is_Con() || old->req() < 3, "unexpected node"); > > So you want to put check only for original old node and allow input to be Phi node for any original old node? It is different from existing code. My assert check allows this (Phis) only if original old node was load from constant table node so it is more strict. I was having a little trouble mapping the new assert onto the old logic since it seems more strict in other ways, since it requires req == 3 for the handling of temps and I don't see any reason for that restriction. I think reversing the sense of only_one_input would make the assert read more easily. Also if you swap the assert and is_Con() lines then the !only_one_input would subsumes is_MachTemp checks. + if (old->is_Con() && (old->req() > 1)) { + // Load from constant table node may have Phi node as input. + multiple_inputs = true; + } + assert(multiple_inputs || old->req() < 3, "expecting only one data input"); You could assert in the is_Con case that the inputs are only Phi, MachTemp and MachConstantBase. tom > > Vladimir > >> I'm not sure that assert is complete but I think it captures the cases we're expecting. I'm just not sure it adds value. >> tom >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> On Jan 4, 2012, at 7:54 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7110824/webrev >>>>> >>>>> 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM >>>>> >>>>> PhaseChaitin::yank_if_dead() can't handle nodes which load from constant table because MachConstantBase node could be spilled and Phi nodes are generated for it. In failing case loadConP_load node has Phi node as input and it is yanked since there is an other copy of the same constant load. >>>>> >>>>> Change yank_if_dead() to recursive method to remove all dead inputs. >>>> The change seems fine though the limited logic would protect us from bad graph shapes and I'm a little concerned that it will now just blindly trim anything away that it sees without complaining. We'd probably die at a later point in that case but it will be a bit more mysterious. An assert could check that we only start yanking certain node type but I don't know how long that list would be. Would that be overkill? >>>> tom >>>>> Tested with full CTW and failing test. >>>>> >>>>> Thanks, >>>>> Vladimir From vladimir.kozlov at oracle.com Thu Jan 5 14:24:22 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 05 Jan 2012 14:24:22 -0800 Subject: Request for reviews (S): 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM In-Reply-To: <91D8A5FE-0D3E-4822-ACC6-BFE11FA13A66@oracle.com> References: <4F051F0C.9040000@oracle.com> <5BAA294C-47FD-4B2B-A10D-A1781A26333F@oracle.com> <4F05FBA3.7010101@oracle.com> <444B082F-E06C-47A2-B90A-0A08B12D07F7@oracle.com> <4F0605AE.3020508@oracle.com> <91D8A5FE-0D3E-4822-ACC6-BFE11FA13A66@oracle.com> Message-ID: <4F062316.2060508@oracle.com> Tom Rodriguez wrote: > On Jan 5, 2012, at 12:18 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>> On Jan 5, 2012, at 11:36 AM, Vladimir Kozlov wrote: >>>> How about this?: >>>> >>>> http://cr.openjdk.java.net/~kvn/7110824/webrev >>>> >>>> Normal load constant nodes have only one (root) input so I look for 2 inputs loads and allow multiple inputs only in that case. Should I use guarantee instead of assert? >>> Could you do the same thing with the flag but only have it true for the initial call and false for the recursive ones and then the function would start with something like: >>> assert(!first_yank || old->is_Con() || old->req() < 3, "unexpected node"); >> So you want to put check only for original old node and allow input to be Phi node for any original old node? It is different from existing code. My assert check allows this (Phis) only if original old node was load from constant table node so it is more strict. > > I was having a little trouble mapping the new assert onto the old logic since it seems more strict in other ways, since it requires req == 3 for the handling of temps and I don't see any reason for that restriction. Yes, I missed that original code allowed any numbers of temps. I think we have an other problem here since I saw cases where MachTemp is spilled so original old node may have >3 inputs which are MSC of MachTemp. It could be an other case when we hit current assert. > I think reversing the sense of only_one_input would make the assert read more easily. Also if you swap the assert and is_Con() lines then the !only_one_input would subsumes is_MachTemp checks. MachTemp is not used by Con nodes, it is a different nodes case, so it can't be subsumed by is_Con() check. is_Con inputs can be only Phi, MSC and MachConstantBase. I will look more on how to handle all these cases. Thanks, Vladimir > > + if (old->is_Con() && (old->req() > 1)) { > + // Load from constant table node may have Phi node as input. > + multiple_inputs = true; > + } > + assert(multiple_inputs || old->req() < 3, "expecting only one data input"); > > You could assert in the is_Con case that the inputs are only Phi, MachTemp and MachConstantBase. > > tom > >> Vladimir >> >>> I'm not sure that assert is complete but I think it captures the cases we're expecting. I'm just not sure it adds value. >>> tom >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> On Jan 4, 2012, at 7:54 PM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7110824/webrev >>>>>> >>>>>> 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM >>>>>> >>>>>> PhaseChaitin::yank_if_dead() can't handle nodes which load from constant table because MachConstantBase node could be spilled and Phi nodes are generated for it. In failing case loadConP_load node has Phi node as input and it is yanked since there is an other copy of the same constant load. >>>>>> >>>>>> Change yank_if_dead() to recursive method to remove all dead inputs. >>>>> The change seems fine though the limited logic would protect us from bad graph shapes and I'm a little concerned that it will now just blindly trim anything away that it sees without complaining. We'd probably die at a later point in that case but it will be a bit more mysterious. An assert could check that we only start yanking certain node type but I don't know how long that list would be. Would that be overkill? >>>>> tom >>>>>> Tested with full CTW and failing test. >>>>>> >>>>>> Thanks, >>>>>> Vladimir > From igor.veresov at oracle.com Thu Jan 5 15:47:30 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 5 Jan 2012 15:47:30 -0800 Subject: review(XS): 7119294: Two command line options cause JVM to crash. Message-ID: <347F89D03F3B4098A07AB4F3C3CC2154@oracle.com> Tiered crashed on x64 with -XX:-UseTLAB because the thread register was not setup in MacroAssembler::incr_allocated_bytes() in case the thread register passed as an argument was noreg. Webrev: http://cr.openjdk.java.net/~iveresov/7119294/webrev.00/ igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120105/d62ef317/attachment.html From vladimir.kozlov at oracle.com Thu Jan 5 16:05:08 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 05 Jan 2012 16:05:08 -0800 Subject: review(XS): 7119294: Two command line options cause JVM to crash. In-Reply-To: <347F89D03F3B4098A07AB4F3C3CC2154@oracle.com> References: <347F89D03F3B4098A07AB4F3C3CC2154@oracle.com> Message-ID: <4F063AB4.9010509@oracle.com> Looks good. Igor, my mail client see the webrev link as text only in your mails. Could you fix it? Thanks, Vladimir Igor Veresov wrote: > Tiered crashed on x64 with -XX:-UseTLAB because the thread register was > not setup in MacroAssembler::incr_allocated_bytes() in case the thread > register passed as an argument was noreg. > > Webrev: http://cr.openjdk.java.net/~iveresov/7119294/webrev.00/ > > igor > From igor.veresov at oracle.com Thu Jan 5 16:11:14 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 5 Jan 2012 16:11:14 -0800 Subject: review(XS): 7119294: Two command line options cause JVM to crash. In-Reply-To: <4F063AB4.9010509@oracle.com> References: <347F89D03F3B4098A07AB4F3C3CC2154@oracle.com> <4F063AB4.9010509@oracle.com> Message-ID: On Thursday, January 5, 2012 at 4:05 PM, Vladimir Kozlov wrote: > Looks good. Thanks! > > Igor, my mail client see the webrev link as text only in your mails. Could you > fix it? Yeah, I forgot to switch to plain text... igor > > Thanks, > Vladimir > > Igor Veresov wrote: > > Tiered crashed on x64 with -XX:-UseTLAB because the thread register was > > not setup in MacroAssembler::incr_allocated_bytes() in case the thread > > register passed as an argument was noreg. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7119294/webrev.00/ > > > > igor From john.coomes at oracle.com Thu Jan 5 20:40:05 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:40:05 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b20 for changeset 5a5eaf6374bc Message-ID: <20120106044005.4F702478B3@hg.openjdk.java.net> Changeset: cc771d92284f Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/cc771d92284f Added tag jdk8-b20 for changeset 5a5eaf6374bc ! .hgtags From john.coomes at oracle.com Thu Jan 5 20:40:12 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:40:12 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b20 for changeset 51d8b6cb18c0 Message-ID: <20120106044014.F1B89478B4@hg.openjdk.java.net> Changeset: f157fc2a71a3 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/f157fc2a71a3 Added tag jdk8-b20 for changeset 51d8b6cb18c0 ! .hgtags From john.coomes at oracle.com Thu Jan 5 20:40:21 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:40:21 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b20 for changeset f052abb8f374 Message-ID: <20120106044021.EBE2D478B5@hg.openjdk.java.net> Changeset: d41eeadf5c13 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/d41eeadf5c13 Added tag jdk8-b20 for changeset f052abb8f374 ! .hgtags From john.coomes at oracle.com Thu Jan 5 20:40:28 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:40:28 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b20 for changeset 2b2818e3386f Message-ID: <20120106044028.BA2AB478B6@hg.openjdk.java.net> Changeset: dc2ee8b87884 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/dc2ee8b87884 Added tag jdk8-b20 for changeset 2b2818e3386f ! .hgtags From john.coomes at oracle.com Thu Jan 5 20:41:23 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:41:23 +0000 Subject: hg: hsx/hotspot-comp/jdk: 9 new changesets Message-ID: <20120106044326.1CA37478B7@hg.openjdk.java.net> Changeset: 172d70c50c65 Author: cgruszka Date: 2011-09-15 13:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/172d70c50c65 7066713: Separate demos from the bundles on Solaris and Linux Summary: add new license files to demos and samples, new directory for bundling Reviewed-by: katleman, ohair, billyh ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: eaf967fd25c5 Author: cgruszka Date: 2011-10-18 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/eaf967fd25c5 7099017: jdk7u2-dev does not build Summary: changes to skip demo/DEMOS_LICENSE and sample/SAMPLES_LICENSE when building OPENJDK Reviewed-by: ohair, billyh ! make/common/Release.gmk Changeset: 39b7f01203c9 Author: cgruszka Date: 2011-11-17 16:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39b7f01203c9 Merge Changeset: b64e7263b4fd Author: cgruszka Date: 2011-11-18 01:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b64e7263b4fd Merge Changeset: e98869ff9f1e Author: cgruszka Date: 2011-12-05 12:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e98869ff9f1e Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: ffa36a6a46f5 Author: cgruszka Date: 2011-12-16 15:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ffa36a6a46f5 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 5fe1525e6e2c Author: cgruszka Date: 2011-12-23 10:43 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5fe1525e6e2c Merge Changeset: 39e938cd1b82 Author: cgruszka Date: 2012-01-03 14:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39e938cd1b82 Merge Changeset: fc050750f8a0 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fc050750f8a0 Added tag jdk8-b20 for changeset 39e938cd1b82 ! .hgtags From john.coomes at oracle.com Thu Jan 5 20:44:38 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:44:38 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b20 for changeset ffd294128a48 Message-ID: <20120106044445.329D8478B8@hg.openjdk.java.net> Changeset: 020819eb56d2 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/020819eb56d2 Added tag jdk8-b20 for changeset ffd294128a48 ! .hgtags From christian.thalinger at oracle.com Fri Jan 6 00:12:11 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 6 Jan 2012 09:12:11 +0100 Subject: Crash in C2 with 7u2b13 In-Reply-To: References: <6AE9CE8B-1787-480B-B0DC-1CDFF139A36E@oracle.com> Message-ID: On Jan 4, 2012, at 7:30 PM, Tom Rodriguez wrote: > > On Jan 4, 2012, at 9:46 AM, Charles Oliver Nutter wrote: > >> Ok, the second user to report it started up the same application on a >> fastdebug build...and it didn't even boot all the way before crashing. >> Here's the log output: >> >> https://gist.github.com/935107b210befb41812a > > That makes some sense. That looks a bit like 7094138 which is fixed in hs23 which will be 7u4. That may explain the later crash during compilation though there's no guarantee. Stale oops can lead to almost any kind of crash. They could try testing with the latest 1.8 to confirm that there aren't other issues. The fix should have appeared in 1.8b15 and we're on b19 now. Yes, this certainly is 7094138. -- Chris > > tom > >> >> - Charlie >> >> On Tue, Jan 3, 2012 at 5:24 PM, Charles Oliver Nutter >> wrote: >>> I had another user report the same thing, and it only happens with >>> invokedynamic use (in JRuby) turned on. They are able to reproduce it >>> regularly, so I'll have them try a fastdebug build and see how that >>> goes. >>> >>> - Charlie >>> >>> On Tue, Jan 3, 2012 at 2:19 PM, Tom Rodriguez wrote: >>>> >>>> On Dec 31, 2011, at 12:10 PM, Charles Oliver Nutter wrote: >>>> >>>>> Got this report from a JRuby user, so I figured I'd toss it on this >>>>> list and see if I should report it (or if one of you want to look into >>>>> it directly): >>>>> >>>>> http://jira.codehaus.org/browse/JRUBY-6297 >>>>> >>>>> It's crashing in one of the compiler threads in >>>>> ciMethod::resolve_invoke, as far as I can tell. I have no simple >>>>> reproduction at the moment :( >>>> >>>> It's hard to conclude anything from the hs_err other than it looks like an unexpected NULL. Try a fastdebug build to maybe get more info or keep looking for a reproducible test case. >>>> >>>> tom >>>> >>>>> >>>>> - Charlie >>>> > From igor.veresov at oracle.com Fri Jan 6 00:29:05 2012 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 06 Jan 2012 08:29:05 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7119294: Two command line options cause JVM to crash Message-ID: <20120106082911.21E90478CA@hg.openjdk.java.net> Changeset: 1cb50d7a9d95 Author: iveresov Date: 2012-01-05 17:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1cb50d7a9d95 7119294: Two command line options cause JVM to crash Summary: Setup thread register in MacroAssembler::incr_allocated_bytes() on x64 Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp From vladimir.kozlov at oracle.com Fri Jan 6 23:18:19 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 07 Jan 2012 07:18:19 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 26 new changesets Message-ID: <20120107071910.C6612478DF@hg.openjdk.java.net> Changeset: 4ceaf61479fc Author: dcubed Date: 2011-12-22 12:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4ceaf61479fc 7122253: Instrumentation.retransformClasses() leaks class bytes Summary: Change ClassFileParser::parseClassFile() to use the instanceKlass:_cached_class_file_bytes field to avoid leaking the cache. Reviewed-by: coleenp, acorn, poonam ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4ec93d767458 Author: vladidan Date: 2011-12-26 20:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4ec93d767458 Merge Changeset: 3db6ea5ce021 Author: vladidan Date: 2011-12-29 20:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3db6ea5ce021 Merge Changeset: 20bfb6d15a94 Author: iveresov Date: 2011-12-27 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/20bfb6d15a94 7124829: NUMA: memory leak on Linux with large pages Summary: In os::free_memory() use mmap with the same attributes as for the heap space Reviewed-by: kvn Contributed-by: Aleksey Ignatenko ! 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/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/runtime/os.hpp Changeset: 776173fc2df9 Author: stefank Date: 2011-12-29 07:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/776173fc2df9 7125516: G1: ~ConcurrentMark() frees incorrectly Summary: Replaced the code with a ShouldNotReachHere Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 5ee33ff9b1c4 Author: jmasa Date: 2012-01-03 10:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5ee33ff9b1c4 Merge Changeset: 75c0a73eee98 Author: coleenp Date: 2011-11-17 12:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/75c0a73eee98 7102776: Pack instanceKlass boolean fields into single u1 field Summary: Reduce class runtime memory usage by packing 4 instanceKlass boolean fields into single u1 field. Save 4-byte for each loaded class. Reviewed-by: dholmes, bobv, phh, twisti, never, coleenp Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: da4dd142ea01 Author: bobv Date: 2011-11-29 14:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/da4dd142ea01 Merge ! src/share/vm/code/dependencies.cpp Changeset: 52b5d32fbfaf Author: coleenp Date: 2011-12-06 18:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/52b5d32fbfaf 7117052: instanceKlass::_init_state can be u1 type Summary: Change instanceKlass::_init_state field to u1 type. Reviewed-by: bdelsart, coleenp, dholmes, phh, never Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: eccc4b1f8945 Author: vladidan Date: 2011-12-07 16:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eccc4b1f8945 7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle Summary: missing release barrier in Monitor::IUnlock Reviewed-by: dholmes, dice ! src/share/vm/runtime/mutex.cpp Changeset: 2685ea97b89f Author: jiangli Date: 2011-12-09 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2685ea97b89f Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: 8fdf463085e1 Author: jiangli Date: 2011-12-16 17:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8fdf463085e1 Merge Changeset: dca455dea3a7 Author: bdelsart Date: 2011-12-20 12:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dca455dea3a7 7116216: StackOverflow GC crash Summary: GC crash for explicit stack overflow checks after a C2I transition. Reviewed-by: coleenp, never Contributed-by: yang02.wang at sap.com, bertrand.delsart at oracle.com ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp + test/compiler/7116216/LargeFrame.java + test/compiler/7116216/StackOverflow.java Changeset: cd5d8cafcc84 Author: jiangli Date: 2011-12-28 12:15 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cd5d8cafcc84 7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type. Summary: Change instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count to u2 type. Reviewed-by: never, bdelsart, dholmes Contributed-by: Jiangli Zhou ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 05de27e852c4 Author: jiangli Date: 2012-01-04 12:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/05de27e852c4 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: b6a04c79ccbc Author: stefank Date: 2012-01-02 10:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b6a04c79ccbc 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 Summary: Used uintptr_t and void* for all the casts and checks in test_is_in. Reviewed-by: tonyp, jmasa ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 4753e3dda3c8 Author: jmasa Date: 2012-01-04 07:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4753e3dda3c8 Merge Changeset: 2ee4167627a3 Author: jmasa Date: 2012-01-05 21:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2ee4167627a3 Merge Changeset: 7ab5f6318694 Author: phh Date: 2012-01-01 11:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7ab5f6318694 7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64 Summary: Add rdtsc detection and inline generation. Reviewed-by: kamg, dholmes Contributed-by: karen.kinnear at oracle.com ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp + src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp + src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp + src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + src/share/vm/runtime/os_ext.hpp Changeset: b16494a69d3d Author: phh Date: 2012-01-03 15:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b16494a69d3d 7126185: Clean up lasterror handling, add os::get_last_error() Summary: Add os::get_last_error(), replace getLastErrorString() by os::lasterror() in os_windows.cpp. Reviewed-by: kamg, dholmes Contributed-by: erik.gahlin at oracle.com ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 5b58979183f9 Author: dcubed Date: 2012-01-05 06:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5b58979183f9 7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary Summary: Use JavaThread::jvmti_thread_state() instead of JvmtiThreadState::state_for(). Reviewed-by: coleenp, poonam, acorn ! src/share/vm/classfile/classFileParser.cpp Changeset: 8a63c6323842 Author: fparain Date: 2012-01-05 07:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8a63c6323842 7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Reviewed-by: sspitsyn, dcubed, mchung, dholmes ! src/share/vm/services/threadService.cpp Changeset: 2e0ef19fc891 Author: phh Date: 2012-01-05 17:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2e0ef19fc891 7126480: Make JVM start time in milliseconds since the Java epoch available Summary: Expose existing Management::_begin_vm_creation_time via new accessor Management::begin_vm_creation_time(). Reviewed-by: acorn, dcubed ! src/share/vm/services/management.hpp Changeset: 66259eca2bf7 Author: phh Date: 2012-01-05 17:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/66259eca2bf7 Merge Changeset: 2b3acb34791f Author: dcubed Date: 2012-01-06 16:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2b3acb34791f Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/os.hpp Changeset: 22cee0ee8927 Author: kvn Date: 2012-01-06 20:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/22cee0ee8927 Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp From vladimir.kozlov at oracle.com Sat Jan 7 13:07:42 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 07 Jan 2012 21:07:42 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM Message-ID: <20120107210746.E4331478E2@hg.openjdk.java.net> Changeset: 5da7201222d5 Author: kvn Date: 2012-01-07 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5da7201222d5 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM Summary: Change yank_if_dead() to recursive method to remove all dead inputs. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp From vladimir.kozlov at oracle.com Sat Jan 7 15:48:58 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 07 Jan 2012 23:48:58 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7125896: Eliminate nested locks Message-ID: <20120107234901.0C9B6478E3@hg.openjdk.java.net> Changeset: e9a5e0a812c8 Author: kvn Date: 2012-01-07 13:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e9a5e0a812c8 7125896: Eliminate nested locks Summary: Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp From vladimir.kozlov at oracle.com Mon Jan 9 14:08:19 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 09 Jan 2012 14:08:19 -0800 Subject: Request for reviews (S): 7128352: assert(obj_node == obj) failed Message-ID: <4F0B6553.7050006@oracle.com> http://cr.openjdk.java.net/~kvn/7128352/webrev 7128352: assert(obj_node == obj) failed The assert was added in 7125896 changes. Object reference in monitor info could be CheckCastPP of the locked object. Compare uncasted object nodes. Also added missing "public" for 7116216/StackOverflow.java. Tested with full CTW and compiler regression tests. Thanks, Vladimir From tom.rodriguez at oracle.com Mon Jan 9 15:40:36 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 9 Jan 2012 15:40:36 -0800 Subject: Request for reviews (S): 7128352: assert(obj_node == obj) failed In-Reply-To: <4F0B6553.7050006@oracle.com> References: <4F0B6553.7050006@oracle.com> Message-ID: <92BB5C0F-F7A6-4C1A-94AF-11C0815EB8A7@oracle.com> On Jan 9, 2012, at 2:08 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7128352/webrev > > 7128352: assert(obj_node == obj) failed > > The assert was added in 7125896 changes. Object reference in monitor info could be CheckCastPP of the locked object. Compare uncasted object nodes. The change looks fine though it duplicates PhaseTransform::eqv_uncast. Maybe that should be removed in favor of the new one? It doesn't make a lot of sense that it's in PhaseTransform in the first place. Oddly, uncast is depth limited, which might be ok for existing uses, but does your use require that it doesn't give up? tom > > Also added missing "public" for 7116216/StackOverflow.java. > > Tested with full CTW and compiler regression tests. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Mon Jan 9 16:53:56 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 09 Jan 2012 16:53:56 -0800 Subject: Request for reviews (S): 7128352: assert(obj_node == obj) failed In-Reply-To: <92BB5C0F-F7A6-4C1A-94AF-11C0815EB8A7@oracle.com> References: <4F0B6553.7050006@oracle.com> <92BB5C0F-F7A6-4C1A-94AF-11C0815EB8A7@oracle.com> Message-ID: <4F0B8C24.4050206@oracle.com> Thank you, Tom Tom Rodriguez wrote: > On Jan 9, 2012, at 2:08 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7128352/webrev >> >> 7128352: assert(obj_node == obj) failed >> >> The assert was added in 7125896 changes. Object reference in monitor info could be CheckCastPP of the locked object. Compare uncasted object nodes. > > The change looks fine though it duplicates PhaseTransform::eqv_uncast. Maybe that should be removed in favor of the new one? It doesn't make a lot of sense that it's in PhaseTransform in the first place. Replaced. > Oddly, uncast is depth limited, which might be ok for existing uses, but does your use require that it doesn't give up? It is s problem. It also problem for EA where it is heavy used. Other places may also expecting full uncast. I changed it to be unlimited but in debug mode added dead loop check for 1000 iterations which is "reasonable", I think. I updated webrev. Thanks, Vladimir > > tom > >> Also added missing "public" for 7116216/StackOverflow.java. >> >> Tested with full CTW and compiler regression tests. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Tue Jan 10 15:36:51 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 10 Jan 2012 15:36:51 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Message-ID: <4F0CCB93.7010005@oracle.com> http://cr.openjdk.java.net/~kvn/7128355/webrev 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Regression after 7125896 changes. Merge Phi was not created for BoxLockNode. Other problems showed up after fixing this: - EA did not recognize BoxLock phis. EA should ignore them. - Matcher and RA does not expect box phis in debug info. Next assert was hit: assert((op == Op_BoxLock) == jvms->is_monitor_use(i), "boxes only at monitor sites"); - Lock elimination code may miss some safepoints (because they separated by additional phi nodes) when replacing old box (which could be Phi) with new "eliminated" Box. As result debug info could be incorrect. Do commoning of merged Box nodes (which has Phi uses) before locks elimination to resolve these problems. Tested with full CTW and compiler regression tests. Thanks, Vladimir From tom.rodriguez at oracle.com Tue Jan 10 16:08:54 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 10 Jan 2012 16:08:54 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <4F0CCB93.7010005@oracle.com> References: <4F0CCB93.7010005@oracle.com> Message-ID: On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7128355/webrev > > 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed > > Regression after 7125896 changes. Merge Phi was not created for BoxLockNode. > Other problems showed up after fixing this: > - EA did not recognize BoxLock phis. EA should ignore them. > - Matcher and RA does not expect box phis in debug info. Next assert was hit: > assert((op == Op_BoxLock) == jvms->is_monitor_use(i), "boxes only at monitor sites"); > - Lock elimination code may miss some safepoints (because they separated by additional phi nodes) when replacing old box (which could be Phi) with new "eliminated" Box. As result debug info could be incorrect. > > Do commoning of merged Box nodes (which has Phi uses) before locks elimination to resolve these problems. Doesn't that break nested lock elimination? Two unrelated boxes that happened to participate in different Phis could end up commoned together wouldn't they? Don't you want to perform explicit Phi simplification instead, replacing the Phi and all other boxes with one of the boxes feeding the Phi? tom > > Tested with full CTW and compiler regression tests. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Jan 10 16:52:01 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 10 Jan 2012 16:52:01 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: References: <4F0CCB93.7010005@oracle.com> Message-ID: <4F0CDD31.50104@oracle.com> Tom Rodriguez wrote: > On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7128355/webrev >> >> 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed >> >> Regression after 7125896 changes. Merge Phi was not created for BoxLockNode. >> Other problems showed up after fixing this: >> - EA did not recognize BoxLock phis. EA should ignore them. >> - Matcher and RA does not expect box phis in debug info. Next assert was hit: >> assert((op == Op_BoxLock) == jvms->is_monitor_use(i), "boxes only at monitor sites"); >> - Lock elimination code may miss some safepoints (because they separated by additional phi nodes) when replacing old box (which could be Phi) with new "eliminated" Box. As result debug info could be incorrect. >> >> Do commoning of merged Box nodes (which has Phi uses) before locks elimination to resolve these problems. > > Doesn't that break nested lock elimination? Possible but rare since merged boxes are rare cases. It does not affect normal case when Box node is unique for nested lock region. The failure I see is OSR compilations of nested loop inside synchronized scope and compilations of irreducible loops. The scenario where nested lock elimination will be broken is when during first locks nodes elimination (after EA) Box node was commoned because it has Phi user but later after CCP that Phi could be eliminated so Box could became unique. I thought about doing box commoning only after all optimizations done. But I concern that during first locks elimination after EA not all safepoints will be patched. > Two unrelated boxes that happened to participate in different Phis could end up commoned together wouldn't they? Don't you want to perform explicit Phi simplification instead, replacing the Phi and all other boxes with one of the boxes feeding the Phi? For eliminating locks of non escaped objects it does not matter that unrelated Boxes are commoned - it worked before. And I want this because it allows to find all related safepoints. Consider case of different lock regions of the same non escaped object. Thanks, Vladimir > > tom > >> Tested with full CTW and compiler regression tests. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Tue Jan 10 17:36:28 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 10 Jan 2012 17:36:28 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <4F0CDD31.50104@oracle.com> References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> Message-ID: <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> On Jan 10, 2012, at 4:52 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7128355/webrev >>> >>> 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed >>> >>> Regression after 7125896 changes. Merge Phi was not created for BoxLockNode. >>> Other problems showed up after fixing this: >>> - EA did not recognize BoxLock phis. EA should ignore them. >>> - Matcher and RA does not expect box phis in debug info. Next assert was hit: >>> assert((op == Op_BoxLock) == jvms->is_monitor_use(i), "boxes only at monitor sites"); >>> - Lock elimination code may miss some safepoints (because they separated by additional phi nodes) when replacing old box (which could be Phi) with new "eliminated" Box. As result debug info could be incorrect. >>> >>> Do commoning of merged Box nodes (which has Phi uses) before locks elimination to resolve these problems. >> Doesn't that break nested lock elimination? > > Possible but rare since merged boxes are rare cases. But it would still be a bug wouldn't it? Nested lock elimination is relying on the BoxLock identity to eliminate the useless operations for some locking region. I think the rules for the box lock are way too complicated after these changes. The commoning behaviour shouldn't be conditional on EliminateNestedLocks so that we can settle on some standard set of rules for how they operate. I think BoxLockNodes should never common and any Phi of BoxLocks should simplify into a single set BoxLock. This could be done with specific logic in PhiNode::Ideal that replaces any Phi with a single BoxLock during IGVN. We'll have to make sure we reprocess them after parse but that doesn't seem that hard. I think we want to maintain the invariant that after parse there aren't any Phi's of BoxLock. That's a good rule. tom > It does not affect normal case when Box node is unique for nested lock region. The failure I see is OSR compilations of nested loop inside synchronized scope and compilations of irreducible loops. The scenario where nested lock elimination will be broken is when during first locks nodes elimination (after EA) Box node was commoned because it has Phi user but later after CCP that Phi could be eliminated so Box could became unique. I thought about doing box commoning only after all optimizations done. But I concern that during first locks elimination after EA not all safepoints will be patched. > >> Two unrelated boxes that happened to participate in different Phis could end up commoned together wouldn't they? Don't you want to perform explicit Phi simplification instead, replacing the Phi and all other boxes with one of the boxes feeding the Phi? > > For eliminating locks of non escaped objects it does not matter that unrelated Boxes are commoned - it worked before. And I want this because it allows to find all related safepoints. Consider case of different lock regions of the same non escaped object. > > Thanks, > Vladimir > >> tom >>> Tested with full CTW and compiler regression tests. >>> >>> Thanks, >>> Vladimir From tom.rodriguez at oracle.com Tue Jan 10 17:40:46 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 10 Jan 2012 17:40:46 -0800 Subject: Request for reviews (S): 7128352: assert(obj_node == obj) failed In-Reply-To: <4F0B8C24.4050206@oracle.com> References: <4F0B6553.7050006@oracle.com> <92BB5C0F-F7A6-4C1A-94AF-11C0815EB8A7@oracle.com> <4F0B8C24.4050206@oracle.com> Message-ID: That looks good. tom On Jan 9, 2012, at 4:53 PM, Vladimir Kozlov wrote: > Thank you, Tom > > Tom Rodriguez wrote: >> On Jan 9, 2012, at 2:08 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7128352/webrev >>> >>> 7128352: assert(obj_node == obj) failed >>> >>> The assert was added in 7125896 changes. Object reference in monitor info could be CheckCastPP of the locked object. Compare uncasted object nodes. >> The change looks fine though it duplicates PhaseTransform::eqv_uncast. Maybe that should be removed in favor of the new one? It doesn't make a lot of sense that it's in PhaseTransform in the first place. > > Replaced. > >> Oddly, uncast is depth limited, which might be ok for existing uses, but does your use require that it doesn't give up? > > It is s problem. It also problem for EA where it is heavy used. Other places may also expecting full uncast. I changed it to be unlimited but in debug mode added dead loop check for 1000 iterations which is "reasonable", I think. > > I updated webrev. > > Thanks, > Vladimir > >> tom >>> Also added missing "public" for 7116216/StackOverflow.java. >>> >>> Tested with full CTW and compiler regression tests. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Tue Jan 10 17:41:22 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 10 Jan 2012 17:41:22 -0800 Subject: Request for reviews (S): 7128352: assert(obj_node == obj) failed In-Reply-To: References: <4F0B6553.7050006@oracle.com> <92BB5C0F-F7A6-4C1A-94AF-11C0815EB8A7@oracle.com> <4F0B8C24.4050206@oracle.com> Message-ID: <4F0CE8C2.2020809@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > That looks good. > > tom > > On Jan 9, 2012, at 4:53 PM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Tom Rodriguez wrote: >>> On Jan 9, 2012, at 2:08 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7128352/webrev >>>> >>>> 7128352: assert(obj_node == obj) failed >>>> >>>> The assert was added in 7125896 changes. Object reference in monitor info could be CheckCastPP of the locked object. Compare uncasted object nodes. >>> The change looks fine though it duplicates PhaseTransform::eqv_uncast. Maybe that should be removed in favor of the new one? It doesn't make a lot of sense that it's in PhaseTransform in the first place. >> Replaced. >> >>> Oddly, uncast is depth limited, which might be ok for existing uses, but does your use require that it doesn't give up? >> It is s problem. It also problem for EA where it is heavy used. Other places may also expecting full uncast. I changed it to be unlimited but in debug mode added dead loop check for 1000 iterations which is "reasonable", I think. >> >> I updated webrev. >> >> Thanks, >> Vladimir >> >>> tom >>>> Also added missing "public" for 7116216/StackOverflow.java. >>>> >>>> Tested with full CTW and compiler regression tests. >>>> >>>> Thanks, >>>> Vladimir > From vladimir.kozlov at oracle.com Tue Jan 10 18:05:07 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 10 Jan 2012 18:05:07 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> Message-ID: <4F0CEE53.4060707@oracle.com> Tom Rodriguez wrote: > On Jan 10, 2012, at 4:52 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>> On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7128355/webrev >>>> >>>> 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed >>> Doesn't that break nested lock elimination? >> Possible but rare since merged boxes are rare cases. > > But it would still be a bug wouldn't it? Nested lock elimination is relying on the BoxLock identity to eliminate the useless operations for some locking region. Why it is bug? It is only opportunity lost: nested lock will not be eliminated if Box is marked as commoned. But I agree with you, the logic become too complex. I will try to replace Phi with Box node after Parse and add checks to make sure such phis are not created during optimizations. I will not common boxes in new code. But I want to keep EliminateNestedLocks flags to be able restore previous behavior. Thanks, Vladimir > > I think the rules for the box lock are way too complicated after these changes. The commoning behaviour shouldn't be conditional on EliminateNestedLocks so that we can settle on some standard set of rules for how they operate. I think BoxLockNodes should never common and any Phi of BoxLocks should simplify into a single set BoxLock. This could be done with specific logic in PhiNode::Ideal that replaces any Phi with a single BoxLock during IGVN. We'll have to make sure we reprocess them after parse but that doesn't seem that hard. I think we want to maintain the invariant that after parse there aren't any Phi's of BoxLock. That's a good rule. > > tom > >> It does not affect normal case when Box node is unique for nested lock region. The failure I see is OSR compilations of nested loop inside synchronized scope and compilations of irreducible loops. The scenario where nested lock elimination will be broken is when during first locks nodes elimination (after EA) Box node was commoned because it has Phi user but later after CCP that Phi could be eliminated so Box could became unique. I thought about doing box commoning only after all optimizations done. But I concern that during first locks elimination after EA not all safepoints will be patched. >> >>> Two unrelated boxes that happened to participate in different Phis could end up commoned together wouldn't they? Don't you want to perform explicit Phi simplification instead, replacing the Phi and all other boxes with one of the boxes feeding the Phi? >> For eliminating locks of non escaped objects it does not matter that unrelated Boxes are commoned - it worked before. And I want this because it allows to find all related safepoints. Consider case of different lock regions of the same non escaped object. >> >> Thanks, >> Vladimir >> >>> tom >>>> Tested with full CTW and compiler regression tests. >>>> >>>> Thanks, >>>> Vladimir > From vladimir.kozlov at oracle.com Wed Jan 11 00:34:59 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 11 Jan 2012 08:34:59 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7128352: assert(obj_node == obj) failed Message-ID: <20120111083503.DB94F47919@hg.openjdk.java.net> Changeset: 35acf8f0a2e4 Author: kvn Date: 2012-01-10 18:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/35acf8f0a2e4 7128352: assert(obj_node == obj) failed Summary: Compare uncasted object nodes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/subnode.cpp ! test/compiler/7116216/StackOverflow.java From tom.rodriguez at oracle.com Wed Jan 11 11:27:57 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 11 Jan 2012 11:27:57 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <4F0CEE53.4060707@oracle.com> References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> <4F0CEE53.4060707@oracle.com> Message-ID: <92955949-1C81-4E86-AE90-C8A81BCB339F@oracle.com> On Jan 10, 2012, at 6:05 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> On Jan 10, 2012, at 4:52 PM, Vladimir Kozlov wrote: >>> Tom Rodriguez wrote: >>>> On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7128355/webrev >>>>> >>>>> 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed >>>> Doesn't that break nested lock elimination? >>> Possible but rare since merged boxes are rare cases. >> But it would still be a bug wouldn't it? Nested lock elimination is relying on the BoxLock identity to eliminate the useless operations for some locking region. > > Why it is bug? It is only opportunity lost: nested lock will not be eliminated if Box is marked as communed. I missed that is_commoned disabled the optimization. tom > > But I agree with you, the logic become too complex. I will try to replace Phi with Box node after Parse and add checks to make sure such phis are not created during optimizations. I will not common boxes in new code. But I want to keep EliminateNestedLocks flags to be able restore previous behavior. > > Thanks, > Vladimir > >> I think the rules for the box lock are way too complicated after these changes. The commoning behaviour shouldn't be conditional on EliminateNestedLocks so that we can settle on some standard set of rules for how they operate. I think BoxLockNodes should never common and any Phi of BoxLocks should simplify into a single set BoxLock. This could be done with specific logic in PhiNode::Ideal that replaces any Phi with a single BoxLock during IGVN. We'll have to make sure we reprocess them after parse but that doesn't seem that hard. I think we want to maintain the invariant that after parse there aren't any Phi's of BoxLock. That's a good rule. >> tom >>> It does not affect normal case when Box node is unique for nested lock region. The failure I see is OSR compilations of nested loop inside synchronized scope and compilations of irreducible loops. The scenario where nested lock elimination will be broken is when during first locks nodes elimination (after EA) Box node was commoned because it has Phi user but later after CCP that Phi could be eliminated so Box could became unique. I thought about doing box commoning only after all optimizations done. But I concern that during first locks elimination after EA not all safepoints will be patched. >>> >>>> Two unrelated boxes that happened to participate in different Phis could end up commoned together wouldn't they? Don't you want to perform explicit Phi simplification instead, replacing the Phi and all other boxes with one of the boxes feeding the Phi? >>> For eliminating locks of non escaped objects it does not matter that unrelated Boxes are commoned - it worked before. And I want this because it allows to find all related safepoints. Consider case of different lock regions of the same non escaped object. >>> >>> Thanks, >>> Vladimir >>> >>>> tom >>>>> Tested with full CTW and compiler regression tests. >>>>> >>>>> Thanks, >>>>> Vladimir From vladimir.kozlov at oracle.com Wed Jan 11 17:51:28 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 Jan 2012 17:51:28 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <4F0CEE53.4060707@oracle.com> References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> <4F0CEE53.4060707@oracle.com> Message-ID: <4F0E3CA0.1000004@oracle.com> Updated changes. http://cr.openjdk.java.net/~kvn/7128355/webrev.01 Don not common BoxLock nodes and avoid creating phis of boxes. During parsing replace new BoxLock node with old BoxLock node at merge points. Use as_BoxLock() which checks that node is BoxLockNode instead of BoxLockNode::box_node(). Call box_node() node only after RA which may create spills of BoxLock nodes. Vladimir Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> On Jan 10, 2012, at 4:52 PM, Vladimir Kozlov wrote: >> >>> Tom Rodriguez wrote: >>>> On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7128355/webrev >>>>> >>>>> 7128355: assert(!nocreate) failed: Cannot build a phi for a block >>>>> already parsed >>>> Doesn't that break nested lock elimination? >>> Possible but rare since merged boxes are rare cases. >> >> But it would still be a bug wouldn't it? Nested lock elimination is >> relying on the BoxLock identity to eliminate the useless operations >> for some locking region. > > Why it is bug? It is only opportunity lost: nested lock will not be > eliminated if Box is marked as commoned. > > But I agree with you, the logic become too complex. I will try to > replace Phi with Box node after Parse and add checks to make sure such > phis are not created during optimizations. I will not common boxes in > new code. But I want to keep EliminateNestedLocks flags to be able > restore previous behavior. > > Thanks, > Vladimir > >> >> I think the rules for the box lock are way too complicated after these >> changes. The commoning behaviour shouldn't be conditional on >> EliminateNestedLocks so that we can settle on some standard set of >> rules for how they operate. I think BoxLockNodes should never common >> and any Phi of BoxLocks should simplify into a single set BoxLock. >> This could be done with specific logic in PhiNode::Ideal that replaces >> any Phi with a single BoxLock during IGVN. We'll have to make sure we >> reprocess them after parse but that doesn't seem that hard. I think >> we want to maintain the invariant that after parse there aren't any >> Phi's of BoxLock. That's a good rule. >> >> tom >> >>> It does not affect normal case when Box node is unique for nested >>> lock region. The failure I see is OSR compilations of nested loop >>> inside synchronized scope and compilations of irreducible loops. The >>> scenario where nested lock elimination will be broken is when during >>> first locks nodes elimination (after EA) Box node was commoned >>> because it has Phi user but later after CCP that Phi could be >>> eliminated so Box could became unique. I thought about doing box >>> commoning only after all optimizations done. But I concern that >>> during first locks elimination after EA not all safepoints will be >>> patched. >>> >>>> Two unrelated boxes that happened to participate in different Phis >>>> could end up commoned together wouldn't they? Don't you want to >>>> perform explicit Phi simplification instead, replacing the Phi and >>>> all other boxes with one of the boxes feeding the Phi? >>> For eliminating locks of non escaped objects it does not matter that >>> unrelated Boxes are commoned - it worked before. And I want this >>> because it allows to find all related safepoints. Consider case of >>> different lock regions of the same non escaped object. >>> >>> Thanks, >>> Vladimir >>> >>>> tom >>>>> Tested with full CTW and compiler regression tests. >>>>> >>>>> Thanks, >>>>> Vladimir >> From tom.rodriguez at oracle.com Thu Jan 12 10:21:59 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 12 Jan 2012 10:21:59 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <4F0E3CA0.1000004@oracle.com> References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> <4F0CEE53.4060707@oracle.com> <4F0E3CA0.1000004@oracle.com> Message-ID: <53FAF387-60CD-4041-A52F-C4D3D2EFACD7@oracle.com> On Jan 11, 2012, at 5:51 PM, Vladimir Kozlov wrote: > Updated changes. > > http://cr.openjdk.java.net/~kvn/7128355/webrev.01 > > Don not common BoxLock nodes and avoid creating phis of boxes. During parsing replace new BoxLock node with old BoxLock node at merge points. Use as_BoxLock() which checks that node is BoxLockNode instead of BoxLockNode::box_node(). Call box_node() node only after RA which may create spills of BoxLock nodes. I like that better. tom > > Vladimir > > Vladimir Kozlov wrote: >> Tom Rodriguez wrote: >>> On Jan 10, 2012, at 4:52 PM, Vladimir Kozlov wrote: >>> >>>> Tom Rodriguez wrote: >>>>> On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7128355/webrev >>>>>> >>>>>> 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed >>>>> Doesn't that break nested lock elimination? >>>> Possible but rare since merged boxes are rare cases. >>> >>> But it would still be a bug wouldn't it? Nested lock elimination is relying on the BoxLock identity to eliminate the useless operations for some locking region. >> Why it is bug? It is only opportunity lost: nested lock will not be eliminated if Box is marked as commoned. >> But I agree with you, the logic become too complex. I will try to replace Phi with Box node after Parse and add checks to make sure such phis are not created during optimizations. I will not common boxes in new code. But I want to keep EliminateNestedLocks flags to be able restore previous behavior. >> Thanks, >> Vladimir >>> >>> I think the rules for the box lock are way too complicated after these changes. The commoning behaviour shouldn't be conditional on EliminateNestedLocks so that we can settle on some standard set of rules for how they operate. I think BoxLockNodes should never common and any Phi of BoxLocks should simplify into a single set BoxLock. This could be done with specific logic in PhiNode::Ideal that replaces any Phi with a single BoxLock during IGVN. We'll have to make sure we reprocess them after parse but that doesn't seem that hard. I think we want to maintain the invariant that after parse there aren't any Phi's of BoxLock. That's a good rule. >>> >>> tom >>> >>>> It does not affect normal case when Box node is unique for nested lock region. The failure I see is OSR compilations of nested loop inside synchronized scope and compilations of irreducible loops. The scenario where nested lock elimination will be broken is when during first locks nodes elimination (after EA) Box node was commoned because it has Phi user but later after CCP that Phi could be eliminated so Box could became unique. I thought about doing box commoning only after all optimizations done. But I concern that during first locks elimination after EA not all safepoints will be patched. >>>> >>>>> Two unrelated boxes that happened to participate in different Phis could end up commoned together wouldn't they? Don't you want to perform explicit Phi simplification instead, replacing the Phi and all other boxes with one of the boxes feeding the Phi? >>>> For eliminating locks of non escaped objects it does not matter that unrelated Boxes are commoned - it worked before. And I want this because it allows to find all related safepoints. Consider case of different lock regions of the same non escaped object. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> tom >>>>>> Tested with full CTW and compiler regression tests. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>> From vladimir.kozlov at oracle.com Thu Jan 12 10:35:27 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Jan 2012 10:35:27 -0800 Subject: Request for reviews (S): 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Message-ID: <4F0F27EF.50905@oracle.com> http://cr.openjdk.java.net/~kvn/7064302/webrev 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Very rare case when CMoveP control edge is CountedLoop back control. During loop iteration splitting CMoveP clone is placed on entry path of post-loop. Later when pre-loop is created clone_loop() code pulls Bool and Cmp nodes through Phi down to CMoveP clone. Note that Phi's region is above CMoveP clone's control which is fallthrough path of post-loop's zero-trip guard. Split through Phi optimization tries to reverse this merged subgraph and incorrectly splits this CMoveP node. As result 2 clones of CMoveP were placed at the same place as original node. It creates bad graph. The fix itself is very small: don't split CMove node if it's control edge is different from split region. Large part of changes is additional debug output in build_loop_late_post() where bad graph is detected. It helped me investigate this problem. I also added missing initialization of local variable. I was not able to construct regression test but customer verified the fix. Thanks, Vladimir From vladimir.kozlov at oracle.com Thu Jan 12 10:48:11 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Jan 2012 10:48:11 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <53FAF387-60CD-4041-A52F-C4D3D2EFACD7@oracle.com> References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> <4F0CEE53.4060707@oracle.com> <4F0E3CA0.1000004@oracle.com> <53FAF387-60CD-4041-A52F-C4D3D2EFACD7@oracle.com> Message-ID: <4F0F2AEB.4050906@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > On Jan 11, 2012, at 5:51 PM, Vladimir Kozlov wrote: > >> Updated changes. >> >> http://cr.openjdk.java.net/~kvn/7128355/webrev.01 >> >> Don not common BoxLock nodes and avoid creating phis of boxes. During parsing replace new BoxLock node with old BoxLock node at merge points. Use as_BoxLock() which checks that node is BoxLockNode instead of BoxLockNode::box_node(). Call box_node() node only after RA which may create spills of BoxLock nodes. > > I like that better. > > tom > >> Vladimir >> >> Vladimir Kozlov wrote: >>> Tom Rodriguez wrote: >>>> On Jan 10, 2012, at 4:52 PM, Vladimir Kozlov wrote: >>>> >>>>> Tom Rodriguez wrote: >>>>>> On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/7128355/webrev >>>>>>> >>>>>>> 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed >>>>>> Doesn't that break nested lock elimination? >>>>> Possible but rare since merged boxes are rare cases. >>>> But it would still be a bug wouldn't it? Nested lock elimination is relying on the BoxLock identity to eliminate the useless operations for some locking region. >>> Why it is bug? It is only opportunity lost: nested lock will not be eliminated if Box is marked as commoned. >>> But I agree with you, the logic become too complex. I will try to replace Phi with Box node after Parse and add checks to make sure such phis are not created during optimizations. I will not common boxes in new code. But I want to keep EliminateNestedLocks flags to be able restore previous behavior. >>> Thanks, >>> Vladimir >>>> I think the rules for the box lock are way too complicated after these changes. The commoning behaviour shouldn't be conditional on EliminateNestedLocks so that we can settle on some standard set of rules for how they operate. I think BoxLockNodes should never common and any Phi of BoxLocks should simplify into a single set BoxLock. This could be done with specific logic in PhiNode::Ideal that replaces any Phi with a single BoxLock during IGVN. We'll have to make sure we reprocess them after parse but that doesn't seem that hard. I think we want to maintain the invariant that after parse there aren't any Phi's of BoxLock. That's a good rule. >>>> >>>> tom >>>> >>>>> It does not affect normal case when Box node is unique for nested lock region. The failure I see is OSR compilations of nested loop inside synchronized scope and compilations of irreducible loops. The scenario where nested lock elimination will be broken is when during first locks nodes elimination (after EA) Box node was commoned because it has Phi user but later after CCP that Phi could be eliminated so Box could became unique. I thought about doing box commoning only after all optimizations done. But I concern that during first locks elimination after EA not all safepoints will be patched. >>>>> >>>>>> Two unrelated boxes that happened to participate in different Phis could end up commoned together wouldn't they? Don't you want to perform explicit Phi simplification instead, replacing the Phi and all other boxes with one of the boxes feeding the Phi? >>>>> For eliminating locks of non escaped objects it does not matter that unrelated Boxes are commoned - it worked before. And I want this because it allows to find all related safepoints. Consider case of different lock regions of the same non escaped object. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> tom >>>>>>> Tested with full CTW and compiler regression tests. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir > From tom.rodriguez at oracle.com Thu Jan 12 11:36:26 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 12 Jan 2012 11:36:26 -0800 Subject: Request for reviews (S): 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app In-Reply-To: <4F0F27EF.50905@oracle.com> References: <4F0F27EF.50905@oracle.com> Message-ID: <84E5B0A7-6E67-4B1D-9A64-139B6C8F2ECA@oracle.com> On Jan 12, 2012, at 10:35 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7064302/webrev > > 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app > > Very rare case when CMoveP control edge is CountedLoop back control. During loop iteration splitting CMoveP clone is placed on entry path of post-loop. Later when pre-loop is created clone_loop() code pulls Bool and Cmp nodes through Phi down to CMoveP clone. Note that Phi's region is above CMoveP clone's control which is fallthrough path of post-loop's zero-trip guard. > > Split through Phi optimization tries to reverse this merged subgraph and incorrectly splits this CMoveP node. As result 2 clones of CMoveP were placed at the same place as original node. It creates bad graph. > > The fix itself is very small: don't split CMove node if it's control edge is different from split region. Large part of changes is additional debug output in build_loop_late_post() where bad graph is detected. It helped me investigate this problem. The fix looks fine and the new dumping code looks extensive, which should really help debugging these problems. Can you move the debugging code into it's own function? It's in the middle of a relatively simple loop and completely dwarfs the body. tom > > I also added missing initialization of local variable. > > I was not able to construct regression test but customer verified the fix. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Jan 12 11:45:32 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Jan 2012 11:45:32 -0800 Subject: Request for reviews (S): 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app In-Reply-To: <84E5B0A7-6E67-4B1D-9A64-139B6C8F2ECA@oracle.com> References: <4F0F27EF.50905@oracle.com> <84E5B0A7-6E67-4B1D-9A64-139B6C8F2ECA@oracle.com> Message-ID: <4F0F385C.9020005@oracle.com> Thank you, Tom I will move dumping code as you suggested. Thanks, Vladimir Tom Rodriguez wrote: > On Jan 12, 2012, at 10:35 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7064302/webrev >> >> 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app >> >> Very rare case when CMoveP control edge is CountedLoop back control. During loop iteration splitting CMoveP clone is placed on entry path of post-loop. Later when pre-loop is created clone_loop() code pulls Bool and Cmp nodes through Phi down to CMoveP clone. Note that Phi's region is above CMoveP clone's control which is fallthrough path of post-loop's zero-trip guard. >> >> Split through Phi optimization tries to reverse this merged subgraph and incorrectly splits this CMoveP node. As result 2 clones of CMoveP were placed at the same place as original node. It creates bad graph. >> >> The fix itself is very small: don't split CMove node if it's control edge is different from split region. Large part of changes is additional debug output in build_loop_late_post() where bad graph is detected. It helped me investigate this problem. > > The fix looks fine and the new dumping code looks extensive, which should really help debugging these problems. Can you move the debugging code into it's own function? It's in the middle of a relatively simple loop and completely dwarfs the body. > > tom > >> I also added missing initialization of local variable. >> >> I was not able to construct regression test but customer verified the fix. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Thu Jan 12 13:27:27 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Jan 2012 13:27:27 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <4F0F2AEB.4050906@oracle.com> References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> <4F0CEE53.4060707@oracle.com> <4F0E3CA0.1000004@oracle.com> <53FAF387-60CD-4041-A52F-C4D3D2EFACD7@oracle.com> <4F0F2AEB.4050906@oracle.com> Message-ID: <4F0F503F.5010705@oracle.com> Tom, before pushing I ran additional tests (nsk.jdi) which failed during Nightly and found that they still failing next assert in BoxLockNode::is_simple_lock_region(): assert(obj_node->eqv_uncast(obj),""); http://cr.openjdk.java.net/~kvn/7128355/webrev.01/src/share/vm/opto/locknode.cpp.html It verifies that safepoint references the same object as locks in simple lock region. It failed because SFP references Phi node of different CheckCastPP nodes of that object so uncast() did not help. I think I can remove this safepoint verification since at that case all locks and unlocks associated with this Box are referencing the same object and it does not matter what SFP references (it should be the same object). But I use the same check "obj_node->eqv_uncast(obj)" when looking for safepoints in which old Box should be replaced with its clone in PhaseMacroExpand::mark_eliminated_box(). Monitor info will be incorrect when it does not match but locks are eliminated (since it is non escaped object). It seems, for safepoint checks I need something like eqv_uncast_and_unphi(obj) but it again become complex. Note, this problem existed - we had incorrect monitors info in safepoints. I will think more what I can do. Just letting you know that I may add more code to this fix. thanks, Vladimir Vladimir Kozlov wrote: > Thank you, Tom > > Vladimir > > Tom Rodriguez wrote: >> On Jan 11, 2012, at 5:51 PM, Vladimir Kozlov wrote: >> >>> Updated changes. >>> >>> http://cr.openjdk.java.net/~kvn/7128355/webrev.01 >>> >>> Don not common BoxLock nodes and avoid creating phis of boxes. During >>> parsing replace new BoxLock node with old BoxLock node at merge >>> points. Use as_BoxLock() which checks that node is BoxLockNode >>> instead of BoxLockNode::box_node(). Call box_node() node only after >>> RA which may create spills of BoxLock nodes. >> >> I like that better. >> >> tom >> >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> Tom Rodriguez wrote: >>>>> On Jan 10, 2012, at 4:52 PM, Vladimir Kozlov wrote: >>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: >>>>>>>> http://cr.openjdk.java.net/~kvn/7128355/webrev >>>>>>>> >>>>>>>> 7128355: assert(!nocreate) failed: Cannot build a phi for a >>>>>>>> block already parsed >>>>>>> Doesn't that break nested lock elimination? >>>>>> Possible but rare since merged boxes are rare cases. >>>>> But it would still be a bug wouldn't it? Nested lock elimination >>>>> is relying on the BoxLock identity to eliminate the useless >>>>> operations for some locking region. >>>> Why it is bug? It is only opportunity lost: nested lock will not be >>>> eliminated if Box is marked as commoned. >>>> But I agree with you, the logic become too complex. I will try to >>>> replace Phi with Box node after Parse and add checks to make sure >>>> such phis are not created during optimizations. I will not common >>>> boxes in new code. But I want to keep EliminateNestedLocks flags to >>>> be able restore previous behavior. >>>> Thanks, >>>> Vladimir >>>>> I think the rules for the box lock are way too complicated after >>>>> these changes. The commoning behaviour shouldn't be conditional on >>>>> EliminateNestedLocks so that we can settle on some standard set of >>>>> rules for how they operate. I think BoxLockNodes should never >>>>> common and any Phi of BoxLocks should simplify into a single set >>>>> BoxLock. This could be done with specific logic in PhiNode::Ideal >>>>> that replaces any Phi with a single BoxLock during IGVN. We'll >>>>> have to make sure we reprocess them after parse but that doesn't >>>>> seem that hard. I think we want to maintain the invariant that >>>>> after parse there aren't any Phi's of BoxLock. That's a good rule. >>>>> >>>>> tom >>>>> >>>>>> It does not affect normal case when Box node is unique for nested >>>>>> lock region. The failure I see is OSR compilations of nested loop >>>>>> inside synchronized scope and compilations of irreducible loops. >>>>>> The scenario where nested lock elimination will be broken is when >>>>>> during first locks nodes elimination (after EA) Box node was >>>>>> commoned because it has Phi user but later after CCP that Phi >>>>>> could be eliminated so Box could became unique. I thought about >>>>>> doing box commoning only after all optimizations done. But I >>>>>> concern that during first locks elimination after EA not all >>>>>> safepoints will be patched. >>>>>> >>>>>>> Two unrelated boxes that happened to participate in different >>>>>>> Phis could end up commoned together wouldn't they? Don't you >>>>>>> want to perform explicit Phi simplification instead, replacing >>>>>>> the Phi and all other boxes with one of the boxes feeding the Phi? >>>>>> For eliminating locks of non escaped objects it does not matter >>>>>> that unrelated Boxes are commoned - it worked before. And I want >>>>>> this because it allows to find all related safepoints. Consider >>>>>> case of different lock regions of the same non escaped object. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> tom >>>>>>>> Tested with full CTW and compiler regression tests. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >> From tom.rodriguez at oracle.com Thu Jan 12 14:49:20 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 12 Jan 2012 14:49:20 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <4F0F503F.5010705@oracle.com> References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> <4F0CEE53.4060707@oracle.com> <4F0E3CA0.1000004@oracle.com> <53FAF387-60CD-4041-A52F-C4D3D2EFACD7@oracle.com> <4F0F2AEB.4050906@oracle.com> <4F0F503F.5010705@oracle.com> Message-ID: <82179E60-444F-4D82-AE7D-95DDF5203828@oracle.com> On Jan 12, 2012, at 1:27 PM, Vladimir Kozlov wrote: > Tom, > > before pushing I ran additional tests (nsk.jdi) which failed during Nightly and found that they still failing next assert in BoxLockNode::is_simple_lock_region(): > > assert(obj_node->eqv_uncast(obj),""); > > http://cr.openjdk.java.net/~kvn/7128355/webrev.01/src/share/vm/opto/locknode.cpp.html > > It verifies that safepoint references the same object as locks in simple lock region. It failed because SFP references Phi node of different CheckCastPP nodes of that object so uncast() did not help. I think I can remove this safepoint verification since at that case all locks and unlocks associated with this Box are referencing the same object and it does not matter what SFP references (it should be the same object). > > But I use the same check "obj_node->eqv_uncast(obj)" when looking for safepoints in which old Box should be replaced with its clone in PhaseMacroExpand::mark_eliminated_box(). Monitor info will be incorrect when it does not match but locks are eliminated (since it is non escaped object). > > It seems, for safepoint checks I need something like eqv_uncast_and_unphi(obj) but it again become complex. Note, this problem existed - we had incorrect monitors info in safe points. It's not truly incorrect is it? It's just not easily provably equal. The fact that we're compiling it says that the locks are block structured so they must be equal. For an OSR in a nested loop with locking we're just trusting that they are referring to the same object. tom > > I will think more what I can do. Just letting you know that I may add more code to this fix. > > thanks, > Vladimir > > Vladimir Kozlov wrote: >> Thank you, Tom >> Vladimir >> Tom Rodriguez wrote: >>> On Jan 11, 2012, at 5:51 PM, Vladimir Kozlov wrote: >>> >>>> Updated changes. >>>> >>>> http://cr.openjdk.java.net/~kvn/7128355/webrev.01 >>>> >>>> Don not common BoxLock nodes and avoid creating phis of boxes. During parsing replace new BoxLock node with old BoxLock node at merge points. Use as_BoxLock() which checks that node is BoxLockNode instead of BoxLockNode::box_node(). Call box_node() node only after RA which may create spills of BoxLock nodes. >>> >>> I like that better. >>> >>> tom >>> >>>> Vladimir >>>> >>>> Vladimir Kozlov wrote: >>>>> Tom Rodriguez wrote: >>>>>> On Jan 10, 2012, at 4:52 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: >>>>>>>>> http://cr.openjdk.java.net/~kvn/7128355/webrev >>>>>>>>> >>>>>>>>> 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed >>>>>>>> Doesn't that break nested lock elimination? >>>>>>> Possible but rare since merged boxes are rare cases. >>>>>> But it would still be a bug wouldn't it? Nested lock elimination is relying on the BoxLock identity to eliminate the useless operations for some locking region. >>>>> Why it is bug? It is only opportunity lost: nested lock will not be eliminated if Box is marked as commoned. >>>>> But I agree with you, the logic become too complex. I will try to replace Phi with Box node after Parse and add checks to make sure such phis are not created during optimizations. I will not common boxes in new code. But I want to keep EliminateNestedLocks flags to be able restore previous behavior. >>>>> Thanks, >>>>> Vladimir >>>>>> I think the rules for the box lock are way too complicated after these changes. The commoning behaviour shouldn't be conditional on EliminateNestedLocks so that we can settle on some standard set of rules for how they operate. I think BoxLockNodes should never common and any Phi of BoxLocks should simplify into a single set BoxLock. This could be done with specific logic in PhiNode::Ideal that replaces any Phi with a single BoxLock during IGVN. We'll have to make sure we reprocess them after parse but that doesn't seem that hard. I think we want to maintain the invariant that after parse there aren't any Phi's of BoxLock. That's a good rule. >>>>>> >>>>>> tom >>>>>> >>>>>>> It does not affect normal case when Box node is unique for nested lock region. The failure I see is OSR compilations of nested loop inside synchronized scope and compilations of irreducible loops. The scenario where nested lock elimination will be broken is when during first locks nodes elimination (after EA) Box node was commoned because it has Phi user but later after CCP that Phi could be eliminated so Box could became unique. I thought about doing box commoning only after all optimizations done. But I concern that during first locks elimination after EA not all safepoints will be patched. >>>>>>> >>>>>>>> Two unrelated boxes that happened to participate in different Phis could end up commoned together wouldn't they? Don't you want to perform explicit Phi simplification instead, replacing the Phi and all other boxes with one of the boxes feeding the Phi? >>>>>>> For eliminating locks of non escaped objects it does not matter that unrelated Boxes are commoned - it worked before. And I want this because it allows to find all related safepoints. Consider case of different lock regions of the same non escaped object. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> tom >>>>>>>>> Tested with full CTW and compiler regression tests. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>> From vladimir.kozlov at oracle.com Thu Jan 12 14:58:43 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Jan 2012 14:58:43 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <82179E60-444F-4D82-AE7D-95DDF5203828@oracle.com> References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> <4F0CEE53.4060707@oracle.com> <4F0E3CA0.1000004@oracle.com> <53FAF387-60CD-4041-A52F-C4D3D2EFACD7@oracle.com> <4F0F2AEB.4050906@oracle.com> <4F0F503F.5010705@oracle.com> <82179E60-444F-4D82-AE7D-95DDF5203828@oracle.com> Message-ID: <4F0F65A3.5060505@oracle.com> > It's not truly incorrect is it? It's just not easily provably equal. The fact that we're compiling it says that the locks are block structured so they must be equal. For an OSR in a nested loop with locking we're just trusting that they are referring to the same object. Yes, I think, for this implementation it is just difficult to prove objects equivalence, generated code should be correct. Anyway, I decided to push current 7128355 fix as it is and filed separate bug: 7129618: assert(obj_node->eqv_uncast(obj),"") Thanks, Vladimir Tom Rodriguez wrote: > On Jan 12, 2012, at 1:27 PM, Vladimir Kozlov wrote: > >> Tom, >> >> before pushing I ran additional tests (nsk.jdi) which failed during Nightly and found that they still failing next assert in BoxLockNode::is_simple_lock_region(): >> >> assert(obj_node->eqv_uncast(obj),""); >> >> http://cr.openjdk.java.net/~kvn/7128355/webrev.01/src/share/vm/opto/locknode.cpp.html >> >> It verifies that safepoint references the same object as locks in simple lock region. It failed because SFP references Phi node of different CheckCastPP nodes of that object so uncast() did not help. I think I can remove this safepoint verification since at that case all locks and unlocks associated with this Box are referencing the same object and it does not matter what SFP references (it should be the same object). >> >> But I use the same check "obj_node->eqv_uncast(obj)" when looking for safepoints in which old Box should be replaced with its clone in PhaseMacroExpand::mark_eliminated_box(). Monitor info will be incorrect when it does not match but locks are eliminated (since it is non escaped object). >> >> It seems, for safepoint checks I need something like eqv_uncast_and_unphi(obj) but it again become complex. Note, this problem existed - we had incorrect monitors info in safe points. > > It's not truly incorrect is it? It's just not easily provably equal. The fact that we're compiling it says that the locks are block structured so they must be equal. For an OSR in a nested loop with locking we're just trusting that they are referring to the same object. > > tom > >> I will think more what I can do. Just letting you know that I may add more code to this fix. >> >> thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> Thank you, Tom >>> Vladimir >>> Tom Rodriguez wrote: >>>> On Jan 11, 2012, at 5:51 PM, Vladimir Kozlov wrote: >>>> >>>>> Updated changes. >>>>> >>>>> http://cr.openjdk.java.net/~kvn/7128355/webrev.01 >>>>> >>>>> Don not common BoxLock nodes and avoid creating phis of boxes. During parsing replace new BoxLock node with old BoxLock node at merge points. Use as_BoxLock() which checks that node is BoxLockNode instead of BoxLockNode::box_node(). Call box_node() node only after RA which may create spills of BoxLock nodes. >>>> I like that better. >>>> >>>> tom >>>> >>>>> Vladimir >>>>> >>>>> Vladimir Kozlov wrote: >>>>>> Tom Rodriguez wrote: >>>>>>> On Jan 10, 2012, at 4:52 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> On Jan 10, 2012, at 3:36 PM, Vladimir Kozlov wrote: >>>>>>>>>> http://cr.openjdk.java.net/~kvn/7128355/webrev >>>>>>>>>> >>>>>>>>>> 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed >>>>>>>>> Doesn't that break nested lock elimination? >>>>>>>> Possible but rare since merged boxes are rare cases. >>>>>>> But it would still be a bug wouldn't it? Nested lock elimination is relying on the BoxLock identity to eliminate the useless operations for some locking region. >>>>>> Why it is bug? It is only opportunity lost: nested lock will not be eliminated if Box is marked as commoned. >>>>>> But I agree with you, the logic become too complex. I will try to replace Phi with Box node after Parse and add checks to make sure such phis are not created during optimizations. I will not common boxes in new code. But I want to keep EliminateNestedLocks flags to be able restore previous behavior. >>>>>> Thanks, >>>>>> Vladimir >>>>>>> I think the rules for the box lock are way too complicated after these changes. The commoning behaviour shouldn't be conditional on EliminateNestedLocks so that we can settle on some standard set of rules for how they operate. I think BoxLockNodes should never common and any Phi of BoxLocks should simplify into a single set BoxLock. This could be done with specific logic in PhiNode::Ideal that replaces any Phi with a single BoxLock during IGVN. We'll have to make sure we reprocess them after parse but that doesn't seem that hard. I think we want to maintain the invariant that after parse there aren't any Phi's of BoxLock. That's a good rule. >>>>>>> >>>>>>> tom >>>>>>> >>>>>>>> It does not affect normal case when Box node is unique for nested lock region. The failure I see is OSR compilations of nested loop inside synchronized scope and compilations of irreducible loops. The scenario where nested lock elimination will be broken is when during first locks nodes elimination (after EA) Box node was commoned because it has Phi user but later after CCP that Phi could be eliminated so Box could became unique. I thought about doing box commoning only after all optimizations done. But I concern that during first locks elimination after EA not all safepoints will be patched. >>>>>>>> >>>>>>>>> Two unrelated boxes that happened to participate in different Phis could end up commoned together wouldn't they? Don't you want to perform explicit Phi simplification instead, replacing the Phi and all other boxes with one of the boxes feeding the Phi? >>>>>>>> For eliminating locks of non escaped objects it does not matter that unrelated Boxes are commoned - it worked before. And I want this because it allows to find all related safepoints. Consider case of different lock regions of the same non escaped object. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> tom >>>>>>>>>> Tested with full CTW and compiler regression tests. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir > From vladimir.kozlov at oracle.com Thu Jan 12 15:35:30 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 12 Jan 2012 23:35:30 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Message-ID: <20120112233532.ADF984794A@hg.openjdk.java.net> Changeset: c8d8e124380c Author: kvn Date: 2012-01-12 12:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c8d8e124380c 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Summary: Don't split CMove node if it's control edge is different from split region. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp From vladimir.kozlov at oracle.com Thu Jan 12 21:31:22 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 13 Jan 2012 05:31:22 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Message-ID: <20120113053130.A090547957@hg.openjdk.java.net> Changeset: b0ff910edfc9 Author: kvn Date: 2012-01-12 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b0ff910edfc9 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Summary: Do not common BoxLock nodes and avoid creating phis of boxes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp From john.r.rose at oracle.com Fri Jan 13 00:48:22 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 13 Jan 2012 00:48:22 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: <4F0F65A3.5060505@oracle.com> References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> <4F0CEE53.4060707@oracle.com> <4F0E3CA0.1000004@oracle.com> <53FAF387-60CD-4041-A52F-C4D3D2EFACD7@oracle.com> <4F0F2AEB.4050906@oracle.com> <4F0F503F.5010705@oracle.com> <82179E60-444F-4D82-AE7D-95DDF5203828@oracle.com> <4F0F65A3.5060505@oracle.com> Message-ID: On Jan 12, 2012, at 2:58 PM, Vladimir Kozlov wrote: > Anyway, I decided to push current 7128355 fix as it is and filed separate bug: > > 7129618: assert(obj_node->eqv_uncast(obj),"") For this week's gatekeeping, I'm pushing everything up to, but not including, this fix. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120113/87116618/attachment.html From john.r.rose at oracle.com Fri Jan 13 06:15:03 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 13 Jan 2012 14:15:03 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6 new changesets Message-ID: <20120113141520.5988047960@hg.openjdk.java.net> Changeset: 8f8b94305aff Author: dcubed Date: 2012-01-11 19:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8f8b94305aff 7129240: backout fix for 7102776 until 7128770 is resolved Reviewed-by: phh, bobv, coleenp, dcubed Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 4f25538b54c9 Author: fparain Date: 2012-01-09 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4f25538b54c9 7120511: Add diagnostic commands Reviewed-by: acorn, phh, dcubed, sspitsyn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 865e0817f32b Author: kamg Date: 2012-01-10 15:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/865e0817f32b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: efdf6985a3a2 Author: kamg Date: 2012-01-12 09:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/efdf6985a3a2 Merge Changeset: 31a5b9aad4bc Author: jrose Date: 2012-01-13 00:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/31a5b9aad4bc Merge ! src/share/vm/runtime/arguments.cpp Changeset: f4d8930a45b9 Author: jrose Date: 2012-01-13 00:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f4d8930a45b9 Merge From vladimir.kozlov at oracle.com Fri Jan 13 08:34:07 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 Jan 2012 08:34:07 -0800 Subject: Request for reviews (M): 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed In-Reply-To: References: <4F0CCB93.7010005@oracle.com> <4F0CDD31.50104@oracle.com> <8AEFAE15-8148-4A26-99F7-DECB30F7061C@oracle.com> <4F0CEE53.4060707@oracle.com> <4F0E3CA0.1000004@oracle.com> <53FAF387-60CD-4041-A52F-C4D3D2EFACD7@oracle.com> <4F0F2AEB.4050906@oracle.com> <4F0F503F.5010705@oracle.com> <82179E60-444F-4D82-AE7D-95DDF5203828@oracle.com> <4F0F65A3.5060505@oracle.com> Message-ID: <4F105CFF.8060109@oracle.com> We should have skipped the push to main this week. Too many Nightly failures because of this 7128355 and 7129618 bugs. Vladimir On 1/13/12 12:48 AM, John Rose wrote: > On Jan 12, 2012, at 2:58 PM, Vladimir Kozlov wrote: > >> Anyway, I decided to push current 7128355 fix as it is and filed separate bug: >> >> 7129618: assert(obj_node->eqv_uncast(obj),"") > > For this week's gatekeeping, I'm pushing everything up to, but not including, this fix. > > -- John From vladimir.kozlov at oracle.com Fri Jan 13 11:19:40 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 Jan 2012 11:19:40 -0800 Subject: Request for reviews (S): 7129618: assert(obj_node->eqv_uncast(obj),""); Message-ID: <4F1083CC.5010303@oracle.com> http://cr.openjdk.java.net/~kvn/7129618/webrev 7129618: assert(obj_node->eqv_uncast(obj),""); Relax verification and locks elimination checks for new implementation (EliminateNestedLocks). Don't verify safepoints monitor info in is_simple_lock_region() since the referenced node could be different from the locked object. It could be Phi node of different cast nodes which point to this locked object. We assume that no other objects could be referenced in monitor info associated with this BoxLock node because in verified case all associated locks and unlocks are referencing only this one object. New implementation has separate BoxLock node for each locked region so mark all associated locks/unlocks as eliminated in mark_eliminated_box() even if different objects are referenced in one locked region (for example, OSR compilation of nested loop inside locked scope). Verified with failed tests. Thanks, Vladimir From vladimir.kozlov at oracle.com Fri Jan 13 16:14:44 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 14 Jan 2012 00:14:44 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7129618: assert(obj_node->eqv_uncast(obj),""); Message-ID: <20120114001448.B8DE347972@hg.openjdk.java.net> Changeset: 89d0a5d40008 Author: kvn Date: 2012-01-13 12:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/89d0a5d40008 7129618: assert(obj_node->eqv_uncast(obj),""); Summary: Relax verification and locks elimination checks for new implementation (EliminateNestedLocks). Reviewed-by: iveresov ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp From john.r.rose at oracle.com Fri Jan 13 17:08:34 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 13 Jan 2012 17:08:34 -0800 Subject: Request for reviews (S): 7129618: assert(obj_node->eqv_uncast(obj),""); In-Reply-To: <4F1083CC.5010303@oracle.com> References: <4F1083CC.5010303@oracle.com> Message-ID: <8E5203D7-C4D7-49E3-AE44-DEE7CFA8A36D@oracle.com> On Jan 13, 2012, at 11:19 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7129618/webrev > > 7129618: assert(obj_node->eqv_uncast(obj),""); It looks good. This comment, because it talks of a "new implementation" seems like it will go out of date quickly: + // New implementation (EliminateNestedLocks) has separate BoxLock Perhaps you could say: ++ // Under EliminateNestedLocks there is a separate BoxLock Also, a typo: + // unlocks are reference only this one object. ++ // unlocks are referencing only this one object. I notice that (in a previous changeset) we generate phi nodes for BoxLocks using a bottom_type of TypeRawPtr. Will those phi nodes ever be allocated to registers or stack slots? I'm hoping not, because that could let the oops escape the GC. -- John From vladimir.kozlov at oracle.com Fri Jan 13 17:39:53 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 Jan 2012 17:39:53 -0800 Subject: Request for reviews (S): 7129618: assert(obj_node->eqv_uncast(obj),""); In-Reply-To: <8E5203D7-C4D7-49E3-AE44-DEE7CFA8A36D@oracle.com> References: <4F1083CC.5010303@oracle.com> <8E5203D7-C4D7-49E3-AE44-DEE7CFA8A36D@oracle.com> Message-ID: <4F10DCE9.1080206@oracle.com> Thank you, John I will fix comments next time since I got review from Igor and pushed this fix already. > I notice that (in a previous changeset) we generate phi nodes for BoxLocks using a bottom_type of TypeRawPtr. Final revision of previous 7128355 fix removed generation of box phis: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/diff/b0ff910edfc9/src/share/vm/opto/parse1.cpp http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b0ff910edfc9 Thanks, Vladimir On 1/13/12 5:08 PM, John Rose wrote: > On Jan 13, 2012, at 11:19 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7129618/webrev >> >> 7129618: assert(obj_node->eqv_uncast(obj),""); > > > It looks good. > > This comment, because it talks of a "new implementation" seems like it will go out of date quickly: > + // New implementation (EliminateNestedLocks) has separate BoxLock > Perhaps you could say: > ++ // Under EliminateNestedLocks there is a separate BoxLock > > Also, a typo: > + // unlocks are reference only this one object. > ++ // unlocks are referencing only this one object. > > I notice that (in a previous changeset) we generate phi nodes for BoxLocks using a bottom_type of TypeRawPtr. > Will those phi nodes ever be allocated to registers or stack slots? I'm hoping not, because that could let the oops escape the GC. > > -- John From bertrand.delsart at oracle.com Mon Jan 16 08:06:22 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Mon, 16 Jan 2012 17:06:22 +0100 Subject: RFR, XS, 7120448, Fix FP values for compiled frames in frame::describe Message-ID: <4F144AFE.6020308@oracle.com> Here is simple review for the first of a series of fixes and extensions for frame::describe. http://cr.openjdk.java.net/~bdelsart/7120448/webrev.01/webrev/ This is the first of a series of fixes and extensions for frame::describe. frame::describe() was calling the platform dependent frame::fp() to get the frame pointer. Unfortunately, the semantic of frame::fp() is not clearly defined. On compiled x86 frames, the value could be arbitrary. That could cause frame::describe to dump misleading information and useless memory slots. Defined a new frame::real_fp() with a more precise semantic for portable shared code. This is the value expected by the platform ABI when it defines a frame pointer register. It may differ from the effective value of the FP register when that register is used in the JVM for other purposes (like compiled frames on some platforms). On other platforms, it is defined so that the stack area used by this frame goes from real_fp() to sp(). By default, the new definition is equivalent to the old frame::fp() definition. x86 is the only OpenJDK supported platform which required a different definition. Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From vitalyd at gmail.com Mon Jan 16 21:45:32 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Jan 2012 00:45:32 -0500 Subject: SIMD auto-vectorization in hotspot Message-ID: Hi guys, Does the -XX:+UseSuperWord (I see it's set to true on 6u23) optimization enable auto-vectorization of certain loops? If so, are there any switches that can be turned on (in product VM) to see if vectorization is being applied or not? In general, would someone be able to describe the current state of loop vectorization (i.e. implementation limits, restrictions, etc)? Which ISAs are supported (i.e. SSE, AVX)? Any other info on this subject would be greatly appreciated ... Thanks very much, Vitaly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120117/96690b9f/attachment.html From vitalyd at gmail.com Mon Jan 16 22:11:21 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Jan 2012 01:11:21 -0500 Subject: EscapeAnalysis diagnostics + user-guided stack allocation Message-ID: Hi, Is there a way, in product build, to get diagnostics on EA? For example, to see which allocations in a method are removed? I realize EA is an implementation detail and subject to change release to release, but it would be a great option to have for performance tuning. There are many classes which are simple wrappers on top of a primitive (e.g. Apache's HashCodeBuilder, EqualsBuilder) which people use, and if the allocations are not removed, they create a lot of GC pressure. In cases where EA does not remove them, it would be advantageous to hand-code the functionality instead of using these utility wrappers. However, the only way to know right now (to my knowledge) is to look at disassembly via hsdis -- it'd be great if there was a simpler and quicker way to do that check. Also, are there any plans to support struct/value-type like (ala CLR's struct) constructs in the JVM (presumably java can then target it)? This would allow developer to control where something gets allocated without relying on EA, and it would also reduce the amount of indirection in object graphs (and the mem/cpu performance hit of them) since struct members of a heap allocated object could be allocated "inline". Apologies if this mailgroup isn't the most appropriate for this particular question, so feel free to redirect me to the right one. Thanks -- Vitaly 617-548-7007 (mobile) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120117/d5549a4e/attachment.html From rednaxelafx at gmail.com Mon Jan 16 22:36:20 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 17 Jan 2012 14:36:20 +0800 Subject: SIMD auto-vectorization in hotspot In-Reply-To: References: Message-ID: Hi, Apparently, the source code to read is opto/superword.[hpp|cpp] [1][2]. The flag to trace it is -XX:+TraceSuperWord. There's a paper mentioned in [1], which is the origin of the algorithm used. An example to see superword in action is a simple array copy loop: // byte[] src = ... // byte[] dest = ... // assert(src.length == dest.length) for (int i = 0; i < src.length; i++) { dest[i] = src[i]; } This loop will be vectorized by superword and then unrolled a bit, turning the actual copy into something like: (on 32-bit x86) movq 0xc(%ecx,%edi,4),%xmm0 movq %xmm0,0xc(%edx,%edi,4) HTH, - Kris [1]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/src/share/vm/opto/superword.hpp [2]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/src/share/vm/opto/superword.cpp On Tue, Jan 17, 2012 at 1:45 PM, Vitaly Davidovich wrote: > Hi guys, > > Does the -XX:+UseSuperWord (I see it's set to true on 6u23) optimization > enable auto-vectorization of certain loops? If so, are there any switches > that can be turned on (in product VM) to see if vectorization is being > applied or not? In general, would someone be able to describe the current > state of loop vectorization (i.e. implementation limits, restrictions, > etc)? Which ISAs are supported (i.e. SSE, AVX)? Any other info on this > subject would be greatly appreciated ... > > Thanks very much, > > Vitaly > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120117/db942185/attachment.html From vitalyd at gmail.com Mon Jan 16 23:03:21 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Jan 2012 02:03:21 -0500 Subject: SIMD auto-vectorization in hotspot In-Reply-To: References: Message-ID: Thanks Kris, I'll take a look. I should've been clearer in my question though -- I'm mostly interested in packed math (integer and floating point). Cheers On Tue, Jan 17, 2012 at 1:36 AM, Krystal Mok wrote: > Hi, > > Apparently, the source code to read is opto/superword.[hpp|cpp] [1][2]. > The flag to trace it is -XX:+TraceSuperWord. > There's a paper mentioned in [1], which is the origin of the algorithm > used. > > An example to see superword in action is a simple array copy loop: > > // byte[] src = ... > // byte[] dest = ... > // assert(src.length == dest.length) > for (int i = 0; i < src.length; i++) { > dest[i] = src[i]; > } > > This loop will be vectorized by superword and then unrolled a bit, turning > the actual copy into something like: (on 32-bit x86) > > movq 0xc(%ecx,%edi,4),%xmm0 > movq %xmm0,0xc(%edx,%edi,4) > > HTH, > - Kris > > [1]: > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/src/share/vm/opto/superword.hpp > [2]: > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/src/share/vm/opto/superword.cpp > > > > On Tue, Jan 17, 2012 at 1:45 PM, Vitaly Davidovich wrote: > >> Hi guys, >> >> Does the -XX:+UseSuperWord (I see it's set to true on 6u23) optimization >> enable auto-vectorization of certain loops? If so, are there any switches >> that can be turned on (in product VM) to see if vectorization is being >> applied or not? In general, would someone be able to describe the current >> state of loop vectorization (i.e. implementation limits, restrictions, >> etc)? Which ISAs are supported (i.e. SSE, AVX)? Any other info on this >> subject would be greatly appreciated ... >> >> Thanks very much, >> >> Vitaly >> >> > -- Vitaly 617-548-7007 (mobile) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120117/1ee3883b/attachment.html From vladimir.kozlov at oracle.com Tue Jan 17 00:52:23 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Jan 2012 00:52:23 -0800 Subject: SIMD auto-vectorization in hotspot In-Reply-To: References: Message-ID: <4F1536C7.5050500@oracle.com> Vector arithmetic are not generated yet (we have plan to do it). Only array initialization and array copy is done. I recently added AVX support to generated 3-operands instructions but only scalar one. Vladimir On 1/16/12 11:03 PM, Vitaly Davidovich wrote: > Thanks Kris, I'll take a look. I should've been clearer in my question though -- I'm mostly interested in packed math > (integer and floating point). > > Cheers > > On Tue, Jan 17, 2012 at 1:36 AM, Krystal Mok > wrote: > > Hi, > > Apparently, the source code to read is opto/superword.[hpp|cpp] [1][2]. The flag to trace it is -XX:+TraceSuperWord. > There's a paper mentioned in [1], which is the origin of the algorithm used. > > An example to see superword in action is a simple array copy loop: > > // byte[] src = ... > // byte[] dest = ... > // assert(src.length == dest.length) > for (int i = 0; i < src.length; i++) { > dest[i] = src[i]; > } > > This loop will be vectorized by superword and then unrolled a bit, turning the actual copy into something like: (on > 32-bit x86) > > movq 0xc(%ecx,%edi,4),%xmm0 > movq %xmm0,0xc(%edx,%edi,4) > > HTH, > - Kris > > [1]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/src/share/vm/opto/superword.hpp > [2]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/tip/src/share/vm/opto/superword.cpp > > > > On Tue, Jan 17, 2012 at 1:45 PM, Vitaly Davidovich > wrote: > > Hi guys, > > Does the -XX:+UseSuperWord (I see it's set to true on 6u23) optimization enable auto-vectorization of certain > loops? If so, are there any switches that can be turned on (in product VM) to see if vectorization is being > applied or not? In general, would someone be able to describe the current state of loop vectorization (i.e. > implementation limits, restrictions, etc)? Which ISAs are supported (i.e. SSE, AVX)? Any other info on this > subject would be greatly appreciated ... > > Thanks very much, > > Vitaly > > > > > > -- > Vitaly > 617-548-7007 (mobile) From vitalyd at gmail.com Tue Jan 17 06:19:37 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Jan 2012 09:19:37 -0500 Subject: SIMD auto-vectorization in hotspot In-Reply-To: <4F1536C7.5050500@oracle.com> References: <4F1536C7.5050500@oracle.com> Message-ID: Awesome, that's great to hear. Is there a release tentatively scheduled to have this or it's still beyond the current horizon? If I may I'd like to petition for a flag being available, ideally in product, to trace diagnostics on this part as well; TraceSuperWord or a new companion, whichever you think makes most sense. Regards, Vitaly On Jan 17, 2012 3:50 AM, "Vladimir Kozlov" wrote: > Vector arithmetic are not generated yet (we have plan to do it). Only > array initialization and array copy is done. I recently added AVX support > to generated 3-operands instructions but only scalar one. > > Vladimir > > On 1/16/12 11:03 PM, Vitaly Davidovich wrote: > >> Thanks Kris, I'll take a look. I should've been clearer in my question >> though -- I'm mostly interested in packed math >> (integer and floating point). >> >> Cheers >> >> On Tue, Jan 17, 2012 at 1:36 AM, Krystal Mok > rednaxelafx at gmail.com>**> wrote: >> >> Hi, >> >> Apparently, the source code to read is opto/superword.[hpp|cpp] >> [1][2]. The flag to trace it is -XX:+TraceSuperWord. >> There's a paper mentioned in [1], which is the origin of the algorithm >> used. >> >> An example to see superword in action is a simple array copy loop: >> >> // byte[] src = ... >> // byte[] dest = ... >> // assert(src.length == dest.length) >> for (int i = 0; i < src.length; i++) { >> dest[i] = src[i]; >> } >> >> This loop will be vectorized by superword and then unrolled a bit, >> turning the actual copy into something like: (on >> 32-bit x86) >> >> movq 0xc(%ecx,%edi,4),%xmm0 >> movq %xmm0,0xc(%edx,%edi,4) >> >> HTH, >> - Kris >> >> [1]: http://hg.openjdk.java.net/**hsx/hotspot-main/hotspot/file/** >> tip/src/share/vm/opto/**superword.hpp >> [2]: http://hg.openjdk.java.net/**hsx/hotspot-main/hotspot/file/** >> tip/src/share/vm/opto/**superword.cpp >> > tip/src/share/vm/opto/**superword.hpp >> > >> >> >> On Tue, Jan 17, 2012 at 1:45 PM, Vitaly Davidovich > vitalyd at gmail.com>> wrote: >> >> Hi guys, >> >> Does the -XX:+UseSuperWord (I see it's set to true on 6u23) >> optimization enable auto-vectorization of certain >> loops? If so, are there any switches that can be turned on (in >> product VM) to see if vectorization is being >> applied or not? In general, would someone be able to describe the >> current state of loop vectorization (i.e. >> implementation limits, restrictions, etc)? Which ISAs are >> supported (i.e. SSE, AVX)? Any other info on this >> subject would be greatly appreciated ... >> >> Thanks very much, >> >> Vitaly >> >> >> >> >> >> -- >> Vitaly >> 617-548-7007 (mobile) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120117/aa95ef3c/attachment-0001.html From roland.westrelin at oracle.com Tue Jan 17 08:43:20 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 17 Jan 2012 17:43:20 +0100 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests Message-ID: http://cr.openjdk.java.net/~roland/7116050/webrev.00/ Block::schedule_local() creates new nodes and they need to be skipped so that the VM doesn't write beyond the end of the ready_cnt array (following 7077312). The current code has a test to prevent it: if (m->_idx > max_idx) { max_idx is set to matcher.C->unique() in Block::schedule_local() so it may change with every block and it doesn't fully prevent a write beyond the end of the array. Also the test should be a >= rather than a > because max_idx is the size of the ready_cnt array. Also isn't it better to use an intArray rather than int[] array so that similar issues are not missed in the future? Roland. From vladimir.kozlov at oracle.com Tue Jan 17 09:30:56 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Jan 2012 09:30:56 -0800 Subject: RFR, XS, 7120448, Fix FP values for compiled frames in frame::describe In-Reply-To: <4F144AFE.6020308@oracle.com> References: <4F144AFE.6020308@oracle.com> Message-ID: <4F15B050.5060601@oracle.com> I think it looks good. Small note, we need to start updating Copyright year to 2012. Thanks, Vladimir Bertrand Delsart wrote: > Here is simple review for the first of a series of fixes and > extensions for frame::describe. > > http://cr.openjdk.java.net/~bdelsart/7120448/webrev.01/webrev/ > > This is the first of a series of fixes and extensions for > frame::describe. > > frame::describe() was calling the platform dependent frame::fp() to > get the frame pointer. Unfortunately, the semantic of frame::fp() is > not clearly defined. On compiled x86 frames, the value could be > arbitrary. That could cause frame::describe to dump misleading > information and useless memory slots. > > Defined a new frame::real_fp() with a more precise semantic for > portable shared code. > > This is the value expected by the platform ABI when it defines a frame > pointer register. It may differ from the effective value of the FP > register when that register is used in the JVM for other purposes > (like compiled frames on some platforms). On other platforms, it is > defined so that the stack area used by this frame goes from real_fp() > to sp(). > > By default, the new definition is equivalent to the old frame::fp() > definition. x86 is the only OpenJDK supported platform which required > a different definition. > > Bertrand. > From vladimir.kozlov at oracle.com Tue Jan 17 10:09:02 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Jan 2012 10:09:02 -0800 Subject: SIMD auto-vectorization in hotspot In-Reply-To: References: <4F1536C7.5050500@oracle.com> Message-ID: <4F15B93E.50008@oracle.com> Vitaly Davidovich wrote: > Awesome, that's great to hear. Is there a release tentatively scheduled > to have this or it's still beyond the current horizon? It targets jdk 8 and one of future jdk 7 updates. I can't say more precise. > > If I may I'd like to petition for a flag being available, ideally in > product, to trace diagnostics on this part as well; TraceSuperWord or a > new companion, whichever you think makes most sense. We can do that. Vladimir > > Regards, > Vitaly > > On Jan 17, 2012 3:50 AM, "Vladimir Kozlov" > wrote: > > Vector arithmetic are not generated yet (we have plan to do it). > Only array initialization and array copy is done. I recently added > AVX support to generated 3-operands instructions but only scalar one. > > Vladimir > > On 1/16/12 11:03 PM, Vitaly Davidovich wrote: > > Thanks Kris, I'll take a look. I should've been clearer in my > question though -- I'm mostly interested in packed math > (integer and floating point). > > Cheers > > On Tue, Jan 17, 2012 at 1:36 AM, Krystal Mok > > >__> > wrote: > > Hi, > > Apparently, the source code to read is > opto/superword.[hpp|cpp] [1][2]. The flag to trace it is > -XX:+TraceSuperWord. > There's a paper mentioned in [1], which is the origin of the > algorithm used. > > An example to see superword in action is a simple array copy > loop: > > // byte[] src = ... > // byte[] dest = ... > // assert(src.length == dest.length) > for (int i = 0; i < src.length; i++) { > dest[i] = src[i]; > } > > This loop will be vectorized by superword and then unrolled a > bit, turning the actual copy into something like: (on > 32-bit x86) > > movq 0xc(%ecx,%edi,4),%xmm0 > movq %xmm0,0xc(%edx,%edi,4) > > HTH, > - Kris > > [1]: > http://hg.openjdk.java.net/__hsx/hotspot-main/hotspot/file/__tip/src/share/vm/opto/__superword.hpp > > [2]: > http://hg.openjdk.java.net/__hsx/hotspot-main/hotspot/file/__tip/src/share/vm/opto/__superword.cpp > > > > > > > On Tue, Jan 17, 2012 at 1:45 PM, Vitaly Davidovich > > >> wrote: > > Hi guys, > > Does the -XX:+UseSuperWord (I see it's set to true on > 6u23) optimization enable auto-vectorization of certain > loops? If so, are there any switches that can be turned > on (in product VM) to see if vectorization is being > applied or not? In general, would someone be able to > describe the current state of loop vectorization (i.e. > implementation limits, restrictions, etc)? Which ISAs are > supported (i.e. SSE, AVX)? Any other info on this > subject would be greatly appreciated ... > > Thanks very much, > > Vitaly > > > > > > -- > Vitaly > 617-548-7007 (mobile) > From vitalyd at gmail.com Tue Jan 17 10:12:08 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Jan 2012 13:12:08 -0500 Subject: SIMD auto-vectorization in hotspot In-Reply-To: <4F15B93E.50008@oracle.com> References: <4F1536C7.5050500@oracle.com> <4F15B93E.50008@oracle.com> Message-ID: Great, thanks for that - I think vector unit math will bring some serious perf gains on quite a bit of code. Regards, Vitaly Sent from my phone On Jan 17, 2012 1:09 PM, "Vladimir Kozlov" wrote: > Vitaly Davidovich wrote: > >> Awesome, that's great to hear. Is there a release tentatively scheduled >> to have this or it's still beyond the current horizon? >> > > It targets jdk 8 and one of future jdk 7 updates. I can't say more precise. > > >> If I may I'd like to petition for a flag being available, ideally in >> product, to trace diagnostics on this part as well; TraceSuperWord or a new >> companion, whichever you think makes most sense. >> > > We can do that. > > Vladimir > > >> Regards, >> Vitaly >> >> On Jan 17, 2012 3:50 AM, "Vladimir Kozlov" > vladimir.kozlov@**oracle.com >> wrote: >> >> Vector arithmetic are not generated yet (we have plan to do it). >> Only array initialization and array copy is done. I recently added >> AVX support to generated 3-operands instructions but only scalar one. >> >> Vladimir >> >> On 1/16/12 11:03 PM, Vitaly Davidovich wrote: >> >> Thanks Kris, I'll take a look. I should've been clearer in my >> question though -- I'm mostly interested in packed math >> (integer and floating point). >> >> Cheers >> >> On Tue, Jan 17, 2012 at 1:36 AM, Krystal Mok >> >> **>__> >> wrote: >> >> Hi, >> >> Apparently, the source code to read is >> opto/superword.[hpp|cpp] [1][2]. The flag to trace it is >> -XX:+TraceSuperWord. >> There's a paper mentioned in [1], which is the origin of the >> algorithm used. >> >> An example to see superword in action is a simple array copy >> loop: >> >> // byte[] src = ... >> // byte[] dest = ... >> // assert(src.length == dest.length) >> for (int i = 0; i < src.length; i++) { >> dest[i] = src[i]; >> } >> >> This loop will be vectorized by superword and then unrolled a >> bit, turning the actual copy into something like: (on >> 32-bit x86) >> >> movq 0xc(%ecx,%edi,4),%xmm0 >> movq %xmm0,0xc(%edx,%edi,4) >> >> HTH, >> - Kris >> >> [1]: >> http://hg.openjdk.java.net/__**hsx/hotspot-main/hotspot/file/** >> __tip/src/share/vm/opto/__**superword.hpp >> > tip/src/share/vm/opto/**superword.hpp >> > >> [2]: >> http://hg.openjdk.java.net/__**hsx/hotspot-main/hotspot/file/** >> __tip/src/share/vm/opto/__**superword.cpp >> > tip/src/share/vm/opto/**superword.cpp >> > >> > hsx/hotspot-main/hotspot/file/**__tip/src/share/vm/opto/__**superword.hpp >> > tip/src/share/vm/opto/**superword.hpp >> >> >> >> >> On Tue, Jan 17, 2012 at 1:45 PM, Vitaly Davidovich >> >> >> wrote: >> >> Hi guys, >> >> Does the -XX:+UseSuperWord (I see it's set to true on >> 6u23) optimization enable auto-vectorization of certain >> loops? If so, are there any switches that can be turned >> on (in product VM) to see if vectorization is being >> applied or not? In general, would someone be able to >> describe the current state of loop vectorization (i.e. >> implementation limits, restrictions, etc)? Which ISAs are >> supported (i.e. SSE, AVX)? Any other info on this >> subject would be greatly appreciated ... >> >> Thanks very much, >> >> Vitaly >> >> >> >> >> >> -- >> Vitaly >> 617-548-7007 (mobile) >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120117/63d0a9b6/attachment.html From bertrand.delsart at oracle.com Tue Jan 17 10:19:50 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 17 Jan 2012 19:19:50 +0100 Subject: RFR, XS, 7120448, Fix FP values for compiled frames in frame::describe In-Reply-To: <4F15B050.5060601@oracle.com> References: <4F144AFE.6020308@oracle.com> <4F15B050.5060601@oracle.com> Message-ID: <4F15BBC6.6050503@oracle.com> Thanks Vlad, Bertrand. On 01/17/12 06:30 PM, Vladimir Kozlov wrote: > I think it looks good. > > Small note, we need to start updating Copyright year to 2012. > > Thanks, > Vladimir > > Bertrand Delsart wrote: >> Here is simple review for the first of a series of fixes and >> extensions for frame::describe. >> >> http://cr.openjdk.java.net/~bdelsart/7120448/webrev.01/webrev/ >> >> This is the first of a series of fixes and extensions for >> frame::describe. >> >> frame::describe() was calling the platform dependent frame::fp() to >> get the frame pointer. Unfortunately, the semantic of frame::fp() is >> not clearly defined. On compiled x86 frames, the value could be >> arbitrary. That could cause frame::describe to dump misleading >> information and useless memory slots. >> >> Defined a new frame::real_fp() with a more precise semantic for >> portable shared code. >> >> This is the value expected by the platform ABI when it defines a frame >> pointer register. It may differ from the effective value of the FP >> register when that register is used in the JVM for other purposes >> (like compiled frames on some platforms). On other platforms, it is >> defined so that the stack area used by this frame goes from real_fp() >> to sp(). >> >> By default, the new definition is equivalent to the old frame::fp() >> definition. x86 is the only OpenJDK supported platform which required >> a different definition. >> >> Bertrand. >> -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From tom.rodriguez at oracle.com Tue Jan 17 10:30:56 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 17 Jan 2012 10:30:56 -0800 Subject: RFR, XS, 7120448, Fix FP values for compiled frames in frame::describe In-Reply-To: <4F144AFE.6020308@oracle.com> References: <4F144AFE.6020308@oracle.com> Message-ID: Looks good. tom On Jan 16, 2012, at 8:06 AM, Bertrand Delsart wrote: > Here is simple review for the first of a series of fixes and > extensions for frame::describe. > > http://cr.openjdk.java.net/~bdelsart/7120448/webrev.01/webrev/ > > This is the first of a series of fixes and extensions for > frame::describe. > > frame::describe() was calling the platform dependent frame::fp() to > get the frame pointer. Unfortunately, the semantic of frame::fp() is > not clearly defined. On compiled x86 frames, the value could be > arbitrary. That could cause frame::describe to dump misleading > information and useless memory slots. > > Defined a new frame::real_fp() with a more precise semantic for > portable shared code. > > This is the value expected by the platform ABI when it defines a frame > pointer register. It may differ from the effective value of the FP > register when that register is used in the JVM for other purposes > (like compiled frames on some platforms). On other platforms, it is > defined so that the stack area used by this frame goes from real_fp() > to sp(). > > By default, the new definition is equivalent to the old frame::fp() > definition. x86 is the only OpenJDK supported platform which required > a different definition. > > Bertrand. > > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE From vladimir.kozlov at oracle.com Tue Jan 17 10:38:23 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Jan 2012 10:38:23 -0800 Subject: EscapeAnalysis diagnostics + user-guided stack allocation In-Reply-To: References: Message-ID: <4F15C01F.9050400@oracle.com> Vitaly Davidovich wrote: > Hi, > > Is there a way, in product build, to get diagnostics on EA? For example, > to see which allocations in a method are removed? I realize EA is an > implementation detail and subject to change release to release, but it > would be a great option to have for performance tuning. There are many > classes which are simple wrappers on top of a primitive (e.g. Apache's > HashCodeBuilder, EqualsBuilder) which people use, and if the allocations > are not removed, they create a lot of GC pressure. In cases where EA > does not remove them, it would be advantageous to hand-code the > functionality instead of using these utility wrappers. However, the > only way to know right now (to my knowledge) is to look at disassembly > via hsdis -- it'd be great if there was a simpler and quicker way to do > that check. There is debug flag PrintEliminateAllocations. Nobody asked before to make it available but we can change it to diagnostic flag. > > Also, are there any plans to support struct/value-type like (ala CLR's > struct) constructs in the JVM (presumably java can then target it)? This > would allow developer to control where something gets allocated without > relying on EA, and it would also reduce the amount of indirection in > object graphs (and the mem/cpu performance hit of them) since struct > members of a heap allocated object could be allocated "inline". > Apologies if this mailgroup isn't the most appropriate for this > particular question, so feel free to redirect me to the right one. I don't known about such plans. Send this question to hotspot-dev at openjdk.java.net Vladimir > > Thanks > > -- > Vitaly > 617-548-7007 (mobile) From vitalyd at gmail.com Tue Jan 17 10:48:22 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Jan 2012 13:48:22 -0500 Subject: EscapeAnalysis diagnostics + user-guided stack allocation In-Reply-To: <4F15C01F.9050400@oracle.com> References: <4F15C01F.9050400@oracle.com> Message-ID: Vladimir, Diagnostic in product would be much appreciated - in a corporate setting it's not that simple to get a debug build in-house, unfortunately. I'll follow up with hotspot-dev on my 2nd question. Thank you Sent from my phone On Jan 17, 2012 1:38 PM, "Vladimir Kozlov" wrote: > Vitaly Davidovich wrote: > >> Hi, >> >> Is there a way, in product build, to get diagnostics on EA? For example, >> to see which allocations in a method are removed? I realize EA is an >> implementation detail and subject to change release to release, but it >> would be a great option to have for performance tuning. There are many >> classes which are simple wrappers on top of a primitive (e.g. Apache's >> HashCodeBuilder, EqualsBuilder) which people use, and if the allocations >> are not removed, they create a lot of GC pressure. In cases where EA does >> not remove them, it would be advantageous to hand-code the functionality >> instead of using these utility wrappers. However, the only way to know >> right now (to my knowledge) is to look at disassembly via hsdis -- it'd be >> great if there was a simpler and quicker way to do that check. >> > > There is debug flag PrintEliminateAllocations. Nobody asked before to make > it available but we can change it to diagnostic flag. > > >> Also, are there any plans to support struct/value-type like (ala CLR's >> struct) constructs in the JVM (presumably java can then target it)? This >> would allow developer to control where something gets allocated without >> relying on EA, and it would also reduce the amount of indirection in object >> graphs (and the mem/cpu performance hit of them) since struct members of a >> heap allocated object could be allocated "inline". Apologies if this >> mailgroup isn't the most appropriate for this particular question, so feel >> free to redirect me to the right one. >> > > I don't known about such plans. Send this question to > hotspot-dev at openjdk.java.net > > Vladimir > > >> Thanks >> >> -- >> Vitaly >> 617-548-7007 (mobile) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120117/4b3b46f8/attachment.html From vladimir.kozlov at oracle.com Tue Jan 17 12:03:21 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Jan 2012 12:03:21 -0800 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests In-Reply-To: References: Message-ID: <4F15D409.6010500@oracle.com> Why not just use "uint max_idx == (uint)ready_cnt.length()" since ready_cnt can't be changed? You don't need to pass it as argument then. Vladimir Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7116050/webrev.00/ > > Block::schedule_local() creates new nodes and they need to be skipped so > that the VM doesn't write beyond the end of the ready_cnt array > (following 7077312). The current code has a test to prevent it: > > if (m->_idx > max_idx) { > > max_idx is set to matcher.C->unique() in Block::schedule_local() so it > may change with every block and it doesn't fully prevent a write beyond > the end of the array. Also the test should be a >= rather than a > > because max_idx is the size of the ready_cnt array. > > Also isn't it better to use an intArray rather than int[] array so that > similar issues are not missed in the future? > > Roland. From roland.westrelin at oracle.com Tue Jan 17 12:08:46 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 17 Jan 2012 21:08:46 +0100 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests In-Reply-To: <4F15D409.6010500@oracle.com> References: <4F15D409.6010500@oracle.com> Message-ID: <2F296475-52FA-464D-8C36-442640AD5322@oracle.com> > Why not just use "uint max_idx == (uint)ready_cnt.length()" since ready_cnt can't be changed? You don't need to pass it as argument then. Yes, it's the same. I just found that passing the argument was a bit clearer. Anyway I can change it. Roland. From tom.rodriguez at oracle.com Tue Jan 17 12:51:22 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 17 Jan 2012 12:51:22 -0800 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests In-Reply-To: References: Message-ID: On Jan 17, 2012, at 8:43 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7116050/webrev.00/ > > Block::schedule_local() creates new nodes and they need to be skipped so that the VM doesn't write beyond the end of the ready_cnt array (following 7077312). The current code has a test to prevent it: > > if (m->_idx > max_idx) { > > max_idx is set to matcher.C->unique() in Block::schedule_local() so it may change with every block and it doesn't fully prevent a write beyond the end of the array. Also the test should be a >= rather than a > because max_idx is the size of the ready_cnt array. > > Also isn't it better to use an intArray rather than int[] array so that similar issues are not missed in the future? intArray is a C1'ism that should be replaced with something nicer longer term, so I'd recommend GrowableArray instead. They are largely functionally equivalent, other than the fact that intArray is always resource allocated but GrowableArray does either resource or C heap. Otherwise it looks ok. tom > > Roland. From roland.westrelin at oracle.com Wed Jan 18 02:14:21 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 18 Jan 2012 11:14:21 +0100 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests In-Reply-To: References: Message-ID: <2CE3D102-90FF-44FC-820E-9AC09126FAA7@oracle.com> Here is a new webrev that uses GrowableArray and removes the max_idx parameter: http://cr.openjdk.java.net/~roland/7116050/webrev.01/ Roland. From bertrand.delsart at oracle.com Wed Jan 18 08:29:18 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 18 Jan 2012 17:29:18 +0100 Subject: RFR, S, 7120450: complete information dumped by frame_describe Message-ID: <4F16F35E.1040200@oracle.com> Second RFR related to frame_describe: http://cr.openjdk.java.net/~bdelsart/7120450/00/webrev/ This comes on top of 7120448, currently being submitted. Goal of that RFR was to enhance x86/PPC with stuff we had added to our embedded plarforms, namely information about ricochet frames and basic information for non standard frames. This only impacts debugging code (dumps generated by pfl() calls or temporarily added to the JVM during development). We did fix a small issue in frame::describe. is_deoptimized() could fail on assertions for some frames. This was discovered by stress testing the calls with (non submited) print_frame_layout() calls in in the transitions back from the JVM to Java (to ensure the robustness of the dump and the adequacy of the information). Also called print_frame_layout() from trace_method_handle to debug ricochet frames information. This is not part of this RFR since the changes are more intrusive. Thanks, Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From vladimir.kozlov at oracle.com Wed Jan 18 11:59:15 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 Jan 2012 11:59:15 -0800 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests In-Reply-To: <2CE3D102-90FF-44FC-820E-9AC09126FAA7@oracle.com> References: <2CE3D102-90FF-44FC-820E-9AC09126FAA7@oracle.com> Message-ID: <4F172493.8030904@oracle.com> Sorry, but I don't like such expressions: (!--*ready_cnt.adr_at(m->_idx)). I known that it is just conversion to GrowableArray but I would prefer explicit separate expressions and integer compare so the code will be much easier to understand: < --*ready_cnt.adr_at(n->_idx); < assert( !ready_cnt.at(n->_idx), "" ); --- > int n_cnt = ready_cnt.at(n->_idx)-1; > ready_cnt.at_put(n->_idx, n_cnt); > assert(n_cnt ==0, ""); < if( !--*ready_cnt.adr_at(m->_idx) ) --- > int m_cnt = ready_cnt.at(m->_idx)-1; > ready_cnt.at_put(m->_idx, m_cnt); > if(m_cnt == 0) Vladimir Roland Westrelin wrote: > Here is a new webrev that uses GrowableArray and removes the max_idx parameter: > > http://cr.openjdk.java.net/~roland/7116050/webrev.01/ > > Roland. From tom.rodriguez at oracle.com Wed Jan 18 13:54:35 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 18 Jan 2012 13:54:35 -0800 Subject: review for 7130676: Tiered: assert(bci == 0 || 0<= bci && bci http://cr.openjdk.java.net/~never/7130676 14 lines changed: 11 ins; 0 del; 3 mod; 3293 unchg 7130676: Tiered: assert(bci == 0 || 0<= bci && bci References: <32A61BE7-3F2D-4D5A-BFE7-7D19C2E88463@oracle.com> Message-ID: <4F174D46.20307@oracle.com> Looks good. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7130676 > 14 lines changed: 11 ins; 0 del; 3 mod; 3293 unchg > > 7130676: Tiered: assert(bci == 0 || 0<= bci && bci Reviewed-by: > > This appears to be a long standing issue that was exposed by the > tiered code. The bci -1 is used to represent a point in a method > before execution has actually started and is commonly used for the > stack at the monitor enter of a synchronized method > (SynchronizationEntryBCI). The code which records stack traces for > exception only records a u2 so the -1 doesn't fit and it blindly gets > smeared to 65535. If that value is used to look up line number then > it asserts because the value is out of range. In product mode the > line number code would report the line number with the highest bci in > the line number table when it really should report the lowest. The > fix is to smear -1 to 0. > > In this particular case we're throwing an OOM while inside the counter > overflow on entry to a method. The exception appears to propagate up > from compile_method, presumably from the resolve_string_constants and > load_signature_classes calls. compile_method_base is also declared > TRAPS though it can't actually throw an exception. I think the whole > path from CompilationPolicy::event to compile_method_base should be > cleaned up so that exceptions can't propagate. Any exception thrown > in the path are side effects and not exception that should even be > propagated to the regular Java code. I'll file a separate bug for > this. > > Tested with failing test from report. > From john.r.rose at oracle.com Wed Jan 18 16:00:12 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 18 Jan 2012 16:00:12 -0800 Subject: review request (M): 7111138: delete the obsolete flag -XX:+UseRicochetFrames Message-ID: <4699EC87-B34F-48EF-8172-BD236AECA691@oracle.com> http://cr.openjdk.java.net/~jrose/7111138/webrev.00/ This changeset acknowledges that the UseRicochetFrame flag can only be set to true, and that workaround code in the JVM for a pre-ricochet-frame transitional period is no longer needed. Likewise, code included under the macro "TARGET_ARCH_NYI_6939861" is removed, since that code was used only during the transitional period. -- John Background: Ricochet frames were introduced for x86 in this changeset: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/167b70ff3abc Further changesets introduced ricochet frame support for sparc, ppc, and arm. During the transitional period between the ports, a platform-specific diagnostic flag UseRicochetFrames was introduced which would allow porters to turn on and off the use of these frames. This flag also as internally set to true or false depending on port status. Since the JDK code which supports non-ricochet-based method handles has been retired, the "false" setting of the flag no longer makes sense, so we are removing the flag altogether. Likewise, the macro TARGET_ARCH_NYI_6939861 was defined (to "1") for ports that did not yet have assembly code for supporting UseRicochetFrames. At this point, since all ports do have such assembly code, code under that macro is obsolete and can be deleted. Technically, ricochet frames support signature polymorphism for recursive method handles. A recursive method handle is one which can execute two or more targets, one after the other. The final target can be tail-called, but the other targets must be called with some sort of stack frame or continuation to direct execution to the next target. This is what a ricochet frame does. Note that the return value of a non-final target must be made available, at least optionally, to the subsequent target(s). Also, incoming arguments must be made available, at least optionally, to one or more of the targets. Cf. MethodHandles.foldArguments for a more complex example. A single instance of ricochet frame assembly code can handle a broad range of input argument signatures. In fact, there are a finite number of ricochet frame assembly stubs, which collectively handle all possible argument type combinations. The previous version of method handles had a finite (but uncomfortably large) number of Java-coded handler routines, each suited to a relatively small number of argument type combinations. This previous version did not handle all arities and argument type combinations, and so was discarded shortly after the four main CPU ports were completed. Note that a future set of changes is likely to eliminate ricochet frames also, in favor of a solution which uses a new intermediate representation for recursive method handles, the "lambda form". This representation will compile to bytecodes, or else (optionally) be more directly processed by a JVM implementation. For a preview, see the Da Vinci Machine patch repository, especially: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy.txt http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy-7023639.patch http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-lazy-7023639.patch The purpose of this later change will be to reduce the volume of assembly code and make MH invocations easier to analyze by the JIT. From igor.veresov at oracle.com Wed Jan 18 18:47:39 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 18 Jan 2012 18:47:39 -0800 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) Message-ID: After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ igor From igor.veresov at oracle.com Wed Jan 18 18:47:57 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 18 Jan 2012 18:47:57 -0800 Subject: review for 7130676: Tiered: assert(bci =?utf-8?Q?=3D=3D_?=0 || =?utf-8?Q?0<=3D_?=bci && bci References: <32A61BE7-3F2D-4D5A-BFE7-7D19C2E88463@oracle.com> Message-ID: <33DF26810C014A969BF4BC1A538F135F@oracle.com> Looks good! igor On Wednesday, January 18, 2012 at 1:54 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7130676 > 14 lines changed: 11 ins; 0 del; 3 mod; 3293 unchg > > 7130676: Tiered: assert(bci == 0 || 0<= bci && bci Reviewed-by: > > This appears to be a long standing issue that was exposed by the > tiered code. The bci -1 is used to represent a point in a method > before execution has actually started and is commonly used for the > stack at the monitor enter of a synchronized method > (SynchronizationEntryBCI). The code which records stack traces for > exception only records a u2 so the -1 doesn't fit and it blindly gets > smeared to 65535. If that value is used to look up line number then > it asserts because the value is out of range. In product mode the > line number code would report the line number with the highest bci in > the line number table when it really should report the lowest. The > fix is to smear -1 to 0. > > In this particular case we're throwing an OOM while inside the counter > overflow on entry to a method. The exception appears to propagate up > from compile_method, presumably from the resolve_string_constants and > load_signature_classes calls. compile_method_base is also declared > TRAPS though it can't actually throw an exception. I think the whole > path from CompilationPolicy::event to compile_method_base should be > cleaned up so that exceptions can't propagate. Any exception thrown > in the path are side effects and not exception that should even be > propagated to the regular Java code. I'll file a separate bug for > this. > > Tested with failing test from report. From vladimir.kozlov at oracle.com Wed Jan 18 19:18:06 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 Jan 2012 19:18:06 -0800 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) In-Reply-To: References: Message-ID: <4F178B6E.9020204@oracle.com> Why not use should_not_reach_here() in deopt stub? Also x86 deopt stub does not have stop() or should_not_reach_here(). Vladimir Igor Veresov wrote: > After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() > which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. > > Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ > > > igor From igor.veresov at oracle.com Wed Jan 18 19:31:38 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 18 Jan 2012 19:31:38 -0800 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) In-Reply-To: <4F178B6E.9020204@oracle.com> References: <4F178B6E.9020204@oracle.com> Message-ID: <40C041C5F7A94481A86A38D6411B2147@oracle.com> On Wednesday, January 18, 2012 at 7:18 PM, Vladimir Kozlov wrote: > Why not use should_not_reach_here() in deopt stub? No problem. I just didn't want to change the original message. Fixed. > Also x86 deopt stub does not > have stop() or should_not_reach_here(). Fixed. I've updated the webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.01/ igor > > Vladimir > > Igor Veresov wrote: > > After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() > > which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ > > > > > > igor From tom.rodriguez at oracle.com Wed Jan 18 19:34:36 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 18 Jan 2012 19:34:36 -0800 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) In-Reply-To: <4F178B6E.9020204@oracle.com> References: <4F178B6E.9020204@oracle.com> Message-ID: <85571699-5B01-4D33-A14B-5A6A669E5759@oracle.com> On Jan 18, 2012, at 7:18 PM, Vladimir Kozlov wrote: > Why not use should_not_reach_here() in deopt stub? Also x86 deopt stub does not have stop() or should_not_reach_here(). I think the stop should be removed from emit_deopt_handler on sparc since it's preceded by a direct jump. Usually we emit a stop when we do a call that we don't expect to return, like for an exception dispatch, but in this case since it's a jump it's really impossible the reach the following instruction. tom > > Vladimir > > Igor Veresov wrote: >> After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() >> which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. >> Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ >> igor From igor.veresov at oracle.com Wed Jan 18 21:11:57 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 18 Jan 2012 21:11:57 -0800 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) In-Reply-To: <85571699-5B01-4D33-A14B-5A6A669E5759@oracle.com> References: <4F178B6E.9020204@oracle.com> <85571699-5B01-4D33-A14B-5A6A669E5759@oracle.com> Message-ID: On Wednesday, January 18, 2012 at 7:34 PM, Tom Rodriguez wrote: > > On Jan 18, 2012, at 7:18 PM, Vladimir Kozlov wrote: > > > Why not use should_not_reach_here() in deopt stub? Also x86 deopt stub does not have stop() or should_not_reach_here(). > > I think the stop should be removed from emit_deopt_handler on sparc since it's preceded by a direct jump. Usually we emit a stop when we do a call that we don't expect to return, like for an exception dispatch, but in this case since it's a jump it's really impossible the reach the following instruction. Indeed. Removed. But my fix was incorrect. I had to return the 1K limits for the non-product builds. The code that we emit is flag-dependent and with TraceJump on sparc and VerfiyOops on x86 it can grow very large. Unfortunately that means that the asserts are not that useful and we can easily miss such a problem again. I'd like to make them guarantees instead. Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.02/ igor > > tom > > > > > Vladimir > > > > Igor Veresov wrote: > > > After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() > > > which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. > > > Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ > > > igor > > > From vladimir.kozlov at oracle.com Wed Jan 18 22:02:58 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 Jan 2012 22:02:58 -0800 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) In-Reply-To: References: <4F178B6E.9020204@oracle.com> <85571699-5B01-4D33-A14B-5A6A669E5759@oracle.com> Message-ID: <4F17B212.2020703@oracle.com> I am fine with guarantees but I misled you with should_not_reach_here() in deopt stub on x86, sorry. It is not needed for the same reason as on SPARC. Thanks, Vladimir Igor Veresov wrote: > On Wednesday, January 18, 2012 at 7:34 PM, Tom Rodriguez wrote: >> On Jan 18, 2012, at 7:18 PM, Vladimir Kozlov wrote: >> >>> Why not use should_not_reach_here() in deopt stub? Also x86 deopt stub does not have stop() or should_not_reach_here(). >> I think the stop should be removed from emit_deopt_handler on sparc since it's preceded by a direct jump. Usually we emit a stop when we do a call that we don't expect to return, like for an exception dispatch, but in this case since it's a jump it's really impossible the reach the following instruction. > Indeed. Removed. > > But my fix was incorrect. I had to return the 1K limits for the non-product builds. The code that we emit is flag-dependent and with TraceJump on sparc and VerfiyOops on x86 it can grow very large. Unfortunately that means that the asserts are not that useful and we can easily miss such a problem again. I'd like to make them guarantees instead. > > Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.02/ > > igor >> tom >> >>> Vladimir >>> >>> Igor Veresov wrote: >>>> After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() >>>> which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. >>>> Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ >>>> igor > > > From vladimir.kozlov at oracle.com Wed Jan 18 22:18:23 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 Jan 2012 22:18:23 -0800 Subject: Request for reviews (S): 7131302: connode.cpp:205 Error: ShouldNotReachHere() Message-ID: <4F17B5AF.6060504@oracle.com> http://cr.openjdk.java.net/~kvn/7131302/webrev 7131302: connode.cpp:205 Error: ShouldNotReachHere() Split_thru_phi optimization used LoadNode::Value() and incorrectly replaced LoadS(StoreC(65535)) with constant (65535) which does not fit into SHORT type. As result merged Phi type become top. Add Value() methods to short and byte Load nodes to truncate constants which does not fit. Verified with failed test. Thanks, Vladimir From igor.veresov at oracle.com Wed Jan 18 22:31:00 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 18 Jan 2012 22:31:00 -0800 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) In-Reply-To: <4F17B212.2020703@oracle.com> References: <4F178B6E.9020204@oracle.com> <85571699-5B01-4D33-A14B-5A6A669E5759@oracle.com> <4F17B212.2020703@oracle.com> Message-ID: <9B6EDDF784ED4160A6A13B62B4506DF5@oracle.com> I was confused there too because it tries to emulate a call and pushes sort of a return address. But the address is of the jmp instruction rather than the proper return address. Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.03/ igor On Wednesday, January 18, 2012 at 10:02 PM, Vladimir Kozlov wrote: > I am fine with guarantees but I misled you with should_not_reach_here() in deopt > stub on x86, sorry. It is not needed for the same reason as on SPARC. > > Thanks, > Vladimir > > Igor Veresov wrote: > > On Wednesday, January 18, 2012 at 7:34 PM, Tom Rodriguez wrote: > > > On Jan 18, 2012, at 7:18 PM, Vladimir Kozlov wrote: > > > > > > > Why not use should_not_reach_here() in deopt stub? Also x86 deopt stub does not have stop() or should_not_reach_here(). > > > I think the stop should be removed from emit_deopt_handler on sparc since it's preceded by a direct jump. Usually we emit a stop when we do a call that we don't expect to return, like for an exception dispatch, but in this case since it's a jump it's really impossible the reach the following instruction. > > > > > > Indeed. Removed. > > > > But my fix was incorrect. I had to return the 1K limits for the non-product builds. The code that we emit is flag-dependent and with TraceJump on sparc and VerfiyOops on x86 it can grow very large. Unfortunately that means that the asserts are not that useful and we can easily miss such a problem again. I'd like to make them guarantees instead. > > > > Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.02/ > > > > igor > > > tom > > > > > > > Vladimir > > > > > > > > Igor Veresov wrote: > > > > > After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() > > > > > which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. > > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ > > > > > igor > > > > > > > > > > From vladimir.kozlov at oracle.com Wed Jan 18 22:37:07 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 Jan 2012 22:37:07 -0800 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) In-Reply-To: <9B6EDDF784ED4160A6A13B62B4506DF5@oracle.com> References: <4F178B6E.9020204@oracle.com> <85571699-5B01-4D33-A14B-5A6A669E5759@oracle.com> <4F17B212.2020703@oracle.com> <9B6EDDF784ED4160A6A13B62B4506DF5@oracle.com> Message-ID: <4F17BA13.6000407@oracle.com> Looks good. Vladimir Igor Veresov wrote: > I was confused there too because it tries to emulate a call and pushes sort of a return address. But the address is of the jmp instruction rather than the proper return address. > Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.03/ > > igor > > > On Wednesday, January 18, 2012 at 10:02 PM, Vladimir Kozlov wrote: > >> I am fine with guarantees but I misled you with should_not_reach_here() in deopt >> stub on x86, sorry. It is not needed for the same reason as on SPARC. >> >> Thanks, >> Vladimir >> >> Igor Veresov wrote: >>> On Wednesday, January 18, 2012 at 7:34 PM, Tom Rodriguez wrote: >>>> On Jan 18, 2012, at 7:18 PM, Vladimir Kozlov wrote: >>>> >>>>> Why not use should_not_reach_here() in deopt stub? Also x86 deopt stub does not have stop() or should_not_reach_here(). >>>> I think the stop should be removed from emit_deopt_handler on sparc since it's preceded by a direct jump. Usually we emit a stop when we do a call that we don't expect to return, like for an exception dispatch, but in this case since it's a jump it's really impossible the reach the following instruction. >>> >>> Indeed. Removed. >>> >>> But my fix was incorrect. I had to return the 1K limits for the non-product builds. The code that we emit is flag-dependent and with TraceJump on sparc and VerfiyOops on x86 it can grow very large. Unfortunately that means that the asserts are not that useful and we can easily miss such a problem again. I'd like to make them guarantees instead. >>> >>> Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.02/ >>> >>> igor >>>> tom >>>> >>>>> Vladimir >>>>> >>>>> Igor Veresov wrote: >>>>>> After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() >>>>>> which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ >>>>>> igor > > > From john.r.rose at oracle.com Wed Jan 18 22:49:21 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 18 Jan 2012 22:49:21 -0800 Subject: Request for reviews (S): 7131302: connode.cpp:205 Error: ShouldNotReachHere() In-Reply-To: <4F17B5AF.6060504@oracle.com> References: <4F17B5AF.6060504@oracle.com> Message-ID: <13A86326-61B4-4F40-B8DA-FF7D233D01EC@oracle.com> On Jan 18, 2012, at 10:18 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7131302/webrev > > 7131302: connode.cpp:205 Error: ShouldNotReachHere() > > Split_thru_phi optimization used LoadNode::Value() and incorrectly replaced LoadS(StoreC(65535)) with constant (65535) which does not fit into SHORT type. As result merged Phi type become top. > > Add Value() methods to short and byte Load nodes to truncate constants which does not fit. > > Verified with failed test. Your fix works but I think it makes it harder to read the resulting code, especially regarding the implicit correlation between Value and Identity. It is also possible to encounter non-constants with the wrong kind of sign, such as a value in the range 0..65535 for a signed short. The logic which handles this is in LoadNode::Identity, guarded with "memory_size() < BytesPerInt". I suggest putting parallel logic into LoadNode::Value, rather than splitting LoadNode::Value. That will make it easier to see the relation between Ideal and Value. Below is a rough sketch of what I'm thinking of. It's easy to see that your proposed change fixes problems with wrongly signed constant nodes popping up, but it doesn't correspond to the similar task of guarding against other sorts of wrongly signed nodes. Thanks, -- John diff --git a/src/share/vm/opto/memnode.cpp b/src/share/vm/opto/memnode.cpp --- a/src/share/vm/opto/memnode.cpp +++ b/src/share/vm/opto/memnode.cpp @@ -1718,8 +1718,24 @@ bool is_instance = (tinst != NULL) && tinst->is_known_instance_field(); if (ReduceFieldZeroing || is_instance) { Node* value = can_see_stored_value(mem,phase); - if (value != NULL && value->is_Con()) - return value->bottom_type(); + if (value != NULL && value->is_Con()) { + if (memory_size() < BytesPerInt && + !phase->type(value)->higher_equal(phase->type(this))) { + // If the input to the store does not fit with the load's result type, + // it must be truncated. We can't delay until Ideal call since + // a singleton Value is needed for split_thru_phi optimization. + int con = value->get_int(); + switch (Opcode()) { + case Op_LoadUB: con = (jubyte) con; break; + ... + default: con = min_jint; break; + } + if (con != min_jint) + return TypeInt::make(con); + } else { + return value->bottom_type(); + } + } } if (is_instance) { From vladimir.kozlov at oracle.com Thu Jan 19 00:57:46 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Jan 2012 00:57:46 -0800 Subject: Request for reviews (S): 7131302: connode.cpp:205 Error: ShouldNotReachHere() In-Reply-To: <13A86326-61B4-4F40-B8DA-FF7D233D01EC@oracle.com> References: <4F17B5AF.6060504@oracle.com> <13A86326-61B4-4F40-B8DA-FF7D233D01EC@oracle.com> Message-ID: <4F17DB0A.1020201@oracle.com> Thank you, John My first implementation was exactly as you suggested. But then I realized that separate Value() methods will be better since they will match corresponding specialized Ideal() methods which handle values which does not fit (for example, LoadBNode::Ideal()). Logic in LoadNode::Identity() just do bailout and relies on Value() and Ideal() to do transformations. Thanks, Vladimir On 1/18/12 10:49 PM, John Rose wrote: > On Jan 18, 2012, at 10:18 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7131302/webrev >> >> 7131302: connode.cpp:205 Error: ShouldNotReachHere() >> >> Split_thru_phi optimization used LoadNode::Value() and incorrectly replaced LoadS(StoreC(65535)) with constant (65535) which does not fit into SHORT type. As result merged Phi type become top. >> >> Add Value() methods to short and byte Load nodes to truncate constants which does not fit. >> >> Verified with failed test. > > Your fix works but I think it makes it harder to read the resulting code, especially regarding the implicit correlation between Value and Identity. > > It is also possible to encounter non-constants with the wrong kind of sign, such as a value in the range 0..65535 for a signed short. The logic which handles this is in LoadNode::Identity, guarded with "memory_size()< BytesPerInt". > > I suggest putting parallel logic into LoadNode::Value, rather than splitting LoadNode::Value. That will make it easier to see the relation between Ideal and Value. Below is a rough sketch of what I'm thinking of. > > It's easy to see that your proposed change fixes problems with wrongly signed constant nodes popping up, but it doesn't correspond to the similar task of guarding against other sorts of wrongly signed nodes. > > Thanks, > -- John > > diff --git a/src/share/vm/opto/memnode.cpp b/src/share/vm/opto/memnode.cpp > --- a/src/share/vm/opto/memnode.cpp > +++ b/src/share/vm/opto/memnode.cpp > @@ -1718,8 +1718,24 @@ > bool is_instance = (tinst != NULL)&& tinst->is_known_instance_field(); > if (ReduceFieldZeroing || is_instance) { > Node* value = can_see_stored_value(mem,phase); > - if (value != NULL&& value->is_Con()) > - return value->bottom_type(); > + if (value != NULL&& value->is_Con()) { > + if (memory_size()< BytesPerInt&& > + !phase->type(value)->higher_equal(phase->type(this))) { > + // If the input to the store does not fit with the load's result type, > + // it must be truncated. We can't delay until Ideal call since > + // a singleton Value is needed for split_thru_phi optimization. > + int con = value->get_int(); > + switch (Opcode()) { > + case Op_LoadUB: con = (jubyte) con; break; > + ... > + default: con = min_jint; break; > + } > + if (con != min_jint) > + return TypeInt::make(con); > + } else { > + return value->bottom_type(); > + } > + } > } > > if (is_instance) { > From roland.westrelin at oracle.com Thu Jan 19 01:01:24 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 19 Jan 2012 10:01:24 +0100 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests In-Reply-To: <4F172493.8030904@oracle.com> References: <2CE3D102-90FF-44FC-820E-9AC09126FAA7@oracle.com> <4F172493.8030904@oracle.com> Message-ID: <7BEB3E4D-F78F-49F4-95E6-1208B8695E19@oracle.com> > Sorry, but I don't like such expressions: (!--*ready_cnt.adr_at(m->_idx)). I known that it is just conversion to GrowableArray but I would prefer explicit separate expressions and integer compare so the code will be much easier to understand: Sure. Here is a new webrev: http://cr.openjdk.java.net/~roland/7116050/webrev.02/ Roland. From vladimir.kozlov at oracle.com Thu Jan 19 01:08:08 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Jan 2012 01:08:08 -0800 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests In-Reply-To: <7BEB3E4D-F78F-49F4-95E6-1208B8695E19@oracle.com> References: <2CE3D102-90FF-44FC-820E-9AC09126FAA7@oracle.com> <4F172493.8030904@oracle.com> <7BEB3E4D-F78F-49F4-95E6-1208B8695E19@oracle.com> Message-ID: <4F17DD78.8050708@oracle.com> Thank you, Roland It looks good. Thanks, Vladimir On 1/19/12 1:01 AM, Roland Westrelin wrote: >> Sorry, but I don't like such expressions: (!--*ready_cnt.adr_at(m->_idx)). I known that it is just conversion to GrowableArray but I would prefer explicit separate expressions and integer compare so the code will be much easier to understand: > > Sure. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/7116050/webrev.02/ > > Roland. From roland.westrelin at oracle.com Thu Jan 19 01:08:23 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 19 Jan 2012 10:08:23 +0100 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests In-Reply-To: <4F17DD78.8050708@oracle.com> References: <2CE3D102-90FF-44FC-820E-9AC09126FAA7@oracle.com> <4F172493.8030904@oracle.com> <7BEB3E4D-F78F-49F4-95E6-1208B8695E19@oracle.com> <4F17DD78.8050708@oracle.com> Message-ID: <6C47CF26-C9E9-4448-AFBA-973A65EDDE1D@oracle.com> > It looks good. Thanks for the review. Roland. From john.r.rose at oracle.com Thu Jan 19 01:13:25 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 19 Jan 2012 01:13:25 -0800 Subject: Request for reviews (S): 7131302: connode.cpp:205 Error: ShouldNotReachHere() In-Reply-To: <4F17DB0A.1020201@oracle.com> References: <4F17B5AF.6060504@oracle.com> <13A86326-61B4-4F40-B8DA-FF7D233D01EC@oracle.com> <4F17DB0A.1020201@oracle.com> Message-ID: <43E08DFB-B9A5-4041-84A9-2923AEB2B69F@oracle.com> On Jan 19, 2012, at 12:57 AM, Vladimir Kozlov wrote: > My first implementation was exactly as you suggested. But then I realized that separate Value() methods will be better since they will match corresponding specialized Ideal() methods which handle values which does not fit (for example, LoadBNode::Ideal()). > > Logic in LoadNode::Identity() just do bailout and relies on Value() and Ideal() to do transformations. That makes sense. Thanks for the explanation. It still bothers me that LoadNode::Value can (in principle) return a bogus type. The LoadBNode::Value override appears to exclude cases where LoadNode::Value would return garbage, but it seems very difficult to verify this is the case. Basically, you've prevented LoadNode::Value from breaking LoadBNode::Value in one known case, but you still call it "trustfully" at the end of the block. You might consider putting in a guard or assert against badly signed types emerging from LoadNode::Value. It could go either in LoadNode::Value (parallel to the similar guard in LoadNode::Identity) or at the calls from Load[UBS]*Node::Value to LoadNode::Value. Even if you don't do this, I'm fine with your change, and you can count me as a reviewer. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120119/6d0fde46/attachment.html From vladimir.kozlov at oracle.com Thu Jan 19 01:32:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Jan 2012 01:32:31 -0800 Subject: Request for reviews (S): 7131302: connode.cpp:205 Error: ShouldNotReachHere() In-Reply-To: <43E08DFB-B9A5-4041-84A9-2923AEB2B69F@oracle.com> References: <4F17B5AF.6060504@oracle.com> <13A86326-61B4-4F40-B8DA-FF7D233D01EC@oracle.com> <4F17DB0A.1020201@oracle.com> <43E08DFB-B9A5-4041-84A9-2923AEB2B69F@oracle.com> Message-ID: <4F17E32F.4080206@oracle.com> On 1/19/12 1:13 AM, John Rose wrote: > On Jan 19, 2012, at 12:57 AM, Vladimir Kozlov wrote: > >> My first implementation was exactly as you suggested. But then I realized that separate Value() methods will be better >> since they will match corresponding specialized Ideal() methods which handle values which does not fit (for example, >> LoadBNode::Ideal()). >> >> Logic in LoadNode::Identity() just do bailout and relies on Value() and Ideal() to do transformations. > > That makes sense. Thanks for the explanation. > > It still bothers me that LoadNode::Value can (in principle) return a bogus type. The LoadBNode::Value override appears > to exclude cases where LoadNode::Value would return garbage, but it seems very difficult to verify this is the case. > Basically, you've prevented LoadNode::Value from breaking LoadBNode::Value in one known case, but you still call it > "trustfully" at the end of the block. I see what you mean, I will add assert in LoadNode::Value(): if (value != NULL && value->is_Con()) { + assert(value->bottom_type()->higher_equal(_type),"sanity"); return value->bottom_type(); } I assume this should be true for all types and not just integer. Right? Thanks, Vladimir > > You might consider putting in a guard or assert against badly signed types emerging from LoadNode::Value. It could go > either in LoadNode::Value (parallel to the similar guard in LoadNode::Identity) or at the calls from > Load[UBS]*Node::Value to LoadNode::Value. > > Even if you don't do this, I'm fine with your change, and you can count me as a reviewer. > > -- John From christian.thalinger at oracle.com Thu Jan 19 02:44:42 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 19 Jan 2012 11:44:42 +0100 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) In-Reply-To: <9B6EDDF784ED4160A6A13B62B4506DF5@oracle.com> References: <4F178B6E.9020204@oracle.com> <85571699-5B01-4D33-A14B-5A6A669E5759@oracle.com> <4F17B212.2020703@oracle.com> <9B6EDDF784ED4160A6A13B62B4506DF5@oracle.com> Message-ID: <622AD6CF-4605-4B55-B7A0-2B280F9531DD@oracle.com> Looks good. -- Chris On Jan 19, 2012, at 7:31 AM, Igor Veresov wrote: > I was confused there too because it tries to emulate a call and pushes sort of a return address. But the address is of the jmp instruction rather than the proper return address. > Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.03/ > > igor > > > On Wednesday, January 18, 2012 at 10:02 PM, Vladimir Kozlov wrote: > >> I am fine with guarantees but I misled you with should_not_reach_here() in deopt >> stub on x86, sorry. It is not needed for the same reason as on SPARC. >> >> Thanks, >> Vladimir >> >> Igor Veresov wrote: >>> On Wednesday, January 18, 2012 at 7:34 PM, Tom Rodriguez wrote: >>>> On Jan 18, 2012, at 7:18 PM, Vladimir Kozlov wrote: >>>> >>>>> Why not use should_not_reach_here() in deopt stub? Also x86 deopt stub does not have stop() or should_not_reach_here(). >>>> I think the stop should be removed from emit_deopt_handler on sparc since it's preceded by a direct jump. Usually we emit a stop when we do a call that we don't expect to return, like for an exception dispatch, but in this case since it's a jump it's really impossible the reach the following instruction. >>> >>> >>> Indeed. Removed. >>> >>> But my fix was incorrect. I had to return the 1K limits for the non-product builds. The code that we emit is flag-dependent and with TraceJump on sparc and VerfiyOops on x86 it can grow very large. Unfortunately that means that the asserts are not that useful and we can easily miss such a problem again. I'd like to make them guarantees instead. >>> >>> Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.02/ >>> >>> igor >>>> tom >>>> >>>>> Vladimir >>>>> >>>>> Igor Veresov wrote: >>>>>> After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() >>>>>> which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ >>>>>> igor >>>>> >>>> >>> >> > > > From christian.thalinger at oracle.com Thu Jan 19 03:15:57 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 19 Jan 2012 12:15:57 +0100 Subject: review request (M): 7111138: delete the obsolete flag -XX:+UseRicochetFrames In-Reply-To: <4699EC87-B34F-48EF-8172-BD236AECA691@oracle.com> References: <4699EC87-B34F-48EF-8172-BD236AECA691@oracle.com> Message-ID: On Jan 19, 2012, at 1:00 AM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7111138/webrev.00/ > > This changeset acknowledges that the UseRicochetFrame flag can only be set to true, and that workaround code in the JVM for a pre-ricochet-frame transitional period is no longer needed. Likewise, code included under the macro "TARGET_ARCH_NYI_6939861" is removed, since that code was used only during the transitional period. Looks good. -- Chris > > -- John > > Background: > > Ricochet frames were introduced for x86 in this changeset: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/167b70ff3abc > > Further changesets introduced ricochet frame support for sparc, ppc, and arm. > > During the transitional period between the ports, a platform-specific diagnostic flag UseRicochetFrames was introduced which would allow porters to turn on and off the use of these frames. This flag also as internally set to true or false depending on port status. Since the JDK code which supports non-ricochet-based method handles has been retired, the "false" setting of the flag no longer makes sense, so we are removing the flag altogether. > > Likewise, the macro TARGET_ARCH_NYI_6939861 was defined (to "1") for ports that did not yet have assembly code for supporting UseRicochetFrames. At this point, since all ports do have such assembly code, code under that macro is obsolete and can be deleted. > > Technically, ricochet frames support signature polymorphism for recursive method handles. > > A recursive method handle is one which can execute two or more targets, one after the other. The final target can be tail-called, but the other targets must be called with some sort of stack frame or continuation to direct execution to the next target. This is what a ricochet frame does. Note that the return value of a non-final target must be made available, at least optionally, to the subsequent target(s). Also, incoming arguments must be made available, at least optionally, to one or more of the targets. Cf. MethodHandles.foldArguments for a more complex example. > > A single instance of ricochet frame assembly code can handle a broad range of input argument signatures. In fact, there are a finite number of ricochet frame assembly stubs, which collectively handle all possible argument type combinations. > > The previous version of method handles had a finite (but uncomfortably large) number of Java-coded handler routines, each suited to a relatively small number of argument type combinations. This previous version did not handle all arities and argument type combinations, and so was discarded shortly after the four main CPU ports were completed. > > Note that a future set of changes is likely to eliminate ricochet frames also, in favor of a solution which uses a new intermediate representation for recursive method handles, the "lambda form". This representation will compile to bytecodes, or else (optionally) be more directly processed by a JVM implementation. For a preview, see the Da Vinci Machine patch repository, especially: > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy.txt > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy-7023639.patch > http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-lazy-7023639.patch > > The purpose of this later change will be to reduce the volume of assembly code and make MH invocations easier to analyze by the JIT. From bertrand.delsart at oracle.com Thu Jan 19 03:30:02 2012 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Thu, 19 Jan 2012 11:30:02 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7120448: Fix FP values for compiled frames in frame::describe Message-ID: <20120119113007.9A781479E9@hg.openjdk.java.net> Changeset: eaa9557116a2 Author: bdelsart Date: 2012-01-18 16:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eaa9557116a2 7120448: Fix FP values for compiled frames in frame::describe Summary: fix for debug method frame::describe Reviewed-by: never, kvn ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp From tom.rodriguez at oracle.com Thu Jan 19 09:25:12 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 19 Jan 2012 09:25:12 -0800 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests In-Reply-To: <7BEB3E4D-F78F-49F4-95E6-1208B8695E19@oracle.com> References: <2CE3D102-90FF-44FC-820E-9AC09126FAA7@oracle.com> <4F172493.8030904@oracle.com> <7BEB3E4D-F78F-49F4-95E6-1208B8695E19@oracle.com> Message-ID: <38FD7E0E-A696-4A5C-A8CF-4E8B8696FF17@oracle.com> Looks good. tom On Jan 19, 2012, at 1:01 AM, Roland Westrelin wrote: >> Sorry, but I don't like such expressions: (!--*ready_cnt.adr_at(m->_idx)). I known that it is just conversion to GrowableArray but I would prefer explicit separate expressions and integer compare so the code will be much easier to understand: > > Sure. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/7116050/webrev.02/ > > Roland. From roland.westrelin at oracle.com Thu Jan 19 09:25:53 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 19 Jan 2012 18:25:53 +0100 Subject: review request (S): 7116050 C2/ARM: memory stomping error with DivideMcTests In-Reply-To: <38FD7E0E-A696-4A5C-A8CF-4E8B8696FF17@oracle.com> References: <2CE3D102-90FF-44FC-820E-9AC09126FAA7@oracle.com> <4F172493.8030904@oracle.com> <7BEB3E4D-F78F-49F4-95E6-1208B8695E19@oracle.com> <38FD7E0E-A696-4A5C-A8CF-4E8B8696FF17@oracle.com> Message-ID: <23C1B795-88A4-4D90-99B6-0BD5D28884BE@oracle.com> > Looks good. Thanks for the review. Roland. From tom.rodriguez at oracle.com Thu Jan 19 09:26:13 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 19 Jan 2012 09:26:13 -0800 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) In-Reply-To: <9B6EDDF784ED4160A6A13B62B4506DF5@oracle.com> References: <4F178B6E.9020204@oracle.com> <85571699-5B01-4D33-A14B-5A6A669E5759@oracle.com> <4F17B212.2020703@oracle.com> <9B6EDDF784ED4160A6A13B62B4506DF5@oracle.com> Message-ID: <6A777BDD-2035-4BBF-A55D-2D1992FB03E9@oracle.com> Looks good. tom On Jan 18, 2012, at 10:31 PM, Igor Veresov wrote: > I was confused there too because it tries to emulate a call and pushes sort of a return address. But the address is of the jmp instruction rather than the proper return address. > Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.03/ > > igor > > > On Wednesday, January 18, 2012 at 10:02 PM, Vladimir Kozlov wrote: > >> I am fine with guarantees but I misled you with should_not_reach_here() in deopt >> stub on x86, sorry. It is not needed for the same reason as on SPARC. >> >> Thanks, >> Vladimir >> >> Igor Veresov wrote: >>> On Wednesday, January 18, 2012 at 7:34 PM, Tom Rodriguez wrote: >>>> On Jan 18, 2012, at 7:18 PM, Vladimir Kozlov wrote: >>>> >>>>> Why not use should_not_reach_here() in deopt stub? Also x86 deopt stub does not have stop() or should_not_reach_here(). >>>> I think the stop should be removed from emit_deopt_handler on sparc since it's preceded by a direct jump. Usually we emit a stop when we do a call that we don't expect to return, like for an exception dispatch, but in this case since it's a jump it's really impossible the reach the following instruction. >>> >>> >>> Indeed. Removed. >>> >>> But my fix was incorrect. I had to return the 1K limits for the non-product builds. The code that we emit is flag-dependent and with TraceJump on sparc and VerfiyOops on x86 it can grow very large. Unfortunately that means that the asserts are not that useful and we can easily miss such a problem again. I'd like to make them guarantees instead. >>> >>> Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.02/ >>> >>> igor >>>> tom >>>> >>>>> Vladimir >>>>> >>>>> Igor Veresov wrote: >>>>>> After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() >>>>>> which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ >>>>>> igor >>>>> >>>> >>> >> > > > From igor.veresov at oracle.com Thu Jan 19 10:31:26 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 19 Jan 2012 10:31:26 -0800 Subject: review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) In-Reply-To: <6A777BDD-2035-4BBF-A55D-2D1992FB03E9@oracle.com> References: <4F178B6E.9020204@oracle.com> <85571699-5B01-4D33-A14B-5A6A669E5759@oracle.com> <4F17B212.2020703@oracle.com> <9B6EDDF784ED4160A6A13B62B4506DF5@oracle.com> <6A777BDD-2035-4BBF-A55D-2D1992FB03E9@oracle.com> Message-ID: <202C045CAC1D4624AD109F99783C9CC7@oracle.com> Thanks Vladimir, Tom and Chris! igor On Thursday, January 19, 2012 at 9:26 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jan 18, 2012, at 10:31 PM, Igor Veresov wrote: > > > I was confused there too because it tries to emulate a call and pushes sort of a return address. But the address is of the jmp instruction rather than the proper return address. > > Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.03/ > > > > igor > > > > > > On Wednesday, January 18, 2012 at 10:02 PM, Vladimir Kozlov wrote: > > > > > I am fine with guarantees but I misled you with should_not_reach_here() in deopt > > > stub on x86, sorry. It is not needed for the same reason as on SPARC. > > > > > > Thanks, > > > Vladimir > > > > > > Igor Veresov wrote: > > > > On Wednesday, January 18, 2012 at 7:34 PM, Tom Rodriguez wrote: > > > > > On Jan 18, 2012, at 7:18 PM, Vladimir Kozlov wrote: > > > > > > > > > > > Why not use should_not_reach_here() in deopt stub? Also x86 deopt stub does not have stop() or should_not_reach_here(). > > > > > I think the stop should be removed from emit_deopt_handler on sparc since it's preceded by a direct jump. Usually we emit a stop when we do a call that we don't expect to return, like for an exception dispatch, but in this case since it's a jump it's really impossible the reach the following instruction. > > > > > > > > > > > > > > > > > > > > Indeed. Removed. > > > > > > > > But my fix was incorrect. I had to return the 1K limits for the non-product builds. The code that we emit is flag-dependent and with TraceJump on sparc and VerfiyOops on x86 it can grow very large. Unfortunately that means that the asserts are not that useful and we can easily miss such a problem again. I'd like to make them guarantees instead. > > > > > > > > Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.02/ > > > > > > > > igor > > > > > tom > > > > > > > > > > > Vladimir > > > > > > > > > > > > Igor Veresov wrote: > > > > > > > After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle() > > > > > > > which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too. > > > > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/ > > > > > > > igor > > > > > > > > > > > > > > > > > > > > > From john.r.rose at oracle.com Thu Jan 19 13:09:32 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 19 Jan 2012 13:09:32 -0800 Subject: review request (M): 7111138: delete the obsolete flag -XX:+UseRicochetFrames In-Reply-To: <4699EC87-B34F-48EF-8172-BD236AECA691@oracle.com> References: <4699EC87-B34F-48EF-8172-BD236AECA691@oracle.com> Message-ID: <7833BB01-0CDD-44B6-BB29-A96433300F31@oracle.com> Thanks for the reviews, David, Bertrand, Vladimir, and Chris. -- John From igor.veresov at oracle.com Thu Jan 19 13:54:50 2012 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 19 Jan 2012 21:54:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) Message-ID: <20120119215453.2AE5D470AB@hg.openjdk.java.net> Changeset: 898522ae3c32 Author: iveresov Date: 2012-01-19 10:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/898522ae3c32 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) Summary: Fix exception handler stub size, enable guarantees to check for the correct deopt and exception stub sizes in the future Reviewed-by: kvn, never, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp From john.r.rose at oracle.com Thu Jan 19 15:02:44 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 19 Jan 2012 23:02:44 +0000 Subject: hg: hsx/hotspot-comp/jdk: 3 new changesets Message-ID: <20120119230335.65E9B470B0@hg.openjdk.java.net> Changeset: db189e2f3cdb Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/db189e2f3cdb 7117167: Misc warnings in java.lang.invoke and sun.invoke.* Reviewed-by: smarks ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 01014596ada1 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/01014596ada1 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init Summary: Use correct access token for unreflecting MHs where setAccessible(true) Reviewed-by: never, twisti ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 92d2cba30f08 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/92d2cba30f08 7030453: JSR 292 ClassValue.get method is too slow Summary: Implement ClassValue cooperatively with Class like ThreadLocal with Thread. Reviewed-by: twisti, mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! test/java/lang/invoke/ClassValueTest.java From igor.veresov at oracle.com Thu Jan 19 18:05:17 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 19 Jan 2012 18:05:17 -0800 Subject: review(XS): 7131028: Switch statement takes wrong path Message-ID: <70BC422549C542048D27A863277F2716@oracle.com> C1 did not pass the type to the branch LIR instruction in one instance. Huge thanks to Vladimir for analysis of the generated code! Webrev: http://cr.openjdk.java.net/~iveresov/7131028/webrev.00/ igor From vladimir.kozlov at oracle.com Thu Jan 19 18:42:45 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Jan 2012 18:42:45 -0800 Subject: review(XS): 7131028: Switch statement takes wrong path In-Reply-To: <70BC422549C542048D27A863277F2716@oracle.com> References: <70BC422549C542048D27A863277F2716@oracle.com> Message-ID: <4F18D4A5.7030704@oracle.com> Looks good. And it passed the test. Thanks, Vladimir On 1/19/12 6:05 PM, Igor Veresov wrote: > C1 did not pass the type to the branch LIR instruction in one instance. > Huge thanks to Vladimir for analysis of the generated code! > > Webrev: http://cr.openjdk.java.net/~iveresov/7131028/webrev.00/ > > igor > > From john.r.rose at oracle.com Thu Jan 19 19:40:28 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 20 Jan 2012 03:40:28 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20120120034031.E75BB470B4@hg.openjdk.java.net> Changeset: 15d394228cfa Author: jrose Date: 2012-01-19 13:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/15d394228cfa 7111138: delete the obsolete flag -XX:+UseRicochetFrames Reviewed-by: dholmes, bdelsart, kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 469e0a46f2fe Author: jrose Date: 2012-01-19 17:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469e0a46f2fe Merge From tom.rodriguez at oracle.com Thu Jan 19 20:24:18 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 19 Jan 2012 20:24:18 -0800 Subject: review(XS): 7131028: Switch statement takes wrong path In-Reply-To: <70BC422549C542048D27A863277F2716@oracle.com> References: <70BC422549C542048D27A863277F2716@oracle.com> Message-ID: Looks good. tom On Jan 19, 2012, at 6:05 PM, Igor Veresov wrote: > C1 did not pass the type to the branch LIR instruction in one instance. > Huge thanks to Vladimir for analysis of the generated code! > > Webrev: http://cr.openjdk.java.net/~iveresov/7131028/webrev.00/ > > igor > > From igor.veresov at oracle.com Thu Jan 19 20:40:37 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 19 Jan 2012 20:40:37 -0800 Subject: review(XS): 7131028: Switch statement takes wrong path In-Reply-To: References: <70BC422549C542048D27A863277F2716@oracle.com> Message-ID: <9E301B9EB7F2437C91CB04101946B4DC@oracle.com> Thanks Vladimir and Tom! igor On Thursday, January 19, 2012 at 8:24 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jan 19, 2012, at 6:05 PM, Igor Veresov wrote: > > > C1 did not pass the type to the branch LIR instruction in one instance. > > Huge thanks to Vladimir for analysis of the generated code! > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7131028/webrev.00/ > > > > igor From john.r.rose at oracle.com Fri Jan 20 02:51:54 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 20 Jan 2012 10:51:54 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 23 new changesets Message-ID: <20120120105246.C347F470BF@hg.openjdk.java.net> Changeset: bacb651cf5bf Author: tonyp Date: 2012-01-05 05:54 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bacb651cf5bf 7113006: G1: excessive ergo output when an evac failure happens Summary: Introduce a flag that is set when a heap expansion attempt during a GC fails so that we do not consantly attempt to expand the heap when it's going to fail anyway. This not only prevents the excessive ergo output (which is generated when a region allocation fails) but also avoids excessive and ultimately unsuccessful expansion attempts. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5fd354a959c5 Author: jmasa Date: 2012-01-05 21:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5fd354a959c5 Merge Changeset: 023652e49ac0 Author: johnc Date: 2011-12-23 11:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/023652e49ac0 7121496: G1: do the per-region evacuation failure handling work in parallel Summary: Parallelize the removal of self forwarding pointers etc. by wrapping in a HeapRegion closure, which is then wrapped inside an AbstractGangTask. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp + src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 02838862dec8 Author: tonyp Date: 2012-01-07 00:43 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/02838862dec8 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array Summary: Store the "next chunk start index" in the length field of the to-space object, instead of the from-space object, so that we can always reliably read the size of all from-space objects. Reviewed-by: johnc, ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 97c00e21fecb Author: tonyp Date: 2012-01-09 23:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/97c00e21fecb 7125281: G1: heap expansion code is replicated Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 1d6185f732aa Author: brutisso Date: 2012-01-10 20:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1d6185f732aa 7128532: G1: Change default value of G1DefaultMaxNewGenPercent to 80 Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2ace1c4ee8da Author: tonyp Date: 2012-01-10 18:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2ace1c4ee8da 6888336: G1: avoid explicitly marking and pushing objects in survivor spaces Summary: This change simplifies the interaction between GC and concurrent marking. By disabling survivor spaces during the initial-mark pause we don't need to propagate marks of objects we copy during each GC (since we never need to copy an explicitly marked object). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.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/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 9d4f4a1825e4 Author: brutisso Date: 2012-01-13 01:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9d4f4a1825e4 Merge Changeset: 5acd82522540 Author: brutisso Date: 2012-01-13 06:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5acd82522540 Merge Changeset: e504fd26c073 Author: kvn Date: 2012-01-13 14:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e504fd26c073 Merge Changeset: fe2c87649981 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fe2c87649981 Added tag jdk8-b19 for changeset 9232e0ecbc2c ! .hgtags Changeset: 9952d1c439d6 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9952d1c439d6 Added tag jdk8-b20 for changeset fe2c87649981 ! .hgtags Changeset: ed621d125d02 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ed621d125d02 Added tag jdk8-b21 for changeset 9952d1c439d6 ! .hgtags Changeset: 513351373923 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/513351373923 Merge Changeset: 24727fb37561 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/24727fb37561 Added tag hs23-b10 for changeset 513351373923 ! .hgtags Changeset: 4e80db53c323 Author: amurillo Date: 2012-01-14 00:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4e80db53c323 7129512: new hotspot build - hs23-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 94ec88ca68e2 Author: phh Date: 2012-01-11 17:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/94ec88ca68e2 7115199: Add event tracing hooks and Java Flight Recorder infrastructure Summary: Added a nop tracing infrastructure, JFR makefile changes and other infrastructure used only by JFR. Reviewed-by: acorn, sspitsyn Contributed-by: markus.gronlund at oracle.com ! make/Makefile ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jni.cpp + src/share/vm/prims/jniExport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp + src/share/vm/trace/traceEventTypes.hpp + src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4f3ce9284781 Author: phh Date: 2012-01-11 17:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4f3ce9284781 Merge ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp Changeset: f1cd52d6ce02 Author: kamg Date: 2012-01-17 10:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f1cd52d6ce02 Merge Changeset: d7e3846464d0 Author: zgu Date: 2012-01-17 13:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d7e3846464d0 7071311: Decoder enhancement Summary: Made decoder thread-safe Reviewed-by: coleenp, kamg - src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/decoder_machO.cpp + src/os/bsd/vm/decoder_machO.hpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp + src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp + src/share/vm/utilities/decoder_elf.cpp + src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 6520f9861937 Author: kamg Date: 2012-01-17 21:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6520f9861937 Merge Changeset: db18ca98d237 Author: zgu Date: 2012-01-18 11:45 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/db18ca98d237 7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X Summary: Decoder API changes did not reflect in os_bsd Reviewed-by: kamg, dcubed ! src/os/bsd/vm/os_bsd.cpp Changeset: 50d9b7a0072c Author: jrose Date: 2012-01-19 18:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/50d9b7a0072c Merge From vladimir.kozlov at oracle.com Fri Jan 20 14:31:46 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 20 Jan 2012 22:31:46 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7131302: connode.cpp:205 Error: ShouldNotReachHere() Message-ID: <20120120223150.830E0470DB@hg.openjdk.java.net> Changeset: 53a127075045 Author: kvn Date: 2012-01-20 09:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/53a127075045 7131302: connode.cpp:205 Error: ShouldNotReachHere() Summary: Add Value() methods to short and byte Load nodes to truncate constants which does not fit. Reviewed-by: jrose ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp From igor.veresov at oracle.com Fri Jan 20 19:09:07 2012 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sat, 21 Jan 2012 03:09:07 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7131028: Switch statement takes wrong path Message-ID: <20120121030913.C7AC3470F2@hg.openjdk.java.net> Changeset: 9164b8236699 Author: iveresov Date: 2012-01-20 15:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9164b8236699 7131028: Switch statement takes wrong path Summary: Pass correct type to branch in LIRGenerator::do_SwitchRanges() Reviewed-by: kvn, never ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp From john.coomes at oracle.com Sat Jan 21 15:23:08 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:23:08 +0000 Subject: hg: hsx/hotspot-comp: 2 new changesets Message-ID: <20120121232308.CCBDB470FE@hg.openjdk.java.net> Changeset: 7ad075c80995 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/7ad075c80995 Added tag jdk8-b21 for changeset cc771d92284f ! .hgtags Changeset: 60d6f64a86b1 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/60d6f64a86b1 Added tag jdk8-b22 for changeset 7ad075c80995 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:23:14 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:23:14 +0000 Subject: hg: hsx/hotspot-comp/corba: 2 new changesets Message-ID: <20120121232316.935AF470FF@hg.openjdk.java.net> Changeset: a11d0062c445 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/a11d0062c445 Added tag jdk8-b21 for changeset f157fc2a71a3 ! .hgtags Changeset: 5218eb256658 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/5218eb256658 Added tag jdk8-b22 for changeset a11d0062c445 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:23:22 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:23:22 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 2 new changesets Message-ID: <20120121232322.187F047100@hg.openjdk.java.net> Changeset: cf9d6ec44f89 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/cf9d6ec44f89 Added tag jdk8-b21 for changeset d41eeadf5c13 ! .hgtags Changeset: 95102fd33418 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/95102fd33418 Added tag jdk8-b22 for changeset cf9d6ec44f89 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:23:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:23:27 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 4 new changesets Message-ID: <20120121232327.D58B447101@hg.openjdk.java.net> Changeset: e67d51254533 Author: ohair Date: 2012-01-09 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/e67d51254533 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar Reviewed-by: dholmes ! build-defs.xml Changeset: c266cab0e3ff Author: katleman Date: 2012-01-11 16:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/c266cab0e3ff Merge Changeset: 8d3df89b0f2d Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/8d3df89b0f2d Added tag jdk8-b21 for changeset c266cab0e3ff ! .hgtags Changeset: 25ce7a000487 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/25ce7a000487 Added tag jdk8-b22 for changeset 8d3df89b0f2d ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:24:02 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:24:02 +0000 Subject: hg: hsx/hotspot-comp/jdk: 20 new changesets Message-ID: <20120121232733.C0FA647106@hg.openjdk.java.net> Changeset: 1c4fffa22930 Author: okutsu Date: 2011-12-21 17:09 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1c4fffa22930 7122054: (tz) Windows-only: tzmappings needs update for KB2633952 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: b1814b3ea6d3 Author: michaelm Date: 2011-12-21 10:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b1814b3ea6d3 7078386: NetworkInterface.getNetworkInterfaces() may return corrupted results on linux Reviewed-by: michaelm, alanb, chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/NetworkInterface.c Changeset: a9dfdc523c2c Author: valeriep Date: 2011-12-21 14:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a9dfdc523c2c 6839886: Array overrun in pkcs11 Summary: Fix the wrong value when dealing w/ month and day. Reviewed-by: mullan ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Changeset: 11698dedbe79 Author: weijun Date: 2011-12-22 15:35 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/11698dedbe79 7122169: TcpTimeout fail for various reasons Reviewed-by: alanb ! test/sun/security/krb5/auto/TcpTimeout.java Changeset: 559e07ed1f56 Author: alanb Date: 2011-12-22 10:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/559e07ed1f56 7076310: (file) AclEntry.Builder setFlags throws IllegalArgumentException if set argument is empty Reviewed-by: alanb Contributed-by: stephen.flores at oracle.com ! src/share/classes/java/nio/file/attribute/AclEntry.java + test/java/nio/file/attribute/AclEntry/EmptySet.java Changeset: 3c1ab134db71 Author: dcubed Date: 2011-12-22 18:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3c1ab134db71 7121600: Instrumentation.redefineClasses() leaks class bytes Summary: Call JNI ReleaseByteArrayElements() on memory returned by JNI GetByteArrayElements(). Also push test for 7122253. Reviewed-by: acorn, poonam ! src/share/instrument/JPLISAgent.c + test/java/lang/instrument/BigClass.java + test/java/lang/instrument/MakeJAR4.sh + test/java/lang/instrument/RedefineBigClass.sh + test/java/lang/instrument/RedefineBigClassAgent.java + test/java/lang/instrument/RedefineBigClassApp.java + test/java/lang/instrument/RetransformBigClass.sh + test/java/lang/instrument/RetransformBigClassAgent.java + test/java/lang/instrument/RetransformBigClassApp.java Changeset: 437255d15e76 Author: lana Date: 2011-12-28 10:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/437255d15e76 Merge - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 3a7ea63302f8 Author: smarks Date: 2011-12-29 16:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3a7ea63302f8 7122061: add -Xlint:all -Werror to warning-free build steps Reviewed-by: chegar, alanb, dholmes, ohair ! make/com/sun/demo/jvmti/hprof/Makefile ! make/com/sun/java/browser/net/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Makefile ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/java/instrument/Makefile ! make/java/rmi/Makefile ! make/java/text/base/Makefile ! make/java/text/bidi/Makefile ! make/java/util/Makefile ! make/javax/accessibility/Makefile ! make/javax/others/Makefile ! make/javax/security/Makefile ! make/jpda/tty/Makefile ! make/sun/launcher/Makefile ! make/sun/serialver/Makefile ! make/sun/text/Makefile ! make/sun/util/Makefile Changeset: 5aeefe0e5d8c Author: chegar Date: 2012-01-01 09:24 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5aeefe0e5d8c 7125055: ContentHandler.getContent API changed in error Reviewed-by: alanb ! src/share/classes/java/net/ContentHandler.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 Changeset: 8952a5f494f9 Author: ksrini Date: 2012-01-03 08:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8952a5f494f9 7123582: (launcher) display the -version and -XshowSettings Reviewed-by: alanb ! src/share/bin/java.c ! test/tools/launcher/Settings.java Changeset: 5e34726cb4bb Author: ksrini Date: 2012-01-03 08:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5e34726cb4bb 7124443: (launcher) test DefaultsLocaleTest fails with Windows shells. Reviewed-by: darcy ! test/tools/launcher/DefaultLocaleTest.java - test/tools/launcher/DefaultLocaleTest.sh + test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java Changeset: 0194fe5ca404 Author: fparain Date: 2012-01-04 03:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0194fe5ca404 7104647: Adding a diagnostic command framework Reviewed-by: mchung, dholmes ! make/common/Release.gmk ! make/java/management/mapfile-vers ! make/launchers/Makefile ! make/sun/tools/Makefile + src/linux/doc/man/jcmd.1 + src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java + src/share/classes/com/sun/management/DiagnosticCommandInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java + src/share/classes/sun/tools/jcmd/Arguments.java + src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/HotSpotDiagnostic.c + src/solaris/doc/sun/man/man1/jcmd.1 + test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/jcmd/dcmd-script.txt + test/sun/tools/jcmd/help_help.out + test/sun/tools/jcmd/jcmd-Defaults.sh + test/sun/tools/jcmd/jcmd-f.sh + test/sun/tools/jcmd/jcmd-help-help.sh + test/sun/tools/jcmd/jcmd-help.sh + test/sun/tools/jcmd/jcmd-pid.sh + test/sun/tools/jcmd/jcmd_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output2.awk + test/sun/tools/jcmd/usage.out Changeset: 38a318502e19 Author: lana Date: 2012-01-04 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/38a318502e19 Merge ! make/common/Release.gmk - test/tools/launcher/DefaultLocaleTest.sh Changeset: 93ab1df09d11 Author: lana Date: 2012-01-09 19:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/93ab1df09d11 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: ddb97d4fa83d Author: ohair Date: 2012-01-04 17:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ddb97d4fa83d 7127104: Build issue with prtconf and zones, also using := to avoid extra execs Reviewed-by: katleman ! make/common/shared/Platform.gmk Changeset: 7c8c16f2c05e Author: ohair Date: 2012-01-09 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7c8c16f2c05e 7128320: Fix freetype sanity check to make it more generic Reviewed-by: luchsh, katleman Contributed-by: Jonathan Lu ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/tools/freetypecheck/Makefile Changeset: 664fa4fb0ee4 Author: katleman Date: 2012-01-11 16:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/664fa4fb0ee4 Merge Changeset: dda27c73d8db Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dda27c73d8db Added tag jdk8-b21 for changeset 664fa4fb0ee4 ! .hgtags Changeset: 76bfd08d8cc5 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/76bfd08d8cc5 Added tag jdk8-b22 for changeset dda27c73d8db ! .hgtags Changeset: 81a2629aa2a2 Author: amurillo Date: 2012-01-20 14:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/81a2629aa2a2 Merge From tom.rodriguez at oracle.com Sun Jan 22 18:45:04 2012 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Mon, 23 Jan 2012 02:45:04 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7130676: Tiered: assert(bci == 0 || 0<= bci && bci Changeset: a81f60ddab06 Author: never Date: 2012-01-22 14:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a81f60ddab06 7130676: Tiered: assert(bci == 0 || 0<= bci && bci References: <4F16F35E.1040200@oracle.com> Message-ID: That looks great. Thanks for improving the output so much. tom On Jan 18, 2012, at 8:29 AM, Bertrand Delsart wrote: > Second RFR related to frame_describe: > http://cr.openjdk.java.net/~bdelsart/7120450/00/webrev/ > > This comes on top of 7120448, currently being submitted. > > Goal of that RFR was to enhance x86/PPC with stuff we had added to our embedded plarforms, namely information about ricochet frames and basic information for non standard frames. This only impacts debugging code (dumps generated by pfl() calls or temporarily added to the JVM during development). > > We did fix a small issue in frame::describe. is_deoptimized() could > fail on assertions for some frames. This was discovered by stress testing the calls with (non submited) print_frame_layout() calls in in the transitions back from the JVM to Java (to ensure the robustness of the dump and the adequacy of the information). > > Also called print_frame_layout() from trace_method_handle to debug ricochet frames information. This is not part of this RFR since the changes are more intrusive. > > Thanks, > > Bertrand. > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE From john.coomes at oracle.com Mon Jan 23 14:33:17 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Mon, 23 Jan 2012 22:33:17 +0000 Subject: hg: hsx/hotspot-comp/langtools: 8 new changesets Message-ID: <20120123223336.60DAC47141@hg.openjdk.java.net> Changeset: 116f68a5e677 Author: jjg Date: 2011-12-23 22:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/116f68a5e677 7124605: typos in javac comments Reviewed-by: ksrini ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/inference/7086601/T7086601b.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/LambdaParserTest.java Changeset: 67512b631961 Author: lana Date: 2011-12-28 10:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/67512b631961 Merge Changeset: 7a836147b266 Author: jjg Date: 2012-01-03 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/7a836147b266 4881269: improve diagnostic for ill-formed tokens Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IllegalDot.java + test/tools/javac/parser/T4881269.java + test/tools/javac/parser/T4881269.out Changeset: a07eef109532 Author: jjh Date: 2012-01-03 17:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a07eef109532 7046929: tools/javac/api/T6397104.java fails Reviewed-by: jjg ! test/tools/javac/api/T6397104.java Changeset: 4e8aa6eca726 Author: lana Date: 2012-01-04 10:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4e8aa6eca726 Merge Changeset: bcb21abf1c41 Author: lana Date: 2012-01-09 19:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/bcb21abf1c41 Merge Changeset: 390a7828ae18 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/390a7828ae18 Added tag jdk8-b21 for changeset bcb21abf1c41 ! .hgtags Changeset: f6191bad139a Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f6191bad139a Added tag jdk8-b22 for changeset 390a7828ae18 ! .hgtags From christian.thalinger at oracle.com Tue Jan 24 01:57:51 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 24 Jan 2012 10:57:51 +0100 Subject: RFR, S, 7120450: complete information dumped by frame_describe In-Reply-To: <4F16F35E.1040200@oracle.com> References: <4F16F35E.1040200@oracle.com> Message-ID: Looks good. Only one little nit: + intptr_t* esp = * interpreter_frame_esp_addr(); Could you remove that extra space for the dereference? It looked like a multiplication at first sight :-) -- Chris On Jan 18, 2012, at 5:29 PM, Bertrand Delsart wrote: > Second RFR related to frame_describe: > http://cr.openjdk.java.net/~bdelsart/7120450/00/webrev/ > > This comes on top of 7120448, currently being submitted. > > Goal of that RFR was to enhance x86/PPC with stuff we had added to our embedded plarforms, namely information about ricochet frames and basic information for non standard frames. This only impacts debugging code (dumps generated by pfl() calls or temporarily added to the JVM during development). > > We did fix a small issue in frame::describe. is_deoptimized() could > fail on assertions for some frames. This was discovered by stress testing the calls with (non submited) print_frame_layout() calls in in the transitions back from the JVM to Java (to ensure the robustness of the dump and the adequacy of the information). > > Also called print_frame_layout() from trace_method_handle to debug ricochet frames information. This is not part of this RFR since the changes are more intrusive. > > Thanks, > > Bertrand. > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE From bertrand.delsart at oracle.com Tue Jan 24 05:06:28 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 24 Jan 2012 14:06:28 +0100 Subject: RFR, S, 7120450: complete information dumped by frame_describe In-Reply-To: References: <4F16F35E.1040200@oracle.com> Message-ID: <4F1EACD4.2010508@oracle.com> Thanks Chris, will do. Bertrand. On 01/24/12 10:57 AM, Christian Thalinger wrote: > Looks good. Only one little nit: > > + intptr_t* esp = * interpreter_frame_esp_addr(); > > Could you remove that extra space for the dereference? It looked like a multiplication at first sight :-) > > -- Chris > > On Jan 18, 2012, at 5:29 PM, Bertrand Delsart wrote: > >> Second RFR related to frame_describe: >> http://cr.openjdk.java.net/~bdelsart/7120450/00/webrev/ >> >> This comes on top of 7120448, currently being submitted. >> >> Goal of that RFR was to enhance x86/PPC with stuff we had added to our embedded plarforms, namely information about ricochet frames and basic information for non standard frames. This only impacts debugging code (dumps generated by pfl() calls or temporarily added to the JVM during development). >> >> We did fix a small issue in frame::describe. is_deoptimized() could >> fail on assertions for some frames. This was discovered by stress testing the calls with (non submited) print_frame_layout() calls in in the transitions back from the JVM to Java (to ensure the robustness of the dump and the adequacy of the information). >> >> Also called print_frame_layout() from trace_method_handle to debug ricochet frames information. This is not part of this RFR since the changes are more intrusive. >> >> Thanks, >> >> Bertrand. >> -- >> Bertrand Delsart, bertrand.delsart at oracle.com, >> Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, >> 38334 Saint Ismier, FRANCE > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From bertrand.delsart at oracle.com Tue Jan 24 12:02:50 2012 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Tue, 24 Jan 2012 20:02:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7120450: complete information dumped by frame_describe Message-ID: <20120124200255.25AB847172@hg.openjdk.java.net> Changeset: 82e5a84b7436 Author: bdelsart Date: 2012-01-24 15:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/82e5a84b7436 7120450: complete information dumped by frame_describe Summary: improvements of frame_describe Reviewed-by: never, twisti ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/runtime/frame.cpp From jiangli.zhou at oracle.com Tue Jan 24 12:04:53 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 24 Jan 2012 12:04:53 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type Message-ID: <4F1F0EE5.5060401@oracle.com> Hi, Please review the change for 7132690: http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ It changes InstanceKlass::_reference_type from ReferenceType to u1. The ReferenceType is defined as an enum with 6 values (src/share/vm/utilities/globalDefinitions.hpp). The change saves 4-byte for each class. Tested with runThese and ute vm.quick.testlist. Ran jprt. Thanks, Jiangli From roland.westrelin at oracle.com Tue Jan 24 12:16:54 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 24 Jan 2012 21:16:54 +0100 Subject: review request (XS): 7123910 Some CTW tests crash VM: is_loaded() && that->is_loaded() Message-ID: <8CB2D3FD-EA8A-414F-9CE2-F5CFAB7D6D32@oracle.com> http://cr.openjdk.java.net/~roland/7123910/webrev.00/ Parse::do_checkcast() calls GraphKit::gen_checkcast() and it crashes because the object's klass is not loaded. It is not caught by the checks in Parse::do_checkcast() because obj is a pointer to an array. This extends those checks so that an uncommon trap is inserted not only for an oop but also for an arrayOop. Roland. From igor.veresov at oracle.com Tue Jan 24 12:42:52 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 24 Jan 2012 12:42:52 -0800 Subject: review(XXS): 7132945: Tiered: adjust OSR threshold of level 3 Message-ID: I'd like to adjust one of the thresholds for tiered. Roland and I noticed that setting the value of Tier3BackEdgeThreshold to 60000 instead of 7000 yield far superior startup performance on machines with one CPU. There is no significant change for machines with many cores. Webrev: http://cr.openjdk.java.net/~iveresov/7132945/webrev.00/ igor From vladimir.kozlov at oracle.com Tue Jan 24 12:45:19 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 Jan 2012 12:45:19 -0800 Subject: review(XXS): 7132945: Tiered: adjust OSR threshold of level 3 In-Reply-To: References: Message-ID: <4F1F185F.8050200@oracle.com> Good. Vladimir Igor Veresov wrote: > I'd like to adjust one of the thresholds for tiered. Roland and I noticed that setting the value of Tier3BackEdgeThreshold to 60000 instead of 7000 yield far superior startup performance on machines with one CPU. There is no significant change for machines with many cores. > > Webrev: http://cr.openjdk.java.net/~iveresov/7132945/webrev.00/ > > igor > > From vladimir.kozlov at oracle.com Tue Jan 24 12:55:13 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 Jan 2012 12:55:13 -0800 Subject: review request (XS): 7123910 Some CTW tests crash VM: is_loaded() && that->is_loaded() In-Reply-To: <8CB2D3FD-EA8A-414F-9CE2-F5CFAB7D6D32@oracle.com> References: <8CB2D3FD-EA8A-414F-9CE2-F5CFAB7D6D32@oracle.com> Message-ID: <4F1F1AB1.2020805@oracle.com> Looks good. Vladimir Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7123910/webrev.00/ > > Parse::do_checkcast() calls GraphKit::gen_checkcast() and it crashes because the object's klass is not loaded. It is not caught by the checks in Parse::do_checkcast() because obj is a pointer to an array. This extends those checks so that an uncommon trap is inserted not only for an oop but also for an arrayOop. > > Roland. From vitalyd at gmail.com Tue Jan 24 14:13:48 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 24 Jan 2012 17:13:48 -0500 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F0EE5.5060401@oracle.com> References: <4F1F0EE5.5060401@oracle.com> Message-ID: Hi Jiangli, This is probably overly paranoid so feel free to ignore, but should the setter in InstanceKlass assert that the passed in ReferenceType fits into a u1 instead of silently narrowing it? Or change the setter to take a u1 and make caller do the cast? This would prevent someone defining another member of the enum with an explicit value that doesn't fit into u1. Like I said, paranoia ... :) Thanks Sent from my phone On Jan 24, 2012 3:06 PM, "Jiangli Zhou" wrote: > Hi, > > Please review the change for 7132690: > > http://cr.openjdk.java.net/~**jiangli/7132690/webrev.00/ > > It changes InstanceKlass::_reference_type from ReferenceType to u1. The > ReferenceType is defined as an enum with 6 values (src/share/vm/utilities/ > **globalDefinitions.hpp). The change saves 4-byte for each class. > > Tested with runThese and ute vm.quick.testlist. Ran jprt. > > Thanks, > > Jiangli > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120124/962dae2b/attachment.html From igor.veresov at oracle.com Tue Jan 24 14:24:30 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 24 Jan 2012 14:24:30 -0800 Subject: review(XXS): 7132945: Tiered: adjust OSR threshold of level 3 In-Reply-To: <4F1F185F.8050200@oracle.com> References: <4F1F185F.8050200@oracle.com> Message-ID: Thanks! igor On Tuesday, January 24, 2012 at 12:45 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > Igor Veresov wrote: > > I'd like to adjust one of the thresholds for tiered. Roland and I noticed that setting the value of Tier3BackEdgeThreshold to 60000 instead of 7000 yield far superior startup performance on machines with one CPU. There is no significant change for machines with many cores. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7132945/webrev.00/ > > > > igor From jiangli.zhou at oracle.com Tue Jan 24 14:54:38 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 24 Jan 2012 14:54:38 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: References: <4F1F0EE5.5060401@oracle.com> Message-ID: <4F1F36AE.6060001@oracle.com> Hi Vitaly, An assert in the setter probably is a good idea. I should have added it when making the change. Thanks for the comments! Thanks, Jiangli On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: > > Hi Jiangli, > > This is probably overly paranoid so feel free to ignore, but should > the setter in InstanceKlass assert that the passed in ReferenceType > fits into a u1 instead of silently narrowing it? Or change the setter > to take a u1 and make caller do the cast? This would prevent someone > defining another member of the enum with an explicit value that > doesn't fit into u1. Like I said, paranoia ... :) > > Thanks > > Sent from my phone > > On Jan 24, 2012 3:06 PM, "Jiangli Zhou" > wrote: > > Hi, > > Please review the change for 7132690: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ > > > It changes InstanceKlass::_reference_type from ReferenceType to > u1. The ReferenceType is defined as an enum with 6 values > (src/share/vm/utilities/globalDefinitions.hpp). The change saves > 4-byte for each class. > > Tested with runThese and ute vm.quick.testlist. Ran jprt. > > Thanks, > > Jiangli > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120124/d1465722/attachment-0001.html From vladimir.kozlov at oracle.com Tue Jan 24 15:00:02 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 Jan 2012 15:00:02 -0800 Subject: Request for reviews (S): 7132936: guarantee(t != NULL) failed: must be con Message-ID: <4F1F37F2.9060108@oracle.com> http://cr.openjdk.java.net/~kvn/7132936/webrev 7132936: guarantee(t != NULL) failed: must be con Use !higher_equal() check to skip top and values which fit. LoadNode::Ideal() will return value's type in such cases. Verified with failed tests. Thanks, Vladimir From tom.rodriguez at oracle.com Tue Jan 24 15:03:25 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 24 Jan 2012 15:03:25 -0800 Subject: review(XXS): 7132945: Tiered: adjust OSR threshold of level 3 In-Reply-To: References: Message-ID: <607A0B87-60CF-4AE4-A469-2BB10EEA999A@oracle.com> Looks good. tom On Jan 24, 2012, at 12:42 PM, Igor Veresov wrote: > I'd like to adjust one of the thresholds for tiered. Roland and I noticed that setting the value of Tier3BackEdgeThreshold to 60000 instead of 7000 yield far superior startup performance on machines with one CPU. There is no significant change for machines with many cores. > > Webrev: http://cr.openjdk.java.net/~iveresov/7132945/webrev.00/ > > igor > > From tom.rodriguez at oracle.com Tue Jan 24 15:08:11 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 24 Jan 2012 15:08:11 -0800 Subject: Request for reviews (S): 7132936: guarantee(t != NULL) failed: must be con In-Reply-To: <4F1F37F2.9060108@oracle.com> References: <4F1F37F2.9060108@oracle.com> Message-ID: <4E591045-CEF8-4D31-AC5C-23180C9E1544@oracle.com> Looks good. tom On Jan 24, 2012, at 3:00 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7132936/webrev > > 7132936: guarantee(t != NULL) failed: must be con > > Use !higher_equal() check to skip top and values which fit. LoadNode::Ideal() will return value's type in such cases. > > Verified with failed tests. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Jan 24 15:10:39 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 Jan 2012 15:10:39 -0800 Subject: Request for reviews (S): 7132936: guarantee(t != NULL) failed: must be con In-Reply-To: <4E591045-CEF8-4D31-AC5C-23180C9E1544@oracle.com> References: <4F1F37F2.9060108@oracle.com> <4E591045-CEF8-4D31-AC5C-23180C9E1544@oracle.com> Message-ID: <4F1F3A6F.20800@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Jan 24, 2012, at 3:00 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7132936/webrev >> >> 7132936: guarantee(t != NULL) failed: must be con >> >> Use !higher_equal() check to skip top and values which fit. LoadNode::Ideal() will return value's type in such cases. >> >> Verified with failed tests. >> >> Thanks, >> Vladimir > From jiangli.zhou at oracle.com Tue Jan 24 15:33:33 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 24 Jan 2012 15:33:33 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F36AE.6060001@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> Message-ID: <4F1F3FCD.4060704@oracle.com> The updated webrev is : http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ Thanks, Jiangli On 01/24/2012 02:54 PM, Jiangli Zhou wrote: > Hi Vitaly, > > An assert in the setter probably is a good idea. I should have added > it when making the change. Thanks for the comments! > > Thanks, > Jiangli > > On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >> >> Hi Jiangli, >> >> This is probably overly paranoid so feel free to ignore, but should >> the setter in InstanceKlass assert that the passed in ReferenceType >> fits into a u1 instead of silently narrowing it? Or change the setter >> to take a u1 and make caller do the cast? This would prevent someone >> defining another member of the enum with an explicit value that >> doesn't fit into u1. Like I said, paranoia ... :) >> >> Thanks >> >> Sent from my phone >> >> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" > > wrote: >> >> Hi, >> >> Please review the change for 7132690: >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >> >> >> It changes InstanceKlass::_reference_type from ReferenceType to >> u1. The ReferenceType is defined as an enum with 6 values >> (src/share/vm/utilities/globalDefinitions.hpp). The change saves >> 4-byte for each class. >> >> Tested with runThese and ute vm.quick.testlist. Ran jprt. >> >> Thanks, >> >> Jiangli >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120124/5bcfb1f6/attachment.html From vitalyd at gmail.com Tue Jan 24 16:17:06 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 24 Jan 2012 19:17:06 -0500 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F3FCD.4060704@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> Message-ID: I think you'll be fully covered (including negative values) by doing the following instead of hard coding max value in the assert: assert(t == (u1)t, "doesn't fit") Sent from my phone On Jan 24, 2012 6:33 PM, "Jiangli Zhou" wrote: > ** > The updated webrev is : > http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ > > Thanks, > Jiangli > > On 01/24/2012 02:54 PM, Jiangli Zhou wrote: > > Hi Vitaly, > > An assert in the setter probably is a good idea. I should have added it > when making the change. Thanks for the comments! > > Thanks, > Jiangli > > On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: > > Hi Jiangli, > > This is probably overly paranoid so feel free to ignore, but should the > setter in InstanceKlass assert that the passed in ReferenceType fits into a > u1 instead of silently narrowing it? Or change the setter to take a u1 and > make caller do the cast? This would prevent someone defining another member > of the enum with an explicit value that doesn't fit into u1. Like I said, > paranoia ... :) > > Thanks > > Sent from my phone > On Jan 24, 2012 3:06 PM, "Jiangli Zhou" wrote: > >> Hi, >> >> Please review the change for 7132690: >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >> >> It changes InstanceKlass::_reference_type from ReferenceType to u1. The >> ReferenceType is defined as an enum with 6 values >> (src/share/vm/utilities/globalDefinitions.hpp). The change saves 4-byte for >> each class. >> >> Tested with runThese and ute vm.quick.testlist. Ran jprt. >> >> Thanks, >> >> Jiangli >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120124/3c2e91f2/attachment.html From igor.veresov at oracle.com Tue Jan 24 16:44:01 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 24 Jan 2012 16:44:01 -0800 Subject: review(XXS): 7132945: Tiered: adjust OSR threshold of level 3 In-Reply-To: <607A0B87-60CF-4AE4-A469-2BB10EEA999A@oracle.com> References: <607A0B87-60CF-4AE4-A469-2BB10EEA999A@oracle.com> Message-ID: <930D4E719A714AD6B871CBA08EB550E7@oracle.com> Thank you, Tom! igor On Tuesday, January 24, 2012 at 3:03 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jan 24, 2012, at 12:42 PM, Igor Veresov wrote: > > > I'd like to adjust one of the thresholds for tiered. Roland and I noticed that setting the value of Tier3BackEdgeThreshold to 60000 instead of 7000 yield far superior startup performance on machines with one CPU. There is no significant change for machines with many cores. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7132945/webrev.00/ > > > > igor From jiangli.zhou at oracle.com Tue Jan 24 19:19:45 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 24 Jan 2012 19:19:45 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> Message-ID: <4F1F74D1.1040708@oracle.com> Hi Vitaly, Thanks for catching it! A range check seems to be more explicit in this case: http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ Thanks, Jiangli On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: > > I think you'll be fully covered (including negative values) by doing > the following instead of hard coding max value in the assert: > > assert(t == (u1)t, "doesn't fit") > > Sent from my phone > > On Jan 24, 2012 6:33 PM, "Jiangli Zhou" > wrote: > > The updated webrev is : > http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ > > > Thanks, > Jiangli > > On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >> Hi Vitaly, >> >> An assert in the setter probably is a good idea. I should have >> added it when making the change. Thanks for the comments! >> >> Thanks, >> Jiangli >> >> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>> >>> Hi Jiangli, >>> >>> This is probably overly paranoid so feel free to ignore, but >>> should the setter in InstanceKlass assert that the passed in >>> ReferenceType fits into a u1 instead of silently narrowing it? >>> Or change the setter to take a u1 and make caller do the cast? >>> This would prevent someone defining another member of the enum >>> with an explicit value that doesn't fit into u1. Like I said, >>> paranoia ... :) >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >> > wrote: >>> >>> Hi, >>> >>> Please review the change for 7132690: >>> >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>> >>> >>> It changes InstanceKlass::_reference_type from ReferenceType >>> to u1. The ReferenceType is defined as an enum with 6 values >>> (src/share/vm/utilities/globalDefinitions.hpp). The change >>> saves 4-byte for each class. >>> >>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>> >>> Thanks, >>> >>> Jiangli >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120124/c49e9a33/attachment.html From dean.long at oracle.com Tue Jan 24 19:55:48 2012 From: dean.long at oracle.com (Dean Long) Date: Tue, 24 Jan 2012 19:55:48 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F74D1.1040708@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> Message-ID: <4F1F7D44.6000502@oracle.com> I agree with Vitaly. You can find existing examples in the code: interpreter/rewriter.cpp: assert(cache_index == (u1)cache_index, "index overflow"); You could also assert that reference_type == t after the assignment. dl On 1/24/2012 7:19 PM, Jiangli Zhou wrote: > Hi Vitaly, > > Thanks for catching it! A range check seems to be more explicit in > this case: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >> >> I think you'll be fully covered (including negative values) by doing >> the following instead of hard coding max value in the assert: >> >> assert(t == (u1)t, "doesn't fit") >> >> Sent from my phone >> >> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" > > wrote: >> >> The updated webrev is : >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >> >> >> Thanks, >> Jiangli >> >> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>> Hi Vitaly, >>> >>> An assert in the setter probably is a good idea. I should have >>> added it when making the change. Thanks for the comments! >>> >>> Thanks, >>> Jiangli >>> >>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>> >>>> Hi Jiangli, >>>> >>>> This is probably overly paranoid so feel free to ignore, but >>>> should the setter in InstanceKlass assert that the passed in >>>> ReferenceType fits into a u1 instead of silently narrowing it? >>>> Or change the setter to take a u1 and make caller do the cast? >>>> This would prevent someone defining another member of the enum >>>> with an explicit value that doesn't fit into u1. Like I said, >>>> paranoia ... :) >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>> > wrote: >>>> >>>> Hi, >>>> >>>> Please review the change for 7132690: >>>> >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>> >>>> >>>> It changes InstanceKlass::_reference_type from >>>> ReferenceType to u1. The ReferenceType is defined as an >>>> enum with 6 values >>>> (src/share/vm/utilities/globalDefinitions.hpp). The change >>>> saves 4-byte for each class. >>>> >>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120124/7bd69106/attachment.html From vitalyd at gmail.com Tue Jan 24 20:41:55 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 24 Jan 2012 23:41:55 -0500 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F74D1.1040708@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> Message-ID: Hi Jiangli, I think doing the comparison via the cast and == check to make sure it "roundtrips" is better than explicit range check because this way you don't have to change the assert if you change the width of the type (e.g. using u2 instead of u1 would require updating the range). Plus as Dean mentioned, it looks like the cast version is already used in the codebase. Cheers Sent from my phone On Jan 24, 2012 10:19 PM, "Jiangli Zhou" wrote: > ** > Hi Vitaly, > > Thanks for catching it! A range check seems to be more explicit in this > case: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: > > I think you'll be fully covered (including negative values) by doing the > following instead of hard coding max value in the assert: > > assert(t == (u1)t, "doesn't fit") > > Sent from my phone > On Jan 24, 2012 6:33 PM, "Jiangli Zhou" wrote: > >> The updated webrev is : >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >> >> Thanks, >> Jiangli >> >> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >> >> Hi Vitaly, >> >> An assert in the setter probably is a good idea. I should have added it >> when making the change. Thanks for the comments! >> >> Thanks, >> Jiangli >> >> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >> >> Hi Jiangli, >> >> This is probably overly paranoid so feel free to ignore, but should the >> setter in InstanceKlass assert that the passed in ReferenceType fits into a >> u1 instead of silently narrowing it? Or change the setter to take a u1 and >> make caller do the cast? This would prevent someone defining another member >> of the enum with an explicit value that doesn't fit into u1. Like I said, >> paranoia ... :) >> >> Thanks >> >> Sent from my phone >> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" wrote: >> >>> Hi, >>> >>> Please review the change for 7132690: >>> >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>> >>> It changes InstanceKlass::_reference_type from ReferenceType to u1. The >>> ReferenceType is defined as an enum with 6 values >>> (src/share/vm/utilities/globalDefinitions.hpp). The change saves 4-byte for >>> each class. >>> >>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>> >>> Thanks, >>> >>> Jiangli >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120124/391ea0b1/attachment-0001.html From igor.veresov at oracle.com Tue Jan 24 23:23:42 2012 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 25 Jan 2012 07:23:42 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7132945: Tiered: adjust OSR threshold of level 3 Message-ID: <20120125072347.1F72C47188@hg.openjdk.java.net> Changeset: dddf0be88eb1 Author: iveresov Date: 2012-01-24 17:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dddf0be88eb1 7132945: Tiered: adjust OSR threshold of level 3 Summary: Change the value of Tier3BackEdgeThreshold from 7000 to 60000 Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp From david.holmes at oracle.com Tue Jan 24 23:44:59 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Jan 2012 17:44:59 +1000 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> Message-ID: <4F1FB2FB.5060208@oracle.com> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: > Hi Jiangli, > > I think doing the comparison via the cast and == check to make sure it > "roundtrips" is better than explicit range check because this way you > don't have to change the assert if you change the width of the type > (e.g. using u2 instead of u1 would require updating the range). Plus as > Dean mentioned, it looks like the cast version is already used in the > codebase. Plus the range check assumes that the enum will never have negative values (not likely here but why preclude it). David > Cheers > > Sent from my phone > > On Jan 24, 2012 10:19 PM, "Jiangli Zhou" > wrote: > > __ > Hi Vitaly, > > Thanks for catching it! A range check seems to be more explicit in > this case: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >> >> I think you'll be fully covered (including negative values) by >> doing the following instead of hard coding max value in the assert: >> >> assert(t == (u1)t, "doesn't fit") >> >> Sent from my phone >> >> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" > > wrote: >> >> The updated webrev is : >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >> >> >> Thanks, >> Jiangli >> >> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>> Hi Vitaly, >>> >>> An assert in the setter probably is a good idea. I should >>> have added it when making the change. Thanks for the comments! >>> >>> Thanks, >>> Jiangli >>> >>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>> >>>> Hi Jiangli, >>>> >>>> This is probably overly paranoid so feel free to ignore, but >>>> should the setter in InstanceKlass assert that the passed in >>>> ReferenceType fits into a u1 instead of silently narrowing >>>> it? Or change the setter to take a u1 and make caller do the >>>> cast? This would prevent someone defining another member of >>>> the enum with an explicit value that doesn't fit into u1. >>>> Like I said, paranoia ... :) >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>> > >>>> wrote: >>>> >>>> Hi, >>>> >>>> Please review the change for 7132690: >>>> >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>> >>>> >>>> It changes InstanceKlass::_reference_type from >>>> ReferenceType to u1. The ReferenceType is defined as an >>>> enum with 6 values >>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>> change saves 4-byte for each class. >>>> >>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>> >> > From tom.rodriguez at oracle.com Wed Jan 25 08:22:48 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 25 Jan 2012 08:22:48 -0800 Subject: review request (XS): 7123910 Some CTW tests crash VM: is_loaded() && that->is_loaded() In-Reply-To: <8CB2D3FD-EA8A-414F-9CE2-F5CFAB7D6D32@oracle.com> References: <8CB2D3FD-EA8A-414F-9CE2-F5CFAB7D6D32@oracle.com> Message-ID: <589B8B1A-6784-4289-A118-BFB0DCA449C5@oracle.com> Looks good. tom On Jan 24, 2012, at 12:16 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7123910/webrev.00/ > > Parse::do_checkcast() calls GraphKit::gen_checkcast() and it crashes because the object's klass is not loaded. It is not caught by the checks in Parse::do_checkcast() because obj is a pointer to an array. This extends those checks so that an uncommon trap is inserted not only for an oop but also for an arrayOop. > > Roland. From roland.westrelin at oracle.com Wed Jan 25 08:34:33 2012 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Wed, 25 Jan 2012 16:34:33 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7116050: C2/ARM: memory stomping error with DivideMcTests Message-ID: <20120125163435.7836147195@hg.openjdk.java.net> Changeset: cf407b7d3d78 Author: roland Date: 2012-01-25 09:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cf407b7d3d78 7116050: C2/ARM: memory stomping error with DivideMcTests Summary: Block::schedule_local() may write beyond end of ready_cnt array Reviewed-by: never, kvn ! src/share/vm/opto/block.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp From bertrand.delsart at oracle.com Wed Jan 25 08:42:26 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 25 Jan 2012 17:42:26 +0100 Subject: Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle Message-ID: <4F2030F2.1060606@oracle.com> Hi all, Here is the third (and last) frame::describe related CR I wanted to putback: http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/ Goal of that RFE was to use the frame::describe debugging output to enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. The change in fact fixes a few minor bugs in the current version of trace_method_handle. Main changes are: - make frame::describe available in all non-product builds (else we could no longer build in "optimized" mode) - improvements of trace_method_handle for SPARC * protect FP result register, which was corrupted by traces * protect all globals (G6 corruption caused an issue) * walk up to the right frame to dump * safely build a frame on which to call describe (see below) - improvements of trace_method_handle for x86 * properly pass r13 (and not rsi) as the saved_sp on LP64 * protect FP result register, which was corrupted by traces * build a real frame in the stub wrapper to allow stack walking * walk up to the right frame to dump * safely build a frame on which to call describe (see below) Note on the "safely build a frame": trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames. If you are curious, I attached an example (an amd64) that shows a ricocher sequence, including both walkable and non walkable frames. Regards, Bertrand -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: TRACE_EXAMPLE Url: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120125/fa4cabac/TRACE_EXAMPLE.ksh From jiangli.zhou at oracle.com Wed Jan 25 09:19:41 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2012 09:19:41 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F7D44.6000502@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1F7D44.6000502@oracle.com> Message-ID: <4F2039AD.2030600@oracle.com> Hi Dean, I was looking for existing code for hotspot conventions. My quick search didn't reveal any. Thanks for the pointer. Thanks, Jiangli Dean Long wrote: > I agree with Vitaly. You can find existing examples in the code: > > interpreter/rewriter.cpp: assert(cache_index == > (u1)cache_index, "index overflow"); > > You could also assert that reference_type == t after the assignment. > > dl > > On 1/24/2012 7:19 PM, Jiangli Zhou wrote: >> Hi Vitaly, >> >> Thanks for catching it! A range check seems to be more explicit in >> this case: >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >> >> Thanks, >> >> Jiangli >> >> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>> >>> I think you'll be fully covered (including negative values) by doing >>> the following instead of hard coding max value in the assert: >>> >>> assert(t == (u1)t, "doesn't fit") >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >> > wrote: >>> >>> The updated webrev is : >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>> >>> >>> Thanks, >>> Jiangli >>> >>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>> Hi Vitaly, >>>> >>>> An assert in the setter probably is a good idea. I should have >>>> added it when making the change. Thanks for the comments! >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>> >>>>> Hi Jiangli, >>>>> >>>>> This is probably overly paranoid so feel free to ignore, but >>>>> should the setter in InstanceKlass assert that the passed in >>>>> ReferenceType fits into a u1 instead of silently narrowing it? >>>>> Or change the setter to take a u1 and make caller do the cast? >>>>> This would prevent someone defining another member of the enum >>>>> with an explicit value that doesn't fit into u1. Like I said, >>>>> paranoia ... :) >>>>> >>>>> Thanks >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the change for 7132690: >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>> >>>>> >>>>> It changes InstanceKlass::_reference_type from >>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>> enum with 6 values >>>>> (src/share/vm/utilities/globalDefinitions.hpp). The change >>>>> saves 4-byte for each class. >>>>> >>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>> >>>>> Thanks, >>>>> >>>>> Jiangli >>>>> >>>> >>> >> From jiangli.zhou at oracle.com Wed Jan 25 10:32:10 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2012 10:32:10 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1FB2FB.5060208@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> Message-ID: <4F204AAA.2070003@oracle.com> Hi Vitaly and David, I've updated the webrev to do a == check via the cast. http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ Thanks, Jiangli On 01/24/2012 11:44 PM, David Holmes wrote: > On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >> Hi Jiangli, >> >> I think doing the comparison via the cast and == check to make sure it >> "roundtrips" is better than explicit range check because this way you >> don't have to change the assert if you change the width of the type >> (e.g. using u2 instead of u1 would require updating the range). Plus as >> Dean mentioned, it looks like the cast version is already used in the >> codebase. > > Plus the range check assumes that the enum will never have negative > values (not likely here but why preclude it). > > David > >> Cheers >> >> Sent from my phone >> >> On Jan 24, 2012 10:19 PM, "Jiangli Zhou" > > wrote: >> >> __ >> Hi Vitaly, >> >> Thanks for catching it! A range check seems to be more explicit in >> this case: >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >> >> Thanks, >> >> Jiangli >> >> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>> >>> I think you'll be fully covered (including negative values) by >>> doing the following instead of hard coding max value in the assert: >>> >>> assert(t == (u1)t, "doesn't fit") >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >> > wrote: >>> >>> The updated webrev is : >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>> >>> >>> Thanks, >>> Jiangli >>> >>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>> Hi Vitaly, >>>> >>>> An assert in the setter probably is a good idea. I should >>>> have added it when making the change. Thanks for the comments! >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>> >>>>> Hi Jiangli, >>>>> >>>>> This is probably overly paranoid so feel free to ignore, but >>>>> should the setter in InstanceKlass assert that the passed in >>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>> it? Or change the setter to take a u1 and make caller do the >>>>> cast? This would prevent someone defining another member of >>>>> the enum with an explicit value that doesn't fit into u1. >>>>> Like I said, paranoia ... :) >>>>> >>>>> Thanks >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>> > >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the change for 7132690: >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>> >>>>> >>>>> It changes InstanceKlass::_reference_type from >>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>> enum with 6 values >>>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>>> change saves 4-byte for each class. >>>>> >>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>> >>>>> Thanks, >>>>> >>>>> Jiangli >>>>> >>>> >>> >> From vitalyd at gmail.com Wed Jan 25 10:34:26 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 25 Jan 2012 13:34:26 -0500 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F204AAA.2070003@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> Message-ID: looks good although I'm not a reviewer :) Vitaly Sent from my phone On Jan 25, 2012 1:33 PM, "Jiangli Zhou" wrote: > Hi Vitaly and David, > > I've updated the webrev to do a == check via the cast. > > http://cr.openjdk.java.net/~**jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 11:44 PM, David Holmes wrote: > >> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >> >>> Hi Jiangli, >>> >>> I think doing the comparison via the cast and == check to make sure it >>> "roundtrips" is better than explicit range check because this way you >>> don't have to change the assert if you change the width of the type >>> (e.g. using u2 instead of u1 would require updating the range). Plus as >>> Dean mentioned, it looks like the cast version is already used in the >>> codebase. >>> >> >> Plus the range check assumes that the enum will never have negative >> values (not likely here but why preclude it). >> >> David >> >> Cheers >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 10:19 PM, "Jiangli Zhou" >> >> wrote: >>> >>> __ >>> Hi Vitaly, >>> >>> Thanks for catching it! A range check seems to be more explicit in >>> this case: >>> >>> http://cr.openjdk.java.net/~**jiangli/7132690/webrev.02/ >>> >>> Thanks, >>> >>> Jiangli >>> >>> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>> >>>> >>>> I think you'll be fully covered (including negative values) by >>>> doing the following instead of hard coding max value in the assert: >>>> >>>> assert(t == (u1)t, "doesn't fit") >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >>> >> wrote: >>>> >>>> The updated webrev is : >>>> http://cr.openjdk.java.net/~**jiangli/7132690/webrev.01/ >>>> >>>> > >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>> >>>>> Hi Vitaly, >>>>> >>>>> An assert in the setter probably is a good idea. I should >>>>> have added it when making the change. Thanks for the comments! >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>> >>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> This is probably overly paranoid so feel free to ignore, but >>>>>> should the setter in InstanceKlass assert that the passed in >>>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>>> it? Or change the setter to take a u1 and make caller do the >>>>>> cast? This would prevent someone defining another member of >>>>>> the enum with an explicit value that doesn't fit into u1. >>>>>> Like I said, paranoia ... :) >>>>>> >>>>>> Thanks >>>>>> >>>>>> Sent from my phone >>>>>> >>>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>>> >>>>>> >> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the change for 7132690: >>>>>> >>>>>> http://cr.openjdk.java.net/~**jiangli/7132690/webrev.00/ >>>>>> >>>>>> > >>>>>> >>>>>> It changes InstanceKlass::_reference_type from >>>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>>> enum with 6 values >>>>>> (src/share/vm/utilities/**globalDefinitions.hpp). The >>>>>> change saves 4-byte for each class. >>>>>> >>>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> >>>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120125/25f7ebd8/attachment.html From jiangli.zhou at oracle.com Wed Jan 25 10:36:33 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2012 10:36:33 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> Message-ID: <4F204BB1.8070504@oracle.com> Thanks for the review in any case! :) Jiangli On 01/25/2012 10:34 AM, Vitaly Davidovich wrote: > > looks good although I'm not a reviewer :) > > Vitaly > > Sent from my phone > > On Jan 25, 2012 1:33 PM, "Jiangli Zhou" > wrote: > > Hi Vitaly and David, > > I've updated the webrev to do a == check via the cast. > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > > Thanks, > > Jiangli > > On 01/24/2012 11:44 PM, David Holmes wrote: > > On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: > > Hi Jiangli, > > I think doing the comparison via the cast and == check to > make sure it > "roundtrips" is better than explicit range check because > this way you > don't have to change the assert if you change the width of > the type > (e.g. using u2 instead of u1 would require updating the > range). Plus as > Dean mentioned, it looks like the cast version is already > used in the > codebase. > > > Plus the range check assumes that the enum will never have > negative values (not likely here but why preclude it). > > David > > Cheers > > Sent from my phone > > On Jan 24, 2012 10:19 PM, "Jiangli Zhou" > > >> wrote: > > __ > Hi Vitaly, > > Thanks for catching it! A range check seems to be more > explicit in > this case: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > > Thanks, > > Jiangli > > On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: > > > I think you'll be fully covered (including negative > values) by > doing the following instead of hard coding max > value in the assert: > > assert(t == (u1)t, "doesn't fit") > > Sent from my phone > > On Jan 24, 2012 6:33 PM, "Jiangli Zhou" > > >> wrote: > > The updated webrev is : > http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ > > > > Thanks, > Jiangli > > On 01/24/2012 02:54 PM, Jiangli Zhou wrote: > > Hi Vitaly, > > An assert in the setter probably is a good > idea. I should > have added it when making the change. > Thanks for the comments! > > Thanks, > Jiangli > > On 01/24/2012 02:13 PM, Vitaly Davidovich > wrote: > > > Hi Jiangli, > > This is probably overly paranoid so > feel free to ignore, but > should the setter in InstanceKlass > assert that the passed in > ReferenceType fits into a u1 instead of > silently narrowing > it? Or change the setter to take a u1 > and make caller do the > cast? This would prevent someone > defining another member of > the enum with an explicit value that > doesn't fit into u1. > Like I said, paranoia ... :) > > Thanks > > Sent from my phone > > On Jan 24, 2012 3:06 PM, "Jiangli Zhou" > > >> > wrote: > > Hi, > > Please review the change for 7132690: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ > > > > It changes > InstanceKlass::_reference_type from > ReferenceType to u1. The > ReferenceType is defined as an > enum with 6 values > > (src/share/vm/utilities/globalDefinitions.hpp). > The > change saves 4-byte for each class. > > Tested with runThese and ute > vm.quick.testlist. Ran jprt. > > Thanks, > > Jiangli > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120125/472ead1a/attachment-0001.html From karen.kinnear at oracle.com Wed Jan 25 10:48:02 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 25 Jan 2012 13:48:02 -0500 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F204AAA.2070003@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> Message-ID: Jiangli, Looks good. thanks, Karen On Jan 25, 2012, at 1:32 PM, Jiangli Zhou wrote: > Hi Vitaly and David, > > I've updated the webrev to do a == check via the cast. > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 11:44 PM, David Holmes wrote: >> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >>> Hi Jiangli, >>> >>> I think doing the comparison via the cast and == check to make sure it >>> "roundtrips" is better than explicit range check because this way you >>> don't have to change the assert if you change the width of the type >>> (e.g. using u2 instead of u1 would require updating the range). Plus as >>> Dean mentioned, it looks like the cast version is already used in the >>> codebase. >> >> Plus the range check assumes that the enum will never have negative values (not likely here but why preclude it). >> >> David >> >>> Cheers >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 10:19 PM, "Jiangli Zhou" >> > wrote: >>> >>> __ >>> Hi Vitaly, >>> >>> Thanks for catching it! A range check seems to be more explicit in >>> this case: >>> >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >>> >>> Thanks, >>> >>> Jiangli >>> >>> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>>> >>>> I think you'll be fully covered (including negative values) by >>>> doing the following instead of hard coding max value in the assert: >>>> >>>> assert(t == (u1)t, "doesn't fit") >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >>> > wrote: >>>> >>>> The updated webrev is : >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>>> >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>>> Hi Vitaly, >>>>> >>>>> An assert in the setter probably is a good idea. I should >>>>> have added it when making the change. Thanks for the comments! >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> This is probably overly paranoid so feel free to ignore, but >>>>>> should the setter in InstanceKlass assert that the passed in >>>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>>> it? Or change the setter to take a u1 and make caller do the >>>>>> cast? This would prevent someone defining another member of >>>>>> the enum with an explicit value that doesn't fit into u1. >>>>>> Like I said, paranoia ... :) >>>>>> >>>>>> Thanks >>>>>> >>>>>> Sent from my phone >>>>>> >>>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the change for 7132690: >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>>> >>>>>> >>>>>> It changes InstanceKlass::_reference_type from >>>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>>> enum with 6 values >>>>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>>>> change saves 4-byte for each class. >>>>>> >>>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> >>>>> >>>> >>> > From jiangli.zhou at oracle.com Wed Jan 25 11:03:43 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2012 11:03:43 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> Message-ID: <4F20520F.5060400@oracle.com> Hi Karen, Thanks for the review. Jiangli On 01/25/2012 10:48 AM, Karen Kinnear wrote: > Jiangli, > > Looks good. > > thanks, > Karen > > On Jan 25, 2012, at 1:32 PM, Jiangli Zhou wrote: > >> Hi Vitaly and David, >> >> I've updated the webrev to do a == check via the cast. >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >> >> Thanks, >> >> Jiangli >> >> On 01/24/2012 11:44 PM, David Holmes wrote: >>> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >>>> Hi Jiangli, >>>> >>>> I think doing the comparison via the cast and == check to make sure it >>>> "roundtrips" is better than explicit range check because this way you >>>> don't have to change the assert if you change the width of the type >>>> (e.g. using u2 instead of u1 would require updating the range). Plus as >>>> Dean mentioned, it looks like the cast version is already used in the >>>> codebase. >>> Plus the range check assumes that the enum will never have negative values (not likely here but why preclude it). >>> >>> David >>> >>>> Cheers >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 10:19 PM, "Jiangli Zhou">>> > wrote: >>>> >>>> __ >>>> Hi Vitaly, >>>> >>>> Thanks for catching it! A range check seems to be more explicit in >>>> this case: >>>> >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>>> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>>>> I think you'll be fully covered (including negative values) by >>>>> doing the following instead of hard coding max value in the assert: >>>>> >>>>> assert(t == (u1)t, "doesn't fit") >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou">>>> > wrote: >>>>> >>>>> The updated webrev is : >>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>>>> >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>>>> Hi Vitaly, >>>>>> >>>>>> An assert in the setter probably is a good idea. I should >>>>>> have added it when making the change. Thanks for the comments! >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> This is probably overly paranoid so feel free to ignore, but >>>>>>> should the setter in InstanceKlass assert that the passed in >>>>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>>>> it? Or change the setter to take a u1 and make caller do the >>>>>>> cast? This would prevent someone defining another member of >>>>>>> the enum with an explicit value that doesn't fit into u1. >>>>>>> Like I said, paranoia ... :) >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Sent from my phone >>>>>>> >>>>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Please review the change for 7132690: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>>>> >>>>>>> >>>>>>> It changes InstanceKlass::_reference_type from >>>>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>>>> enum with 6 values >>>>>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>>>>> change saves 4-byte for each class. >>>>>>> >>>>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jiangli >>>>>>> From tom.rodriguez at oracle.com Wed Jan 25 11:36:24 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 25 Jan 2012 11:36:24 -0800 Subject: Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle In-Reply-To: <4F2030F2.1060606@oracle.com> References: <4F2030F2.1060606@oracle.com> Message-ID: <76FD9630-6354-428F-A105-3DE88B28CC0F@oracle.com> Looks good. tom On Jan 25, 2012, at 8:42 AM, Bertrand Delsart wrote: > Hi all, > > Here is the third (and last) frame::describe related CR I wanted to putback: > > http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/ > > Goal of that RFE was to use the frame::describe debugging output to > enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. > > The change in fact fixes a few minor bugs in the current version of trace_method_handle. > > Main changes are: > - make frame::describe available in all non-product builds > (else we could no longer build in "optimized" mode) > - improvements of trace_method_handle for SPARC > * protect FP result register, which was corrupted by traces > * protect all globals (G6 corruption caused an issue) > * walk up to the right frame to dump > * safely build a frame on which to call describe (see below) > - improvements of trace_method_handle for x86 > * properly pass r13 (and not rsi) as the saved_sp on LP64 > * protect FP result register, which was corrupted by traces > * build a real frame in the stub wrapper to allow stack walking > * walk up to the right frame to dump > * safely build a frame on which to call describe (see below) > > Note on the "safely build a frame": > > trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. > > The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames. > > If you are curious, I attached an example (an amd64) that shows a ricocher sequence, including both walkable and non walkable frames. > > Regards, > > Bertrand > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE > From vladimir.kozlov at oracle.com Wed Jan 25 14:05:12 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 25 Jan 2012 22:05:12 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20120125220516.67141471A3@hg.openjdk.java.net> Changeset: 52474ec73861 Author: kvn Date: 2012-01-24 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/52474ec73861 7132936: guarantee(t != NULL) failed: must be con Summary: Use !higher_equal() check to skip top and values which fit. Reviewed-by: never ! src/share/vm/opto/memnode.cpp Changeset: 94f0ce74d48e Author: kvn Date: 2012-01-25 08:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/94f0ce74d48e Merge From david.holmes at oracle.com Wed Jan 25 17:09:44 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Jan 2012 11:09:44 +1000 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F204AAA.2070003@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> Message-ID: <4F20A7D8.9030702@oracle.com> Looks good to me. David On 26/01/2012 4:32 AM, Jiangli Zhou wrote: > Hi Vitaly and David, > > I've updated the webrev to do a == check via the cast. > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 11:44 PM, David Holmes wrote: >> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >>> Hi Jiangli, >>> >>> I think doing the comparison via the cast and == check to make sure it >>> "roundtrips" is better than explicit range check because this way you >>> don't have to change the assert if you change the width of the type >>> (e.g. using u2 instead of u1 would require updating the range). Plus as >>> Dean mentioned, it looks like the cast version is already used in the >>> codebase. >> >> Plus the range check assumes that the enum will never have negative >> values (not likely here but why preclude it). >> >> David >> >>> Cheers >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 10:19 PM, "Jiangli Zhou" >> > wrote: >>> >>> __ >>> Hi Vitaly, >>> >>> Thanks for catching it! A range check seems to be more explicit in >>> this case: >>> >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >>> >>> Thanks, >>> >>> Jiangli >>> >>> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>>> >>>> I think you'll be fully covered (including negative values) by >>>> doing the following instead of hard coding max value in the assert: >>>> >>>> assert(t == (u1)t, "doesn't fit") >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >>> > wrote: >>>> >>>> The updated webrev is : >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>>> >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>>> Hi Vitaly, >>>>> >>>>> An assert in the setter probably is a good idea. I should >>>>> have added it when making the change. Thanks for the comments! >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> This is probably overly paranoid so feel free to ignore, but >>>>>> should the setter in InstanceKlass assert that the passed in >>>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>>> it? Or change the setter to take a u1 and make caller do the >>>>>> cast? This would prevent someone defining another member of >>>>>> the enum with an explicit value that doesn't fit into u1. >>>>>> Like I said, paranoia ... :) >>>>>> >>>>>> Thanks >>>>>> >>>>>> Sent from my phone >>>>>> >>>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the change for 7132690: >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>>> >>>>>> >>>>>> It changes InstanceKlass::_reference_type from >>>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>>> enum with 6 values >>>>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>>>> change saves 4-byte for each class. >>>>>> >>>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> >>>>> >>>> >>> > From jiangli.zhou at oracle.com Wed Jan 25 17:18:02 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2012 17:18:02 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F20A7D8.9030702@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> <4F20A7D8.9030702@oracle.com> Message-ID: <4F20A9CA.3050207@oracle.com> Thanks, David. Jiangli On 01/25/2012 05:09 PM, David Holmes wrote: > Looks good to me. > > David > > On 26/01/2012 4:32 AM, Jiangli Zhou wrote: >> Hi Vitaly and David, >> >> I've updated the webrev to do a == check via the cast. >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >> >> Thanks, >> >> Jiangli >> >> On 01/24/2012 11:44 PM, David Holmes wrote: >>> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >>>> Hi Jiangli, >>>> >>>> I think doing the comparison via the cast and == check to make sure it >>>> "roundtrips" is better than explicit range check because this way you >>>> don't have to change the assert if you change the width of the type >>>> (e.g. using u2 instead of u1 would require updating the range). >>>> Plus as >>>> Dean mentioned, it looks like the cast version is already used in the >>>> codebase. >>> >>> Plus the range check assumes that the enum will never have negative >>> values (not likely here but why preclude it). >>> >>> David >>> >>>> Cheers >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 10:19 PM, "Jiangli Zhou" >>> > wrote: >>>> >>>> __ >>>> Hi Vitaly, >>>> >>>> Thanks for catching it! A range check seems to be more explicit in >>>> this case: >>>> >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>>> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>>>> >>>>> I think you'll be fully covered (including negative values) by >>>>> doing the following instead of hard coding max value in the assert: >>>>> >>>>> assert(t == (u1)t, "doesn't fit") >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >>>> > wrote: >>>>> >>>>> The updated webrev is : >>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>>>> >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>>>> Hi Vitaly, >>>>>> >>>>>> An assert in the setter probably is a good idea. I should >>>>>> have added it when making the change. Thanks for the comments! >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>>>> >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> This is probably overly paranoid so feel free to ignore, but >>>>>>> should the setter in InstanceKlass assert that the passed in >>>>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>>>> it? Or change the setter to take a u1 and make caller do the >>>>>>> cast? This would prevent someone defining another member of >>>>>>> the enum with an explicit value that doesn't fit into u1. >>>>>>> Like I said, paranoia ... :) >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Sent from my phone >>>>>>> >>>>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Please review the change for 7132690: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>>>> >>>>>>> >>>>>>> It changes InstanceKlass::_reference_type from >>>>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>>>> enum with 6 values >>>>>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>>>>> change saves 4-byte for each class. >>>>>>> >>>>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jiangli >>>>>>> >>>>>> >>>>> >>>> >> From igor.veresov at oracle.com Wed Jan 25 19:03:07 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 25 Jan 2012 19:03:07 -0800 Subject: review(S): 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS Message-ID: <36AF49669ACA40F1B4B56AB1EBC29035@oracle.com> Make sure that CompilationPolicy::event() doesn't throw exceptions. Webrev: http://cr.openjdk.java.net/~iveresov/7131259/webrev.01/ igor From vladimir.kozlov at oracle.com Wed Jan 25 19:17:55 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 Jan 2012 19:17:55 -0800 Subject: review(S): 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS In-Reply-To: <36AF49669ACA40F1B4B56AB1EBC29035@oracle.com> References: <36AF49669ACA40F1B4B56AB1EBC29035@oracle.com> Message-ID: <4F20C5E3.6060405@oracle.com> Looks good. Vladimir On 1/25/12 7:03 PM, Igor Veresov wrote: > Make sure that CompilationPolicy::event() doesn't throw exceptions. > > Webrev: http://cr.openjdk.java.net/~iveresov/7131259/webrev.01/ > > igor > > From tom.rodriguez at oracle.com Wed Jan 25 19:56:26 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 25 Jan 2012 19:56:26 -0800 Subject: review(S): 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS In-Reply-To: <36AF49669ACA40F1B4B56AB1EBC29035@oracle.com> References: <36AF49669ACA40F1B4B56AB1EBC29035@oracle.com> Message-ID: <18315D07-B872-4296-8C71-E0471ABE5B6F@oracle.com> On Jan 25, 2012, at 7:03 PM, Igor Veresov wrote: > Make sure that CompilationPolicy::event() doesn't throw exceptions. > > Webrev: http://cr.openjdk.java.net/~iveresov/7131259/webrev.01/ In several places the code assumes and checks that the Thread is actually a JavaThread. Could it be changed to be JavaThread all the way through so the checks and casts can be removed? Otherwise it looks good. tom > > igor > > From igor.veresov at oracle.com Wed Jan 25 23:34:04 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 25 Jan 2012 23:34:04 -0800 Subject: review(S): 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS In-Reply-To: <18315D07-B872-4296-8C71-E0471ABE5B6F@oracle.com> References: <36AF49669ACA40F1B4B56AB1EBC29035@oracle.com> <18315D07-B872-4296-8C71-E0471ABE5B6F@oracle.com> Message-ID: <8B4363276BCB40FA885AAC3246C6BCDA@oracle.com> On Wednesday, January 25, 2012 at 7:56 PM, Tom Rodriguez wrote: > > On Jan 25, 2012, at 7:03 PM, Igor Veresov wrote: > > > Make sure that CompilationPolicy::event() doesn't throw exceptions. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7131259/webrev.01/ > > In several places the code assumes and checks that the Thread is actually a JavaThread. Could it be changed to be JavaThread all the way through so the checks and casts can be removed? Otherwise it looks good. > Good point. Done: http://cr.openjdk.java.net/~iveresov/7131259/webrev.02/ igor From roland.westrelin at oracle.com Thu Jan 26 00:35:48 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 26 Jan 2012 09:35:48 +0100 Subject: review request (XS): 7123910 Some CTW tests crash VM: is_loaded() && that->is_loaded() In-Reply-To: <589B8B1A-6784-4289-A118-BFB0DCA449C5@oracle.com> References: <8CB2D3FD-EA8A-414F-9CE2-F5CFAB7D6D32@oracle.com> <589B8B1A-6784-4289-A118-BFB0DCA449C5@oracle.com> Message-ID: <97B1BEBA-DA68-405F-AC20-DE8DD281911F@oracle.com> Thanks for the review, Tom & Vladimir. Roland. From bertrand.delsart at oracle.com Thu Jan 26 00:49:52 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Thu, 26 Jan 2012 09:49:52 +0100 Subject: Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle In-Reply-To: <76FD9630-6354-428F-A105-3DE88B28CC0F@oracle.com> References: <4F2030F2.1060606@oracle.com> <76FD9630-6354-428F-A105-3DE88B28CC0F@oracle.com> Message-ID: <4F2113B0.8080809@oracle.com> Thanks Tom, Bertrand. On 01/25/12 08:36 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jan 25, 2012, at 8:42 AM, Bertrand Delsart wrote: > >> Hi all, >> >> Here is the third (and last) frame::describe related CR I wanted to putback: >> >> http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/ >> >> Goal of that RFE was to use the frame::describe debugging output to >> enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. >> >> The change in fact fixes a few minor bugs in the current version of trace_method_handle. >> >> Main changes are: >> - make frame::describe available in all non-product builds >> (else we could no longer build in "optimized" mode) >> - improvements of trace_method_handle for SPARC >> * protect FP result register, which was corrupted by traces >> * protect all globals (G6 corruption caused an issue) >> * walk up to the right frame to dump >> * safely build a frame on which to call describe (see below) >> - improvements of trace_method_handle for x86 >> * properly pass r13 (and not rsi) as the saved_sp on LP64 >> * protect FP result register, which was corrupted by traces >> * build a real frame in the stub wrapper to allow stack walking >> * walk up to the right frame to dump >> * safely build a frame on which to call describe (see below) >> >> Note on the "safely build a frame": >> >> trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. >> >> The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames. >> >> If you are curious, I attached an example (an amd64) that shows a ricocher sequence, including both walkable and non walkable frames. >> >> Regards, >> >> Bertrand >> -- >> Bertrand Delsart, bertrand.delsart at oracle.com, >> Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, >> 38334 Saint Ismier, FRANCE >> > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From roland.westrelin at oracle.com Thu Jan 26 06:20:52 2012 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Thu, 26 Jan 2012 14:20:52 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7123910: Some CTW tests crash VM: is_loaded() && that->is_loaded() Message-ID: <20120126142059.6D182471CD@hg.openjdk.java.net> Changeset: 9a28ddfc1f4a Author: roland Date: 2012-01-26 09:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9a28ddfc1f4a 7123910: Some CTW tests crash VM: is_loaded() && that->is_loaded() Summary: handle not loaded array klass in Parse::do_checkcast(). Reviewed-by: kvn, never ! src/share/vm/opto/parseHelper.cpp From christian.thalinger at oracle.com Thu Jan 26 07:22:07 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 26 Jan 2012 16:22:07 +0100 Subject: Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle In-Reply-To: <4F2030F2.1060606@oracle.com> References: <4F2030F2.1060606@oracle.com> Message-ID: <05E002BE-0DBF-4E81-B9CF-500B29CF48C7@oracle.com> Looks good. Thanks for fixing the tracing! -- Chris On Jan 25, 2012, at 5:42 PM, Bertrand Delsart wrote: > Hi all, > > Here is the third (and last) frame::describe related CR I wanted to putback: > > http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/ > > Goal of that RFE was to use the frame::describe debugging output to > enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. > > The change in fact fixes a few minor bugs in the current version of trace_method_handle. > > Main changes are: > - make frame::describe available in all non-product builds > (else we could no longer build in "optimized" mode) > - improvements of trace_method_handle for SPARC > * protect FP result register, which was corrupted by traces > * protect all globals (G6 corruption caused an issue) > * walk up to the right frame to dump > * safely build a frame on which to call describe (see below) > - improvements of trace_method_handle for x86 > * properly pass r13 (and not rsi) as the saved_sp on LP64 > * protect FP result register, which was corrupted by traces > * build a real frame in the stub wrapper to allow stack walking > * walk up to the right frame to dump > * safely build a frame on which to call describe (see below) > > Note on the "safely build a frame": > > trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. > > The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames. > > If you are curious, I attached an example (an amd64) that shows a ricocher sequence, including both walkable and non walkable frames. > > Regards, > > Bertrand > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE > From bertrand.delsart at oracle.com Thu Jan 26 07:34:46 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Thu, 26 Jan 2012 16:34:46 +0100 Subject: Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle In-Reply-To: <05E002BE-0DBF-4E81-B9CF-500B29CF48C7@oracle.com> References: <4F2030F2.1060606@oracle.com> <05E002BE-0DBF-4E81-B9CF-500B29CF48C7@oracle.com> Message-ID: <4F217296.3000603@oracle.com> Thanks Chris, Bertrand. On 01/26/12 04:22 PM, Christian Thalinger wrote: > Looks good. Thanks for fixing the tracing! -- Chris > > On Jan 25, 2012, at 5:42 PM, Bertrand Delsart wrote: > >> Hi all, >> >> Here is the third (and last) frame::describe related CR I wanted to putback: >> >> http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/ >> >> Goal of that RFE was to use the frame::describe debugging output to >> enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. >> >> The change in fact fixes a few minor bugs in the current version of trace_method_handle. >> >> Main changes are: >> - make frame::describe available in all non-product builds >> (else we could no longer build in "optimized" mode) >> - improvements of trace_method_handle for SPARC >> * protect FP result register, which was corrupted by traces >> * protect all globals (G6 corruption caused an issue) >> * walk up to the right frame to dump >> * safely build a frame on which to call describe (see below) >> - improvements of trace_method_handle for x86 >> * properly pass r13 (and not rsi) as the saved_sp on LP64 >> * protect FP result register, which was corrupted by traces >> * build a real frame in the stub wrapper to allow stack walking >> * walk up to the right frame to dump >> * safely build a frame on which to call describe (see below) >> >> Note on the "safely build a frame": >> >> trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. >> >> The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames. >> >> If you are curious, I attached an example (an amd64) that shows a ricocher sequence, including both walkable and non walkable frames. >> >> Regards, >> >> Bertrand >> -- >> Bertrand Delsart, bertrand.delsart at oracle.com, >> Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, >> 38334 Saint Ismier, FRANCE >> > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From tom.rodriguez at oracle.com Thu Jan 26 10:07:17 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 26 Jan 2012 10:07:17 -0800 Subject: review(S): 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS In-Reply-To: <8B4363276BCB40FA885AAC3246C6BCDA@oracle.com> References: <36AF49669ACA40F1B4B56AB1EBC29035@oracle.com> <18315D07-B872-4296-8C71-E0471ABE5B6F@oracle.com> <8B4363276BCB40FA885AAC3246C6BCDA@oracle.com> Message-ID: Looks good. tom On Jan 25, 2012, at 11:34 PM, Igor Veresov wrote: > On Wednesday, January 25, 2012 at 7:56 PM, Tom Rodriguez wrote: >> >> On Jan 25, 2012, at 7:03 PM, Igor Veresov wrote: >> >>> Make sure that CompilationPolicy::event() doesn't throw exceptions. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/7131259/webrev.01/ >> >> In several places the code assumes and checks that the Thread is actually a JavaThread. Could it be changed to be JavaThread all the way through so the checks and casts can be removed? Otherwise it looks good. >> > Good point. Done: http://cr.openjdk.java.net/~iveresov/7131259/webrev.02/ > > igor > > From igor.veresov at oracle.com Thu Jan 26 10:28:03 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 26 Jan 2012 10:28:03 -0800 Subject: review(S): 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS In-Reply-To: References: <36AF49669ACA40F1B4B56AB1EBC29035@oracle.com> <18315D07-B872-4296-8C71-E0471ABE5B6F@oracle.com> <8B4363276BCB40FA885AAC3246C6BCDA@oracle.com> Message-ID: <00F620BEED684576AA7567AB69A31B96@oracle.com> Thank you Tom and Vladimir! igor On Thursday, January 26, 2012 at 10:07 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jan 25, 2012, at 11:34 PM, Igor Veresov wrote: > > > On Wednesday, January 25, 2012 at 7:56 PM, Tom Rodriguez wrote: > > > > > > On Jan 25, 2012, at 7:03 PM, Igor Veresov wrote: > > > > > > > Make sure that CompilationPolicy::event() doesn't throw exceptions. > > > > > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7131259/webrev.01/ > > > > > > In several places the code assumes and checks that the Thread is actually a JavaThread. Could it be changed to be JavaThread all the way through so the checks and casts can be removed? Otherwise it looks good. > > Good point. Done: http://cr.openjdk.java.net/~iveresov/7131259/webrev.02/ > > > > igor From bertrand.delsart at oracle.com Thu Jan 26 11:00:41 2012 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Thu, 26 Jan 2012 19:00:41 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle Message-ID: <20120126190043.C51B0471DB@hg.openjdk.java.net> Changeset: 5dbed2f542ff Author: bdelsart Date: 2012-01-26 16:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5dbed2f542ff 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle Summary: improvements of TraceMethodHandles for JSR292 Reviewed-by: never, twisti ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp From igor.veresov at oracle.com Thu Jan 26 14:47:06 2012 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 26 Jan 2012 22:47:06 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS Message-ID: <20120126224709.11011471E3@hg.openjdk.java.net> Changeset: 20334ed5ed3c Author: iveresov Date: 2012-01-26 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/20334ed5ed3c 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS Summary: Make sure that CompilationPolicy::event() doesn't throw exceptions Reviewed-by: kvn, never ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! src/share/vm/utilities/exceptions.hpp From john.coomes at oracle.com Thu Jan 26 20:37:25 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:37:25 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b23 for changeset 5218eb256658 Message-ID: <20120127043727.E3F5147205@hg.openjdk.java.net> Changeset: b98f0e6dddf9 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/b98f0e6dddf9 Added tag jdk8-b23 for changeset 5218eb256658 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:37:36 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:37:36 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b23 for changeset 95102fd33418 Message-ID: <20120127043736.627F547206@hg.openjdk.java.net> Changeset: 7836655e2495 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/7836655e2495 Added tag jdk8-b23 for changeset 95102fd33418 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:37:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:37:43 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b23 for changeset 25ce7a000487 Message-ID: <20120127043743.B315C47207@hg.openjdk.java.net> Changeset: e0d90803439b Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/e0d90803439b Added tag jdk8-b23 for changeset 25ce7a000487 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:38:46 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:38:46 +0000 Subject: hg: hsx/hotspot-comp/jdk: 43 new changesets Message-ID: <20120127044619.A9C1E4720D@hg.openjdk.java.net> Changeset: 44bd765c22f4 Author: prr Date: 2012-01-13 13:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/44bd765c22f4 7127827: JRE8: javaws fails to launch on oracle linux due to XRender Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java Changeset: b566004bcb1a Author: dbuck Date: 2012-01-16 11:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b566004bcb1a 7083621: Add fontconfig file for OEL6 and rename RH/O EL 5 file so that it is picked up for all 5.x updates Reviewed-by: bae, prr ! make/sun/awt/Makefile Changeset: 397667460892 Author: lana Date: 2012-01-18 11:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/397667460892 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: e0f94b9c53a8 Author: alexsch Date: 2012-01-10 15:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e0f94b9c53a8 7110815: closed/javax/swing/JSplitPane/4885629/bug4885629.java unstable on MacOS Reviewed-by: kizune + test/javax/swing/JSplitPane/4885629/bug4885629.java Changeset: 79d14e328670 Author: alexsch Date: 2012-01-10 17:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/79d14e328670 6505523: NullPointerException in BasicTreeUI when a node is removed by expansion listener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/6505523/bug6505523.java Changeset: ce32a4e1be1d Author: alexsch Date: 2012-01-13 12:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ce32a4e1be1d 7121765: closed/javax/swing/JTextArea/4697612/bug4697612.java fails on MacOS on Aqua L&F Reviewed-by: rupashka + test/javax/swing/JTextArea/4697612/bug4697612.java + test/javax/swing/JTextArea/4697612/bug4697612.txt Changeset: 59b8875949e1 Author: malenkov Date: 2012-01-16 18:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/59b8875949e1 7122740: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java Changeset: 3e9d35e6ee4f Author: denis Date: 2012-01-17 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3e9d35e6ee4f 7110590: DnDMerlinQLTestsuite_DnDJTextArea test fails with an java.awt.dnd.InvalidDnDOperationException Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: 89bc9d08fe82 Author: anthony Date: 2012-01-18 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/89bc9d08fe82 7130662: GTK file dialog crashes with a NPE Summary: Guard adding a back slash to the directory name with an if (!= null) check Reviewed-by: anthony, art Contributed-by: Matt ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: fe1278123fbb Author: lana Date: 2012-01-18 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fe1278123fbb Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: 4d8b49a45cff Author: lana Date: 2012-01-18 20:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4d8b49a45cff Merge Changeset: 400cc379adb5 Author: alanb Date: 2012-01-06 15:00 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/400cc379adb5 7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed Reviewed-by: forax, chegar ! src/share/classes/java/nio/file/FileTreeWalker.java Changeset: cdc128128044 Author: valeriep Date: 2012-01-05 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cdc128128044 6414899: P11Digest should support cloning Summary: Enhanced the PKCS11 Digest implementation to support cloning Reviewed-by: vinnie ! make/sun/security/pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h + test/sun/security/pkcs11/MessageDigest/TestCloning.java Changeset: e6ef778c1df4 Author: valeriep Date: 2012-01-06 11:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e6ef778c1df4 Merge Changeset: 6720ae7b1448 Author: valeriep Date: 2012-01-06 16:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6720ae7b1448 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException Summary: Changed to always use full transformation as provider properties. Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/javax/crypto/Cipher/GetMaxAllowed.java Changeset: 2050ff9dfc92 Author: darcy Date: 2012-01-06 18:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2050ff9dfc92 7123649: Remove public modifier from Math.powerOfTwoF. Reviewed-by: smarks, alanb ! src/share/classes/java/lang/Math.java Changeset: 74c92c3e66ad Author: gadams Date: 2012-01-09 19:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/74c92c3e66ad 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space Reviewed-by: alanb ! test/java/io/FileInputStream/LargeFileAvailable.java Changeset: 858038d89fd5 Author: darcy Date: 2012-01-09 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/858038d89fd5 7128441: StrictMath performance improvement note shared with Math Reviewed-by: darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java Changeset: dd69d3695cee Author: darcy Date: 2012-01-09 20:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dd69d3695cee 7128512: Javadoc typo in java.lang.invoke.MethodHandle Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/MethodHandle.java Changeset: d72de8b3fe36 Author: chegar Date: 2012-01-10 10:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d72de8b3fe36 7123415: Some cases of network interface indexes being read incorrectly Reviewed-by: chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/net_util_md.c Changeset: bba276a6aa0d Author: chegar Date: 2012-01-10 12:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bba276a6aa0d 7128584: Typo in sun.misc.VM's private directMemory field comment Reviewed-by: forax, chegar Contributed-by: Krystal Mok ! src/share/classes/sun/misc/VM.java Changeset: 49e64a8fc18f Author: darcy Date: 2012-01-10 17:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/49e64a8fc18f 7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances Reviewed-by: mduigou ! src/share/classes/java/lang/Object.java Changeset: 62dbcbe4c446 Author: darcy Date: 2012-01-10 17:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/62dbcbe4c446 7128931: Bad HTML escaping in java.lang.Throwable javadoc Reviewed-by: mduigou ! src/share/classes/java/lang/Throwable.java Changeset: 31a1fc60a895 Author: chegar Date: 2012-01-11 10:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/31a1fc60a895 7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLConnection/UnmodifiableMaps.java Changeset: 82144054d2d8 Author: alanb Date: 2012-01-11 13:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/82144054d2d8 7068856: (fs) Typo in Files.isSameFile() javadoc 7099208: (fs) Files.newBufferedReader has typo in javadoc Reviewed-by: forax ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java Changeset: 96fe796fd242 Author: ksrini Date: 2012-01-11 08:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/96fe796fd242 7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 Reviewed-by: sherman, mchung, darcy ! src/share/bin/java.c + test/tools/launcher/I18NJarTest.java ! test/tools/launcher/TestHelper.java Changeset: 11e52d5ba64e Author: xuelei Date: 2012-01-12 03:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/11e52d5ba64e 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/Length.java ! src/windows/classes/sun/security/mscapi/Key.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/ShortRSAKey1024.sh + test/sun/security/mscapi/ShortRSAKey512.sh + test/sun/security/mscapi/ShortRSAKey768.sh + test/sun/security/mscapi/ShortRSAKeyWithinTLS.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java Changeset: 38bf1e9b6979 Author: weijun Date: 2012-01-13 09:50 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/38bf1e9b6979 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests Reviewed-by: mullan + test/javax/security/auth/x500/X500Principal/NameFormat.java Changeset: ef3b6736c074 Author: valeriep Date: 2012-01-12 16:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ef3b6736c074 7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API. Reviewed-by: weijun ! make/com/oracle/Makefile + make/com/oracle/net/Makefile + make/com/oracle/nio/Makefile + make/com/oracle/security/ucrypto/FILES_c.gmk + make/com/oracle/security/ucrypto/Makefile + make/com/oracle/security/ucrypto/mapfile-vers + make/com/oracle/util/Makefile ! src/share/lib/security/java.security-solaris ! test/Makefile + test/com/oracle/security/ucrypto/TestAES.java + test/com/oracle/security/ucrypto/TestDigest.java + test/com/oracle/security/ucrypto/TestRSA.java + test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/security/Provider/DefaultPKCS11.java Changeset: a7ad2fcd7291 Author: valeriep Date: 2012-01-12 18:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a7ad2fcd7291 Merge Changeset: 7e593aa6ad41 Author: littlee Date: 2012-01-13 13:20 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7e593aa6ad41 7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/sun/nio/fs/genUnixConstants.c Changeset: e8e08d46cc37 Author: weijun Date: 2012-01-16 10:10 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e8e08d46cc37 7118809: rcache deadlock Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/ReplayCache.java Changeset: d1b0bda3a3c7 Author: alanb Date: 2012-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d1b0bda3a3c7 7130398: ProblemList.txt updates (1/2012) Reviewed-by: chegar ! test/ProblemList.txt Changeset: e8a143213c65 Author: chegar Date: 2012-01-16 18:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e8a143213c65 7129083: CookieManager does not store cookies if url is read before setting cookie manager Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java + test/sun/net/www/http/HttpClient/CookieHttpClientTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java Changeset: 40d699d7f6a1 Author: chegar Date: 2012-01-17 14:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/40d699d7f6a1 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Reviewed-by: alanb ! test/ProblemList.txt - test/java/io/File/BlockIsDirectory.java Changeset: 2f096eb72520 Author: mchung Date: 2012-01-17 15:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2f096eb72520 7117570: Warnings in sun.mangement.* and its subpackages Reviewed-by: mchung, dsamersoff Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/ConnectorAddressLink.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotThread.java ! src/share/classes/sun/management/LazyCompositeData.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java ! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java ! src/share/classes/sun/management/snmp/util/MibLogger.java ! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpTableCache.java Changeset: b14e13237498 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b14e13237498 Merge Changeset: e6614f361127 Author: lana Date: 2012-01-18 20:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e6614f361127 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 227fcf5d0bec Author: lana Date: 2012-01-24 13:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/227fcf5d0bec Merge - test/java/io/File/BlockIsDirectory.java Changeset: 954a1c535730 Author: amurillo Date: 2012-01-25 12:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/954a1c535730 Merge - test/java/io/File/BlockIsDirectory.java Changeset: d3b334e376d3 Author: mr Date: 2012-01-23 12:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d3b334e376d3 7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems Reviewed-by: ohair ! make/javax/sound/jsoundalsa/Makefile Changeset: 54202e0148ec Author: katleman Date: 2012-01-25 13:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/54202e0148ec Merge Changeset: 34029a0c69bb Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/34029a0c69bb Added tag jdk8-b23 for changeset 54202e0148ec ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:37:17 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:37:17 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b23 for changeset 60d6f64a86b1 Message-ID: <20120127043717.A90FD47203@hg.openjdk.java.net> Changeset: 1a5f1d6b98d6 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/1a5f1d6b98d6 Added tag jdk8-b23 for changeset 60d6f64a86b1 ! .hgtags From john.r.rose at oracle.com Fri Jan 27 02:06:05 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 27 Jan 2012 10:06:05 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 5 new changesets Message-ID: <20120127100619.32DC347220@hg.openjdk.java.net> Changeset: 338d438ee229 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/338d438ee229 Added tag jdk8-b22 for changeset 24727fb37561 ! .hgtags Changeset: dcc292399a39 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dcc292399a39 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: e850d8e7ea54 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e850d8e7ea54 Added tag hs23-b11 for changeset dcc292399a39 ! .hgtags Changeset: 5f3fcd591768 Author: amurillo Date: 2012-01-20 17:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5f3fcd591768 7131979: new hotspot build - hs23-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 072384a61312 Author: jrose Date: 2012-01-26 19:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/072384a61312 Merge From tom.rodriguez at oracle.com Fri Jan 27 10:30:54 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 27 Jan 2012 10:30:54 -0800 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale Message-ID: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> http://cr.openjdk.java.net/~never/7129164 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale Summary: Reviewed-by: The machinery for GC_locker which supports GetPrimitiveArrayCritical maintains a count of the number of threads that currently have raw pointers exposed. This is used to allow existing critical sections to drain before creating new ones so that a GC can occur. Currently these counts are updated using atomic all the time, even if a GC isn't being requested. This creates scalability problem when a lot of threads are hammering atomic operations on the jni_lock_count. The count only needs to be valid when checking if a critical section is currently active and when draining the existing sections. The fix is to make the count be computed as part of the safepointing machinery and to only decrement the counters when _needs_gc is true. In debug mode the old count is maintained and validated against the lazily computed count. On a microbenchmark that stresses GetPrimitiveArrayCritical with many threads and relatively short critical section it can more than double the throughput. This also slightly speeds up the normal GetPrimtiveArrayCritical calls. Mostly it's not easily measurable with larger scale programs. Tested with microbenchmark that stresses GetPrimtiveArrayCritical and the crypto benchmarks of specjvm2008 on x86 and sparc. I also ran the java.io regression tests from the JDK. From igor.veresov at oracle.com Fri Jan 27 11:49:07 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 27 Jan 2012 11:49:07 -0800 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale In-Reply-To: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> References: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> Message-ID: <59B07013FD3B4667AD4C062A3DEAF324@oracle.com> gcLocker.cpp: 70 wait_begin = os::javaTimeMillis(); 71 if (PrintJNIGCStalls && PrintGCDetails) { I think the call to javaTimeMillis() can be moved inside the scope of the if since wait_begin is used only for printing. Also, may be wait_begin could be a member of GCLocker ? Otherwise looks good! igor On Friday, January 27, 2012 at 10:30 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7129164 > 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg > > 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale > Summary: > Reviewed-by: > > The machinery for GC_locker which supports GetPrimitiveArrayCritical > maintains a count of the number of threads that currently have raw > pointers exposed. This is used to allow existing critical sections to > drain before creating new ones so that a GC can occur. Currently > these counts are updated using atomic all the time, even if a GC isn't > being requested. This creates scalability problem when a lot of > threads are hammering atomic operations on the jni_lock_count. The > count only needs to be valid when checking if a critical section is > currently active and when draining the existing sections. The fix is > to make the count be computed as part of the safepointing machinery > and to only decrement the counters when _needs_gc is true. In debug > mode the old count is maintained and validated against the lazily > computed count. > > On a microbenchmark that stresses GetPrimitiveArrayCritical with many > threads and relatively short critical section it can more than double > the throughput. This also slightly speeds up the normal > GetPrimtiveArrayCritical calls. Mostly it's not easily measurable > with larger scale programs. > > Tested with microbenchmark that stresses GetPrimtiveArrayCritical and > the crypto benchmarks of specjvm2008 on x86 and sparc. I also ran the > java.io (http://java.io) regression tests from the JDK. From john.coomes at oracle.com Fri Jan 27 12:30:01 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 20:30:01 +0000 Subject: hg: hsx/hotspot-comp/langtools: 8 new changesets Message-ID: <20120127203021.6F8BE4723A@hg.openjdk.java.net> Changeset: 70d92518063e Author: mcimadamore Date: 2012-01-11 18:23 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/70d92518063e 7126754: Generics compilation failure casting List to List Summary: Problems with Types.rewriteQuantifiers not preserving variance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7126754/T7126754.java + test/tools/javac/cast/7126754/T7126754.out Changeset: 133744729455 Author: mcimadamore Date: 2012-01-12 15:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/133744729455 7123100: javac fails with java.lang.StackOverflowError Summary: Inference of under-constrained type-variables creates erroneous recursive wildcard types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/cast/7123100/T7123100a.java + test/tools/javac/cast/7123100/T7123100a.out + test/tools/javac/cast/7123100/T7123100b.java + test/tools/javac/cast/7123100/T7123100b.out + test/tools/javac/cast/7123100/T7123100c.java + test/tools/javac/cast/7123100/T7123100c.out + test/tools/javac/cast/7123100/T7123100d.java + test/tools/javac/cast/7123100/T7123100d.out Changeset: 1e2f4f4fb9f7 Author: jjh Date: 2012-01-17 17:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1e2f4f4fb9f7 7127924: langtools regression tests sometimes fail en-masse on windows Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: f00afa80f1f0 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f00afa80f1f0 Merge Changeset: cf2496340fef Author: darcy Date: 2012-01-18 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/cf2496340fef 7130768: Clarify behavior of Element.getEnclosingElements in subtypes Reviewed-by: mcimadamore, jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java Changeset: 99261fc7d95d Author: jjh Date: 2012-01-18 18:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/99261fc7d95d 7131308: Three regression tests fail due to bad fix for 7127924 Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: 601ffcc6551d Author: lana Date: 2012-01-24 13:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/601ffcc6551d Merge Changeset: 6c9d21ca92c4 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6c9d21ca92c4 Added tag jdk8-b23 for changeset 601ffcc6551d ! .hgtags From tom.rodriguez at oracle.com Sun Jan 29 20:30:23 2012 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Mon, 30 Jan 2012 04:30:23 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale Message-ID: <20120130043029.15EE34726C@hg.openjdk.java.net> Changeset: 1a2723f7ad8e Author: never Date: 2012-01-29 16:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1a2723f7ad8e 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale Reviewed-by: kvn, iveresov, dholmes ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/thread.hpp From christian.thalinger at oracle.com Mon Jan 30 02:29:11 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 30 Jan 2012 11:29:11 +0100 Subject: Request for review (XS): 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle Message-ID: <1085A828-C745-4E56-9F2E-AE7B90DA35C4@oracle.com> http://cr.openjdk.java.net/~twisti/7132180/ 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle Reviewed-by: The logic for detecting the selectAlternative idiom in GraphBuilder::for_method_handle_inline assumes that both inputs of the phi node are constant. This might now be the case. The fix is to check for is_constant on the ObjectType of both inputs. Tested with failing test. src/share/vm/c1/c1_GraphBuilder.cpp From tom.rodriguez at oracle.com Mon Jan 30 08:14:33 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 30 Jan 2012 08:14:33 -0800 Subject: Request for review (XS): 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle In-Reply-To: <1085A828-C745-4E56-9F2E-AE7B90DA35C4@oracle.com> References: <1085A828-C745-4E56-9F2E-AE7B90DA35C4@oracle.com> Message-ID: <8F24ACCC-F591-4558-A3FC-F6603B43C47B@oracle.com> Looks good. tom On Jan 30, 2012, at 2:29 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7132180/ > > 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle > Reviewed-by: > > The logic for detecting the selectAlternative idiom in > GraphBuilder::for_method_handle_inline assumes that both inputs of the > phi node are constant. This might now be the case. > > The fix is to check for is_constant on the ObjectType of both inputs. > > Tested with failing test. > > src/share/vm/c1/c1_GraphBuilder.cpp > From christian.thalinger at oracle.com Mon Jan 30 09:05:18 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 30 Jan 2012 18:05:18 +0100 Subject: Request for review (XS): 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle In-Reply-To: <8F24ACCC-F591-4558-A3FC-F6603B43C47B@oracle.com> References: <1085A828-C745-4E56-9F2E-AE7B90DA35C4@oracle.com> <8F24ACCC-F591-4558-A3FC-F6603B43C47B@oracle.com> Message-ID: Thank you, Tom. -- Chris On Jan 30, 2012, at 5:14 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jan 30, 2012, at 2:29 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7132180/ >> >> 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle >> Reviewed-by: >> >> The logic for detecting the selectAlternative idiom in >> GraphBuilder::for_method_handle_inline assumes that both inputs of the >> phi node are constant. This might now be the case. >> >> The fix is to check for is_constant on the ObjectType of both inputs. >> >> Tested with failing test. >> >> src/share/vm/c1/c1_GraphBuilder.cpp >> > From roland.westrelin at oracle.com Mon Jan 30 09:08:58 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 30 Jan 2012 18:08:58 +0100 Subject: review request (S): 7090976 Eclipse/CDT causes a JVM crash while indexing C++ code Message-ID: http://cr.openjdk.java.net/~roland/7090976/webrev.00/ The crash occurs at a getfield in a callee that is inlined at an invokeinterface. The LoadField node in the callee is replaced by a previous LoadField in the caller by local value numbering but the previous LoadField doesn't load a value of the same type. The inlining at the invokeinterface is done with an extra checkcast because the inlining code optimistically assumes the receiver is of some particular class. The LoadField in the callee uses the receiver which can be erroneous because we are not sure the receiver is of the class that was used to perform the inlining. See the test case for the interface hierarchy needed for this to happen. The extra check on decl_interface prevents unecessary and potentially dangerous inlining. Passing the result of the checkcast as receiver is another way of preventing the problem. It's not required (the check on decl_interface is sufficient) but may help performance by improving type information in the inlinee. Roland. From tom.rodriguez at oracle.com Mon Jan 30 11:28:41 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 30 Jan 2012 11:28:41 -0800 Subject: review request (S): 7090976 Eclipse/CDT causes a JVM crash while indexing C++ code In-Reply-To: References: Message-ID: On Jan 30, 2012, at 9:08 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7090976/webrev.00/ > > The crash occurs at a getfield in a callee that is inlined at an invokeinterface. The LoadField node in the callee is replaced by a previous LoadField in the caller by local value numbering but the previous LoadField doesn't load a value of the same type. The inlining at the invokeinterface is done with an extra checkcast because the inlining code optimistically assumes the receiver is of some particular class. The LoadField in the callee uses the receiver which can be erroneous because we are not sure the receiver is of the class that was used to perform the inlining. See the test case for the interface hierarchy needed for this to happen. The extra check on decl_interface prevents unecessary and potentially dangerous inlining. Passing the result of the checkcast as receiver is another way of preventing the problem. It's not required (the check on decl_interface is sufficient) but may help performance by improving type information in the inline. Because of invokedynamic I think your test for the existence of a receiver is in adequate. I know I suggested passing the receiver all the time before but it might be simpler to only pass the receiver for this specific case. That makes the tests more straightforward I think. Otherwise it looks good. tom > > Roland. From vladimir.kozlov at oracle.com Mon Jan 30 13:10:55 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 Jan 2012 13:10:55 -0800 Subject: Request for reviews (S): 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints Message-ID: <4F27075F.4010601@oracle.com> http://cr.openjdk.java.net/~kvn/7140924/webrev 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints Bytecode Escape Analyzer incorrectly reports that a method returns only new allocation even if it may also return NULL or Constant Pool pointers. It happens because bc analyzer uses empty_map for such constants. Use unknown_obj instead. Verified with failed test. Thanks, Vladimir From vladimir.kozlov at oracle.com Mon Jan 30 13:57:44 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 Jan 2012 13:57:44 -0800 Subject: Request for reviews (S): 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints In-Reply-To: References: <4F27075F.4010601@oracle.com> Message-ID: <4F271258.70309@oracle.com> Thank you, Igor Vladimir Igor Veresov wrote: > Looks good! > > > igor > > On Monday, January 30, 2012 at 1:10 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7140924/webrev >> >> 7140924: SIGSEGV in compiled code for >> sun.awt.X11.XDecoratedPeer.updateMinSizeHints >> >> Bytecode Escape Analyzer incorrectly reports that a method returns >> only new >> allocation even if it may also return NULL or Constant Pool pointers. >> It happens >> because bc analyzer uses empty_map for such constants. Use unknown_obj >> instead. >> >> Verified with failed test. >> >> Thanks, >> Vladimir > From igor.veresov at oracle.com Mon Jan 30 13:57:08 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 30 Jan 2012 13:57:08 -0800 Subject: Request for reviews (S): 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints In-Reply-To: <4F27075F.4010601@oracle.com> References: <4F27075F.4010601@oracle.com> Message-ID: Looks good! igor On Monday, January 30, 2012 at 1:10 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7140924/webrev > > 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints > > Bytecode Escape Analyzer incorrectly reports that a method returns only new > allocation even if it may also return NULL or Constant Pool pointers. It happens > because bc analyzer uses empty_map for such constants. Use unknown_obj instead. > > Verified with failed test. > > Thanks, > Vladimir > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120130/1af2d449/attachment.html From igor.veresov at oracle.com Mon Jan 30 14:38:40 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 30 Jan 2012 14:38:40 -0800 Subject: review(XXS): 7141059: 7116795 broke pure c2 builds Message-ID: <3B04D7CC5EBD471E80A3578C4EC0FD76@oracle.com> 7116795 broke pure c2 builds (on x86 and sparc) because it switches TieredCompilation on by default and this, in turn, will the CompilationPolicyChoice to 3, which would fail if TIERED is not defined. Also, methodHandles.hpp had to be included in frame_{x86,sparc}.cpp in order to building without C1 present. Webrev: http://cr.openjdk.java.net/~iveresov/7141059/webrev.00/ Thanks! igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120130/4b965705/attachment.html From bengt.rutisson at oracle.com Mon Jan 30 14:50:41 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Jan 2012 23:50:41 +0100 Subject: review(XXS): 7141059: 7116795 broke pure c2 builds In-Reply-To: <3B04D7CC5EBD471E80A3578C4EC0FD76@oracle.com> References: <3B04D7CC5EBD471E80A3578C4EC0FD76@oracle.com> Message-ID: <4F271EC1.9040002@oracle.com> Igor, Looks good. Thanks for fixing this so quickly! Bengt On 2012-01-30 23:38, Igor Veresov wrote: > 7116795 broke pure c2 builds (on x86 and sparc) because it switches > TieredCompilation on by default and this, in turn, will the > CompilationPolicyChoice to 3, which would fail if TIERED is not defined. > > Also, methodHandles.hpp had to be included in frame_{x86,sparc}.cpp in > order to building without C1 present. > > Webrev: http://cr.openjdk.java.net/~iveresov/7141059/webrev.00/ > > Thanks! > igor > From tom.rodriguez at oracle.com Mon Jan 30 14:43:49 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 30 Jan 2012 14:43:49 -0800 Subject: Request for reviews (S): 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints In-Reply-To: <4F27075F.4010601@oracle.com> References: <4F27075F.4010601@oracle.com> Message-ID: Looks good. tom On Jan 30, 2012, at 1:10 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7140924/webrev > > 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints > > Bytecode Escape Analyzer incorrectly reports that a method returns only new allocation even if it may also return NULL or Constant Pool pointers. It happens because bc analyzer uses empty_map for such constants. Use unknown_obj instead. > > Verified with failed test. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Mon Jan 30 14:45:03 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 Jan 2012 14:45:03 -0800 Subject: Request for reviews (S): 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints In-Reply-To: References: <4F27075F.4010601@oracle.com> Message-ID: <4F271D6F.1060305@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Jan 30, 2012, at 1:10 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7140924/webrev >> >> 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints >> >> Bytecode Escape Analyzer incorrectly reports that a method returns only new allocation even if it may also return NULL or Constant Pool pointers. It happens because bc analyzer uses empty_map for such constants. Use unknown_obj instead. >> >> Verified with failed test. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Mon Jan 30 14:52:09 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 Jan 2012 14:52:09 -0800 Subject: review(XXS): 7141059: 7116795 broke pure c2 builds In-Reply-To: <3B04D7CC5EBD471E80A3578C4EC0FD76@oracle.com> References: <3B04D7CC5EBD471E80A3578C4EC0FD76@oracle.com> Message-ID: <4F271F19.1050506@oracle.com> What about other platforms? Vladimir Igor Veresov wrote: > 7116795 broke pure c2 builds (on x86 and sparc) because it switches > TieredCompilation on by default and this, in turn, will the > CompilationPolicyChoice to 3, which would fail if TIERED is not defined. > > Also, methodHandles.hpp had to be included in frame_{x86,sparc}.cpp in > order to building without C1 present. > > Webrev: http://cr.openjdk.java.net/~iveresov/7141059/webrev.00/ > > Thanks! > igor > From igor.veresov at oracle.com Mon Jan 30 18:06:37 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 30 Jan 2012 18:06:37 -0800 Subject: review(XXS): 7141059: 7116795 broke pure c2 builds In-Reply-To: <4F271F19.1050506@oracle.com> References: <3B04D7CC5EBD471E80A3578C4EC0FD76@oracle.com> <4F271F19.1050506@oracle.com> Message-ID: <6D70C06816924895A7D0E102CB7994BD@oracle.com> Currently other platforms have tiered off by default. igor On Monday, January 30, 2012 at 2:52 PM, Vladimir Kozlov wrote: > What about other platforms? > > Vladimir > > Igor Veresov wrote: > > 7116795 broke pure c2 builds (on x86 and sparc) because it switches > > TieredCompilation on by default and this, in turn, will the > > CompilationPolicyChoice to 3, which would fail if TIERED is not defined. > > > > Also, methodHandles.hpp had to be included in frame_{x86,sparc}.cpp in > > order to building without C1 present. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7141059/webrev.00/ > > > > Thanks! > > igor > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120130/f8764655/attachment-0001.html From tom.rodriguez at oracle.com Mon Jan 30 18:33:12 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 30 Jan 2012 18:33:12 -0800 Subject: review(XXS): 7141059: 7116795 broke pure c2 builds In-Reply-To: <3B04D7CC5EBD471E80A3578C4EC0FD76@oracle.com> References: <3B04D7CC5EBD471E80A3578C4EC0FD76@oracle.com> Message-ID: <9C30629B-CD4E-4DB6-9EC7-BE52D44BC0B4@oracle.com> Looks good. tom On Jan 30, 2012, at 2:38 PM, Igor Veresov wrote: > 7116795 broke pure c2 builds (on x86 and sparc) because it switches TieredCompilation on by default and this, in turn, will the CompilationPolicyChoice to 3, which would fail if TIERED is not defined. > > Also, methodHandles.hpp had to be included in frame_{x86,sparc}.cpp in order to building without C1 present. > > Webrev: http://cr.openjdk.java.net/~iveresov/7141059/webrev.00/ > > Thanks! > igor > From vladimir.kozlov at oracle.com Mon Jan 30 19:13:21 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 Jan 2012 19:13:21 -0800 Subject: review(XXS): 7141059: 7116795 broke pure c2 builds In-Reply-To: <6D70C06816924895A7D0E102CB7994BD@oracle.com> References: <3B04D7CC5EBD471E80A3578C4EC0FD76@oracle.com> <4F271F19.1050506@oracle.com> <6D70C06816924895A7D0E102CB7994BD@oracle.com> Message-ID: <4F275C51.7030506@oracle.com> OK. Vladimir Igor Veresov wrote: > Currently other platforms have tiered off by default. > > igor > > On Monday, January 30, 2012 at 2:52 PM, Vladimir Kozlov wrote: > >> What about other platforms? >> >> Vladimir >> >> Igor Veresov wrote: >>> 7116795 broke pure c2 builds (on x86 and sparc) because it switches >>> TieredCompilation on by default and this, in turn, will the >>> CompilationPolicyChoice to 3, which would fail if TIERED is not defined. >>> >>> Also, methodHandles.hpp had to be included in frame_{x86,sparc}.cpp in >>> order to building without C1 present. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/7141059/webrev.00/ >>> >>> Thanks! >>> igor > From igor.veresov at oracle.com Mon Jan 30 19:15:08 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 30 Jan 2012 19:15:08 -0800 Subject: review(XXS): 7141059: 7116795 broke pure c2 builds In-Reply-To: <4F275C51.7030506@oracle.com> References: <3B04D7CC5EBD471E80A3578C4EC0FD76@oracle.com> <4F271F19.1050506@oracle.com> <6D70C06816924895A7D0E102CB7994BD@oracle.com> <4F275C51.7030506@oracle.com> Message-ID: <08B86659EB2B41C891726719856E25F6@oracle.com> Thanks Vladimir, Bengt and Tom! igor On Monday, January 30, 2012 at 7:13 PM, Vladimir Kozlov wrote: > OK. > > Vladimir > > Igor Veresov wrote: > > Currently other platforms have tiered off by default. > > > > igor > > > > On Monday, January 30, 2012 at 2:52 PM, Vladimir Kozlov wrote: > > > > > What about other platforms? > > > > > > Vladimir > > > > > > Igor Veresov wrote: > > > > 7116795 broke pure c2 builds (on x86 and sparc) because it switches > > > > TieredCompilation on by default and this, in turn, will the > > > > CompilationPolicyChoice to 3, which would fail if TIERED is not defined. > > > > > > > > Also, methodHandles.hpp had to be included in frame_{x86,sparc}.cpp in > > > > order to building without C1 present. > > > > > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7141059/webrev.00/ > > > > > > > > Thanks! > > > > igor > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120130/b1433f55/attachment.html From igor.veresov at oracle.com Tue Jan 31 00:08:57 2012 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 31 Jan 2012 08:08:57 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7141059: 7116795 broke pure c2 builds Message-ID: <20120131080901.4B200472A4@hg.openjdk.java.net> Changeset: 5f17b16b3219 Author: iveresov Date: 2012-01-30 19:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5f17b16b3219 7141059: 7116795 broke pure c2 builds Summary: Fix pure c2 builds Reviewed-by: kvn, brutisso, never ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/runtime/globals.hpp From roland.westrelin at oracle.com Tue Jan 31 02:03:07 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 31 Jan 2012 11:03:07 +0100 Subject: review request (S): 7090976 Eclipse/CDT causes a JVM crash while indexing C++ code In-Reply-To: References: Message-ID: > Because of invokedynamic I think your test for the existence of a receiver is in adequate. I know I suggested passing the receiver all the time before but it might be simpler to only pass the receiver for this specific case. That makes the tests more straightforward I think. Otherwise it looks good. And the webrev I sent didn't have the assignment to receiver of the checkcast result? Here is a new one: http://cr.openjdk.java.net/~roland/7090976/webrev.01/ Roland. From tom.rodriguez at oracle.com Tue Jan 31 09:19:15 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 31 Jan 2012 09:19:15 -0800 Subject: review request (S): 7090976 Eclipse/CDT causes a JVM crash while indexing C++ code In-Reply-To: References: Message-ID: <6849CC16-31E2-4505-8047-FC9CA2E1C89C@oracle.com> On Jan 31, 2012, at 2:03 AM, Roland Westrelin wrote: >> Because of invokedynamic I think your test for the existence of a receiver is in adequate. I know I suggested passing the receiver all the time before but it might be simpler to only pass the receiver for this specific case. That makes the tests more straightforward I think. Otherwise it looks good. > > And the webrev I sent didn't have the assignment to receiver of the checkcast result? > > Here is a new one: > http://cr.openjdk.java.net/~roland/7090976/webrev.01/ Looks good. tom > > Roland. From vladimir.kozlov at oracle.com Tue Jan 31 09:26:23 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 31 Jan 2012 17:26:23 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints Message-ID: <20120131172628.3F44D472B8@hg.openjdk.java.net> Changeset: 5ed8f599a788 Author: kvn Date: 2012-01-31 07:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5ed8f599a788 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints Summary: Use unknown_obj instead of empty_map for NULL or Constant Pool object constants in bytecode Escape Analyzer. Reviewed-by: iveresov, never ! src/share/vm/ci/bcEscapeAnalyzer.cpp From christian.thalinger at oracle.com Tue Jan 31 12:04:04 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 31 Jan 2012 20:04:04 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle Message-ID: <20120131200409.5BCAA472BB@hg.openjdk.java.net> Changeset: 2f5980b127e3 Author: twisti Date: 2012-01-31 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2f5980b127e3 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp