From Christian.Thalinger at Sun.COM Tue Feb 1 05:37:17 2011 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 01 Feb 2011 13:37:17 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7009309: JSR 292: compiler/6991596/Test6991596.java crashes on fastdebug JDK7/b122 Message-ID: <20110201133720.A562747304@hg.openjdk.java.net> Changeset: 638119ce7cfd Author: twisti Date: 2011-02-01 03:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/638119ce7cfd 7009309: JSR 292: compiler/6991596/Test6991596.java crashes on fastdebug JDK7/b122 Reviewed-by: kvn, never ! agent/src/share/classes/sun/jvm/hotspot/runtime/StubRoutines.java ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interpreter_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.hpp ! src/share/vm/runtime/vmStructs.cpp From Christian.Thalinger at Sun.COM Tue Feb 1 08:00:15 2011 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 01 Feb 2011 16:00:15 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7012339: JSR 292 crash in G1SATBCardTableModRefBS::write_ref_field_pre_work() Message-ID: <20110201160019.7FD254730A@hg.openjdk.java.net> Changeset: fbf3184da15d Author: twisti Date: 2011-02-01 05:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fbf3184da15d 7012339: JSR 292 crash in G1SATBCardTableModRefBS::write_ref_field_pre_work() Reviewed-by: jrose, never ! src/share/vm/oops/cpCacheOop.cpp From vladimir.kozlov at oracle.com Tue Feb 1 11:03:37 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Feb 2011 11:03:37 -0800 Subject: Request for reviews (S): 7014874: Incorrect COOPs modes on solaris-{sparcv9, amd64} with ParallelGC In-Reply-To: <4D42F9D5.6060003@oracle.com> References: <4D41EF1D.502@oracle.com> <4D41F382.8060006@oracle.com> <4D41F67E.9060006@oracle.com> <4D41F8CB.5080107@oracle.com> <4D41FB4C.2040304@oracle.com> <4D42F9D5.6060003@oracle.com> Message-ID: <4D485909.4030807@oracle.com> Serial, CMS and G1 all don't increase heap size. One thing I notice is compressed oops are still OFF by default with G1. Any plans to switch it ON? Thanks, Vladimir Y. Srinivas Ramakrishna wrote: > Hi Vladimir -- > > On 1/27/2011 3:10 PM, Vladimir Kozlov wrote: >> As Igor explained me only Parallel GC requires boundary >> page size alignment due to UseAdaptiveGCBoundary feature. > > Hmm, I do see a lot of "align_size_up()" done on max_size specs > in CollectedHeap::initialize_size_info() and friends, > as well as in GenerationSpec::align(). I didn't follow the > logic through to see if that will or will not affect the > whole heap sizing behaviour wrt the issue > reported in the CR. The bug report states the > anomalous behaviour with ParallelScavenge heaps, > Have you tested G1CollectedHeap and GenCollectedHeap > to see if they do the right thing? > > thanks. > -- ramki > >> >> Vladimir >> >> Y. S. Ramakrishna wrote: >>> May be you need a "partition_aligned()" method that >>> takes an aligned whole and produces aligned partitions >>> thereof given a desired_partitioning request. It would >>> seem as though similar logic would need to apply to >>> other kinds of heaps... or do they do the right thing >>> already? OK, i suppose i should go look, since i am >>> supposed to be reviewing, not interviewing ;-) >>> >>> -- ramki >>> >>> On 01/27/11 14:49, Vladimir Kozlov wrote: >>>> Before rounding YG+OG == total heap size. To keep the same >>>> total size I need to round one size up and the other down. >>>> I still may not preserver the same total size if it is not >>>> rounded to the same or large alignment. But it is fine. >>>> >>>> I already fixed PG rounding before in 6984368 changes: >>>> >>>> src/share/vm/memory/collectorPolicy.cpp Tue Sep 14 17:19:35 2010 -0700 >>>> @@ -32,7 +32,11 @@ >>>> MaxPermSize = PermSize; >>>> } >>>> PermSize = MAX2(min_alignment(), align_size_down_(PermSize, >>>> min_alignment())); >>>> - MaxPermSize = align_size_up(MaxPermSize, max_alignment()); >>>> + // Don't increase Perm size limit above specified. >>>> + MaxPermSize = align_size_down(MaxPermSize, max_alignment()); >>>> + if (PermSize > MaxPermSize) { >>>> + PermSize = MaxPermSize; >>>> + } >>>> >>>> Vladimir >>>> >>>> Y. S. Ramakrishna wrote: >>>>> I don't understand the logic of the patch. Or rather, i do, >>>>> but i question if it is complete: why didn't you also align >>>>> the max size of YG and PG down in like manner? I think you >>>>> should or you would be open to the same issues, no? >>>>> >>>>> In fact, it seems as though, as a matter of uniform policy, all min's >>>>> should align upwards and all max's align downwards wherever >>>>> (page-)alignment >>>>> is sought. >>>>> >>>>> -- ramki >>>>> >>>>> >>>>> On 01/27/11 14:18, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7014874/webrev >>>>>> >>>>>> Fixed 7014874: Incorrect COOPs modes on solaris-{sparcv9,amd64} >>>>>> with ParallelGC >>>>>> >>>>>> scale_by_NewRatio_aligned() aligns boundary between old >>>>>> and young gens to min_alignment() (64K). But code in >>>>>> ParallelScavengeHeap::initialize() aligns up both old and >>>>>> young gen sizes to large page size. >>>>>> As result total heap size could be increased by one large >>>>>> page and cross 4gb boundary preventing usage of 32-bit COOPs. >>>>>> >>>>>> Align old gen size down to keep specified heap size but >>>>>> not less than its old gen min size. > From vladimir.kozlov at oracle.com Tue Feb 1 12:33:09 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 01 Feb 2011 20:33:09 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7014998: assert(is_T_family(features) == is_niagara(features)) failed: Niagara should be T series Message-ID: <20110201203311.F3B2C4731D@hg.openjdk.java.net> Changeset: c52cba2a3359 Author: kvn Date: 2011-02-01 10:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c52cba2a3359 7014998: assert(is_T_family(features) == is_niagara(features)) failed: Niagara should be T series Summary: Use substring search instead of compare and convert string to upper case before search. Reviewed-by: never, phh, iveresov ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp From dlila at redhat.com Wed Feb 2 08:16:32 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 2 Feb 2011 11:16:32 -0500 (EST) Subject: SIGSEGV in C2 compiler In-Reply-To: <1884844406.715025.1296662703236.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1594027707.715362.1296663392784.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Tom. I tried to simplify the reproducer for this. I managed to turn it into a 20 line file that I've attached. However it must be run with -XX:CompileOnly=Test.main. -Xbatch and -XX:OnStackReplacePercentage=60 are no longer needed. I printed a bunch of graphs which you can find here: http://icedtea.classpath.org/~dlila/ecjGraph.xml The graphs were generated using the command ~/src/jdk7/build/linux-amd64-debug/bin/java -Xbatch -XX:-DoEscapeAnalysis -XX:-SubsumeLoads -XX:-UseLoopPredicate -XX:-PartialPeelLoop -XX:-PartialPeelAtUnsignedTests -XX:+LoopUnswitching -XX:+VerifyGraphEdges -XX:+VerifyIterativeGVN -XX:+TraceIterativeGVN -XX:+TraceOptoParse -XX:+TraceLoopPredicate -XX:+TracePartialPeeling -XX:+TraceLoopUnswitching -XX:+PrintCompilation -XX:PrintIdealGraphFile=./ecjGraph.xml -XX:PrintIdealGraphLevel=3 -XX:+PrintIdeal -XX:+PrintOpto -XX:+Verbose -XX:CompileOnly=Test.h Test I tried to turn off as many optimizations as possible. With the above command opto/compile.cpp:1673,1689 end up executing (they are PhaseIdealLoop constructors). All the xml files are from the execution of the first PhaseIdealLoop constructor. By its second call the graph seems to already be broken because in in build_loop_late, build_loop_late_post is called on node 296. The control for 296 is determined to be 314. This seems correct, and it is the variable Node *early. LCA however, is computed as 39. 39 dominates 314 so in the while( early != legal ) we end up bubbling legal up to the root, then we call idom(root), and that causes a segfault because the root isn't dominated by anything. Now, there doesn't seem to be anything wrong with the dominator computations. The problem seems to be that in the _igvn.optimize() call at the end of the first PhaseIdealLoop constructor, node 357 is replaced by its parent 296 because 357 is a phi node and one of its two inputs (node 153) becomes dead. So 296's children become 259 and 295. When compute_lca_of_uses is called the control of 296 is found to be 303 (this is correct). Then, in the next iteration, we get the control of 259 which is 227. So we call dom_lca_for_get_late_ctrl(303, 227, 296) which correctly returns 39. Now, if 357 hadn't been replaced by 296, in that second iteration the if( c->is_Phi() ) path would have been executed, so "use" would have been computed to be 357->in(0)->in(j) == 349, instead of 227. Then dom_lca_for_get_late_ctrl(303, 349, 296) would have been called, which would have returned either 333 or 341 (because 333 may be a split ctrl) both of which are dominated by 314, so no crash would result. So, the problem seems to be either that the phi's input is killed or that that input's corresponding control is not dead. This happens in _igvn.optimize, but I can't see any errors there, so I'm thinking the real problem is in the loop iteration_split call that precedes it. I haven't found the exact problem yet, but I'm working on it. Anyway, I hope this helps (or at least makes sense). Regards, Denis. PS: just to clarify, if the program is run with -XX:-LoopUnswitching, there is no crash, which supports my beliefs from above. ----- Original Message ----- > I was able to reproduce your crash from the class files. I filed > 7004570 for it. Running java -d64 -cp pisces.jar -XX:+PrintCompilation > -Xbatch -XX:OnStackReplacePercentage=60 pisces.Test reproduces it > reliably for me on Solaris. I'm looking into it now. > > tom > > On Nov 22, 2010, at 12:36 PM, Denis Lila wrote: > > >> What about the latest hotspot which is hs20-b02? > > > > That also crashes. > > > >> I think we recently fixed a bad graph bug related to EA. You can > >> try > >> -XX:-DoEscapeAnalysis. Actually if it reproduces with hs17 then > >> it's > >> probably not the same EA bug. > > > > Yes, it also crashes with -XX:-DoEscapeAnalysis. > > > >> Can you provide the ecj compiled class files too? > > > > Certainly. > > > > Regards, > > Denis. > > > > ----- "Tom Rodriguez" wrote: > > > >> On Nov 22, 2010, at 11:27 AM, Denis Lila wrote: > >> > >>> I'm sorry, I accidentally sent this without finishing it. > >>> > >>> I meant to say that gdbdump.txt, hotspot.log, and the hs_err_*.log > >>> files were obtained using a fastdebug build of hotspot 19-b06. > >>> > >>> I can reproduce the crash with hotspot 17 too. > >> > >>>> > >>>> I did not submit a bug report at sun.bugs.com because I couldn't > >> find > >>>> a way > >>>> to attach the 4 files. > >> > >> Yes that's kind of lame. You can just include a note in the > >> description that says to contact you directly for the files. > >> Directly > >> including the hs_err as text is a good idea though. > >> > >> tom > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.java Type: text/x-java Size: 464 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110202/7016c6a9/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.class Type: application/x-java Size: 498 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110202/7016c6a9/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: test.javap Type: application/octet-stream Size: 2496 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110202/7016c6a9/attachment.obj From tom.rodriguez at oracle.com Wed Feb 2 18:49:17 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 2 Feb 2011 18:49:17 -0800 Subject: SIGSEGV in C2 compiler In-Reply-To: <1884844406.715025.1296662703236.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1884844406.715025.1296662703236.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: I'm sorry I didn't follow up on this with you, I lost track of it over the Christmas holiday. This appears to be the same issue as 6675699 where a ConvI2L with a constrained type on it has it's input replaced with a constant outside that range. The identity transformation converts that to top which causes a phi collapse and the control flow to be killed. We've kind of band aided this in a few other places but it appears that loop unswitching can create similar issues. In your original program it was caused by unswitching on a test which would never actually fail which creates an alternate that if it were to execute it would throw an exception. In your new example it's this part of the output: Pop 147 ConvI2L === _ 20 [[ 153 ]] Type:long:1..maxint:www !jvms: Test::main @ bci:32 < long:1..maxint:www < 147 ConvI2L === _ _ [[]] [3000147] Node 20 is the constant 0 which is outside the range of 1..maxint. > int:0 20 ConI === 0 [[ 399 104 290 147 369 211 211 188 ]] Type:int:0 I think we're unswitching the (j != 0) test which results in a version where j == 0 when we exit the loop which would result in a exception. In your original program, I think if you converted your switches into explicit tests for the possible values the unswitching wouldn't cause any problems. I think you could also make the default case throw an exception to terminate that path. Either of those should also result in a more useful unswitching of your loop as well. As far as bug 6675699 itself, I'd hoped we stamped out the obvious gotchas since there isn't a really nice fix for it. We can stop the problem from occurring by putting control on the ConvI2L but that interferes with a lot of other optimizations that take advantage of the improved type information and we have to work out a solution to that. Anyway, we'll do something about this for 7 and I'll put your reduced test into the bug report. Thanks for distilling it down. Ping me directly if you'd like help restructuring the loop to avoid the problem. tom On Feb 2, 2011, at 8:05 AM, Denis Lila wrote: > Hi Tom. > > I tried to simplify the reproducer for this. I managed to turn > it into a 20 line file that I've attached. However it must be run > with -XX:CompileOnly=Test.main. -Xbatch and > -XX:OnStackReplacePercentage=60 are no longer needed. > > The graphs were generated using the command > ~/src/jdk7/build/linux-amd64-debug/bin/java -Xbatch -XX:-DoEscapeAnalysis -XX:-SubsumeLoads -XX:-UseLoopPredicate -XX:-PartialPeelLoop -XX:-PartialPeelAtUnsignedTests -XX:+LoopUnswitching -XX:+VerifyGraphEdges -XX:+VerifyIterativeGVN -XX:+TraceIterativeGVN -XX:+TraceOptoParse -XX:+TraceLoopPredicate -XX:+TracePartialPeeling -XX:+TraceLoopUnswitching -XX:+PrintCompilation -XX:PrintIdealGraphFile=./ecjGraph.xml -XX:PrintIdealGraphLevel=3 -XX:+PrintIdeal -XX:+PrintOpto -XX:+Verbose -XX:CompileOnly=Test.h Test > > I tried to turn off as many optimizations as possible. > With the above command opto/compile.cpp:1673,1689 end up > executing (they are PhaseIdealLoop constructors). All the xml files > are from the execution of the first PhaseIdealLoop constructor. By > its second call the graph seems to already be broken because in > in build_loop_late, build_loop_late_post is called on node 296. The > control for 296 is determined to be 314. This seems correct, and it > is the variable Node *early. LCA however, is computed as 39. 39 dominates > 314 so in the while( early != legal ) we end up bubbling legal up to the > root, then we call idom(root), and that causes a segfault because the root > isn't dominated by anything. > > Now, there doesn't seem to be anything wrong with the dominator computations. > The problem seems to be that in the _igvn.optimize() call at the end of the > first PhaseIdealLoop constructor, node 357 is replaced by its parent 296 because > 357 is a phi node and one of its two inputs (node 153) becomes dead. So 296's > children become 259 and 295. When compute_lca_of_uses is called the control of > 296 is found to be 303 (this is correct). Then, in the next iteration, we get > the control of 259 which is 227. So we call dom_lca_for_get_late_ctrl(303, 227, 296) > which correctly returns 39. > Now, if 357 hadn't been replaced by 296, in that second iteration the > if( c->is_Phi() ) path would have been executed, so "use" would have been > computed to be 357->in(0)->in(j) == 349, instead of 227. Then > dom_lca_for_get_late_ctrl(303, 349, 296) would have been called, which would > have returned either 333 or 341 (because 333 may be a split ctrl) both of > which are dominated by 314, so no crash would result. > > So, the problem seems to be either that the phi's input is killed or that that > input's corresponding control is not dead. This happens in _igvn.optimize, but > I can't see any errors there, so I'm thinking the real problem is in the loop > iteration_split call that precedes it. I haven't found the exact problem yet, but > I'm working on it. > > Anyway, I hope this helps (or at least makes sense). > > Regards, > Denis. > > PS: just to clarify, if the program is run with -XX:-LoopUnswitching, there is no > crash, which supports my beliefs from above. > > ----- Original Message ----- >> I was able to reproduce your crash from the class files. I filed >> 7004570 for it. Running java -d64 -cp pisces.jar -XX:+PrintCompilation >> -Xbatch -XX:OnStackReplacePercentage=60 pisces.Test reproduces it >> reliably for me on Solaris. I'm looking into it now. >> >> tom >> >> On Nov 22, 2010, at 12:36 PM, Denis Lila wrote: >> >>>> What about the latest hotspot which is hs20-b02? >>> >>> That also crashes. >>> >>>> I think we recently fixed a bad graph bug related to EA. You can >>>> try >>>> -XX:-DoEscapeAnalysis. Actually if it reproduces with hs17 then >>>> it's >>>> probably not the same EA bug. >>> >>> Yes, it also crashes with -XX:-DoEscapeAnalysis. >>> >>>> Can you provide the ecj compiled class files too? >>> >>> Certainly. >>> >>> Regards, >>> Denis. >>> >>> ----- "Tom Rodriguez" wrote: >>> >>>> On Nov 22, 2010, at 11:27 AM, Denis Lila wrote: >>>> >>>>> I'm sorry, I accidentally sent this without finishing it. >>>>> >>>>> I meant to say that gdbdump.txt, hotspot.log, and the hs_err_*.log >>>>> files were obtained using a fastdebug build of hotspot 19-b06. >>>>> >>>>> I can reproduce the crash with hotspot 17 too. >>>> >>>>>> >>>>>> I did not submit a bug report at sun.bugs.com because I couldn't >>>> find >>>>>> a way >>>>>> to attach the 4 files. >>>> >>>> Yes that's kind of lame. You can just include a note in the >>>> description that says to contact you directly for the files. >>>> Directly >>>> including the hs_err as text is a good idea though. >>>> >>>> tom >>> > From john.coomes at oracle.com Thu Feb 3 20:46:53 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Feb 2011 04:46:53 +0000 Subject: hg: jdk7/hotspot-comp: 11 new changesets Message-ID: <20110204044654.2CA43473DB@hg.openjdk.java.net> Changeset: f722c246ce71 Author: mchung Date: 2011-01-20 22:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/f722c246ce71 7013739: jdk_rmi target is missing in the top repo's test/Makefile Reviewed-by: ohair, igor ! test/Makefile Changeset: 65e6601596e2 Author: lana Date: 2011-01-24 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/65e6601596e2 Merge Changeset: 61f181d43d9a Author: lana Date: 2011-01-28 10:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/61f181d43d9a Merge Changeset: 6db0e6f221bd Author: ohair Date: 2011-01-05 17:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/6db0e6f221bd 7009969: Remove SKIP_OPENJDK_BUILD from top Makefile Reviewed-by: robilad ! Makefile ! make/Defs-internal.gmk Changeset: 49c463695059 Author: ohair Date: 2011-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/49c463695059 Merge Changeset: 6d9bbcc0a8cb Author: ohair Date: 2011-01-13 17:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/6d9bbcc0a8cb Merge Changeset: 24900a58ab9f Author: ohair Date: 2011-01-14 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/24900a58ab9f 6950375: Remove msvcrt.dll from the Windows JRE bundles Reviewed-by: prr ! Makefile ! README-builds.html Changeset: 3a9f19cbf7f1 Author: ohair Date: 2011-01-26 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/3a9f19cbf7f1 Merge Changeset: a7a4f6db294d Author: ohair Date: 2011-01-27 18:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/a7a4f6db294d Merge Changeset: 57d702105b23 Author: ohair Date: 2011-02-02 09:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/57d702105b23 Merge Changeset: 904d7c7c44d9 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/904d7c7c44d9 Added tag jdk7-b128 for changeset 57d702105b23 ! .hgtags From john.coomes at oracle.com Thu Feb 3 20:47:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Feb 2011 04:47:00 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b128 for changeset 9baa8f94a11d Message-ID: <20110204044704.235EB473DC@hg.openjdk.java.net> Changeset: 3ff9acc7cc06 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/3ff9acc7cc06 Added tag jdk7-b128 for changeset 9baa8f94a11d ! .hgtags From john.coomes at oracle.com Thu Feb 3 20:47:10 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Feb 2011 04:47:10 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b128 for changeset a42c6132c746 Message-ID: <20110204044710.EE284473DD@hg.openjdk.java.net> Changeset: f5b60c5a310f Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/f5b60c5a310f Added tag jdk7-b128 for changeset a42c6132c746 ! .hgtags From john.coomes at oracle.com Thu Feb 3 20:47:17 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Feb 2011 04:47:17 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b128 for changeset 88d74afc5593 Message-ID: <20110204044717.D5B3D473DE@hg.openjdk.java.net> Changeset: 0f7b39ad9024 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/0f7b39ad9024 Added tag jdk7-b128 for changeset 88d74afc5593 ! .hgtags From john.coomes at oracle.com Thu Feb 3 20:50:12 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Feb 2011 04:50:12 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 92 new changesets Message-ID: <20110204050616.24AE3473E9@hg.openjdk.java.net> Changeset: 63f5c7704faa Author: prr Date: 2011-01-12 15:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/63f5c7704faa 6958221: java.awt.Font.getFamily() leads to JVM crash on Linux on JDK7 for "custom" fonts Reviewed-by: igor, jgodinez ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11FontManager.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/native/sun/awt/fontpath.c + test/java/awt/FontClass/X11FontPathCrashTest.java Changeset: 5aae8b3162d0 Author: prr Date: 2011-01-13 10:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5aae8b3162d0 7001056: JDK 7 fails on to build on Solaris 10 update 9 - updated Xrender header files Reviewed-by: igor, jgodinez ! make/sun/xawt/Makefile ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 76b8fa7fd229 Author: prr Date: 2011-01-13 12:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/76b8fa7fd229 7012269: mapfile for headless awt needs getFontPathNative defined Reviewed-by: igor ! make/sun/headless/mapfile-vers Changeset: 9f3f38c150b5 Author: prr Date: 2011-01-13 14:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9f3f38c150b5 6917884: NPE in sun.font.FcFontConfiguration.getPlatformFontNames Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FontConfigManager.java Changeset: 987aeabbfda3 Author: prr Date: 2011-01-14 11:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/987aeabbfda3 6951086: Excessive Local References in sun.font.SunLayoutEngine.nativeLayout Reviewed-by: igor, jgodinez ! src/share/native/sun/font/FontInstanceAdapter.cpp Changeset: 646c3cf1ba37 Author: prr Date: 2011-01-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/646c3cf1ba37 6989370: Windows platform fonts may be incorrectly marked as ineligible for the native rasteriser Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunFontManager.java ! src/windows/classes/sun/awt/Win32FontManager.java Changeset: 5cb6bb816a34 Author: prr Date: 2011-01-14 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5cb6bb816a34 6925760: Scaled graphics can cause overlapped LCD mode strings on Windows for pixel size > 48 Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java + test/java/awt/FontClass/LCDScale.java Changeset: 8b33567d68b0 Author: jgodinez Date: 2011-01-14 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8b33567d68b0 6939417: ArrayIndexOutOfBoundsException in Win 7 on selected printers Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java ! test/javax/print/DialogMargins.java Changeset: c2fcb5530ba5 Author: prr Date: 2011-01-14 15:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c2fcb5530ba5 6930980: Disable TrueType hinting for fonts known not to hint well Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0bec5d506120 Author: dlila Date: 2011-01-19 09:44 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0bec5d506120 4724552: CubicCurve2D.contains(Rectangle2D) returns true when only partially contained. Summary: Now using subdivision code in sun.awt.geom.Curve. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java Changeset: c8a10bfd2fcb Author: dlila Date: 2011-01-19 11:31 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c8a10bfd2fcb 4493128: CubicCurve2D intersects method fails Summary: Now using subdivision code in sun.awt.geom.Curve. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java Changeset: 00cc1c09c6dd Author: prr Date: 2011-01-19 09:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/00cc1c09c6dd 6951501: EUDC character is not displayed on Swing Reviewed-by: igor, jgodinez ! src/windows/classes/sun/awt/Win32FontManager.java ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: e58e9e32399a Author: prr Date: 2011-01-19 17:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e58e9e32399a 6983037: closed/java/awt/font/FontNames/Type1Fonts.java failed due to missed font Reviewed-by: igor ! src/share/classes/sun/font/SunFontManager.java ! src/solaris/classes/sun/awt/X11FontManager.java Changeset: fe1b5c15afab Author: prr Date: 2011-01-19 17:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fe1b5c15afab 7013109: windows application manifest problems 6820955: Update application manifests with new Windows 7 dpiAware section Reviewed-by: ohair, art ! make/common/Defs-windows.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! src/windows/resource/java.manifest Changeset: aa1825b1b69d Author: lana Date: 2011-01-19 19:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aa1825b1b69d Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: 0044e8e16a30 Author: prr Date: 2011-01-20 10:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0044e8e16a30 6980204: closed/java/awt/font/LogicalFonts/MappingTest.java fails Reviewed-by: jgodinez ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java Changeset: b1c41e0321a2 Author: prr Date: 2011-01-20 13:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b1c41e0321a2 7013646: remove obsolete fontconfig files for linux and solaris Reviewed-by: igor, jgodinez ! make/sun/awt/Makefile - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: b8f08482aca1 Author: prr Date: 2011-01-21 07:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b8f08482aca1 6892493: potential memory leaks in 2D font code indentified by parfait. Reviewed-by: bae, igor ! src/solaris/native/sun/awt/fontpath.c Changeset: c17e5a95aba7 Author: prr Date: 2011-01-21 08:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c17e5a95aba7 6892138: Windows GDI platform font lookup apis affect start-up for small UI apps Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunFontManager.java ! src/windows/classes/sun/awt/Win32FontManager.java + test/java/awt/font/FontNames/LocaleFamilyNames.java Changeset: ade796b84e71 Author: bae Date: 2011-01-24 15:14 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ade796b84e71 7002766: Java2d: Changes to correct c/c++ language issues for use of parfait Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/image/jpeg/jmorecfg.h ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 63a2e8e00a7b Author: bae Date: 2011-01-24 15:37 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/63a2e8e00a7b 6999620: [parfait] potential buffer overruns in 2d and awt Reviewed-by: jgodinez, prr ! src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 74d020ed7f5b Author: lana Date: 2011-01-24 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/74d020ed7f5b Merge - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties Changeset: 5d4723944cbd Author: dcherepanov Date: 2011-01-20 14:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5d4723944cbd 7011446: ./windows/classes/sun/awt/windows/WToolkit.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: 1bb32dc775c8 Author: dcherepanov Date: 2011-01-20 14:28 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1bb32dc775c8 7011443: ./share/classes/sun/awt/SunToolkit.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: 4cd8718d4548 Author: dcherepanov Date: 2011-01-20 14:29 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4cd8718d4548 7011442: AppletClassLoader.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/share/classes/sun/applet/AppletClassLoader.java Changeset: 4c9a9871830f Author: lana Date: 2011-01-20 10:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4c9a9871830f Merge - test/javax/script/E4XErrorTest.java - test/sun/security/krb5/auto/basic.sh Changeset: f6b73a9b3895 Author: lana Date: 2011-01-24 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f6b73a9b3895 Merge Changeset: 63972a313ca4 Author: rupashka Date: 2011-01-11 12:51 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/63972a313ca4 6589952: Swing: dead links in API documentation Reviewed-by: alexp ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/SizeSequence.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java Changeset: 2a966dd275fc Author: rupashka Date: 2011-01-13 20:12 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2a966dd275fc 6990651: Regression: NPE when refreshing applet since 6u22-b01 Reviewed-by: peterz ! src/share/classes/javax/swing/text/html/parser/ParserDelegator.java + test/javax/swing/JLabel/7004134/bug7004134.java + test/javax/swing/text/html/parser/Parser/6990651/bug6990651.java Changeset: 5787add5b679 Author: rupashka Date: 2011-01-17 19:14 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5787add5b679 6342301: Bad interaction between setting the ui and file filters in JFileChooser Reviewed-by: alexp ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/6342301/bug6342301.java Changeset: ca3bafeffd3b Author: rupashka Date: 2011-01-19 17:01 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ca3bafeffd3b 6246816: SwingSet2 should be rewritten Reviewed-by: peterz ! make/common/Demo.gmk ! make/mkdemo/jfc/Makefile + make/mkdemo/jfc/SwingSet3/Makefile Changeset: e93106dc798b Author: lana Date: 2011-01-19 21:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e93106dc798b Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: b45ea2c3bd6d Author: rupashka Date: 2011-01-24 18:04 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b45ea2c3bd6d 6735293: javax.swing.text.NavigationFilter.getNextVisualPositionFrom() not always throws BadLocationException Reviewed-by: peterz ! src/share/classes/javax/swing/text/View.java + test/javax/swing/text/NavigationFilter/6735293/bug6735293.java Changeset: 1f3ecbfa0c29 Author: lana Date: 2011-01-24 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1f3ecbfa0c29 Merge Changeset: b8663921f5d7 Author: chegar Date: 2011-01-07 13:08 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b8663921f5d7 7000511: PrintStream, PrintWriter, Formatter, Scanner leave files open when exception thrown Reviewed-by: alanb, mduigou ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Scanner.java ! test/ProblemList.txt + test/java/io/PrintStream/FailingConstructors.java + test/java/io/PrintWriter/FailingConstructors.java ! test/java/util/Formatter/Constructors.java + test/java/util/Formatter/FailingConstructors.java + test/java/util/Scanner/FailingConstructors.java Changeset: 5124c2a50539 Author: alanb Date: 2011-01-07 15:49 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5124c2a50539 6993732: Remove the HPI Reviewed-by: ohair, lancea, chegar, mduigou, mchung, mr ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Modules.gmk ! make/common/Release.gmk ! make/java/Makefile ! make/java/fdlibm/Makefile - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile ! make/tools/reorder/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c Changeset: ddaffd64796c Author: alanb Date: 2011-01-07 15:51 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ddaffd64796c Merge Changeset: 6bf1c5958c22 Author: chegar Date: 2011-01-07 21:02 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6bf1c5958c22 7009760: Possible stack corruption in Java_java_net_TwoStacksPlainSocketImpl_socketGetOption Summary: SOCKET_ADDRESS -> SOCKETADDRESS Reviewed-by: alanb ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c Changeset: 3dbc783a8073 Author: smarks Date: 2011-01-07 15:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3dbc783a8073 7008728: diamond conversion of basic security, permissions, authentication Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/UnresolvedPermissionCollection.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/sun/security/acl/AclEntryImpl.java ! src/share/classes/sun/security/acl/AclImpl.java ! src/share/classes/sun/security/acl/GroupImpl.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckConfigs.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckOptions.java Changeset: ee5bf287d0c4 Author: alanb Date: 2011-01-10 09:32 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ee5bf287d0c4 7002957: (fc) FileChannel.transferTo fails to load libsendfile on Solaris 64-bit Reviewed-by: chegar ! make/java/nio/Makefile ! src/solaris/native/sun/nio/ch/FileChannelImpl.c Changeset: f4d755bbdabe Author: lancea Date: 2011-01-10 14:43 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f4d755bbdabe 6544224: Remove the need of sun.reflect.misc Reviewed-by: alanb ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java Changeset: 2a0ff59928de Author: smarks Date: 2011-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2a0ff59928de 7005608: diamond conversion of JCA and crypto providers Reviewed-by: wetmore ! src/share/classes/java/security/Security.java ! src/share/classes/sun/security/jca/ProviderList.java ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/VerificationProvider.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/rsa/RSACore.java ! src/share/classes/sun/security/rsa/SunRsaSign.java Changeset: befe813e24d2 Author: lancea Date: 2011-01-11 12:36 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/befe813e24d2 7000693: java.sql.Timestamp compareTo() issues using low values Reviewed-by: okutsu ! src/share/classes/java/sql/Timestamp.java Changeset: 6d0217114886 Author: smarks Date: 2011-01-11 13:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6d0217114886 7011095: revert diamond changes from 6880112 that occur in method args Reviewed-by: darcy, alanb ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/util/logging/Logger.java Changeset: cb3ecb5e4ce5 Author: dl Date: 2011-01-12 14:40 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cb3ecb5e4ce5 7005424: Resync java.util.concurrent classes with Dougs CVS - Jan 2011 Reviewed-by: dholmes, chegar, mduigou ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! test/ProblemList.txt ! test/java/util/WeakHashMap/GCDuringIteration.java ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java ! test/java/util/concurrent/Executors/AutoShutdown.java ! test/java/util/concurrent/Phaser/Basic.java + test/java/util/concurrent/Phaser/FickleRegister.java + test/java/util/concurrent/Phaser/PhaseOverflow.java + test/java/util/concurrent/Phaser/TieredArriveLoops.java ! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java Changeset: a5a22f93e4c5 Author: smarks Date: 2011-01-12 13:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a5a22f93e4c5 7008713: diamond conversion of kerberos5 and security tools Reviewed-by: weijun ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/Authenticator.java ! src/share/classes/sun/security/krb5/internal/AuthorizationData.java ! src/share/classes/sun/security/krb5/internal/EncAPRepPart.java ! src/share/classes/sun/security/krb5/internal/HostAddresses.java ! src/share/classes/sun/security/krb5/internal/KDCReq.java ! src/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/share/classes/sun/security/krb5/internal/KRBCred.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/LastReq.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! test/sun/security/krb5/IPv6.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/tools/KtabCheck.java Changeset: f5c0b3cbee2f Author: kamg Date: 2011-01-12 11:47 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f5c0b3cbee2f 6436034: Instance filter doesn't filter event if it occurs in native method Summary: Use 'GetLocalInstance' JVMTI extension if it exists Reviewed-by: coleenp, dcubed ! src/share/back/debugInit.c ! src/share/back/eventFilter.c ! src/share/instrument/JPLISAgent.c ! src/share/javavm/export/jvmti.h + test/com/sun/jdi/NativeInstanceFilter.java + test/com/sun/jdi/NativeInstanceFilterTarg.java Changeset: 295f6b861c12 Author: kamg Date: 2011-01-12 15:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/295f6b861c12 Merge Changeset: 538f913777cf Author: michaelm Date: 2011-01-13 11:01 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/538f913777cf 6896088: URLClassLoader.close() apparently not working for JAR URLs on Windows Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B6896088.java Changeset: 9f265d55c1c4 Author: michaelm Date: 2011-01-13 11:02 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9f265d55c1c4 Merge Changeset: 694951adefec Author: chegar Date: 2011-01-13 13:24 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/694951adefec 6964547: Impossible to set useV4 in SocksSocketImpl Summary: Add socksProxyVersion property Reviewed-by: alanb, michaelm ! make/sun/net/FILES_java.gmk ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/doc-files/net-properties.html + src/share/classes/sun/net/SocksProxy.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java + test/java/net/Socks/SocksProxyVersion.java Changeset: 38729ba6eb4f Author: michaelm Date: 2011-01-12 15:05 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/38729ba6eb4f 6829919: URLClassLoader.close() doesn't close resource file if getResourceAsStream(...) was called before Reviewed-by: chegar ! src/share/classes/java/net/URLClassLoader.java ! test/java/net/URLClassLoader/closetest/CloseTest.java + test/java/net/URLClassLoader/closetest/Common.java + test/java/net/URLClassLoader/closetest/GetResourceAsStream.java + test/java/net/URLClassLoader/closetest/build2.sh Changeset: ed390b2e5ca4 Author: michaelm Date: 2011-01-13 11:10 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ed390b2e5ca4 Merge Changeset: 067b5f603fc8 Author: michaelm Date: 2011-01-13 14:41 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/067b5f603fc8 Merge Changeset: 3215b22cd90e Author: michaelm Date: 2011-01-13 16:33 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3215b22cd90e 7003398: NetworkInterface equals() and hashCode() behaviors depend on permissions granted Reviewed-by: chegar, alanb ! src/share/classes/java/net/NetworkInterface.java + test/java/net/NetworkInterface/Equals.java Changeset: 29f2e311cce7 Author: mduigou Date: 2011-01-13 20:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/29f2e311cce7 6728865: Provide a better heuristics for Collections.disjoint method Reviewed-by: alanb, dholmes, chegar, forax ! src/share/classes/java/util/Collections.java Changeset: 59e352561146 Author: darcy Date: 2011-01-13 22:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/59e352561146 7012279: Project Coin: Clarify AutoCloseable and Throwable javadoc Reviewed-by: jjb ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java Changeset: 983364897f72 Author: chegar Date: 2011-01-14 22:34 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/983364897f72 7010903: impl. of http.maxConnections is different from the description in JavaSE document Reviewed-by: alanb, michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java Changeset: d61d9bf190f5 Author: smarks Date: 2011-01-14 15:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d61d9bf190f5 7012003: diamond conversion for ssl Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java Changeset: 507627325c81 Author: sundar Date: 2011-01-17 13:29 +0530 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/507627325c81 6508943: small typo in the documentation 6759414: javascript engine can not write to StringWriter 6869617: RhinoScriptEngine bug : ScriptException cause not set (with fix) 7012701: Add a test to check that Rhino's RegExp parser accepts unescaped '[' Reviewed-by: alanb, jjh ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/javax/script/CompiledScript.java + test/javax/script/CauseExceptionTest.java + test/javax/script/StringWriterPrintTest.java + test/javax/script/UnescapedBracketRegExTest.java Changeset: 9596a600758c Author: lana Date: 2011-01-19 19:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9596a600758c Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: e64b1f11cd0b Author: chegar Date: 2011-01-20 15:23 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e64b1f11cd0b 7011857: java/util/concurrent/Phaser/FickleRegister.java fails on solaris-sparc Summary: Remove from ProblemList, failure resolved by 7009231 Reviewed-by: alanb ! test/ProblemList.txt Changeset: cc195c981ae2 Author: mchung Date: 2011-01-20 22:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cc195c981ae2 7013739: jdk_rmi target is missing in the top repo's test/Makefile Reviewed-by: ohair, igor ! test/ProblemList.txt Changeset: 2a8d1a0a2418 Author: chegar Date: 2011-01-21 17:02 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2a8d1a0a2418 7012768: InetAddress lookupTable leaks/deadlocks when using unsupported name service spi Reviewed-by: alanb, michaelm ! src/share/classes/java/net/InetAddress.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/chaining/Providers.java + test/sun/net/InetAddress/nameservice/chaining/Simple1NameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/Simple2NameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/SimpleNameService.java + test/sun/net/InetAddress/nameservice/deadlock/Hang.java + test/sun/net/InetAddress/nameservice/deadlock/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/deadlock/ThrowingNameService.java + test/sun/net/InetAddress/nameservice/deadlock/ThrowingNameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/simple/CacheTest.java + test/sun/net/InetAddress/nameservice/simple/DefaultCaching.java + test/sun/net/InetAddress/nameservice/simple/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/simple/SimpleNameService.java + test/sun/net/InetAddress/nameservice/simple/SimpleNameServiceDescriptor.java Changeset: 6a7b8406a1b9 Author: chegar Date: 2011-01-21 17:04 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6a7b8406a1b9 Merge Changeset: f26d1a7fe4d2 Author: mchung Date: 2011-01-21 09:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f26d1a7fe4d2 6912013: Remove the temporary launcher fix to add modules in the bootclasspath Reviewed-by: ksrini ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 9c18818e7a5f Author: mchung Date: 2011-01-21 09:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9c18818e7a5f Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 2381e810330b Author: zgu Date: 2011-01-20 10:45 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2381e810330b 6983248: net/net001 and net/net003 fail on WinXP with JDK7-B108 Summary: Using closesocket to close socket handler to avoid invalid C runtime parameter exception. Reviewed-by: alanb, phh, dcubed, dsamersoff, coleenp, acorn ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: d03e47de3a89 Author: zgu Date: 2011-01-21 11:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d03e47de3a89 Merge Changeset: c73c178159d8 Author: phh Date: 2011-01-20 19:34 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c73c178159d8 6173675: M&M: approximate memory allocation rate/amount per thread Summary: Subclass com.sun.management.ThreadMXBean from java.lang.management.ThreadMXBean, add getAllocatedBytes() and friends to c.s.m.ThreadMXBean and have sun.management.ThreadImpl implement c.s.m.ThreadMXBean rather than j.l.m.ThreadMXBean. Reviewed-by: mchung, alanb, dholmes, emcmanus ! make/java/management/mapfile-vers + src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/ThreadImpl.c ! src/share/native/sun/management/VMManagementImpl.c + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java + test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java Changeset: 64ef2f52d781 Author: phh Date: 2011-01-21 07:29 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/64ef2f52d781 7013682: two test checking cpuTime filed java/lang/management/ThreadMXBean Summary: Typo in 6173675 fix dropped getThreadCpuTime(long) result on the floor. Reviewed-by: mchung, dholmes ! src/share/classes/sun/management/ThreadImpl.java Changeset: cd13b2114f2e Author: phh Date: 2011-01-22 08:42 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cd13b2114f2e Merge ! src/share/classes/sun/management/ThreadImpl.java Changeset: d1365fdfb3ea Author: phh Date: 2011-01-22 08:43 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d1365fdfb3ea Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 4cc447291326 Author: sherman Date: 2011-01-24 11:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4cc447291326 7006576: (zipfs) Path.exists() always returns false on dirs when zip/JAR file built without dirs 7009092: (zipfs) ZipPath.isSameFile() should always return true if this Path and the given Path are equal. 7009085: (zipfs) ZipPath.normalize("/./.") returns null. 7009102: (zipfs) ZipPath.toRealPath() should always return absolute path. Summary: zip filesystem provider update Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 1f977c82b733 Author: lana Date: 2011-01-24 13:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1f977c82b733 Merge ! make/common/Defs-windows.gmk - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 47cfd89c3227 Author: lana Date: 2011-01-28 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/47cfd89c3227 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 006c683ead1a Author: ohair Date: 2011-01-05 14:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/006c683ead1a 6975326: Problem in install/make/rebase/Makefile, grep on empty pattern 6413588: Add 'ldd -r' and 'dump -Lv' checks to all .so files delivered in the JDK 7000995: Add check in makefiles to verify that msvcp100.dll is NOT used Reviewed-by: mduigou ! make/com/sun/java/pack/Makefile ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile Changeset: 9576644931b2 Author: ohair Date: 2011-01-07 21:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9576644931b2 6980024: Rebranding jre7/jdk7 License, Copyright, Readme 6912291: Third party license agreement should be present in all bundles Reviewed-by: katleman ! make/common/Modules.gmk ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: 8c3c6ac6fcdb Author: ohair Date: 2011-01-10 09:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8c3c6ac6fcdb Merge Changeset: 658559ca4526 Author: ohair Date: 2011-01-10 17:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/658559ca4526 7011382: Fix use of VS100COMNTOOLS when installed in non-default or non-space path Reviewed-by: prr ! make/common/shared/Defs-windows.gmk Changeset: fd6319676bd3 Author: ohair Date: 2011-01-10 17:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fd6319676bd3 Merge Changeset: 713d20f796c0 Author: ohair Date: 2011-01-10 18:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/713d20f796c0 6989472: Provide simple jdk identification information in the install image Reviewed-by: alanb ! make/common/Release.gmk ! make/common/shared/Defs-versions.gmk Changeset: 523386cfb731 Author: ohair Date: 2011-01-10 22:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/523386cfb731 Merge Changeset: 83cef4633684 Author: ohair Date: 2011-01-13 17:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/83cef4633684 Merge Changeset: 4241588a12c3 Author: ohair Date: 2011-01-13 13:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4241588a12c3 7008047: remove sanity check of msival tool from JDK tree Reviewed-by: billyh ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk Changeset: 81e66ce6f501 Author: ohair Date: 2011-01-13 23:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/81e66ce6f501 Merge Changeset: 0c29bbd10e19 Author: ohair Date: 2011-01-14 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0c29bbd10e19 6950375: Remove msvcrt.dll from the Windows JRE bundles Reviewed-by: prr ! make/Makefile ! make/common/Defs-windows.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile ! make/jdk_generic_profile.sh ! src/share/demo/jvmti/index.html Changeset: 329f49ab5c4c Author: ohair Date: 2011-01-16 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/329f49ab5c4c Merge Changeset: 688f415db098 Author: ohair Date: 2011-01-26 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/688f415db098 Merge Changeset: aecb8f0eb83b Author: ohair Date: 2011-01-27 18:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aecb8f0eb83b Merge Changeset: f08682e23279 Author: ohair Date: 2011-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f08682e23279 Merge ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Modules.gmk ! make/common/Program.gmk ! make/common/Release.gmk Changeset: 07c68a15ec79 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/07c68a15ec79 Added tag jdk7-b128 for changeset f08682e23279 ! .hgtags From vladimir.kozlov at oracle.com Fri Feb 4 11:38:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Feb 2011 11:38:02 -0800 Subject: Request for reviews (M): 7013538: Java memory leak with escape analysis Message-ID: <4D4C559A.7010604@oracle.com> http://cr.openjdk.java.net/~kvn/7013538/webrev Fixed 7013538: Java memory leak with escape analysis First, it is not leak. I instrumented VM around method compilation call to see if there are allocations which are not freed. There are none. I used mechanism similar to NoHandleMark to catch direct calls to os::malloc() (NoMallocMark). I found only one case (see below) but it frees memory almost immediately. The rest (major part) of allocations happened on thread Resource area and Compile arena which return used Chunks to ChunkPool after each compilation. But ChunkPool could become very large with EA. It is cleaned each 5 sec by VM task but there could be situations when 2 compilers threads request a lot of memory during 5 sec period causing out of memory problems. So the problem is compilation with EA consumes C heap a lot more than without it. Collected allocation statistics during one hour of the test run (dacapo is running eclipse several times) shows that used C Heap size with EA is around 500Mb when without EA it is only 150Mb (not all of it is used, it could be fragmented because of the problem 2 below). Also numbers of calls to os::malloc rises from 2.5 millions to 10.5 M. The main cause of native memory consumption is allocation of GrowableArray and VectorSet in next very hot EA method: void ConnectionGraph::PointsTo(VectorSet &ptset, Node * n) { VectorSet visited(Thread::current()->resource_area()); GrowableArray worklist; And the cause of a lot calls to os::malloc() is VectorSetI iterator which is used only by EA but it is used a lot, it could also cause C heap fragmentation: SetI_ *VectorSet::iterate(uint &elem) const { VSetI_ *foo = (new(ResourceObj::C_HEAP) VSetI_(this)); elem = foo->next(); return foo; } The first problem is fixed by reusing structures in PointsTo(). I also added Reset() method to VectorSet to zero data array instead of freeing it. The second problem is fixed by adding new simple VectorSetI iterator (old iterator is renamed to VectorSetIter) which is not based on SetI and doesn't need VSetI_. I also fixed compile time statistics for EA since it is now part of Optimizer. From vladimir.kozlov at oracle.com Fri Feb 4 11:48:40 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Feb 2011 11:48:40 -0800 Subject: Request for reviews (XS): 7017240: C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1 Message-ID: <4D4C5818.8080409@oracle.com> http://cr.openjdk.java.net/~kvn/7017240/webrev Fixed 7017240: C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1 C2 adds additional code for G1 barriers so ideal graph may become larger then with other collectors. Also the compiled method itself is huge: 7102 bytes. Main part of the problem is memory resources usage during escape analysis and it will be resolved with 7013538 fix. But I also noticed that PhaseIdealLoop::build_and_optimize() allocates next arrays without freeing resources on exit (there is no ResourceMark): _idom = NEW_RESOURCE_ARRAY( Node*, _idom_size ); _dom_depth = NEW_RESOURCE_ARRAY( uint, _idom_size ); Add ResourceMark. From tom.rodriguez at oracle.com Fri Feb 4 12:20:39 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Feb 2011 12:20:39 -0800 Subject: Request for reviews (XS): 7017240: C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1 In-Reply-To: <4D4C5818.8080409@oracle.com> References: <4D4C5818.8080409@oracle.com> Message-ID: <8B7DB7FA-9A10-4B9F-BF40-CB2CECF59753@oracle.com> On Feb 4, 2011, at 11:48 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7017240/webrev > > Fixed 7017240: C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1 > > C2 adds additional code for G1 barriers so ideal graph > may become larger then with other collectors. > Also the compiled method itself is huge: 7102 bytes. > Main part of the problem is memory resources usage during > escape analysis and it will be resolved with 7013538 fix. > But I also noticed that PhaseIdealLoop::build_and_optimize() > allocates next arrays without freeing resources on exit > (there is no ResourceMark): > > _idom = NEW_RESOURCE_ARRAY( Node*, _idom_size ); > _dom_depth = NEW_RESOURCE_ARRAY( uint, _idom_size ); > > Add ResourceMark. > That looks good. Should _dom_stk be resource allocated as well? if (_dom_stk == NULL) { uint init_size = C->unique() / 100; // Guess that 1/100 is a reasonable initial size. if (init_size < 10) init_size = 10; _dom_stk = new (C->node_arena()) GrowableArray(C->node_arena(), init_size, 0, 0); } tom From vladimir.kozlov at oracle.com Fri Feb 4 14:12:55 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Feb 2011 14:12:55 -0800 Subject: Request for reviews (XS): 7017240: C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1 In-Reply-To: <8B7DB7FA-9A10-4B9F-BF40-CB2CECF59753@oracle.com> References: <4D4C5818.8080409@oracle.com> <8B7DB7FA-9A10-4B9F-BF40-CB2CECF59753@oracle.com> Message-ID: <4D4C79E7.8090706@oracle.com> Thank you, Tom, for catching _dom_stk. An other one is _dom_lca_tags(C->comp_arena()). I used arena() set by base class PhaseTransform() to Thread::resource_area. Updated webrev: http://cr.openjdk.java.net/~kvn/7017240/webrev thanks, Vladimir Tom Rodriguez wrote: > On Feb 4, 2011, at 11:48 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7017240/webrev >> >> Fixed 7017240: C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1 >> >> C2 adds additional code for G1 barriers so ideal graph >> may become larger then with other collectors. >> Also the compiled method itself is huge: 7102 bytes. >> Main part of the problem is memory resources usage during >> escape analysis and it will be resolved with 7013538 fix. >> But I also noticed that PhaseIdealLoop::build_and_optimize() >> allocates next arrays without freeing resources on exit >> (there is no ResourceMark): >> >> _idom = NEW_RESOURCE_ARRAY( Node*, _idom_size ); >> _dom_depth = NEW_RESOURCE_ARRAY( uint, _idom_size ); >> >> Add ResourceMark. >> > > That looks good. Should _dom_stk be resource allocated as well? > > if (_dom_stk == NULL) { > uint init_size = C->unique() / 100; // Guess that 1/100 is a reasonable initial size. > if (init_size < 10) init_size = 10; > _dom_stk = new (C->node_arena()) GrowableArray(C->node_arena(), init_size, 0, 0); > } > > tom > From tom.rodriguez at oracle.com Fri Feb 4 14:24:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Feb 2011 14:24:27 -0800 Subject: Request for reviews (XS): 7017240: C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1 In-Reply-To: <4D4C79E7.8090706@oracle.com> References: <4D4C5818.8080409@oracle.com> <8B7DB7FA-9A10-4B9F-BF40-CB2CECF59753@oracle.com> <4D4C79E7.8090706@oracle.com> Message-ID: <215F5E6D-5D63-44A7-86DD-D68F996F3C3C@oracle.com> That looks good. tom On Feb 4, 2011, at 2:12 PM, Vladimir Kozlov wrote: > Thank you, Tom, for catching _dom_stk. An other one is _dom_lca_tags(C->comp_arena()). I used arena() set by base class PhaseTransform() to Thread::resource_area. > > Updated webrev: > > http://cr.openjdk.java.net/~kvn/7017240/webrev > > thanks, > Vladimir > > Tom Rodriguez wrote: >> On Feb 4, 2011, at 11:48 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7017240/webrev >>> >>> Fixed 7017240: C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1 >>> >>> C2 adds additional code for G1 barriers so ideal graph >>> may become larger then with other collectors. >>> Also the compiled method itself is huge: 7102 bytes. >>> Main part of the problem is memory resources usage during >>> escape analysis and it will be resolved with 7013538 fix. >>> But I also noticed that PhaseIdealLoop::build_and_optimize() >>> allocates next arrays without freeing resources on exit >>> (there is no ResourceMark): >>> >>> _idom = NEW_RESOURCE_ARRAY( Node*, _idom_size ); >>> _dom_depth = NEW_RESOURCE_ARRAY( uint, _idom_size ); >>> >>> Add ResourceMark. >>> >> That looks good. Should _dom_stk be resource allocated as well? >> if (_dom_stk == NULL) { >> uint init_size = C->unique() / 100; // Guess that 1/100 is a reasonable initial size. >> if (init_size < 10) init_size = 10; >> _dom_stk = new (C->node_arena()) GrowableArray(C->node_arena(), init_size, 0, 0); >> } >> tom From tom.rodriguez at oracle.com Fri Feb 4 15:11:07 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Feb 2011 15:11:07 -0800 Subject: Request for reviews (M): 7013538: Java memory leak with escape analysis In-Reply-To: <4D4C559A.7010604@oracle.com> References: <4D4C559A.7010604@oracle.com> Message-ID: Any reason not to completely replace VectorSetI with your new implementation? Otherwise I think it's ok. tom On Feb 4, 2011, at 11:38 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7013538/webrev > > Fixed 7013538: Java memory leak with escape analysis > > First, it is not leak. I instrumented VM around method > compilation call to see if there are allocations which > are not freed. There are none. I used mechanism similar > to NoHandleMark to catch direct calls to os::malloc() > (NoMallocMark). I found only one case (see below) but it > frees memory almost immediately. The rest (major part) of > allocations happened on thread Resource area and Compile > arena which return used Chunks to ChunkPool after each > compilation. But ChunkPool could become very large with EA. > It is cleaned each 5 sec by VM task but there could be > situations when 2 compilers threads request a lot of > memory during 5 sec period causing out of memory problems. > > So the problem is compilation with EA consumes C heap a lot > more than without it. Collected allocation statistics during > one hour of the test run (dacapo is running eclipse several > times) shows that used C Heap size with EA is around 500Mb > when without EA it is only 150Mb (not all of it is used, > it could be fragmented because of the problem 2 below). > Also numbers of calls to os::malloc rises from 2.5 millions > to 10.5 M. > > The main cause of native memory consumption is allocation > of GrowableArray and VectorSet in next very hot EA method: > > void ConnectionGraph::PointsTo(VectorSet &ptset, Node * n) { > VectorSet visited(Thread::current()->resource_area()); > GrowableArray worklist; > > And the cause of a lot calls to os::malloc() is VectorSetI > iterator which is used only by EA but it is used a lot, > it could also cause C heap fragmentation: > > SetI_ *VectorSet::iterate(uint &elem) const > { > VSetI_ *foo = (new(ResourceObj::C_HEAP) VSetI_(this)); > elem = foo->next(); > return foo; > } > > The first problem is fixed by reusing structures in PointsTo(). > I also added Reset() method to VectorSet to zero data array > instead of freeing it. > > The second problem is fixed by adding new simple VectorSetI > iterator (old iterator is renamed to VectorSetIter) which > is not based on SetI and doesn't need VSetI_. > > I also fixed compile time statistics for EA since it is now > part of Optimizer. From vladimir.kozlov at oracle.com Fri Feb 4 16:04:30 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Feb 2011 16:04:30 -0800 Subject: Request for reviews (M): 7013538: Java memory leak with escape analysis In-Reply-To: References: <4D4C559A.7010604@oracle.com> Message-ID: <4D4C940E.3090902@oracle.com> Tom Rodriguez wrote: > Any reason not to completely replace VectorSetI with your new implementation? Otherwise I think it's ok. I thought someone may want to keep old code and if I remove it they will complain :) I would be glad to remove it if nobody objects. Thanks, Vladimir > > tom > > On Feb 4, 2011, at 11:38 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7013538/webrev >> >> Fixed 7013538: Java memory leak with escape analysis >> >> First, it is not leak. I instrumented VM around method >> compilation call to see if there are allocations which >> are not freed. There are none. I used mechanism similar >> to NoHandleMark to catch direct calls to os::malloc() >> (NoMallocMark). I found only one case (see below) but it >> frees memory almost immediately. The rest (major part) of >> allocations happened on thread Resource area and Compile >> arena which return used Chunks to ChunkPool after each >> compilation. But ChunkPool could become very large with EA. >> It is cleaned each 5 sec by VM task but there could be >> situations when 2 compilers threads request a lot of >> memory during 5 sec period causing out of memory problems. >> >> So the problem is compilation with EA consumes C heap a lot >> more than without it. Collected allocation statistics during >> one hour of the test run (dacapo is running eclipse several >> times) shows that used C Heap size with EA is around 500Mb >> when without EA it is only 150Mb (not all of it is used, >> it could be fragmented because of the problem 2 below). >> Also numbers of calls to os::malloc rises from 2.5 millions >> to 10.5 M. >> >> The main cause of native memory consumption is allocation >> of GrowableArray and VectorSet in next very hot EA method: >> >> void ConnectionGraph::PointsTo(VectorSet &ptset, Node * n) { >> VectorSet visited(Thread::current()->resource_area()); >> GrowableArray worklist; >> >> And the cause of a lot calls to os::malloc() is VectorSetI >> iterator which is used only by EA but it is used a lot, >> it could also cause C heap fragmentation: >> >> SetI_ *VectorSet::iterate(uint &elem) const >> { >> VSetI_ *foo = (new(ResourceObj::C_HEAP) VSetI_(this)); >> elem = foo->next(); >> return foo; >> } >> >> The first problem is fixed by reusing structures in PointsTo(). >> I also added Reset() method to VectorSet to zero data array >> instead of freeing it. >> >> The second problem is fixed by adding new simple VectorSetI >> iterator (old iterator is renamed to VectorSetIter) which >> is not based on SetI and doesn't need VSetI_. >> >> I also fixed compile time statistics for EA since it is now >> part of Optimizer. > From igor.veresov at oracle.com Fri Feb 4 18:03:13 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 04 Feb 2011 18:03:13 -0800 Subject: Request for review(M): 7017434: Tiered needs to support reprofiling Message-ID: <4D4CAFE1.2020600@oracle.com> Tiered needs to support proper method reprofiling after deopts. The idea is to measure the amount of time spent additionally profiling the method by adding start counters to MDO. The difference between current values and start values is used as a measure of profile maturity. Webrev: http://cr.openjdk.java.net/~iveresov/7017434/webrev.00/ Thanks, igor From vladimir.kozlov at oracle.com Fri Feb 4 18:04:26 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Feb 2011 18:04:26 -0800 Subject: Request for reviews (M): 7013538: Java memory leak with escape analysis In-Reply-To: References: <4D4C559A.7010604@oracle.com> <4D4C940E.3090902@oracle.com> Message-ID: <4D4CB02A.9000303@oracle.com> OK. Thanks, Tom Vladimir Tom Rodriguez wrote: > On Feb 4, 2011, at 4:04 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>> Any reason not to completely replace VectorSetI with your new implementation? Otherwise I think it's ok. >> I thought someone may want to keep old code and >> if I remove it they will complain :) >> I would be glad to remove it if nobody objects. > > Who's going to object on Friday at 5? ;) I'd say remove it. It doesn't really match hotspot style anyway which is why we got into trouble. > > tom > >> Thanks, >> Vladimir >> >>> tom >>> On Feb 4, 2011, at 11:38 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7013538/webrev >>>> >>>> Fixed 7013538: Java memory leak with escape analysis >>>> >>>> First, it is not leak. I instrumented VM around method >>>> compilation call to see if there are allocations which >>>> are not freed. There are none. I used mechanism similar >>>> to NoHandleMark to catch direct calls to os::malloc() >>>> (NoMallocMark). I found only one case (see below) but it >>>> frees memory almost immediately. The rest (major part) of >>>> allocations happened on thread Resource area and Compile >>>> arena which return used Chunks to ChunkPool after each >>>> compilation. But ChunkPool could become very large with EA. >>>> It is cleaned each 5 sec by VM task but there could be >>>> situations when 2 compilers threads request a lot of >>>> memory during 5 sec period causing out of memory problems. >>>> >>>> So the problem is compilation with EA consumes C heap a lot >>>> more than without it. Collected allocation statistics during >>>> one hour of the test run (dacapo is running eclipse several >>>> times) shows that used C Heap size with EA is around 500Mb >>>> when without EA it is only 150Mb (not all of it is used, >>>> it could be fragmented because of the problem 2 below). >>>> Also numbers of calls to os::malloc rises from 2.5 millions >>>> to 10.5 M. >>>> >>>> The main cause of native memory consumption is allocation >>>> of GrowableArray and VectorSet in next very hot EA method: >>>> >>>> void ConnectionGraph::PointsTo(VectorSet &ptset, Node * n) { >>>> VectorSet visited(Thread::current()->resource_area()); >>>> GrowableArray worklist; >>>> >>>> And the cause of a lot calls to os::malloc() is VectorSetI >>>> iterator which is used only by EA but it is used a lot, >>>> it could also cause C heap fragmentation: >>>> >>>> SetI_ *VectorSet::iterate(uint &elem) const >>>> { >>>> VSetI_ *foo = (new(ResourceObj::C_HEAP) VSetI_(this)); >>>> elem = foo->next(); >>>> return foo; >>>> } >>>> >>>> The first problem is fixed by reusing structures in PointsTo(). >>>> I also added Reset() method to VectorSet to zero data array >>>> instead of freeing it. >>>> >>>> The second problem is fixed by adding new simple VectorSetI >>>> iterator (old iterator is renamed to VectorSetIter) which >>>> is not based on SetI and doesn't need VSetI_. >>>> >>>> I also fixed compile time statistics for EA since it is now >>>> part of Optimizer. > From vladimir.kozlov at oracle.com Fri Feb 4 18:44:13 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Feb 2011 18:44:13 -0800 Subject: Request for review(M): 7017434: Tiered needs to support reprofiling In-Reply-To: <4D4CAFE1.2020600@oracle.com> References: <4D4CAFE1.2020600@oracle.com> Message-ID: <4D4CB97D.2070009@oracle.com> You use intx for new values. It is long in 64bit VM but you use them in int expressions and use %d format to print. Otherwise looks fine. Vladimir Igor Veresov wrote: > Tiered needs to support proper method reprofiling after deopts. The idea > is to measure the amount of time spent additionally profiling the method > by adding start counters to MDO. The difference between current values > and start values is used as a measure of profile maturity. > > > Webrev: http://cr.openjdk.java.net/~iveresov/7017434/webrev.00/ > > > Thanks, > igor From igor.veresov at oracle.com Fri Feb 4 20:20:53 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 04 Feb 2011 20:20:53 -0800 Subject: Request for review(M): 7017434: Tiered needs to support reprofiling In-Reply-To: <4D4CB97D.2070009@oracle.com> References: <4D4CAFE1.2020600@oracle.com> <4D4CB97D.2070009@oracle.com> Message-ID: <4D4CD025.9070708@oracle.com> Yes, you're right, those should be just ints. Thanks, igor On 2/4/11 6:44 PM, Vladimir Kozlov wrote: > You use intx for new values. It is long in 64bit VM but you use them in > int expressions and use %d format to print. Otherwise looks fine. > > Vladimir > > Igor Veresov wrote: >> Tiered needs to support proper method reprofiling after deopts. The >> idea is to measure the amount of time spent additionally profiling the >> method by adding start counters to MDO. The difference between current >> values and start values is used as a measure of profile maturity. >> >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7017434/webrev.00/ >> >> >> Thanks, >> igor From dlila at redhat.com Mon Feb 7 09:06:33 2011 From: dlila at redhat.com (Denis Lila) Date: Mon, 7 Feb 2011 12:06:33 -0500 (EST) Subject: SIGSEGV in C2 compiler In-Reply-To: Message-ID: <625704537.35662.1297098393114.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Ping me directly if you'd like help restructuring the loop to avoid the > problem. Thank you, but I already know how to do that. The reason I worked on this is because I am interested in compilers, and I would like to work on hotspot. This seemed like a good place to start. > I'm sorry I didn't follow up on this with you, I lost track of it over > the Christmas holiday. This appears to be the same issue as 6675699 > where a ConvI2L with a constrained type on it has it's input replaced > with a constant outside that range. The identity transformation > converts that to top which causes a phi collapse and the control flow > to be killed. We've kind of band aided this in a few other places but > it appears that loop unswitching can create similar issues. I've spent a lot of time thinking about this and staring at graphs, and here's what I think: (now, before this, I had never even read anything about compilers, let alone worked on one, so please, if anything doesn't make sense, don't go easy on me ;-) ) (Before I begin, I refer to a lot of node indexes below. Here's the graphs they were taken from: http://icedtea.classpath.org/~dlila/ecjGraph.xml. I used IdealGraphVisualizer from src/share/tools) That bug's evaluation says "We need to remove the band aid fixes for 4781451 and 4799512 and disallow ConvI2L from being initialized with a narrower type than bottom". I'm not sure I understand why. I mean, in this case it made sense to me that node 147 should be initialized with type 1..maxint because, like the comment where this is done says, we can simply assume that our input is a valid array index because if it's not a runtime check will take care of that case and the index won't be used. What I think is going wrong is that when we do subsume_node(k, i) (in phaseX.cpp:1108 - in this case that would be subsume_node(357, 296)) we are losing information about one of the uses of 296. Before the subsume the uses of 296 are 357 (the phi) and 295. After the subsume they are 259 and 295. When compute_lca_of_uses(296, 314) is called, Node *c in the loop becomes 259 in the 2nd iteration, and when we call get_ctrl(259) we get 226. 226 is dominated by 350, and the idom of 350 is 286 (the if that is executed before the loops - the one generated by the loop splitting) because the controls from both split loops to 350 are still alive. 286 dominates the early control of 296 (which is 314), so it thinks this is a bad graph. If 357 had not been removed, when c.idx==357 in compute_lca_of_uses(296...), because 357 is a phi node, we know to "skip" over the region and set the "use" variable to the control input to the region that corresponds to the data input in question to the phi. In this case 296 is the data input, the phi is 357, and the corresponding control input to the region is 349, which is the control from the split loop where 296 is computed. So "use" would be set to node 349, and nothing would go wrong because 314 dominates both 349 and 303. So, what I meant when I said "we are losing information about one of the uses of 296" is that we are losing the information that, if the value produced by node 296 is used by node 259, the control path taken _must_ have gone through 349, and it _cannot_ have gone through 217 (which is control path from the i!=8 unswitched loop (the one that never runs)). It seems to me like this problem isn't specific to ConvI2L, but can happen any time that a data input to a phi node dies, but the control input to that phi's region that corresponds to the dead data doesn't die. I'm not sure if this state of affairs can be caused by anything other than a ConvI2L, but even so, I think this should get its own fix, because in PhiNode::unique_input, when we do if (un == NULL || un == this || phase->type(un) == Type::TOP) { continue; // ignore if top, or in(i) and "this" are in a data cycle } we're not stating an invariant such as "a phi's data input dies if and only if that data's corresponding control dies". So, as long as it's possible for the data to die, but that data's control to stay alive, I think this will be a problem, regardless of ConvI2L's behaviour. I have two potential fixes in mind: 1. Don't subsume a phi node with its unique input if it has dead inputs but the dead inputs' controls are not dead. 2. For every node N that is used by a phi node P that is killed, save a pointer to P->in(0) and a number j such that P->in(j) == N. That will allow us to correctly compute "use" in compute_lca_of_uses even if c isn't a phi. Like I said above, I'm not sure if any of this makes any sense at all so I would very much appreciate any criticism. Thank you, Denis. ----- Original Message ----- > > Pop 147 ConvI2L === _ 20 [[ 153 ]] Type:long:1..maxint:www !jvms: > Test::main @ bci:32 > < long:1..maxint:www < 147 ConvI2L === _ _ [[]] [3000147] ... From vladimir.kozlov at oracle.com Mon Feb 7 12:08:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Feb 2011 12:08:33 -0800 Subject: Request for reviews (S): 7014874: Incorrect COOPs modes on solaris-{sparcv9, amd64} with ParallelGC In-Reply-To: <4D42F9D5.6060003@oracle.com> References: <4D41EF1D.502@oracle.com> <4D41F382.8060006@oracle.com> <4D41F67E.9060006@oracle.com> <4D41F8CB.5080107@oracle.com> <4D41FB4C.2040304@oracle.com> <4D42F9D5.6060003@oracle.com> Message-ID: <4D505141.1000304@oracle.com> Ramki, I looked more on this. Gen collectors align Young and Old gens sizes down. Look in collectorPolicy.cpp on methods initialize_flags(). They align up MaxHeapSize but if it is already specified with good rounding (as in my case) then it stays the same: set_max_heap_byte_size(align_size_up(MaxHeapSize, max_alignment())); G1 uses this size without any adjustment (G1CollectedHeap::initialize()): size_t max_byte_size = collector_policy()->max_heap_byte_size(); It seems, only Parallel GC modifies it. Thanks, Vladimir Y. Srinivas Ramakrishna wrote: > Hi Vladimir -- > > On 1/27/2011 3:10 PM, Vladimir Kozlov wrote: >> As Igor explained me only Parallel GC requires boundary >> page size alignment due to UseAdaptiveGCBoundary feature. > > Hmm, I do see a lot of "align_size_up()" done on max_size specs > in CollectedHeap::initialize_size_info() and friends, > as well as in GenerationSpec::align(). I didn't follow the > logic through to see if that will or will not affect the > whole heap sizing behaviour wrt the issue > reported in the CR. The bug report states the > anomalous behaviour with ParallelScavenge heaps, > Have you tested G1CollectedHeap and GenCollectedHeap > to see if they do the right thing? > > thanks. > -- ramki > >> >> Vladimir >> >> Y. S. Ramakrishna wrote: >>> May be you need a "partition_aligned()" method that >>> takes an aligned whole and produces aligned partitions >>> thereof given a desired_partitioning request. It would >>> seem as though similar logic would need to apply to >>> other kinds of heaps... or do they do the right thing >>> already? OK, i suppose i should go look, since i am >>> supposed to be reviewing, not interviewing ;-) >>> >>> -- ramki >>> >>> On 01/27/11 14:49, Vladimir Kozlov wrote: >>>> Before rounding YG+OG == total heap size. To keep the same >>>> total size I need to round one size up and the other down. >>>> I still may not preserver the same total size if it is not >>>> rounded to the same or large alignment. But it is fine. >>>> >>>> I already fixed PG rounding before in 6984368 changes: >>>> >>>> src/share/vm/memory/collectorPolicy.cpp Tue Sep 14 17:19:35 2010 -0700 >>>> @@ -32,7 +32,11 @@ >>>> MaxPermSize = PermSize; >>>> } >>>> PermSize = MAX2(min_alignment(), align_size_down_(PermSize, >>>> min_alignment())); >>>> - MaxPermSize = align_size_up(MaxPermSize, max_alignment()); >>>> + // Don't increase Perm size limit above specified. >>>> + MaxPermSize = align_size_down(MaxPermSize, max_alignment()); >>>> + if (PermSize > MaxPermSize) { >>>> + PermSize = MaxPermSize; >>>> + } >>>> >>>> Vladimir >>>> >>>> Y. S. Ramakrishna wrote: >>>>> I don't understand the logic of the patch. Or rather, i do, >>>>> but i question if it is complete: why didn't you also align >>>>> the max size of YG and PG down in like manner? I think you >>>>> should or you would be open to the same issues, no? >>>>> >>>>> In fact, it seems as though, as a matter of uniform policy, all min's >>>>> should align upwards and all max's align downwards wherever >>>>> (page-)alignment >>>>> is sought. >>>>> >>>>> -- ramki >>>>> >>>>> >>>>> On 01/27/11 14:18, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7014874/webrev >>>>>> >>>>>> Fixed 7014874: Incorrect COOPs modes on solaris-{sparcv9,amd64} >>>>>> with ParallelGC >>>>>> >>>>>> scale_by_NewRatio_aligned() aligns boundary between old >>>>>> and young gens to min_alignment() (64K). But code in >>>>>> ParallelScavengeHeap::initialize() aligns up both old and >>>>>> young gen sizes to large page size. >>>>>> As result total heap size could be increased by one large >>>>>> page and cross 4gb boundary preventing usage of 32-bit COOPs. >>>>>> >>>>>> Align old gen size down to keep specified heap size but >>>>>> not less than its old gen min size. > From y.s.ramakrishna at oracle.com Mon Feb 7 14:23:00 2011 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Mon, 07 Feb 2011 14:23:00 -0800 Subject: Request for reviews (S): 7014874: Incorrect COOPs modes on solaris-{sparcv9, amd64} with ParallelGC In-Reply-To: <4D505141.1000304@oracle.com> References: <4D41EF1D.502@oracle.com> <4D41F382.8060006@oracle.com> <4D41F67E.9060006@oracle.com> <4D41F8CB.5080107@oracle.com> <4D41FB4C.2040304@oracle.com> <4D42F9D5.6060003@oracle.com> <4D505141.1000304@oracle.com> Message-ID: <4D5070C4.2090803@oracle.com> Hi Vladimir, thanks for checking! On 2/7/2011 12:08 PM, Vladimir Kozlov wrote: > Ramki, > > I looked more on this. Gen collectors align Young and > Old gens sizes down. Look in collectorPolicy.cpp on methods > initialize_flags(). They align up MaxHeapSize but if it > is already specified with good rounding (as in my case) > then it stays the same: > > set_max_heap_byte_size(align_size_up(MaxHeapSize, max_alignment())); It would seem to me that this should be align_size_down() above for the case when it's not aligned and we want to stay within the band specified by [Min, Max]. But I understand that in yr case with an already aligned heap size spec this would not cause an issue. [The concern i was getting at comes up from time to time, but we have ended up patching over it in piecemeal fashion in the past; we should probably just consolidate this into one place and fix it, but that's a bigger, separate issue deserving its own CR, so should not block your fix here.] > > G1 uses this size without any adjustment (G1CollectedHeap::initialize()): > > size_t max_byte_size = collector_policy()->max_heap_byte_size(); That's good. > > It seems, only Parallel GC modifies it. Thanks for checking, and your change looks fine to me for addressing the immediate problem. Thumbs up from my side, and sorry for my nit-picking! :-) -- ramki > > Thanks, > Vladimir > > Y. Srinivas Ramakrishna wrote: >> Hi Vladimir -- >> >> On 1/27/2011 3:10 PM, Vladimir Kozlov wrote: >>> As Igor explained me only Parallel GC requires boundary >>> page size alignment due to UseAdaptiveGCBoundary feature. >> >> Hmm, I do see a lot of "align_size_up()" done on max_size specs >> in CollectedHeap::initialize_size_info() and friends, >> as well as in GenerationSpec::align(). I didn't follow the >> logic through to see if that will or will not affect the >> whole heap sizing behaviour wrt the issue >> reported in the CR. The bug report states the >> anomalous behaviour with ParallelScavenge heaps, >> Have you tested G1CollectedHeap and GenCollectedHeap >> to see if they do the right thing? >> >> thanks. >> -- ramki >> >>> >>> Vladimir >>> >>> Y. S. Ramakrishna wrote: >>>> May be you need a "partition_aligned()" method that >>>> takes an aligned whole and produces aligned partitions >>>> thereof given a desired_partitioning request. It would >>>> seem as though similar logic would need to apply to >>>> other kinds of heaps... or do they do the right thing >>>> already? OK, i suppose i should go look, since i am >>>> supposed to be reviewing, not interviewing ;-) >>>> >>>> -- ramki >>>> >>>> On 01/27/11 14:49, Vladimir Kozlov wrote: >>>>> Before rounding YG+OG == total heap size. To keep the same >>>>> total size I need to round one size up and the other down. >>>>> I still may not preserver the same total size if it is not >>>>> rounded to the same or large alignment. But it is fine. >>>>> >>>>> I already fixed PG rounding before in 6984368 changes: >>>>> >>>>> src/share/vm/memory/collectorPolicy.cpp Tue Sep 14 17:19:35 2010 -0700 >>>>> @@ -32,7 +32,11 @@ >>>>> MaxPermSize = PermSize; >>>>> } >>>>> PermSize = MAX2(min_alignment(), align_size_down_(PermSize, min_alignment())); >>>>> - MaxPermSize = align_size_up(MaxPermSize, max_alignment()); >>>>> + // Don't increase Perm size limit above specified. >>>>> + MaxPermSize = align_size_down(MaxPermSize, max_alignment()); >>>>> + if (PermSize > MaxPermSize) { >>>>> + PermSize = MaxPermSize; >>>>> + } >>>>> >>>>> Vladimir >>>>> >>>>> Y. S. Ramakrishna wrote: >>>>>> I don't understand the logic of the patch. Or rather, i do, >>>>>> but i question if it is complete: why didn't you also align >>>>>> the max size of YG and PG down in like manner? I think you >>>>>> should or you would be open to the same issues, no? >>>>>> >>>>>> In fact, it seems as though, as a matter of uniform policy, all min's >>>>>> should align upwards and all max's align downwards wherever (page-)alignment >>>>>> is sought. >>>>>> >>>>>> -- ramki >>>>>> >>>>>> >>>>>> On 01/27/11 14:18, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/7014874/webrev >>>>>>> >>>>>>> Fixed 7014874: Incorrect COOPs modes on solaris-{sparcv9,amd64} with ParallelGC >>>>>>> >>>>>>> scale_by_NewRatio_aligned() aligns boundary between old >>>>>>> and young gens to min_alignment() (64K). But code in >>>>>>> ParallelScavengeHeap::initialize() aligns up both old and >>>>>>> young gen sizes to large page size. >>>>>>> As result total heap size could be increased by one large >>>>>>> page and cross 4gb boundary preventing usage of 32-bit COOPs. >>>>>>> >>>>>>> Align old gen size down to keep specified heap size but >>>>>>> not less than its old gen min size. >> From vladimir.kozlov at oracle.com Mon Feb 7 15:17:04 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 07 Feb 2011 23:17:04 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7017240: C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1 Message-ID: <20110207231709.38EF0474D5@hg.openjdk.java.net> Changeset: 194c9fdee631 Author: kvn Date: 2011-02-07 09:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/194c9fdee631 7017240: C2: native memory leak in nsk/regression/b4675027 on windows-x86 in comp mode with G1 Summary: Add ResourceMark into PhaseIdealLoop::build_and_optimize(). Reviewed-by: never ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp From vladimir.kozlov at oracle.com Mon Feb 7 19:17:10 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 08 Feb 2011 03:17:10 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7013538: Java memory leak with escape analysis Message-ID: <20110208031717.EB736474DF@hg.openjdk.java.net> Changeset: 3763ca6579b7 Author: kvn Date: 2011-02-07 10:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3763ca6579b7 7013538: Java memory leak with escape analysis Summary: Don't allocate VectorSet iterator on C heap. Reuse resource storage in EA. Reviewed-by: never ! src/share/vm/libadt/vectset.cpp ! src/share/vm/libadt/vectset.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/phase.cpp From vladimir.kozlov at oracle.com Mon Feb 7 21:19:33 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 08 Feb 2011 05:19:33 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7017124: Fix some VM stats to avoid 32-bit overflow Message-ID: <20110208051936.AF76E474E4@hg.openjdk.java.net> Changeset: f7de3327c683 Author: kvn Date: 2011-02-07 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f7de3327c683 7017124: Fix some VM stats to avoid 32-bit overflow Summary: Added new method inc_stat_counter() to increment long statistic values and use atomic long load and store. Reviewed-by: dholmes, jrose, phh, never ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/opto/indexSet.cpp ! src/share/vm/opto/indexSet.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp From dlila at redhat.com Tue Feb 8 10:14:48 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 8 Feb 2011 13:14:48 -0500 (EST) Subject: SIGSEGV in C2 compiler In-Reply-To: <625704537.35662.1297098393114.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <862224818.102134.1297188888115.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Tom. > So, as long as it's possible for the data to die, but that data's > control to stay alive, I think this will be a problem, regardless > of ConvI2L's behaviour. I should have probably asked this before I sent that huge e-mail: Is it a legal state for a data input of a phi to be dead but that data's control to be alive? To me it doesn't seem so. In that case, can this happen with any node other than a range checked ConvI2L whose input is always out of range? Thank you, Denis. ----- Original Message ----- > > Ping me directly if you'd like help restructuring the loop to avoid > > the > > problem. > > Thank you, but I already know how to do that. The reason I worked on > this > is because I am interested in compilers, and I would like to work on > hotspot. This seemed like a good place to start. > > > I'm sorry I didn't follow up on this with you, I lost track of it > > over > > the Christmas holiday. This appears to be the same issue as 6675699 > > where a ConvI2L with a constrained type on it has it's input > > replaced > > with a constant outside that range. The identity transformation > > converts that to top which causes a phi collapse and the control > > flow > > to be killed. We've kind of band aided this in a few other places > > but > > it appears that loop unswitching can create similar issues. > > I've spent a lot of time thinking about this and staring at graphs, > and > here's what I think: (now, before this, I had never even read anything > about > compilers, let alone worked on one, so please, if anything doesn't > make > sense, don't go easy on me ;-) ) > > (Before I begin, I refer to a lot of node indexes below. Here's the > graphs > they were taken from: > http://icedtea.classpath.org/~dlila/ecjGraph.xml. I used > IdealGraphVisualizer from src/share/tools) > > That bug's evaluation says "We need to remove the band aid fixes for > 4781451 and 4799512 and disallow ConvI2L from being initialized with > a narrower type than bottom". I'm not sure I understand why. I mean, > in this case it made sense to me that node 147 should be initialized > with type 1..maxint because, like the comment where this is done says, > we can simply assume that our input is a valid array index because if > it's not a runtime check will take care of that case and the index > won't > be used. > > What I think is going wrong is that when we do subsume_node(k, i) (in > phaseX.cpp:1108 - in this case that would be subsume_node(357, 296)) > we > are losing information about one of the uses of 296. Before the > subsume > the uses of 296 are 357 (the phi) and 295. After the subsume they are > 259 and 295. When compute_lca_of_uses(296, 314) is called, Node *c in > the > loop becomes 259 in the 2nd iteration, and when we call get_ctrl(259) > we > get 226. 226 is dominated by 350, and the idom of 350 is 286 (the if > that > is executed before the loops - the one generated by the loop > splitting) > because the controls from both split loops to 350 are still > alive. > 286 dominates the early control of 296 (which is 314), so it thinks > this > is a bad graph. > > If 357 had not been removed, when c.idx==357 in > compute_lca_of_uses(296...), > because 357 is a phi node, we know to "skip" over the region and set > the > "use" variable to the control input to the region that corresponds to > the > data input in question to the phi. In this case 296 is the data input, > the phi > is 357, and the corresponding control input to the region is 349, > which is > the control from the split loop where 296 is computed. So "use" would > be set > to node 349, and nothing would go wrong because 314 dominates both 349 > and 303. > > So, what I meant when I said "we are losing information about one of > the uses > of 296" is that we are losing the information that, if the value > produced by > node 296 is used by node 259, the control path taken _must_ have gone > through > 349, and it _cannot_ have gone through 217 (which is control path from > the i!=8 > unswitched loop (the one that never runs)). > > It seems to me like this problem isn't specific to ConvI2L, but can > happen > any time that a data input to a phi node dies, but the control input > to that > phi's region that corresponds to the dead data doesn't die. I'm not > sure if > this state of affairs can be caused by anything other than a ConvI2L, > but even > so, I think this should get its own fix, because in > PhiNode::unique_input, when > we do > if (un == NULL || un == this || phase->type(un) == Type::TOP) { > continue; // ignore if top, or in(i) and "this" are in a data cycle > } > we're not stating an invariant such as "a phi's data input dies if and > only if > that data's corresponding control dies". So, as long as it's possible > for the > data to die, but that data's control to stay alive, I think this will > be a > problem, regardless of ConvI2L's behaviour. > > I have two potential fixes in mind: > 1. Don't subsume a phi node with its unique input if it has dead > inputs but > the dead inputs' controls are not dead. > 2. For every node N that is used by a phi node P that is killed, save > a pointer > to P->in(0) and a number j such that P->in(j) == N. That will allow us > to correctly > compute "use" in compute_lca_of_uses even if c isn't a phi. > > Like I said above, I'm not sure if any of this makes any sense at all > so I > would very much appreciate any criticism. > > Thank you, > Denis. > > ----- Original Message ----- > > > > > Pop 147 ConvI2L === _ 20 [[ 153 ]] Type:long:1..maxint:www !jvms: > > Test::main @ bci:32 > > < long:1..maxint:www < 147 ConvI2L === _ _ [[]] [3000147] > ... From tom.rodriguez at oracle.com Tue Feb 8 11:22:06 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Feb 2011 11:22:06 -0800 Subject: SIGSEGV in C2 compiler In-Reply-To: <862224818.102134.1297188888115.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <862224818.102134.1297188888115.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <5784DF81-99E2-4687-8EE6-9F6E7FA5F956@oracle.com> On Feb 8, 2011, at 10:14 AM, Denis Lila wrote: > Hi Tom. > >> So, as long as it's possible for the data to die, but that data's >> control to stay alive, I think this will be a problem, regardless >> of ConvI2L's behaviour. > > I should have probably asked this before I sent that huge e-mail: > > Is it a legal state for a data input of a phi to be dead but that data's > control to be alive? No it's not. Data is only allowed to go dead as a result of control going dead. That's why this is a bug in how ConvI2L is used and not a bug with handling of Phis. It would be nicer if we detected this during GVN itself but it's not entirely simple to do so. Maybe processing of Phis could be delayed until all other control nodes are processed and then Phis with top inputs would be flagged as an error. That would require significant reworking of the worklist processing I think. tom > > To me it doesn't seem so. In that case, can this happen with any node > other than a range checked ConvI2L whose input is always out of range? > > Thank you, > Denis. > > ----- Original Message ----- >>> Ping me directly if you'd like help restructuring the loop to avoid >>> the >>> problem. >> >> Thank you, but I already know how to do that. The reason I worked on >> this >> is because I am interested in compilers, and I would like to work on >> hotspot. This seemed like a good place to start. >> >>> I'm sorry I didn't follow up on this with you, I lost track of it >>> over >>> the Christmas holiday. This appears to be the same issue as 6675699 >>> where a ConvI2L with a constrained type on it has it's input >>> replaced >>> with a constant outside that range. The identity transformation >>> converts that to top which causes a phi collapse and the control >>> flow >>> to be killed. We've kind of band aided this in a few other places >>> but >>> it appears that loop unswitching can create similar issues. >> >> I've spent a lot of time thinking about this and staring at graphs, >> and >> here's what I think: (now, before this, I had never even read anything >> about >> compilers, let alone worked on one, so please, if anything doesn't >> make >> sense, don't go easy on me ;-) ) >> >> (Before I begin, I refer to a lot of node indexes below. Here's the >> graphs >> they were taken from: >> http://icedtea.classpath.org/~dlila/ecjGraph.xml. I used >> IdealGraphVisualizer from src/share/tools) >> >> That bug's evaluation says "We need to remove the band aid fixes for >> 4781451 and 4799512 and disallow ConvI2L from being initialized with >> a narrower type than bottom". I'm not sure I understand why. I mean, >> in this case it made sense to me that node 147 should be initialized >> with type 1..maxint because, like the comment where this is done says, >> we can simply assume that our input is a valid array index because if >> it's not a runtime check will take care of that case and the index >> won't >> be used. >> >> What I think is going wrong is that when we do subsume_node(k, i) (in >> phaseX.cpp:1108 - in this case that would be subsume_node(357, 296)) >> we >> are losing information about one of the uses of 296. Before the >> subsume >> the uses of 296 are 357 (the phi) and 295. After the subsume they are >> 259 and 295. When compute_lca_of_uses(296, 314) is called, Node *c in >> the >> loop becomes 259 in the 2nd iteration, and when we call get_ctrl(259) >> we >> get 226. 226 is dominated by 350, and the idom of 350 is 286 (the if >> that >> is executed before the loops - the one generated by the loop >> splitting) >> because the controls from both split loops to 350 are still >> alive. >> 286 dominates the early control of 296 (which is 314), so it thinks >> this >> is a bad graph. >> >> If 357 had not been removed, when c.idx==357 in >> compute_lca_of_uses(296...), >> because 357 is a phi node, we know to "skip" over the region and set >> the >> "use" variable to the control input to the region that corresponds to >> the >> data input in question to the phi. In this case 296 is the data input, >> the phi >> is 357, and the corresponding control input to the region is 349, >> which is >> the control from the split loop where 296 is computed. So "use" would >> be set >> to node 349, and nothing would go wrong because 314 dominates both 349 >> and 303. >> >> So, what I meant when I said "we are losing information about one of >> the uses >> of 296" is that we are losing the information that, if the value >> produced by >> node 296 is used by node 259, the control path taken _must_ have gone >> through >> 349, and it _cannot_ have gone through 217 (which is control path from >> the i!=8 >> unswitched loop (the one that never runs)). >> >> It seems to me like this problem isn't specific to ConvI2L, but can >> happen >> any time that a data input to a phi node dies, but the control input >> to that >> phi's region that corresponds to the dead data doesn't die. I'm not >> sure if >> this state of affairs can be caused by anything other than a ConvI2L, >> but even >> so, I think this should get its own fix, because in >> PhiNode::unique_input, when >> we do >> if (un == NULL || un == this || phase->type(un) == Type::TOP) { >> continue; // ignore if top, or in(i) and "this" are in a data cycle >> } >> we're not stating an invariant such as "a phi's data input dies if and >> only if >> that data's corresponding control dies". So, as long as it's possible >> for the >> data to die, but that data's control to stay alive, I think this will >> be a >> problem, regardless of ConvI2L's behaviour. >> >> I have two potential fixes in mind: >> 1. Don't subsume a phi node with its unique input if it has dead >> inputs but >> the dead inputs' controls are not dead. >> 2. For every node N that is used by a phi node P that is killed, save >> a pointer >> to P->in(0) and a number j such that P->in(j) == N. That will allow us >> to correctly >> compute "use" in compute_lca_of_uses even if c isn't a phi. >> >> Like I said above, I'm not sure if any of this makes any sense at all >> so I >> would very much appreciate any criticism. >> >> Thank you, >> Denis. >> >> ----- Original Message ----- >> >>> >>> Pop 147 ConvI2L === _ 20 [[ 153 ]] Type:long:1..maxint:www !jvms: >>> Test::main @ bci:32 >>> < long:1..maxint:www < 147 ConvI2L === _ _ [[]] [3000147] >> ... From vladimir.kozlov at oracle.com Tue Feb 8 23:33:26 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 09 Feb 2011 07:33:26 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7014874: Incorrect COOPs modes on solaris-{sparcv9, amd64} with ParallelGC Message-ID: <20110209073328.EE76147532@hg.openjdk.java.net> Changeset: 336d17dff7cc Author: kvn Date: 2011-02-08 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/336d17dff7cc 7014874: Incorrect COOPs modes on solaris-{sparcv9,amd64} with ParallelGC Summary: Align old gen size down to keep specified heap size. Reviewed-by: ysr ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp From christian.thalinger at oracle.com Wed Feb 9 09:33:02 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Feb 2011 18:33:02 +0100 Subject: Request for reviews (S): 7018277: JSR 292 change test/compiler/6987555/Test6987555.java to new MH syntax Message-ID: <6D91116E-0973-4A91-ACDF-9DEB8EBA3815@oracle.com> http://cr.openjdk.java.net/~twisti/7018277/webrev.01/ 7018277: JSR 292 change test/compiler/6987555/Test6987555.java to new MH syntax Summary: test/compiler/6987555/Test6987555.java currently does not compile because the MH return-type syntax has changed. Reviewed-by: test/compiler/6987555/Test6987555.java currently does not compile because the MH return-type syntax has changed. The trivial fix is to change the method handle call sites to the new syntax. From tom.rodriguez at oracle.com Wed Feb 9 13:13:41 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 9 Feb 2011 13:13:41 -0800 Subject: review (XS) for 7012072: CompileTheWorld causes incorrect class initialization Message-ID: http://cr.openjdk.java.net/~never/7012072 7012072: CompileTheWorld causes incorrect class initialization Reviewed-by: A class in java.util.concurrent had a static initializer with a dependency on it's outer class that could result in the unsafe offsets being used before they'd actually been initialized if the inner class was initialized before the outer. This would result in a failure during a later heap verification because the header word of an oop was overwritten. The class is being fixed to be more robust under a separate bug id but I thought we should add an assert to complain more directly at the use. It won't catch all possible cases of this since it doesn't guard against unsafe uses in the compiler but running -Xint would show the problem. Tested with failing test. From tom.rodriguez at oracle.com Wed Feb 9 13:22:43 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 9 Feb 2011 13:22:43 -0800 Subject: Request for reviews (S): 7018277: JSR 292 change test/compiler/6987555/Test6987555.java to new MH syntax In-Reply-To: <6D91116E-0973-4A91-ACDF-9DEB8EBA3815@oracle.com> References: <6D91116E-0973-4A91-ACDF-9DEB8EBA3815@oracle.com> Message-ID: <6C95D12E-E4CF-4FE9-A860-37675F0A5ECB@oracle.com> Looks ok. tom On Feb 9, 2011, at 9:33 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7018277/webrev.01/ > > 7018277: JSR 292 change test/compiler/6987555/Test6987555.java to new MH syntax > Summary: test/compiler/6987555/Test6987555.java currently does not compile because the MH return-type syntax has changed. > Reviewed-by: > > test/compiler/6987555/Test6987555.java currently does not compile > because the MH return-type syntax has changed. > > The trivial fix is to change the method handle call sites to the new > syntax. From vladimir.kozlov at oracle.com Wed Feb 9 16:35:34 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Feb 2011 16:35:34 -0800 Subject: Request for reviews (S): 7017746: Regression : C2 compiler crash due to SIGSEGV in PhaseCFG::schedule_early() Message-ID: <4D5332D6.7020900@oracle.com> http://cr.openjdk.java.net/~kvn/7017746/webrev Fixed 7017746: Regression : C2 compiler crash due to SIGSEGV in PhaseCFG::schedule_early() ADLC generates incorrect Expand() for mach nodes which have duplicated operands and TEMP. The Expand() moves TEMP edge before it is added. As result last edge will look like prec edge and corresponding Ideal node is not mapped to mach node: the failed node on the entry to Expand() (_cnt==6): 870 cadd_cmpLTMask_1 === _ o1388 o1357 o1388 o1357 o64 [[]] after duplicated operands are removed (_cnt==4): 870 cadd_cmpLTMask_1 === _ o1388 o1357 o64 |o64 [[]] VM dies in schedule_early() when tries to place o64 Ideal node. Add TEMP edges (and KILL projections) before duplicated operands are removed (the code was simple moved). Also we don't need new operand for TEMP since it is already constructed during a mach node construction. Added asserts to Node::del_req() to catch such situation (asserts are copied from set_req() method). Remove cadd_cmpLTMask2() since ADLC already generates clones of cadd_cmpLTMask() with swapped inputs. Added cmpLTMask0 missed on sparc. cadd_cmpLTMask originaly was added to optimize code in jvm98 compress benchmark. But currently it is not matching since transformation (Bool [lt] CmpI (SubI(a, b), #0)) --> (Bool [lt] CmpI (a, b)) was removed long ago as incorrect in case of integer overflow in SubI. Adding cmpLTMask0 helps to reduce the code size. Addred regression test. Tested with CTW and JPRT. From tom.rodriguez at oracle.com Wed Feb 9 17:02:00 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 9 Feb 2011 17:02:00 -0800 Subject: Request for reviews (S): 7017746: Regression : C2 compiler crash due to SIGSEGV in PhaseCFG::schedule_early() In-Reply-To: <4D5332D6.7020900@oracle.com> References: <4D5332D6.7020900@oracle.com> Message-ID: <8A65E9B1-512E-4612-B2F7-9310AAAAA002@oracle.com> Looks good. tom On Feb 9, 2011, at 4:35 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7017746/webrev > > Fixed 7017746: Regression : C2 compiler crash due to SIGSEGV in PhaseCFG::schedule_early() > > ADLC generates incorrect Expand() for mach nodes which > have duplicated operands and TEMP. The Expand() moves > TEMP edge before it is added. As result last edge will look > like prec edge and corresponding Ideal node is not mapped > to mach node: > > the failed node on the entry to Expand() (_cnt==6): > > 870 cadd_cmpLTMask_1 === _ o1388 o1357 o1388 o1357 o64 [[]] > > after duplicated operands are removed (_cnt==4): > > 870 cadd_cmpLTMask_1 === _ o1388 o1357 o64 |o64 [[]] > > VM dies in schedule_early() when tries to place o64 Ideal node. > > > Add TEMP edges (and KILL projections) before duplicated > operands are removed (the code was simple moved). > Also we don't need new operand for TEMP since it is > already constructed during a mach node construction. > > Added asserts to Node::del_req() to catch such situation > (asserts are copied from set_req() method). > > Remove cadd_cmpLTMask2() since ADLC already generates > clones of cadd_cmpLTMask() with swapped inputs. > > Added cmpLTMask0 missed on sparc. > cadd_cmpLTMask originaly was added to optimize code > in jvm98 compress benchmark. But currently it is not > matching since transformation > > (Bool [lt] CmpI (SubI(a, b), #0)) --> (Bool [lt] CmpI (a, b)) > > was removed long ago as incorrect in case of integer > overflow in SubI. Adding cmpLTMask0 helps to reduce > the code size. > > Addred regression test. Tested with CTW and JPRT. From vladimir.kozlov at oracle.com Wed Feb 9 17:01:22 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Feb 2011 17:01:22 -0800 Subject: Request for reviews (S): 7017746: Regression : C2 compiler crash due to SIGSEGV in PhaseCFG::schedule_early() In-Reply-To: <8A65E9B1-512E-4612-B2F7-9310AAAAA002@oracle.com> References: <4D5332D6.7020900@oracle.com> <8A65E9B1-512E-4612-B2F7-9310AAAAA002@oracle.com> Message-ID: <4D5338E2.6050705@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Feb 9, 2011, at 4:35 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7017746/webrev >> >> Fixed 7017746: Regression : C2 compiler crash due to SIGSEGV in PhaseCFG::schedule_early() >> >> ADLC generates incorrect Expand() for mach nodes which >> have duplicated operands and TEMP. The Expand() moves >> TEMP edge before it is added. As result last edge will look >> like prec edge and corresponding Ideal node is not mapped >> to mach node: >> >> the failed node on the entry to Expand() (_cnt==6): >> >> 870 cadd_cmpLTMask_1 === _ o1388 o1357 o1388 o1357 o64 [[]] >> >> after duplicated operands are removed (_cnt==4): >> >> 870 cadd_cmpLTMask_1 === _ o1388 o1357 o64 |o64 [[]] >> >> VM dies in schedule_early() when tries to place o64 Ideal node. >> >> >> Add TEMP edges (and KILL projections) before duplicated >> operands are removed (the code was simple moved). >> Also we don't need new operand for TEMP since it is >> already constructed during a mach node construction. >> >> Added asserts to Node::del_req() to catch such situation >> (asserts are copied from set_req() method). >> >> Remove cadd_cmpLTMask2() since ADLC already generates >> clones of cadd_cmpLTMask() with swapped inputs. >> >> Added cmpLTMask0 missed on sparc. >> cadd_cmpLTMask originaly was added to optimize code >> in jvm98 compress benchmark. But currently it is not >> matching since transformation >> >> (Bool [lt] CmpI (SubI(a, b), #0)) --> (Bool [lt] CmpI (a, b)) >> >> was removed long ago as incorrect in case of integer >> overflow in SubI. Adding cmpLTMask0 helps to reduce >> the code size. >> >> Addred regression test. Tested with CTW and JPRT. > From igor.veresov at oracle.com Wed Feb 9 20:18:17 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 10 Feb 2011 04:18:17 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7017434: Tiered needs to support reprofiling Message-ID: <20110210041818.D03AA47589@hg.openjdk.java.net> Changeset: 72d6c57d0658 Author: iveresov Date: 2011-02-09 16:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/72d6c57d0658 7017434: Tiered needs to support reprofiling Summary: Tiered needs to support proper method reprofiling after deopts. Reviewed-by: kvn ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp From Christian.Thalinger at Sun.COM Thu Feb 10 03:05:29 2011 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 10 Feb 2011 11:05:29 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7018277: JSR 292 change test/compiler/6987555/Test6987555.java to new MH syntax Message-ID: <20110210110537.9E9AE4759E@hg.openjdk.java.net> Changeset: 62a8557e8f36 Author: twisti Date: 2011-02-10 00:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/62a8557e8f36 7018277: JSR 292 change test/compiler/6987555/Test6987555.java to new MH syntax Summary: test/compiler/6987555/Test6987555.java currently does not compile because the MH return-type syntax has changed. Reviewed-by: never ! test/compiler/6987555/Test6987555.java From gbenson at redhat.com Thu Feb 10 06:49:27 2011 From: gbenson at redhat.com (Gary Benson) Date: Thu, 10 Feb 2011 14:49:27 +0000 Subject: Review Request: Zero fixes Message-ID: <20110210144926.GC4905@redhat.com> Hi all, 6953144, 6990754 and 7009756 made some changes which broke Zero. This webrev fixes: http://cr.openjdk.java.net/~gbenson/6953144-6990754-7009756-fixups/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From christian.thalinger at oracle.com Thu Feb 10 08:56:12 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Feb 2011 17:56:12 +0100 Subject: Request for reviews (M): 7018378: JSR 292: _bound_int_mh produces wrong result on 64-bit SPARC Message-ID: <5B1EB6D4-A1D9-4B39-AD23-C9186D5AF2C9@oracle.com> http://cr.openjdk.java.net/~twisti/7018378/webrev.01/ 7018378: JSR 292: _bound_int_mh produces wrong result on 64-bit SPARC Reviewed-by: The bug is in the implementation of SPARC's _bound_int_direct_mh. The current code reads a 64-bit integer value with ldx and tries to sign-extend it properly for st_long. But that sign-extension code is wrong. The fix is to replace the existing code with a ld_long/st_long sequence. Additionally this change adds a store_sized_value method which is used along with load_sized_value in the _bound_*_mh adapters for SPARC and x86. I also fixed a similar bug in _adapter_opt_i2l to move the right bits to the right registers for st_long. From christian.thalinger at oracle.com Thu Feb 10 09:02:26 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Feb 2011 18:02:26 +0100 Subject: Review Request: Zero fixes In-Reply-To: <20110210144926.GC4905@redhat.com> References: <20110210144926.GC4905@redhat.com> Message-ID: On Feb 10, 2011, at 3:49 PM, Gary Benson wrote: > Hi all, > > 6953144, 6990754 and 7009756 made some changes which broke Zero. > This webrev fixes: > > http://cr.openjdk.java.net/~gbenson/6953144-6990754-7009756-fixups/ > > I don't have a bug id for this. 7018673: Zero: 6953144, 6990754 and 7009756 made some changes which broke Zero The changes look good. -- Christian From christian.thalinger at oracle.com Thu Feb 10 09:06:05 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Feb 2011 18:06:05 +0100 Subject: review (XS) for 7012072: CompileTheWorld causes incorrect class initialization In-Reply-To: References: Message-ID: On Feb 9, 2011, at 10:13 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7012072 > > 7012072: CompileTheWorld causes incorrect class initialization > Reviewed-by: > > A class in java.util.concurrent had a static initializer with a > dependency on it's outer class that could result in the unsafe offsets > being used before they'd actually been initialized if the inner class > was initialized before the outer. This would result in a failure > during a later heap verification because the header word of an oop was > overwritten. The class is being fixed to be more robust under a > separate bug id but I thought we should add an assert to complain more > directly at the use. It won't catch all possible cases of this since > it doesn't guard against unsafe uses in the compiler but running -Xint > would show the problem. Tested with failing test. Looks good. -- Christian From vladimir.kozlov at oracle.com Thu Feb 10 10:00:17 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Feb 2011 10:00:17 -0800 Subject: Request for reviews (M): 7018378: JSR 292: _bound_int_mh produces wrong result on 64-bit SPARC In-Reply-To: <5B1EB6D4-A1D9-4B39-AD23-C9186D5AF2C9@oracle.com> References: <5B1EB6D4-A1D9-4B39-AD23-C9186D5AF2C9@oracle.com> Message-ID: <4D5427B1.7070806@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7018378/webrev.01/ > > 7018378: JSR 292: _bound_int_mh produces wrong result on 64-bit SPARC > Reviewed-by: > > The bug is in the implementation of SPARC's _bound_int_direct_mh. The > current code reads a 64-bit integer value with ldx and tries to > sign-extend it properly for st_long. But that sign-extension code is > wrong. > > The fix is to replace the existing code with a ld_long/st_long > sequence. > > Additionally this change adds a store_sized_value method which is used > along with load_sized_value in the _bound_*_mh adapters for SPARC and > x86. > > I also fixed a similar bug in _adapter_opt_i2l to move the right bits > to the right registers for st_long. From vladimir.kozlov at oracle.com Thu Feb 10 10:02:11 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Feb 2011 10:02:11 -0800 Subject: Review Request: Zero fixes In-Reply-To: References: <20110210144926.GC4905@redhat.com> Message-ID: <4D542823.6070807@oracle.com> Yes, changes are good. Vladimir Christian Thalinger wrote: > On Feb 10, 2011, at 3:49 PM, Gary Benson wrote: >> Hi all, >> >> 6953144, 6990754 and 7009756 made some changes which broke Zero. >> This webrev fixes: >> >> http://cr.openjdk.java.net/~gbenson/6953144-6990754-7009756-fixups/ >> >> I don't have a bug id for this. > > 7018673: Zero: 6953144, 6990754 and 7009756 made some changes which broke Zero > > The changes look good. > > -- Christian From ChrisPhi at LGonQn.Org Thu Feb 10 10:45:51 2011 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Thu, 10 Feb 2011 13:45:51 -0500 Subject: Review Request: Zero fixes In-Reply-To: <20110210144926.GC4905@redhat.com> References: <20110210144926.GC4905@redhat.com> Message-ID: <4D54325F.2030309@LGonQn.Org> (resend, forgot to Cc list, newly setup mailer) Hi Gary, Looks good to me. Chris On 10/02/11 09:49 AM, Gary Benson wrote: > Hi all, > > 6953144, 6990754 and 7009756 made some changes which broke Zero. > This webrev fixes: > > http://cr.openjdk.java.net/~gbenson/6953144-6990754-7009756-fixups/ > > I don't have a bug id for this. > > Cheers, > Gary > From tom.rodriguez at oracle.com Thu Feb 10 11:13:43 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 10 Feb 2011 11:13:43 -0800 Subject: review (XS) for 7018506: CTW swallowing OOMs after symbol changes Message-ID: <9378D63A-8683-4B32-AC7B-1951D66526C4@oracle.com> http://cr.openjdk.java.net/~never/7018506 7018506: CTW swallowing OOMs after symbol changes Reviewed-by: Previously the symbol creation could throw an OOM for perm but now it can't and the next two exception points just swallowed exception so it keeps on going. The fix is to always allow OOMs to be propagated. Tested with CTW. From igor.veresov at oracle.com Thu Feb 10 11:36:18 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 10 Feb 2011 11:36:18 -0800 Subject: review (XS) for 7018506: CTW swallowing OOMs after symbol changes In-Reply-To: <9378D63A-8683-4B32-AC7B-1951D66526C4@oracle.com> References: <9378D63A-8683-4B32-AC7B-1951D66526C4@oracle.com> Message-ID: <4D543E32.3030708@oracle.com> Looks good. igor On 2/10/11 11:13 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7018506 > > 7018506: CTW swallowing OOMs after symbol changes > Reviewed-by: > > Previously the symbol creation could throw an OOM for perm but now it > can't and the next two exception points just swallowed exception so it > keeps on going. The fix is to always allow OOMs to be propagated. > Tested with CTW. From vladimir.kozlov at oracle.com Thu Feb 10 11:15:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Feb 2011 11:15:42 -0800 Subject: review (XS) for 7018506: CTW swallowing OOMs after symbol changes In-Reply-To: <9378D63A-8683-4B32-AC7B-1951D66526C4@oracle.com> References: <9378D63A-8683-4B32-AC7B-1951D66526C4@oracle.com> Message-ID: <4D54395E.9000609@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7018506 > > 7018506: CTW swallowing OOMs after symbol changes > Reviewed-by: > > Previously the symbol creation could throw an OOM for perm but now it > can't and the next two exception points just swallowed exception so it > keeps on going. The fix is to always allow OOMs to be propagated. > Tested with CTW. From tom.rodriguez at oracle.com Thu Feb 10 11:47:49 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 10 Feb 2011 11:47:49 -0800 Subject: review (XS) for 7018506: CTW swallowing OOMs after symbol changes In-Reply-To: <4D543E32.3030708@oracle.com> References: <9378D63A-8683-4B32-AC7B-1951D66526C4@oracle.com> <4D543E32.3030708@oracle.com> Message-ID: Coleen pointed out there are other unchecked CLEAR_PENDING_EXCEPTION calls so I've modified it to check at all of them. Please re-review. tom On Feb 10, 2011, at 11:36 AM, Igor Veresov wrote: > Looks good. > > igor > > On 2/10/11 11:13 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7018506 >> >> 7018506: CTW swallowing OOMs after symbol changes >> Reviewed-by: >> >> Previously the symbol creation could throw an OOM for perm but now it >> can't and the next two exception points just swallowed exception so it >> keeps on going. The fix is to always allow OOMs to be propagated. >> Tested with CTW. > From vladimir.kozlov at oracle.com Thu Feb 10 11:57:27 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Feb 2011 11:57:27 -0800 Subject: review (XS) for 7018506: CTW swallowing OOMs after symbol changes In-Reply-To: References: <9378D63A-8683-4B32-AC7B-1951D66526C4@oracle.com> <4D543E32.3030708@oracle.com> Message-ID: <4D544327.70601@oracle.com> Tom, I think new method should return boolean if exception occurred. There is checked variable 'exception_occurred' to which it should be assigned to: 1324 bool exception_occurred = clear_pending_exception_if_not_oom(CHECK); 1325 if (CompileTheWorldPreloadClasses && k.not_null()) { 1326 constantPoolKlass::preload_and_initialize_all_classes(k->constants(), THREAD); 1327 if (HAS_PENDING_EXCEPTION) { 1328 // If something went wrong in preloading we just ignore it 1329 exception_occurred = clear_pending_exception_if_not_oom(CHECK); 1330 tty->print_cr("Preloading failed for (%d) %s", _compile_the_world_counter, buffer); 1331 } 1332 } Thanks, Vladimir Tom Rodriguez wrote: > Coleen pointed out there are other unchecked CLEAR_PENDING_EXCEPTION calls so I've modified it to check at all of them. Please re-review. > > tom > > On Feb 10, 2011, at 11:36 AM, Igor Veresov wrote: > >> Looks good. >> >> igor >> >> On 2/10/11 11:13 AM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7018506 >>> >>> 7018506: CTW swallowing OOMs after symbol changes >>> Reviewed-by: >>> >>> Previously the symbol creation could throw an OOM for perm but now it >>> can't and the next two exception points just swallowed exception so it >>> keeps on going. The fix is to always allow OOMs to be propagated. >>> Tested with CTW. > From tom.rodriguez at oracle.com Thu Feb 10 12:09:22 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 10 Feb 2011 12:09:22 -0800 Subject: review (XS) for 7018506: CTW swallowing OOMs after symbol changes In-Reply-To: <4D544327.70601@oracle.com> References: <9378D63A-8683-4B32-AC7B-1951D66526C4@oracle.com> <4D543E32.3030708@oracle.com> <4D544327.70601@oracle.com> Message-ID: <5F7B4DDE-9A28-4229-9C0E-E3FE5F019B8C@oracle.com> On Feb 10, 2011, at 11:57 AM, Vladimir Kozlov wrote: > Tom, > > I think new method should return boolean if exception occurred. > There is checked variable 'exception_occurred' to which it > should be assigned to: > > 1324 bool exception_occurred = clear_pending_exception_if_not_oom(CHECK); I considered that but the natural way to use that is: if (clear_pending_exception_if_not_oom(CHECK)) { but having CHECK macros in conditional doesn't work right. Also I think the logic only wants to skip if something went wrong with the initial class load and initialize, not with the constant pool preload_and_init part. tom > > 1325 if (CompileTheWorldPreloadClasses && k.not_null()) { > 1326 constantPoolKlass::preload_and_initialize_all_classes(k->constants(), THREAD); > 1327 if (HAS_PENDING_EXCEPTION) { > 1328 // If something went wrong in preloading we just ignore it > 1329 exception_occurred = clear_pending_exception_if_not_oom(CHECK); > 1330 tty->print_cr("Preloading failed for (%d) %s", _compile_the_world_counter, buffer); > 1331 } > 1332 } > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> Coleen pointed out there are other unchecked CLEAR_PENDING_EXCEPTION calls so I've modified it to check at all of them. Please re-review. >> tom >> On Feb 10, 2011, at 11:36 AM, Igor Veresov wrote: >>> Looks good. >>> >>> igor >>> >>> On 2/10/11 11:13 AM, Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7018506 >>>> >>>> 7018506: CTW swallowing OOMs after symbol changes >>>> Reviewed-by: >>>> >>>> Previously the symbol creation could throw an OOM for perm but now it >>>> can't and the next two exception points just swallowed exception so it >>>> keeps on going. The fix is to always allow OOMs to be propagated. >>>> Tested with CTW. From vladimir.kozlov at oracle.com Thu Feb 10 12:16:41 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Feb 2011 12:16:41 -0800 Subject: review (XS) for 7018506: CTW swallowing OOMs after symbol changes In-Reply-To: <5F7B4DDE-9A28-4229-9C0E-E3FE5F019B8C@oracle.com> References: <9378D63A-8683-4B32-AC7B-1951D66526C4@oracle.com> <4D543E32.3030708@oracle.com> <4D544327.70601@oracle.com> <5F7B4DDE-9A28-4229-9C0E-E3FE5F019B8C@oracle.com> Message-ID: <4D5447A9.6020202@oracle.com> OK. Vladimir Tom Rodriguez wrote: > On Feb 10, 2011, at 11:57 AM, Vladimir Kozlov wrote: > >> Tom, >> >> I think new method should return boolean if exception occurred. >> There is checked variable 'exception_occurred' to which it >> should be assigned to: >> >> 1324 bool exception_occurred = clear_pending_exception_if_not_oom(CHECK); > > I considered that but the natural way to use that is: > > if (clear_pending_exception_if_not_oom(CHECK)) { > > but having CHECK macros in conditional doesn't work right. Also I think the logic only wants to skip if something went wrong with the initial class load and initialize, not with the constant pool preload_and_init part. > > tom > >> 1325 if (CompileTheWorldPreloadClasses && k.not_null()) { >> 1326 constantPoolKlass::preload_and_initialize_all_classes(k->constants(), THREAD); >> 1327 if (HAS_PENDING_EXCEPTION) { >> 1328 // If something went wrong in preloading we just ignore it >> 1329 exception_occurred = clear_pending_exception_if_not_oom(CHECK); >> 1330 tty->print_cr("Preloading failed for (%d) %s", _compile_the_world_counter, buffer); >> 1331 } >> 1332 } >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> Coleen pointed out there are other unchecked CLEAR_PENDING_EXCEPTION calls so I've modified it to check at all of them. Please re-review. >>> tom >>> On Feb 10, 2011, at 11:36 AM, Igor Veresov wrote: >>>> Looks good. >>>> >>>> igor >>>> >>>> On 2/10/11 11:13 AM, Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/7018506 >>>>> >>>>> 7018506: CTW swallowing OOMs after symbol changes >>>>> Reviewed-by: >>>>> >>>>> Previously the symbol creation could throw an OOM for perm but now it >>>>> can't and the next two exception points just swallowed exception so it >>>>> keeps on going. The fix is to always allow OOMs to be propagated. >>>>> Tested with CTW. > From igor.veresov at oracle.com Thu Feb 10 12:21:03 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 10 Feb 2011 12:21:03 -0800 Subject: review (XS) for 7018506: CTW swallowing OOMs after symbol changes In-Reply-To: References: <9378D63A-8683-4B32-AC7B-1951D66526C4@oracle.com> <4D543E32.3030708@oracle.com> Message-ID: <4D5448AF.5040805@oracle.com> Looks ok. igor On 2/10/11 11:47 AM, Tom Rodriguez wrote: > Coleen pointed out there are other unchecked CLEAR_PENDING_EXCEPTION calls so I've modified it to check at all of them. Please re-review. > > tom > > On Feb 10, 2011, at 11:36 AM, Igor Veresov wrote: > >> Looks good. >> >> igor >> >> On 2/10/11 11:13 AM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7018506 >>> >>> 7018506: CTW swallowing OOMs after symbol changes >>> Reviewed-by: >>> >>> Previously the symbol creation could throw an OOM for perm but now it >>> can't and the next two exception points just swallowed exception so it >>> keeps on going. The fix is to always allow OOMs to be propagated. >>> Tested with CTW. >> > From p.thio at xs4all.nl Thu Feb 10 13:44:50 2011 From: p.thio at xs4all.nl (Paul Thio) Date: Thu, 10 Feb 2011 22:44:50 +0100 Subject: ByteBuffer and ByteOrder Message-ID: Hello, I have a question about the compilation of a test program, which uses a ByteBuffer. The program set the byte order to little endian and uses the method ByteBuffer.getLong. The program runs on Linux x86_64, which is also little endian. The compiler assembler output contains a block for little endian conversion and a block for big endian conversion. This block contains bswap instructions. I am wondering if the code for big endian conversion can be eliminated. I attached the test program. Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.java Type: application/octet-stream Size: 768 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110210/877799c1/attachment.obj From vladimir.kozlov at oracle.com Thu Feb 10 16:34:34 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Feb 2011 16:34:34 -0800 Subject: Request for reviews (XS): 7018849: 7017124 fix broke VM build on some platforms Message-ID: <4D54841A.3030500@oracle.com> http://cr.openjdk.java.net/~kvn/7018849/webrev Fixed 7018849: 7017124 fix broke VM build on some platforms 7017124 fix uses Atomic load and store for longs which are not available on all platforms. Use atomic load and store in inc_stat_counter() only on SPARC and X86. From vladimir.kozlov at oracle.com Thu Feb 10 16:38:25 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Feb 2011 00:38:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7017746: Regression : C2 compiler crash due to SIGSEGV in PhaseCFG::schedule_early() Message-ID: <20110211003827.0D71947626@hg.openjdk.java.net> Changeset: ab42c7e1cf83 Author: kvn Date: 2011-02-10 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ab42c7e1cf83 7017746: Regression : C2 compiler crash due to SIGSEGV in PhaseCFG::schedule_early() Summary: Add TEMP edges (and KILL projections) before duplicated operands are removed in Expand() methods. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/node.cpp + test/compiler/7017746/Test.java From john.coomes at oracle.com Thu Feb 10 20:45:07 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 04:45:07 +0000 Subject: hg: jdk7/hotspot-comp/corba: 3 new changesets Message-ID: <20110211044512.A2F8E47638@hg.openjdk.java.net> Changeset: 6a3903e5b6cc Author: ohair Date: 2011-02-03 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/6a3903e5b6cc 6944304: Potential rebranding issues in the openjdk7/corba sources Reviewed-by: alanb, mchung, darcy ! src/share/classes/com/sun/corba/se/spi/logging/data/Activation.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/IOR.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Interceptors.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Naming.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/OMG.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/POA.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Util.mc Changeset: 66fa0fcc7792 Author: ohair Date: 2011-02-04 07:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/66fa0fcc7792 Merge Changeset: 4cdf9b86f550 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/4cdf9b86f550 Added tag jdk7-b129 for changeset 66fa0fcc7792 ! .hgtags From john.coomes at oracle.com Thu Feb 10 20:45:19 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 04:45:19 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b129 for changeset f5b60c5a310f Message-ID: <20110211044519.75F8647639@hg.openjdk.java.net> Changeset: ab107c1bc4b9 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/ab107c1bc4b9 Added tag jdk7-b129 for changeset f5b60c5a310f ! .hgtags From john.coomes at oracle.com Thu Feb 10 20:45:25 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 04:45:25 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b129 for changeset 0f7b39ad9024 Message-ID: <20110211044526.1AF4B4763A@hg.openjdk.java.net> Changeset: ba1fac1c2083 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/ba1fac1c2083 Added tag jdk7-b129 for changeset 0f7b39ad9024 ! .hgtags From john.coomes at oracle.com Thu Feb 10 20:45:36 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 04:45:36 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 5 new changesets Message-ID: <20110211044654.D3B3D4763B@hg.openjdk.java.net> Changeset: 001dcfd0be4b Author: ohair Date: 2011-02-08 16:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/001dcfd0be4b 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 Reviewed-by: rinaldo ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: 1f056ddda771 Author: ohair Date: 2011-01-28 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1f056ddda771 7014301: Change make 3.81 sanity check to a fatal, 3.81 is needed now Reviewed-by: alanb ! make/common/shared/Sanity.gmk Changeset: 3f77dae85c85 Author: ohair Date: 2011-02-08 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3f77dae85c85 Merge Changeset: 14cd5d54a8d0 Author: ohair Date: 2011-02-08 20:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/14cd5d54a8d0 Merge ! make/common/shared/Sanity.gmk Changeset: 326aac19a89f Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/326aac19a89f Added tag jdk7-b129 for changeset 14cd5d54a8d0 ! .hgtags From john.coomes at oracle.com Thu Feb 10 20:47:12 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 04:47:12 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 22 new changesets Message-ID: <20110211044757.BFE764763C@hg.openjdk.java.net> Changeset: d17f37522154 Author: jjg Date: 2011-01-10 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d17f37522154 6992999: fully remove JSR 308 from langtools Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.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/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! test/tools/javac/diags/examples.not-yet.txt Changeset: 7c537f4298fb Author: jjg Date: 2011-01-10 15:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7c537f4298fb 6396503: javac should not require assertions enabled Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.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/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/Assert.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java ! src/share/classes/javax/tools/ToolProvider.java Changeset: 17b271281525 Author: jjg Date: 2011-01-11 08:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/17b271281525 6993305: starting position of a method without modifiers and with type parameters is incorrect Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/tree/T6993305.java Changeset: d33d8c381aa1 Author: jjg Date: 2011-01-13 11:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d33d8c381aa1 6430241: Hard to disable symbol file feature through API Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java + test/tools/javac/api/T6430241.java Changeset: a466f00c5cd2 Author: bpatel Date: 2011-01-13 21:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a466f00c5cd2 7010528: javadoc performance regression Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java Changeset: 2d5aff89aaa3 Author: mcimadamore Date: 2011-01-14 09:45 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2d5aff89aaa3 6992698: JSR 292: remove support for transient syntax in polymorphic signature calls Summary: special syntax to denote indy return type through type parameters should be removed (and cast shall be used instead) Reviewed-by: jjg, jrose ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/Names.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out ! test/tools/javac/meth/TestCP.java ! test/tools/javac/meth/XlintWarn.java Changeset: c8d312dd17bc Author: mcimadamore Date: 2011-01-14 09:45 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c8d312dd17bc 7007432: Test generic types well-formedness Summary: add a new kind of check (well-formedness of generic type w.r.t. declared bounds) in the type-harness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/types/GenericTypeWellFormednessTest.java ! test/tools/javac/types/TypeHarness.java Changeset: 712be35e40b5 Author: mcimadamore Date: 2011-01-14 09:46 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/712be35e40b5 6949040: java.dyn package must be compiled with -target 7 or better Summary: issue error (rather than warning) when @PolymorphicSignature is found and target < 7 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt Changeset: 7c7c1787fbbe Author: jjg Date: 2011-01-14 11:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7c7c1787fbbe 6419926: JSR 199: FileObject.toUri() generates URI without schema (Solaris) Reviewed-by: mcimadamore + test/tools/javac/api/T6419926.java Changeset: 0a509c765657 Author: jjg Date: 2011-01-14 11:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0a509c765657 6571165: Minor doc bugs in JavaCompiler.java Reviewed-by: mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 19f9b6548c70 Author: ksrini Date: 2011-01-14 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/19f9b6548c70 7011272: langtools build.xml should provide a patch target Reviewed-by: jonathan, jjh ! make/build.xml Changeset: 5cf6c432ef2f Author: ksrini Date: 2011-01-18 08:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/5cf6c432ef2f 6982999: tools must support -target 7 bytecodes Reviewed-by: jjg, jrose ! src/share/classes/com/sun/tools/classfile/Attribute.java + src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java Changeset: b6f95173e769 Author: lana Date: 2011-01-19 19:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b6f95173e769 Merge Changeset: 19c900c703c6 Author: mcimadamore Date: 2011-01-24 15:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/19c900c703c6 6943278: spurious error message for inference and type-variable with erroneous bound Summary: type-inference should ignore erroneous bounds Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6943278/T6943278.java + test/tools/javac/generics/inference/6943278/T6943278.out Changeset: ce6175cfe11e Author: mcimadamore Date: 2011-01-24 15:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ce6175cfe11e 6968793: issues with diagnostics Summary: several diagnostic improvements Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6330920/T6330920.out ! test/tools/javac/6717241/T6717241a.out ! test/tools/javac/6717241/T6717241b.out ! test/tools/javac/6857948/T6857948.out ! test/tools/javac/6863465/T6863465c.out ! test/tools/javac/6863465/T6863465d.out ! test/tools/javac/T6247324.out ! test/tools/javac/TryWithResources/ResourceOutsideTry.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CantResolve.java ! test/tools/javac/diags/examples/CantResolveArgsParams.java ! test/tools/javac/diags/examples/CantResolveLocation.java ! test/tools/javac/diags/examples/CantResolveLocationArgs.java ! test/tools/javac/diags/examples/CantResolveLocationArgsParams.java - test/tools/javac/diags/examples/EnumConstRequired.java ! test/tools/javac/diags/examples/ForeachNotApplicable.java ! test/tools/javac/diags/examples/KindnameClass.java ! test/tools/javac/diags/examples/KindnameMethod.java ! test/tools/javac/diags/examples/KindnameVariable.java + test/tools/javac/diags/examples/Location.java + test/tools/javac/diags/examples/Location1.java ! test/tools/javac/diags/examples/OperatorCantBeApplied.java + test/tools/javac/diags/examples/OperatorCantBeApplied1.java ! test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/StaticImportOnlyClassesAndInterfaces.java ! test/tools/javac/failover/FailOver01.out ! test/tools/javac/failover/FailOver02.out ! test/tools/javac/failover/FailOver04.out ! test/tools/javac/generics/6711619/T6711619a.out ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.out ! test/tools/javac/generics/diamond/neg/Neg11.out ! test/tools/javac/generics/inference/6943278/T6943278.out ! test/tools/javac/generics/typevars/5060485/Compatibility.out ! test/tools/javac/generics/typevars/5060485/Compatibility02.out + test/tools/javac/generics/typevars/6968793/T6968793.java + test/tools/javac/generics/typevars/6968793/T6968793.out ! test/tools/javac/policy/test1/byfile.ABD.out ! test/tools/javac/policy/test1/bytodo.ABD.out ! test/tools/javac/policy/test1/simple.ABD.out Changeset: 02e6e7dd1a64 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/02e6e7dd1a64 6510286: Wording of javac error for inner classes Summary: 'inner classes cannot have static declarations' message needs to be reworked Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/InnerNamedConstant_2.out Changeset: 812c6251ea78 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/812c6251ea78 6569633: Varargs: parser error when varargs element type is an array Summary: explicit error message when old-style array syntax is mixed with varargs Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/VarargsAndOldArraySyntax.java + test/tools/javac/varargs/6569633/T6569633.java + test/tools/javac/varargs/6569633/T6569633.out Changeset: 57e3b9bc7fb8 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/57e3b9bc7fb8 7013865: varargs: javac crashes during overload resolution with generic varargs Summary: fixed regression with varargs overload resolution that leads javac to crash Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/varargs/T7013865.java Changeset: 2314f2b07ae7 Author: lana Date: 2011-01-24 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2314f2b07ae7 Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out Changeset: d7225b476a5d Author: lana Date: 2011-01-28 10:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d7225b476a5d Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out Changeset: 1383d1ee8b5d Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/1383d1ee8b5d Added tag jdk7-b128 for changeset d7225b476a5d ! .hgtags Changeset: 03e7fc380090 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/03e7fc380090 Added tag jdk7-b129 for changeset 1383d1ee8b5d ! .hgtags From john.coomes at oracle.com Thu Feb 10 20:45:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Feb 2011 04:45:00 +0000 Subject: hg: jdk7/hotspot-comp: 4 new changesets Message-ID: <20110211044500.9FE1147636@hg.openjdk.java.net> Changeset: ce02c0d73d6a Author: ohair Date: 2011-02-03 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/ce02c0d73d6a 7014634: By default, only build the product bits with a closed jdk build (like openjdk does) Reviewed-by: katleman, cl, igor, trims ! make/Defs-internal.gmk Changeset: e2a214ec8ebc Author: ohair Date: 2011-02-04 07:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/e2a214ec8ebc Merge Changeset: a6b015b59fbc Author: ohair Date: 2011-02-08 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/a6b015b59fbc 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 Reviewed-by: rinaldo ! README-builds.html Changeset: cc58c11af154 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/cc58c11af154 Added tag jdk7-b129 for changeset a6b015b59fbc ! .hgtags From vladimir.kozlov at oracle.com Thu Feb 10 21:44:39 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Feb 2011 05:44:39 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7018849: 7017124 fix broke VM build on some platforms Message-ID: <20110211054441.DAD914764D@hg.openjdk.java.net> Changeset: bf29934d2f4f Author: kvn Date: 2011-02-10 19:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bf29934d2f4f 7018849: 7017124 fix broke VM build on some platforms Summary: Use atomic load and store in inc_stat_counter() only on SPARC and X86. Reviewed-by: iveresov ! src/share/vm/memory/allocation.inline.hpp From christian.thalinger at oracle.com Fri Feb 11 01:05:05 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Feb 2011 10:05:05 +0100 Subject: Review Request: Zero fixes In-Reply-To: <4D54325F.2030309@LGonQn.Org> References: <20110210144926.GC4905@redhat.com> <4D54325F.2030309@LGonQn.Org> Message-ID: On Feb 10, 2011, at 7:45 PM, Chris Phillips wrote: > (resend, forgot to Cc list, newly setup mailer) > Hi Gary, > > Looks good to me. Hi Chris! Is this your OpenJDK username: chrisphi Chris Phillips Oracle I guess so, but I wanted to be sure so I can add you as a reviewer. -- Christian > > Chris > > On 10/02/11 09:49 AM, Gary Benson wrote: >> Hi all, >> >> 6953144, 6990754 and 7009756 made some changes which broke Zero. >> This webrev fixes: >> >> http://cr.openjdk.java.net/~gbenson/6953144-6990754-7009756-fixups/ >> >> I don't have a bug id for this. >> >> Cheers, >> Gary From ChrisPhillips at LGonQn.Org Fri Feb 11 03:45:05 2011 From: ChrisPhillips at LGonQn.Org (Chris Phillips) Date: Fri, 11 Feb 2011 06:45:05 -0500 Subject: Review Request: Zero fixes In-Reply-To: References: <20110210144926.GC4905@redhat.com> <4D54325F.2030309@LGonQn.Org> Message-ID: <4D552141.2030007@LGonQn.Org> Hi Christian, That's a bit out of date :) > chrisphi Chris Phillips Oracle Should be: chrisphi Chris Phillips Red Hat I'll change it if I figure out how to do so. Chris On 11/02/11 04:05 AM, Christian Thalinger wrote: > On Feb 10, 2011, at 7:45 PM, Chris Phillips wrote: >> (resend, forgot to Cc list, newly setup mailer) >> Hi Gary, >> >> Looks good to me. > Hi Chris! Is this your OpenJDK username: > > chrisphi Chris Phillips Oracle > > I guess so, but I wanted to be sure so I can add you as a reviewer. > > -- Christian > >> Chris >> >> On 10/02/11 09:49 AM, Gary Benson wrote: >>> Hi all, >>> >>> 6953144, 6990754 and 7009756 made some changes which broke Zero. >>> This webrev fixes: >>> >>> http://cr.openjdk.java.net/~gbenson/6953144-6990754-7009756-fixups/ >>> >>> I don't have a bug id for this. >>> >>> Cheers, >>> Gary > > > -- -- -- Woda: "Java: write once, debug anywhere" Hong Zhang http://thehenrys.ca | Chris Phillips - Resident cat slave and dubious character | | mailto:NorthernL00n at LGonQn.Org (416)483-3768 | | http://LGonQn.Org/www/Chris.Phillips cell: (416)505-3610 | "EPIC stands for Expects Perfectly Intuitive Compilers" P. Bannon http://www.hazmatmodine.com NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. "blah blah blah - Ginger!" -- From Christian.Thalinger at Sun.COM Fri Feb 11 09:21:06 2011 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 11 Feb 2011 17:21:06 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7018673: Zero: 6953144, 6990754 and 7009756 made some changes which broke Zero Message-ID: <20110211172108.BAEE747674@hg.openjdk.java.net> Changeset: 173926398291 Author: twisti Date: 2011-02-11 03:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/173926398291 7018673: Zero: 6953144, 6990754 and 7009756 made some changes which broke Zero Reviewed-by: kvn, chrisphi, twisti ! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/oops/methodOop.cpp From tom.rodriguez at oracle.com Fri Feb 11 14:08:36 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 11 Feb 2011 22:08:36 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7018506: CTW swallowing OOMs after symbol changes Message-ID: <20110211220838.5590F47682@hg.openjdk.java.net> Changeset: 34457f6ac818 Author: never Date: 2011-02-11 12:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/34457f6ac818 7018506: CTW swallowing OOMs after symbol changes Reviewed-by: kvn, iveresov, coleenp ! src/share/vm/classfile/classLoader.cpp From john.r.rose at oracle.com Sat Feb 12 00:42:23 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 12 Feb 2011 08:42:23 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 3 new changesets Message-ID: <20110212084321.B924C476B1@hg.openjdk.java.net> Changeset: d7de46ec011b Author: jrose Date: 2011-02-11 01:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d7de46ec011b 7013417: JSR 292 needs to support variadic method handle calls Summary: Implement MH.asVarargsCollector, etc., and remove withTypeHandler. Reviewed-by: twisti ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/InvokeGeneric.java ! src/share/classes/sun/dyn/Invokers.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodTypeImpl.java ! test/java/dyn/InvokeDynamicPrintArgs.java ! test/java/dyn/JavaDocExamplesTest.java ! test/java/dyn/MethodHandlesTest.java ! test/java/dyn/indify/Indify.java Changeset: c86c60ad8822 Author: jrose Date: 2011-02-11 01:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c86c60ad8822 7012650: implement JSR 292 EG adjustments through January 2010 Summary: misc. EG changes and polishes (excluding 7013417) Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/ClassValue.java ! src/share/classes/java/dyn/ConstantCallSite.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/MutableCallSite.java + src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/Switcher.java ! src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/dyn/WrongMethodTypeException.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/InvokeGeneric.java ! src/share/classes/sun/dyn/Invokers.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/ToGeneric.java + src/share/classes/sun/dyn/WrapperInstance.java ! test/java/dyn/InvokeGenericTest.java ! test/java/dyn/JavaDocExamplesTest.java ! test/java/dyn/MethodHandlesTest.java Changeset: a2241b109aa1 Author: jrose Date: 2011-02-11 01:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a2241b109aa1 7013730: JSR 292 reflective operations should report errors with standard exception types Summary: remove NoAccessException, replace it by ReflectiveOperationException subtypes; adjust javadoc of exceptions Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/MethodHandles.java - src/share/classes/java/dyn/NoAccessException.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/InvokeGeneric.java ! src/share/classes/sun/dyn/Invokers.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! test/java/dyn/InvokeGenericTest.java ! test/java/dyn/JavaDocExamplesTest.java ! test/java/dyn/MethodHandlesTest.java From john.r.rose at oracle.com Sat Feb 12 13:25:53 2011 From: john.r.rose at oracle.com (John Rose) Date: Sat, 12 Feb 2011 13:25:53 -0800 Subject: FTR: review requests on mlvm-dev Message-ID: From: John Rose Date: February 11, 2011 4:28:23 PM PST To: Da Vinci Machine Project Subject: for review (S): 7014755: JSR 292 member lookup interaction with security manager http://cr.openjdk.java.net/~jrose/7014755/webrev.00/ This review is for pushing the code change to jdk7/hotspot/hotspot/jdk/. The corresponding specification change has been reviewed by the 292 EG and via the Oracle-internal CCC. The implementation is missing; it will be supplied later under another bug. -- John From: John Rose Date: February 11, 2011 4:05:07 PM PST To: Da Vinci Machine Project Subject: review request (S): 7016520: JSR 292 rules for polymorphic signature processing must be in package-info http://cr.openjdk.java.net/~jrose/7016520/webrev.00/ This review is for pushing the code change to jdk7/hotspot/hotspot/jdk/. The corresponding specification change has been reviewed by the 292 EG and via the Oracle-internal CCC. -- John From: John Rose Date: February 11, 2011 4:02:32 PM PST To: Da Vinci Machine Project Subject: review request (S): 7016261: JSR 292 MethodType objects should be serializable http://cr.openjdk.java.net/~jrose/7016261/webrev.00/ This review is for pushing the code change to jdk7/hotspot/hotspot/jdk/. The corresponding specification change has been reviewed by the 292 EG and via the Oracle-internal CCC. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110212/6569b4d1/attachment.html From christian.thalinger at oracle.com Mon Feb 14 05:34:52 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 14 Feb 2011 13:34:52 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7018378: JSR 292: _bound_int_mh produces wrong result on 64-bit SPARC Message-ID: <20110214133456.D3CA74771F@hg.openjdk.java.net> Changeset: 28bf941f445e Author: twisti Date: 2011-02-14 03:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/28bf941f445e 7018378: JSR 292: _bound_int_mh produces wrong result on 64-bit SPARC Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp From tom.rodriguez at oracle.com Mon Feb 14 13:50:07 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Mon, 14 Feb 2011 21:50:07 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7018101: os::dll_address_to_function_name returning wrong answers in 64 bit Message-ID: <20110214215009.29E864773E@hg.openjdk.java.net> Changeset: 2a57c59eb548 Author: never Date: 2011-02-14 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2a57c59eb548 7018101: os::dll_address_to_function_name returning wrong answers in 64 bit Reviewed-by: acorn, kvn, dsamersoff ! src/os/solaris/vm/os_solaris.cpp From vladimir.kozlov at oracle.com Mon Feb 14 17:16:51 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 15 Feb 2011 01:16:51 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 31 new changesets Message-ID: <20110215011747.E75B74774B@hg.openjdk.java.net> Changeset: b7a938236e43 Author: tonyp Date: 2011-01-31 16:28 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b7a938236e43 7014679: G1: deadlock during concurrent cleanup Summary: There's a potential deadlock between the concurrent cleanup thread and the GC workers that are trying to allocate and waiting for more free regions to be made available. Reviewed-by: iveresov, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: e49cfa28f585 Author: ysr Date: 2011-02-01 10:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e49cfa28f585 6999988: CMS: Increased fragmentation leading to promotion failure after CR#6631166 got implemented Summary: Fix calculation of _desired, in free list statistics, which was missing an intended set of parentheses. Reviewed-by: poonam, jmasa ! src/share/vm/gc_implementation/shared/allocationStats.hpp Changeset: 986b2844f7a2 Author: brutisso Date: 2011-02-01 14:05 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/986b2844f7a2 6789220: CMS: intermittent timeout running nsk/regression/b4796926 Summary: The reference handler java thread and the GC could dead lock Reviewed-by: never, johnc, jcoomes ! src/share/vm/compiler/compileBroker.cpp Changeset: c33825b68624 Author: johnc Date: 2011-02-02 10:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c33825b68624 6923430: G1: assert(res != 0,"This should have worked.") 7007446: G1: expand the heap with a single step, not one region at a time Summary: Changed G1CollectedHeap::expand() to expand the committed space by calling VirtualSpace::expand_by() once rather than for every region in the expansion amount. This allows the success or failure of the expansion to be determined before creating any heap regions. Introduced a develop flag G1ExitOnExpansionFailure (false by default) that, when true, will exit the VM if the expansion of the committed space fails. Finally G1CollectedHeap::expand() returns a status back to it's caller so that the caller knows whether to attempt the allocation. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! 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/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 176d0be30214 Author: phh Date: 2011-02-03 16:06 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/176d0be30214 7016998: gcutil class LinearLeastSquareFit doesn't initialize some of its fields Summary: Initialize _sum_x_squared, _intercept and _slope in constructor. Reviewed-by: bobv, coleenp ! src/share/vm/gc_implementation/shared/gcUtil.cpp Changeset: 907c1aed0f8c Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/907c1aed0f8c Added tag jdk7-b127 for changeset 102466e70deb ! .hgtags Changeset: 9a5762f44859 Author: trims Date: 2011-02-01 18:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9a5762f44859 Merge ! .hgtags - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp Changeset: 6ecdca5709df Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6ecdca5709df Added tag jdk7-b128 for changeset 9a5762f44859 ! .hgtags Changeset: ae4b185f2ed1 Author: trims Date: 2011-02-03 23:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ae4b185f2ed1 Merge ! .hgtags - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp Changeset: c6bf3ca2bb31 Author: trims Date: 2011-02-04 16:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c6bf3ca2bb31 Merge Changeset: d70fe6ab4436 Author: coleenp Date: 2011-02-01 11:23 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d70fe6ab4436 6588413: Use -fvisibility=hidden for gcc compiles Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT to visibility=default, add for jio_snprintf and others since -fvisibility=hidden overrides --version-script definitions. Reviewed-by: kamg, never ! make/linux/makefiles/gcc.make ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/cpu/zero/vm/jni_zero.h ! src/os/linux/vm/jvm_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: b92c45f2bc75 Author: bobv Date: 2011-02-02 11:35 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b92c45f2bc75 7016023: Enable building ARM and PPC from src/closed repository Reviewed-by: dholmes, bdelsart ! make/Makefile + make/closed.make ! make/jprt.properties ! make/linux/Makefile ! make/linux/makefiles/adlc.make + make/linux/makefiles/arm.make ! make/linux/makefiles/buildtree.make + make/linux/makefiles/ppc.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make + make/linux/platform_arm + make/linux/platform_ppc ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Defs.hpp ! src/share/vm/c1/c1_FpuStackSim.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jni_md.h ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/icache.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9cd8a2c2d584 Author: bobv Date: 2011-02-02 11:54 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9cd8a2c2d584 Merge ! src/os/linux/vm/os_linux.cpp Changeset: face83fc8882 Author: coleenp Date: 2011-02-02 18:38 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/face83fc8882 7012088: jump to 0 address because of lack of memory ordering in SignatureHandlerLibrary::add Summary: Write method signature handler under lock to prevent race with growable array resizing Reviewed-by: dsamersoff, dholmes ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: bf8517f4e4d0 Author: kamg Date: 2011-02-02 14:38 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bf8517f4e4d0 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" Summary: Defer posting events from the compiler thread: use service thread Reviewed-by: coleenp, dholmes, never, dcubed - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java + agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp + src/share/vm/runtime/serviceThread.cpp + src/share/vm/runtime/serviceThread.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/management.cpp ! src/share/vm/utilities/macros.hpp Changeset: d28def44457d Author: coleenp Date: 2011-02-03 21:30 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d28def44457d 7017009: Secondary out of c-heap memory error reporting out of memory Summary: Use os::malloc() to allocate buffer to read elf symbols and check for null Reviewed-by: zgu, phh, dsamersoff, dholmes, dcubed ! src/share/vm/utilities/elfSymbolTable.cpp Changeset: 5e139f767ddb Author: coleenp Date: 2011-02-03 20:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5e139f767ddb Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: e9f24eebafd4 Author: rottenha Date: 2011-02-07 08:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e9f24eebafd4 Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: d8a72fbc4be7 Author: kamg Date: 2011-02-08 17:20 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d8a72fbc4be7 7003401: Implement VM error-reporting functionality on erroneous termination Summary: Add support for distribution-specific error reporting Reviewed-by: coleenp, phh, jcoomes, ohair ! make/Makefile + make/altsrc.make - make/closed.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/top.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/vm.make ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp + src/share/vm/utilities/errorReporter.cpp + src/share/vm/utilities/errorReporter.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/vmError.cpp Changeset: fb539912d338 Author: coleenp Date: 2011-02-07 14:36 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fb539912d338 6472925: OutOfMemoryError fails to generate stack trace as it now ought Summary: Print an additional message for OOM during stack trace printing Reviewed-by: dholmes, phh, acorn, kamg, dcubed ! src/share/vm/runtime/thread.cpp Changeset: 5fb3ee258e76 Author: coleenp Date: 2011-02-08 19:50 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5fb3ee258e76 Merge - make/closed.make Changeset: f36c9fe788b8 Author: mchung Date: 2011-02-08 09:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f36c9fe788b8 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook Reviewed-by: alanb, dcubed, coleenp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5197f3d713a1 Author: mchung Date: 2011-02-08 22:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5197f3d713a1 Merge - make/closed.make ! src/share/vm/runtime/thread.cpp Changeset: 63d374c54045 Author: ctornqvi Date: 2011-02-09 11:08 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/63d374c54045 7014918: Improve core/minidump handling in Hotspot Summary: Added Minidump support on Windows, enabled large page core dumps when coredump_filter is present and writing out path/rlimit for core dumps. Reviewed-by: poonam, dsamersoff, sla, coleenp ! src/os/linux/vm/os_linux.cpp + src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: b83527d0482d Author: ctornqvi Date: 2011-02-10 12:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b83527d0482d 7018366: hotspot/runtime_erro Fix for 7014918 does not build using MVC 2003 Summary: Looking at API_VERSION_NUMBER define to see what version of dbghelp.h/imagehlp.h is included to determine what MINIDUMP_TYPEs are defined in the header file Reviewed-by: acorn, brutisso, sla ! src/os/windows/vm/os_windows.cpp Changeset: e1523f7fd848 Author: rottenha Date: 2011-02-11 05:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e1523f7fd848 Merge - make/closed.make Changeset: 55b9f498dbce Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/55b9f498dbce Added tag jdk7-b129 for changeset ae4b185f2ed1 ! .hgtags Changeset: 14c2f31280dd Author: trims Date: 2011-02-11 14:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/14c2f31280dd Added tag hs21-b01 for changeset ae4b185f2ed1 ! .hgtags Changeset: 2a9f9f2200fa Author: trims Date: 2011-02-11 15:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2a9f9f2200fa Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: 762bc029de50 Author: trims Date: 2011-02-11 15:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/762bc029de50 7019104: Bump the HS21 build number to 02 Summary: Update the HS21 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 850b2295a494 Author: kvn Date: 2011-02-14 14:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/850b2295a494 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/vmStructs.cpp From john.r.rose at oracle.com Tue Feb 15 00:17:19 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 15 Feb 2011 08:17:19 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 3 new changesets Message-ID: <20110215081812.A15654775C@hg.openjdk.java.net> Changeset: 5e4a41d0fccd Author: jrose Date: 2011-02-15 00:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5e4a41d0fccd 7016261: JSR 292 MethodType objects should be serializable Summary: Define private writeObject, readObject, and readResolve methods. Also add unit tests. Reviewed-by: twisti ! src/share/classes/java/dyn/MethodType.java + test/java/dyn/MethodTypeTest.java Changeset: 56cbd0504a53 Author: jrose Date: 2011-02-15 00:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/56cbd0504a53 7014755: JSR 292 member lookup interaction with security manager Summary: add security manager interactions for Lookup methods Reviewed-by: twisti ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/package-info.java Changeset: 52bcd47b4521 Author: jrose Date: 2011-02-15 00:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/52bcd47b4521 7016520: JSR 292 rules for polymorphic signature processing must be in package-info Summary: insert rules for bytecode processors to recognize signature polymorphic names Reviewed-by: twisti ! src/share/classes/java/dyn/MethodHandle.java From tom.rodriguez at oracle.com Tue Feb 15 15:50:16 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 15 Feb 2011 15:50:16 -0800 Subject: review (XS) for 7019819: bare oop in ciField Message-ID: <52AD392A-FB62-4ABF-9126-B57D0202BC70@oracle.com> http://cr.openjdk.java.net/~never/7019819 7019819: bare oop in ciField Reviewed-by: This appears to be a long standing issue though it was previously unlikely to occur. There's a bare oop in initialize_from over a call to ciField::type which may call compute_type, which make call into ciEnv::get_klass_by_name_impl where a safepoint could potentially occur. The fix for 6354181 added acquire of the Compile_lock which made it more likely that we might safepoint here. The fix is properly handleize the oop over the call. Tested with failing test from nightly. From vladimir.kozlov at oracle.com Tue Feb 15 16:49:59 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Feb 2011 16:49:59 -0800 Subject: review (XS) for 7019819: bare oop in ciField In-Reply-To: <52AD392A-FB62-4ABF-9126-B57D0202BC70@oracle.com> References: <52AD392A-FB62-4ABF-9126-B57D0202BC70@oracle.com> Message-ID: <4D5B1F37.1040905@oracle.com> Should we use KlassHandle instead of simple Handle? Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7019819 > > 7019819: bare oop in ciField > Reviewed-by: > > This appears to be a long standing issue though it was previously > unlikely to occur. There's a bare oop in initialize_from over a call > to ciField::type which may call compute_type, which make call into > ciEnv::get_klass_by_name_impl where a safepoint could potentially > occur. The fix for 6354181 added acquire of the Compile_lock which > made it more likely that we might safepoint here. The fix is properly > handleize the oop over the call. Tested with failing test from nightly. From vladimir.kozlov at oracle.com Tue Feb 15 17:01:31 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Feb 2011 17:01:31 -0800 Subject: review (XS) for 7019819: bare oop in ciField In-Reply-To: <4D5B1F37.1040905@oracle.com> References: <52AD392A-FB62-4ABF-9126-B57D0202BC70@oracle.com> <4D5B1F37.1040905@oracle.com> Message-ID: <4D5B21EB.1030601@oracle.com> Talked with Tom, should use Handle here so changes are fine. Vladimir Vladimir Kozlov wrote: > Should we use KlassHandle instead of simple Handle? > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7019819 >> >> 7019819: bare oop in ciField >> Reviewed-by: >> >> This appears to be a long standing issue though it was previously >> unlikely to occur. There's a bare oop in initialize_from over a call >> to ciField::type which may call compute_type, which make call into >> ciEnv::get_klass_by_name_impl where a safepoint could potentially >> occur. The fix for 6354181 added acquire of the Compile_lock which >> made it more likely that we might safepoint here. The fix is properly >> handleize the oop over the call. Tested with failing test from nightly. From tom.rodriguez at oracle.com Tue Feb 15 19:34:49 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 15 Feb 2011 19:34:49 -0800 Subject: review (XS) for 7019819: bare oop in ciField In-Reply-To: <4D5B21EB.1030601@oracle.com> References: <52AD392A-FB62-4ABF-9126-B57D0202BC70@oracle.com> <4D5B1F37.1040905@oracle.com> <4D5B21EB.1030601@oracle.com> Message-ID: <74ED5B71-D924-4AE1-A0C0-93199B7AF363@oracle.com> Thanks! tom On Feb 15, 2011, at 5:01 PM, Vladimir Kozlov wrote: > Talked with Tom, should use Handle here so changes are fine. > > Vladimir > > Vladimir Kozlov wrote: >> Should we use KlassHandle instead of simple Handle? >> Vladimir >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7019819 >>> >>> 7019819: bare oop in ciField >>> Reviewed-by: >>> >>> This appears to be a long standing issue though it was previously >>> unlikely to occur. There's a bare oop in initialize_from over a call >>> to ciField::type which may call compute_type, which make call into >>> ciEnv::get_klass_by_name_impl where a safepoint could potentially >>> occur. The fix for 6354181 added acquire of the Compile_lock which >>> made it more likely that we might safepoint here. The fix is properly >>> handleize the oop over the call. Tested with failing test from nightly. From igor.veresov at oracle.com Tue Feb 15 20:31:51 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 15 Feb 2011 20:31:51 -0800 Subject: review (XS) for 7019819: bare oop in ciField In-Reply-To: <52AD392A-FB62-4ABF-9126-B57D0202BC70@oracle.com> References: <52AD392A-FB62-4ABF-9126-B57D0202BC70@oracle.com> Message-ID: <4D5B5337.8000306@oracle.com> Looks good, year in the header needs fixing. igor On 2/15/11 3:50 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7019819 > > 7019819: bare oop in ciField > Reviewed-by: > > This appears to be a long standing issue though it was previously > unlikely to occur. There's a bare oop in initialize_from over a call > to ciField::type which may call compute_type, which make call into > ciEnv::get_klass_by_name_impl where a safepoint could potentially > occur. The fix for 6354181 added acquire of the Compile_lock which > made it more likely that we might safepoint here. The fix is properly > handleize the oop over the call. Tested with failing test from nightly. From tom.rodriguez at oracle.com Wed Feb 16 00:59:51 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 16 Feb 2011 08:59:51 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7019819: bare oop in ciField Message-ID: <20110216085955.436F5477B0@hg.openjdk.java.net> Changeset: 1957c1478794 Author: never Date: 2011-02-15 22:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1957c1478794 7019819: bare oop in ciField Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciField.cpp From tom.rodriguez at oracle.com Sat Feb 19 00:08:09 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 19 Feb 2011 08:08:09 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7016474: string compare intrinsic improvements Message-ID: <20110219080811.D0BDA478A8@hg.openjdk.java.net> Changeset: 6bbaedb03534 Author: never Date: 2011-02-09 15:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6bbaedb03534 7016474: string compare intrinsic improvements Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad From christian.thalinger at oracle.com Mon Feb 21 09:15:26 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 21 Feb 2011 18:15:26 +0100 Subject: Request for reviews (L): 7012914: JSR 292 MethodHandlesTest C1: frame::verify_return_pc(return_address) failed: must be a return pc Message-ID: <0F3C7F7F-3390-49C1-8724-230596BA77DB@oracle.com> http://cr.openjdk.java.net/~twisti/7012914/webrev.01/ 7012914: JSR 292 MethodHandlesTest C1: frame::verify_return_pc(return_address) failed: must be a return pc Reviewed-by: The changes of 7007377 changed the way MethodHandlesImpl.raiseException is called from the raise_exception method handle adapter as it calls the C2I adapter. Since MethodHandlesImpl.raiseException has three arguments, on 32-bit x86 we need to pass one argument on the stack. This additional word on the stack needs to be removed when we return to the actual callee during unwinding. Since the call site that triggers the exception is a method handle call site we just need to restore the saved SP from BP. Right now this is only a problem on 32-bit x86 because of the way we implement the raise_exception method handle adapter. But I assume it's not impossible that in the future there are stack manipulations before we throw an exception. So a fix for all architectures seems reasonable. This change removes some unused code in StubGenerator::generate_forward_exception as this stub is only used for runtime calls with a pending exception and runtime calls can't be method handle call sites. It also removes the unused ExceptionCache::_unwind_handler. Additionally there is a small cleanup of SharedRuntime::raw_exception_handler_for_return_address to not call CodeCache::find_blob twice. From tom.rodriguez at oracle.com Mon Feb 21 11:05:07 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 21 Feb 2011 11:05:07 -0800 Subject: Request for reviews (L): 7012914: JSR 292 MethodHandlesTest C1: frame::verify_return_pc(return_address) failed: must be a return pc In-Reply-To: <0F3C7F7F-3390-49C1-8724-230596BA77DB@oracle.com> References: <0F3C7F7F-3390-49C1-8724-230596BA77DB@oracle.com> Message-ID: <74EA707F-0EEA-4CE5-AD9D-40B77A036A35@oracle.com> On Feb 21, 2011, at 9:15 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7012914/webrev.01/ > > 7012914: JSR 292 MethodHandlesTest C1: frame::verify_return_pc(return_address) failed: must be a return pc > Reviewed-by: > > The changes of 7007377 changed the way > MethodHandlesImpl.raiseException is called from the raise_exception > method handle adapter as it calls the C2I adapter. Since > MethodHandlesImpl.raiseException has three arguments, on 32-bit x86 we > need to pass one argument on the stack. This additional word on the > stack needs to be removed when we return to the actual callee during > unwinding. > > Since the call site that triggers the exception is a method handle > call site we just need to restore the saved SP from BP. > > Right now this is only a problem on 32-bit x86 because of the way we > implement the raise_exception method handle adapter. But I assume > it's not impossible that in the future there are stack manipulations > before we throw an exception. So a fix for all architectures seems > reasonable. > > This change removes some unused code in > StubGenerator::generate_forward_exception as this stub is only used > for runtime calls with a pending exception and runtime calls can't be > method handle call sites. It also removes the unused > ExceptionCache::_unwind_handler. > > Additionally there is a small cleanup of > SharedRuntime::raw_exception_handler_for_return_address to not call > CodeCache::find_blob twice. Isn't the second call unreachable? If nm != null then we will already have returned. So can't the whole block be replaced with: guarantee(blob == NULL || !blob->is_runtime_stub(), "caller should have skipped stub"); Otherwise it looks fine. tom From tom.rodriguez at oracle.com Mon Feb 21 14:23:29 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 21 Feb 2011 14:23:29 -0800 Subject: ttyLocker and other locks Message-ID: <319A3E72-5C01-49AA-B6E0-8AEBAC7F2BED@oracle.com> This is going to be a little long. In the recent fix for 6354181, I added a lock of Compile_lock in the ciEnv when we call into the SystemDictionary for lookup. It wasn't strictly required but it seemed like from reading the code that it would be advisable to hold it when querying the SystemDictionary. Unfortunately this appears to cause some lock ordering problems when printing. In particular we use a ttyLocker when we do PrintIdeal or PrintOptoAssembly and some of the printing logic looks up ciFields which may require calling into the SystemDictionary. In particular MachNode::adr_type() may look up the field to figure out whether an oop field is compressed or not. ciInstanceKlass caches the ciFields for instance fields for some lookups but not for statics. I believe this is because the logic for creating shared ciInstanceKlasses wants to avoid caching the _constant_value for static fields when compiling during bootstrap. I tried modifying the CI to always cache the ciField so that ciFields were always created before we were holding the ttyLock but I couldn't resolve the shared ciField issue in a simple way. The init_state of the shared instances may change during compilation which means that the ciField for a static final could become constant along the way and I don't see an easy way to maintain the fiction. I actually think we're exposed to an issue here the shared instances can report changing information during a compile. The partial rewrite I did to completely cache ciField is at http://cr.openjdk.java.net/~never/cik in case you want to see it. Anyway, I'm out of good ideas to fix this other than removing the ttyLocker. I actually think the ttyLocker itself is the problem. It really only exists to encourage our output to be emitted more nicely than we get without it. PrintOptoAssembly in particular produces fairly horrid interleaving when running with multiple compilers. Narrowing the lock to just a single dump call doesn't help since the Compile_lock is acquired inside the dump call. Vladimir suggested having a ttyUnlocker like construct that we could place before the lock of Compile_lock to release the lock if it was held and then reacquire it. That's fairly ugly but I'm all out of pretty I think. tom From vladimir.kozlov at oracle.com Mon Feb 21 15:33:17 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Feb 2011 15:33:17 -0800 Subject: ttyLocker and other locks In-Reply-To: <319A3E72-5C01-49AA-B6E0-8AEBAC7F2BED@oracle.com> References: <319A3E72-5C01-49AA-B6E0-8AEBAC7F2BED@oracle.com> Message-ID: <4D62F63D.1060502@oracle.com> Tom, I like your cache ciField changes and I wish we can apply it. One problem I found: ciInstanceKlass::compute_fields() returns 0 and don't cache static fields if there are no nonstatic fields. Can we throw out the compilation if static final fields state changed at the end of compilation as we do for jvmti? Yes, we have to keep the list of such fields to verify at the end of compilation. Thanks, Vladimir Tom Rodriguez wrote: > This is going to be a little long. In the recent fix for 6354181, I added a lock of Compile_lock in the ciEnv when we call into the SystemDictionary for lookup. It wasn't strictly required but it seemed like from reading the code that it would be advisable to hold it when querying the SystemDictionary. Unfortunately this appears to cause some lock ordering problems when printing. In particular we use a ttyLocker when we do PrintIdeal or PrintOptoAssembly and some of the printing logic looks up ciFields which may require calling into the SystemDictionary. In particular MachNode::adr_type() may look up the field to figure out whether an oop field is compressed or not. ciInstanceKlass caches the ciFields for instance fields for some lookups but not for statics. I believe this is because the logic for creating shared ciInstanceKlasses wants to avoid caching the _constant_value for static fields when compiling during bootstrap. I tried modifying the CI to always cache th e ciField so that ciFields were always created before we were holding the ttyLock but I couldn't resolve the shared ciField issue in a simple way. The init_state of the shared instances may change during compilation which means that the ciField for a static final could become constant along the way and I don't see an easy way to maintain the fiction. I actually think we're exposed to an issue here the shared instances can report changing information during a compile. The partial rewrite I did to completely cache ciField is at http://cr.openjdk.java.net/~never/cik in case you want to see it. > > Anyway, I'm out of good ideas to fix this other than removing the ttyLocker. I actually think the ttyLocker itself is the problem. It really only exists to encourage our output to be emitted more nicely than we get without it. PrintOptoAssembly in particular produces fairly horrid interleaving when running with multiple compilers. Narrowing the lock to just a single dump call doesn't help since the Compile_lock is acquired inside the dump call. Vladimir suggested having a ttyUnlocker like construct that we could place before the lock of Compile_lock to release the lock if it was held and then reacquire it. That's fairly ugly but I'm all out of pretty I think. > > tom From tom.rodriguez at oracle.com Mon Feb 21 16:45:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 21 Feb 2011 16:45:23 -0800 Subject: ttyLocker and other locks In-Reply-To: <4D62F63D.1060502@oracle.com> References: <319A3E72-5C01-49AA-B6E0-8AEBAC7F2BED@oracle.com> <4D62F63D.1060502@oracle.com> Message-ID: <950B40C8-D471-4813-B90D-24726C75A7E1@oracle.com> On Feb 21, 2011, at 3:33 PM, Vladimir Kozlov wrote: > Tom, > > I like your cache ciField changes and I wish we can apply it. One problem I found: ciInstanceKlass::compute_fields() returns 0 and don't cache static fields if there are no nonstatic fields. Yes, it's mildly broken right now because I wasn't able to solve the shared ciField issue. > > Can we throw out the compilation if static final fields state changed at the end of compilation as we do for jvmti? Yes, we have to keep the list of such fields to verify at the end of compilation. I think if we can keep track of them to detect when they've changed then we can track them to make it work correctly. I was thinking that the shared instances need to have some side state that is maintained on a per ciEnv basis so that for the lifetime of a compile we can return stable answers. Once a shared instance reaches the fully_initialized state we can switch to using the stable shared state. It's kind of complicated though. Maybe the ciFields should just be tracked by ciEnv itself instead of maintaining the cache in the ciInstanceKlass. ciFields are kind of an oddity right now since they aren't maintained in a central fashion the way that other ciObjects are. I'm going to see what that would look like. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> This is going to be a little long. In the recent fix for 6354181, I added a lock of Compile_lock in the ciEnv when we call into the SystemDictionary for lookup. It wasn't strictly required but it seemed like from reading the code that it would be advisable to hold it when querying the SystemDictionary. Unfortunately this appears to cause some lock ordering problems when printing. In particular we use a ttyLocker when we do PrintIdeal or PrintOptoAssembly and some of the printing logic looks up ciFields which may require calling into the SystemDictionary. In particular MachNode::adr_type() may look up the field to figure out whether an oop field is compressed or not. ciInstanceKlass caches the ciFields for instance fields for some lookups but not for statics. I believe this is because the logic for creating shared ciInstanceKlasses wants to avoid caching the _constant_value for static fields when compiling during bootstrap. I tried modifying the CI to always cache th > e ciField so that ciFields were always created before we were holding the ttyLock but I couldn't resolve the shared ciField issue in a simple way. The init_state of the shared instances may change during compilation which means that the ciField for a static final could become constant along the way and I don't see an easy way to maintain the fiction. I actually think we're exposed to an issue here the shared instances can report changing information during a compile. The partial rewrite I did to completely cache ciField is at http://cr.openjdk.java.net/~never/cik in case you want to see it. >> Anyway, I'm out of good ideas to fix this other than removing the ttyLocker. I actually think the ttyLocker itself is the problem. It really only exists to encourage our output to be emitted more nicely than we get without it. PrintOptoAssembly in particular produces fairly horrid interleaving when running with multiple compilers. Narrowing the lock to just a single dump call doesn't help since the Compile_lock is acquired inside the dump call. Vladimir suggested having a ttyUnlocker like construct that we could place before the lock of Compile_lock to release the lock if it was held and then reacquire it. That's fairly ugly but I'm all out of pretty I think. >> tom From john.r.rose at oracle.com Mon Feb 21 18:48:13 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 21 Feb 2011 18:48:13 -0800 Subject: ttyLocker and other locks In-Reply-To: <319A3E72-5C01-49AA-B6E0-8AEBAC7F2BED@oracle.com> References: <319A3E72-5C01-49AA-B6E0-8AEBAC7F2BED@oracle.com> Message-ID: On Feb 21, 2011, at 2:23 PM, Tom Rodriguez wrote: > Anyway, I'm out of good ideas to fix this other than removing the ttyLocker. I actually think the ttyLocker itself is the problem. It really only exists to encourage our output to be emitted more nicely than we get without it. PrintOptoAssembly in particular produces fairly horrid interleaving when running with multiple compilers. Narrowing the lock to just a single dump call doesn't help since the Compile_lock is acquired inside the dump call. Vladimir suggested having a ttyUnlocker like construct that we could place before the lock of Compile_lock to release the lock if it was held and then reacquire it. That's fairly ugly but I'm all out of pretty I think. The ttyUnlocker is a good idea. Here's why: ttyLocker not only encourages the system to keep related output together, but it also inserts (into the hotspot.log) markup which shows which threads are emitting which output, when output is interleaved. Not only will ttyUnlocker limit the interleaving of output from multiple threads, but it will also cause the interleaving to be properly marked. -- John From igor.veresov at oracle.com Tue Feb 22 11:57:23 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Feb 2011 11:57:23 -0800 Subject: Request for review(M): 7020521: arraycopy stubs place prebarriers incorrectly Message-ID: <4D641523.3020700@oracle.com> I rearranged the pre-barrier placement in arraycopy stubs so that they are properly called in case of chained calls. Also refactored the code a little bit so that it looks uniform across the platforms and is more readable. Webrev: http://cr.openjdk.java.net/~iveresov/7020521/webrev.00 Thanks, igor From paul.hohensee at oracle.com Tue Feb 22 12:02:39 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 22 Feb 2011 15:02:39 -0500 Subject: Request for review(M): 7020521: arraycopy stubs place prebarriers incorrectly In-Reply-To: <4D641523.3020700@oracle.com> References: <4D641523.3020700@oracle.com> Message-ID: <4D64165F.9000403@oracle.com> ARM and PPC guys should know about this. Paul On 2/22/11 2:57 PM, Igor Veresov wrote: > I rearranged the pre-barrier placement in arraycopy stubs so that they > are properly called in case of chained calls. Also refactored the code > a little bit so that it looks uniform across the platforms and is more > readable. > > Webrev: http://cr.openjdk.java.net/~iveresov/7020521/webrev.00 > > Thanks, > igor From paul.hohensee at oracle.com Tue Feb 22 12:02:39 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 22 Feb 2011 15:02:39 -0500 Subject: Request for review(M): 7020521: arraycopy stubs place prebarriers incorrectly In-Reply-To: <4D641523.3020700@oracle.com> References: <4D641523.3020700@oracle.com> Message-ID: <4D64165F.9000403@oracle.com> ARM and PPC guys should know about this. Paul On 2/22/11 2:57 PM, Igor Veresov wrote: > I rearranged the pre-barrier placement in arraycopy stubs so that they > are properly called in case of chained calls. Also refactored the code > a little bit so that it looks uniform across the platforms and is more > readable. > > Webrev: http://cr.openjdk.java.net/~iveresov/7020521/webrev.00 > > Thanks, > igor From tom.rodriguez at oracle.com Tue Feb 22 12:59:38 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 22 Feb 2011 12:59:38 -0800 Subject: ttyLocker and other locks In-Reply-To: References: <319A3E72-5C01-49AA-B6E0-8AEBAC7F2BED@oracle.com> Message-ID: <051CB0F7-E49D-4D58-880D-DF19D03A2BA7@oracle.com> Resending, again ... On Feb 21, 2011, at 6:48 PM, John Rose wrote: > On Feb 21, 2011, at 2:23 PM, Tom Rodriguez wrote: > >> Anyway, I'm out of good ideas to fix this other than removing the ttyLocker. I actually think the ttyLocker itself is the problem. It really only exists to encourage our output to be emitted more nicely than we get without it. PrintOptoAssembly in particular produces fairly horrid interleaving when running with multiple compilers. Narrowing the lock to just a single dump call doesn't help since the Compile_lock is acquired inside the dump call. Vladimir suggested having a ttyUnlocker like construct that we could place before the lock of Compile_lock to release the lock if it was held and then reacquire it. That's fairly ugly but I'm all out of pretty I think. > > The ttyUnlocker is a good idea. Here's why: ttyLocker not only encourages the system to keep related output together, but it also inserts (into the hotspot.log) markup which shows which threads are emitting which output, when output is interleaved. Not only will ttyUnlocker limit the interleaving of output from multiple threads, but it will also cause the interleaving to be properly marked. It feels like a hack but it's the only way to resolve this in a simple way. I don't think it would be easy to make the CI always cache the types in a way which would avoid lookup in this case. The shared information in the CI has to form a closed graph and adding in all the types of the fields seems likely to expand the number of things we share in an unknown fashion. Anyway, here's the review of that fix. http://cr.openjdk.java.net/~never/7021531 7021531: lock ordering problems after fix for 6354181 Reviewed-by: After the fix for 6354181 we may acquire the Compile_lock while printing and we may be holding the tty lock. In general there isn't an easy way to avoid acquiring this lock during printing so the fix I've ended up with a conditional ttyUnlocker that releases the lock when we acquire the Compile_lock. I didn't modify the others since they don't currently seems problematic. Tested with PrintOptoAssembly on 64 bit that originally showed the problem. tom > > -- John From tom.rodriguez at oracle.com Tue Feb 22 13:02:17 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 22 Feb 2011 13:02:17 -0800 Subject: Request for review(M): 7020521: arraycopy stubs place prebarriers incorrectly In-Reply-To: <4D641523.3020700@oracle.com> References: <4D641523.3020700@oracle.com> Message-ID: On Feb 22, 2011, at 11:57 AM, Igor Veresov wrote: > I rearranged the pre-barrier placement in arraycopy stubs so that they are properly called in case of chained calls. Also refactored the code a little bit so that it looks uniform across the platforms and is more readable. > > Webrev: http://cr.openjdk.java.net/~iveresov/7020521/webrev.00 So the fix part of this is moving the gen_write_ref_array_pre_barrier to after the external entry point instead of before it? If so then I understand it and the rest looks fine. tom > > Thanks, > igor From vladimir.kozlov at oracle.com Tue Feb 22 14:14:32 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Feb 2011 14:14:32 -0800 Subject: ttyLocker and other locks In-Reply-To: <051CB0F7-E49D-4D58-880D-DF19D03A2BA7@oracle.com> References: <319A3E72-5C01-49AA-B6E0-8AEBAC7F2BED@oracle.com> <051CB0F7-E49D-4D58-880D-DF19D03A2BA7@oracle.com> Message-ID: <4D643548.6030409@oracle.com> Looks good. Thanks, Vladimir Tom Rodriguez wrote: > Resending, again ... > > On Feb 21, 2011, at 6:48 PM, John Rose wrote: > >> On Feb 21, 2011, at 2:23 PM, Tom Rodriguez wrote: >> >>> Anyway, I'm out of good ideas to fix this other than removing the ttyLocker. I actually think the ttyLocker itself is the problem. It really only exists to encourage our output to be emitted more nicely than we get without it. PrintOptoAssembly in particular produces fairly horrid interleaving when running with multiple compilers. Narrowing the lock to just a single dump call doesn't help since the Compile_lock is acquired inside the dump call. Vladimir suggested having a ttyUnlocker like construct that we could place before the lock of Compile_lock to release the lock if it was held and then reacquire it. That's fairly ugly but I'm all out of pretty I think. >> The ttyUnlocker is a good idea. Here's why: ttyLocker not only encourages the system to keep related output together, but it also inserts (into the hotspot.log) markup which shows which threads are emitting which output, when output is interleaved. Not only will ttyUnlocker limit the interleaving of output from multiple threads, but it will also cause the interleaving to be properly marked. > > It feels like a hack but it's the only way to resolve this in a simple way. I don't think it would be easy to make the CI always cache the types in a way which would avoid lookup in this case. The shared information in the CI has to form a closed graph and adding in all the types of the fields seems likely to expand the number of things we share in an unknown fashion. > > Anyway, here's the review of that fix. > > http://cr.openjdk.java.net/~never/7021531 > > 7021531: lock ordering problems after fix for 6354181 > Reviewed-by: > > After the fix for 6354181 we may acquire the Compile_lock while > printing and we may be holding the tty lock. In general there isn't > an easy way to avoid acquiring this lock during printing so the fix > I've ended up with a conditional ttyUnlocker that releases the lock > when we acquire the Compile_lock. I didn't modify the others since > they don't currently seems problematic. Tested with PrintOptoAssembly > on 64 bit that originally showed the problem. > > tom > >> -- John > From igor.veresov at oracle.com Tue Feb 22 14:23:52 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Feb 2011 14:23:52 -0800 Subject: Request for review(M): 7020521: arraycopy stubs place prebarriers incorrectly In-Reply-To: References: <4D641523.3020700@oracle.com> Message-ID: <4D643778.2080708@oracle.com> On 2/22/11 1:02 PM, Tom Rodriguez wrote: > > On Feb 22, 2011, at 11:57 AM, Igor Veresov wrote: > >> I rearranged the pre-barrier placement in arraycopy stubs so that they are properly called in case of chained calls. Also refactored the code a little bit so that it looks uniform across the platforms and is more readable. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7020521/webrev.00 > > So the fix part of this is moving the gen_write_ref_array_pre_barrier to after the external entry point instead of before it? If so then I understand it and the rest looks fine. > That's right. It's after the entry point in all the cases and also after the dispatching happens. So only the actual method that does the copying executes a prebarrier. igor > tom > >> >> Thanks, >> igor > From john.r.rose at oracle.com Tue Feb 22 14:24:23 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 22 Feb 2011 14:24:23 -0800 Subject: ttyLocker and other locks In-Reply-To: <4D643548.6030409@oracle.com> References: <319A3E72-5C01-49AA-B6E0-8AEBAC7F2BED@oracle.com> <051CB0F7-E49D-4D58-880D-DF19D03A2BA7@oracle.com> <4D643548.6030409@oracle.com> Message-ID: <6825F96E-00F5-4593-9DA4-C998034C0697@oracle.com> Yes, it's good. Thanks. -- John On Feb 22, 2011, at 2:14 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> Resending, again ... >> On Feb 21, 2011, at 6:48 PM, John Rose wrote: >>> On Feb 21, 2011, at 2:23 PM, Tom Rodriguez wrote: >>> >>>> Anyway, I'm out of good ideas to fix this other than removing the ttyLocker. I actually think the ttyLocker itself is the problem. It really only exists to encourage our output to be emitted more nicely than we get without it. PrintOptoAssembly in particular produces fairly horrid interleaving when running with multiple compilers. Narrowing the lock to just a single dump call doesn't help since the Compile_lock is acquired inside the dump call. Vladimir suggested having a ttyUnlocker like construct that we could place before the lock of Compile_lock to release the lock if it was held and then reacquire it. That's fairly ugly but I'm all out of pretty I think. >>> The ttyUnlocker is a good idea. Here's why: ttyLocker not only encourages the system to keep related output together, but it also inserts (into the hotspot.log) markup which shows which threads are emitting which output, when output is interleaved. Not only will ttyUnlocker limit the interleaving of output from multiple threads, but it will also cause the interleaving to be properly marked. >> It feels like a hack but it's the only way to resolve this in a simple way. I don't think it would be easy to make the CI always cache the types in a way which would avoid lookup in this case. The shared information in the CI has to form a closed graph and adding in all the types of the fields seems likely to expand the number of things we share in an unknown fashion. >> Anyway, here's the review of that fix. >> http://cr.openjdk.java.net/~never/7021531 >> 7021531: lock ordering problems after fix for 6354181 >> Reviewed-by: >> After the fix for 6354181 we may acquire the Compile_lock while >> printing and we may be holding the tty lock. In general there isn't >> an easy way to avoid acquiring this lock during printing so the fix >> I've ended up with a conditional ttyUnlocker that releases the lock >> when we acquire the Compile_lock. I didn't modify the others since >> they don't currently seems problematic. Tested with PrintOptoAssembly >> on 64 bit that originally showed the problem. >> tom >>> -- John From vladimir.kozlov at oracle.com Tue Feb 22 14:41:08 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Feb 2011 14:41:08 -0800 Subject: Request for review(M): 7020521: arraycopy stubs place prebarriers incorrectly In-Reply-To: <4D641523.3020700@oracle.com> References: <4D641523.3020700@oracle.com> Message-ID: <4D643B84.4020407@oracle.com> Looks good. Thank you for cleaning it up. Vladimir Igor Veresov wrote: > I rearranged the pre-barrier placement in arraycopy stubs so that they > are properly called in case of chained calls. Also refactored the code a > little bit so that it looks uniform across the platforms and is more > readable. > > Webrev: http://cr.openjdk.java.net/~iveresov/7020521/webrev.00 > > Thanks, > igor From igor.veresov at oracle.com Tue Feb 22 14:53:53 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Feb 2011 14:53:53 -0800 Subject: Request for review(M): 7020521: arraycopy stubs place prebarriers incorrectly In-Reply-To: <4D643B84.4020407@oracle.com> References: <4D641523.3020700@oracle.com> <4D643B84.4020407@oracle.com> Message-ID: <4D643E81.2050103@oracle.com> Thanks, Tom and Vladimir! igor On 2/22/11 2:41 PM, Vladimir Kozlov wrote: > Looks good. Thank you for cleaning it up. > > Vladimir > > Igor Veresov wrote: >> I rearranged the pre-barrier placement in arraycopy stubs so that they >> are properly called in case of chained calls. Also refactored the code >> a little bit so that it looks uniform across the platforms and is more >> readable. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7020521/webrev.00 >> >> Thanks, >> igor From tom.rodriguez at oracle.com Tue Feb 22 15:19:38 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 22 Feb 2011 15:19:38 -0800 Subject: ttyLocker and other locks In-Reply-To: <6825F96E-00F5-4593-9DA4-C998034C0697@oracle.com> References: <319A3E72-5C01-49AA-B6E0-8AEBAC7F2BED@oracle.com> <051CB0F7-E49D-4D58-880D-DF19D03A2BA7@oracle.com> <4D643548.6030409@oracle.com> <6825F96E-00F5-4593-9DA4-C998034C0697@oracle.com> Message-ID: <8F1E2A93-BAC1-4ECA-B581-4F6AB26755F0@oracle.com> thanks john and vladimir. tom On Feb 22, 2011, at 2:24 PM, John Rose wrote: > Yes, it's good. Thanks. -- John > > On Feb 22, 2011, at 2:14 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> Resending, again ... >>> On Feb 21, 2011, at 6:48 PM, John Rose wrote: >>>> On Feb 21, 2011, at 2:23 PM, Tom Rodriguez wrote: >>>> >>>>> Anyway, I'm out of good ideas to fix this other than removing the ttyLocker. I actually think the ttyLocker itself is the problem. It really only exists to encourage our output to be emitted more nicely than we get without it. PrintOptoAssembly in particular produces fairly horrid interleaving when running with multiple compilers. Narrowing the lock to just a single dump call doesn't help since the Compile_lock is acquired inside the dump call. Vladimir suggested having a ttyUnlocker like construct that we could place before the lock of Compile_lock to release the lock if it was held and then reacquire it. That's fairly ugly but I'm all out of pretty I think. >>>> The ttyUnlocker is a good idea. Here's why: ttyLocker not only encourages the system to keep related output together, but it also inserts (into the hotspot.log) markup which shows which threads are emitting which output, when output is interleaved. Not only will ttyUnlocker limit the interleaving of output from multiple threads, but it will also cause the interleaving to be properly marked. >>> It feels like a hack but it's the only way to resolve this in a simple way. I don't think it would be easy to make the CI always cache the types in a way which would avoid lookup in this case. The shared information in the CI has to form a closed graph and adding in all the types of the fields seems likely to expand the number of things we share in an unknown fashion. >>> Anyway, here's the review of that fix. >>> http://cr.openjdk.java.net/~never/7021531 >>> 7021531: lock ordering problems after fix for 6354181 >>> Reviewed-by: >>> After the fix for 6354181 we may acquire the Compile_lock while >>> printing and we may be holding the tty lock. In general there isn't >>> an easy way to avoid acquiring this lock during printing so the fix >>> I've ended up with a conditional ttyUnlocker that releases the lock >>> when we acquire the Compile_lock. I didn't modify the others since >>> they don't currently seems problematic. Tested with PrintOptoAssembly >>> on 64 bit that originally showed the problem. >>> tom >>>> -- John > From tom.rodriguez at oracle.com Tue Feb 22 18:14:42 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 22 Feb 2011 18:14:42 -0800 Subject: review (S) for 7021603: crash in fill_sync_handler with ExtendedDTrace probes Message-ID: <5788F9CB-22BF-4716-A358-B8DB16A9FFBC@oracle.com> http://cr.openjdk.java.net/~never/7021603 7021603: crash in fill_sync_handler with ExtendedDTrace probes Reviewed-by: The changes for 6809483 added some callouts to notify dtrace for inlined methods. In fill_sync_handler it's using the regular append call which expects there to be a ciBytecodeStream to get the current bci from but in the fill_sync_handler there is no stream so it crashes. The code should be use append_with_bci like the other existing code there. Tested with failing tests. From igor.veresov at oracle.com Tue Feb 22 18:32:05 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Feb 2011 18:32:05 -0800 Subject: review (S) for 7021603: crash in fill_sync_handler with ExtendedDTrace probes In-Reply-To: <5788F9CB-22BF-4716-A358-B8DB16A9FFBC@oracle.com> References: <5788F9CB-22BF-4716-A358-B8DB16A9FFBC@oracle.com> Message-ID: <4D6471A5.8040009@oracle.com> Looks good! igor On 2/22/11 6:14 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7021603 > > 7021603: crash in fill_sync_handler with ExtendedDTrace probes > Reviewed-by: > > The changes for 6809483 added some callouts to notify dtrace for > inlined methods. In fill_sync_handler it's using the regular append > call which expects there to be a ciBytecodeStream to get the current > bci from but in the fill_sync_handler there is no stream so it > crashes. The code should be use append_with_bci like the other > existing code there. Tested with failing tests. From tom.rodriguez at oracle.com Tue Feb 22 18:10:11 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 23 Feb 2011 02:10:11 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7021531: lock ordering problems after fix for 6354181 Message-ID: <20110223021016.6EF284798F@hg.openjdk.java.net> Changeset: 5841dc1964f0 Author: never Date: 2011-02-22 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5841dc1964f0 7021531: lock ordering problems after fix for 6354181 Reviewed-by: kvn, jrose ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp From igor.veresov at oracle.com Tue Feb 22 20:42:57 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 23 Feb 2011 04:42:57 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110223044305.A99FF47996@hg.openjdk.java.net> Changeset: d89a22843c62 Author: iveresov Date: 2011-02-22 15:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d89a22843c62 7020521: arraycopy stubs place prebarriers incorrectly Summary: Rearranged the pre-barrier placement in arraycopy stubs so that they are properly called in case of chained calls. Also refactored the code a little bit so that it looks uniform across the platforms and is more readable. Reviewed-by: never, kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: d5a078cf7f39 Author: iveresov Date: 2011-02-22 18:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d5a078cf7f39 Merge From bertrand.delsart at oracle.com Wed Feb 23 02:25:05 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 23 Feb 2011 11:25:05 +0100 Subject: Request for review(M): 7020521: arraycopy stubs place prebarriers incorrectly In-Reply-To: <4D64165F.9000403@oracle.com> References: <4D641523.3020700@oracle.com> <4D64165F.9000403@oracle.com> Message-ID: <4D64E081.9090701@oracle.com> Thanks Paul, I think the version we have in my private C2 workspaces for ARM is correct with respect to the barrier but external review is welcome: http://hatteras.france.sun.com/mackdrive/export/jrts/work/bd148109/ej2se/repositories/ej2se-master_1.6.0_21/src/cpu/arm/vm/stubGenerator_arm.cpp or /net/mackdrive.france.sun.com/export/jrts/work/bd148109/ej2se/repositories/ej2se-master_1.6.0_21/src/cpu/arm/vm/stubGenerator_arm.cpp This has not yet been pushed into the 'official' embedded workspace but should be done soon (I'm working on a slightly enhanced version but this should not change the barrier code). Since I'm still working on it, I'll probably also cleanup the code for the _entry assignments similarly to what Igor did in this webrev. Bertrand -- Bertrand Delsart, bertrand.delsart at oracle.com Sun-Oracle, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE Phone : +33 4 76 18 81 23 Fax : +33 4 76 18 88 88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bertrand.delsart at oracle.com Wed Feb 23 02:25:05 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 23 Feb 2011 11:25:05 +0100 Subject: Request for review(M): 7020521: arraycopy stubs place prebarriers incorrectly In-Reply-To: <4D64165F.9000403@oracle.com> References: <4D641523.3020700@oracle.com> <4D64165F.9000403@oracle.com> Message-ID: <4D64E081.9090701@oracle.com> Thanks Paul, I think the version we have in my private C2 workspaces for ARM is correct with respect to the barrier but external review is welcome: http://hatteras.france.sun.com/mackdrive/export/jrts/work/bd148109/ej2se/repositories/ej2se-master_1.6.0_21/src/cpu/arm/vm/stubGenerator_arm.cpp or /net/mackdrive.france.sun.com/export/jrts/work/bd148109/ej2se/repositories/ej2se-master_1.6.0_21/src/cpu/arm/vm/stubGenerator_arm.cpp This has not yet been pushed into the 'official' embedded workspace but should be done soon (I'm working on a slightly enhanced version but this should not change the barrier code). Since I'm still working on it, I'll probably also cleanup the code for the _entry assignments similarly to what Igor did in this webrev. Bertrand -- Bertrand Delsart, bertrand.delsart at oracle.com Sun-Oracle, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE Phone : +33 4 76 18 81 23 Fax : +33 4 76 18 88 88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From vladimir.kozlov at oracle.com Wed Feb 23 17:46:33 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 24 Feb 2011 01:46:33 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 22 new changesets Message-ID: <20110224014711.52330479D9@hg.openjdk.java.net> Changeset: c798c277ddd1 Author: brutisso Date: 2011-02-03 20:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c798c277ddd1 7015169: GC Cause not always set Summary: Sometimes the gc cause was not always set. This caused JStat to print the wrong information. Reviewed-by: tonyp, ysr Contributed-by: suenaga.yasumasa at oss.ntt.co.jp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/services/heapDumper.cpp Changeset: c5a923563727 Author: ysr Date: 2011-02-07 22:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c5a923563727 6912621: iCMS: Error: assert(_markBitMap.isMarked(addr + 1),"Missing Printezis bit?") Summary: Fix block_size_if_printezis_bits() so it does not expect the bits, only uses them when available. Fix block_size_no_stall() so it does not stall when the bits are missing such cases, letting the caller deal with zero size returns. Constant pool cache oops do not need to be unparsable or conc_unsafe after their klass pointer is installed. Some cosmetic clean-ups and some assertion checking for conc-usafety which, in the presence of class file redefinition, has no a-priori time boundedness, so all GCs must be able to safely deal with putatively conc-unsafe objects in a stop-world pause. Reviewed-by: jmasa, johnc ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: e5383553fd4e Author: stefank Date: 2011-02-08 12:33 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e5383553fd4e 7014851: Remove unused parallel compaction code Summary: Removed. Reviewed-by: jcoomes, brutisso ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/compiledICHolderKlass.cpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/methodDataKlass.cpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp Changeset: 59e20a452a2a Author: johnc Date: 2011-02-09 09:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/59e20a452a2a 7017008: G1: Turn on compressed oops by default. Summary: Normally compressed oops is enabled when the maximum heap size is under a certain limit, except when G1 is also enabled. Remove this limitation. Also re-enable GCBasher testing with G1 on 64 bit windows in jprt. Reviewed-by: jcoomes, brutisso, tonyp ! make/jprt.properties ! src/share/vm/runtime/arguments.cpp Changeset: 183658a2d0b3 Author: ysr Date: 2011-02-10 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/183658a2d0b3 7018302: newly added assert related to size of constantPoolOop causes secondary assertions or crashes Summary: 6912621 used a raw oop in the newly added assert following an allocation attempt that could result in a GC. Reviewed-by: jmasa ! src/share/vm/oops/constantPoolKlass.cpp Changeset: 55cc33cf55bc Author: stefank Date: 2011-02-11 14:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/55cc33cf55bc 7018257: jmm_DumpThreads allocates into permgen Summary: Don't allocate in permgen Reviewed-by: ysr, sla ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/services/management.cpp Changeset: f7702f8c0e25 Author: tonyp Date: 2011-02-14 22:21 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f7702f8c0e25 Merge ! make/jprt.properties ! src/share/vm/services/management.cpp Changeset: e9aa2ca89ad6 Author: kamg Date: 2011-02-16 16:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e9aa2ca89ad6 7019718: make error reporting flags product instead of diagnostic Summary: see synopsis Reviewed-by: acorn, coleenp ! src/share/vm/runtime/globals.hpp Changeset: 02368ad6c63f Author: trims Date: 2011-02-16 17:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/02368ad6c63f Merge Changeset: 15d6977f04b0 Author: sla Date: 2011-02-10 13:03 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/15d6977f04b0 7017824: Add support for creating 64-bit Visual Studio projects Summary: Updated create.bat and ProjectCreator Reviewed-by: brutisso, stefank, ohair ! make/windows/create.bat ! make/windows/makefiles/compile.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/rules.make - make/windows/platform_amd64 - make/windows/platform_i486 - make/windows/platform_ia64 ! make/windows/projectfiles/common/Makefile ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/DirectoryTree.java ! src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/Macro.java - src/share/tools/ProjectCreator/MacroDefinitions.java ! src/share/tools/ProjectCreator/Util.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC6.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/vm/adlc/adlc.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp Changeset: 7aa1f99ca301 Author: coleenp Date: 2011-02-12 10:28 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7aa1f99ca301 7019157: errorHandler doesn't compile with super old gcc without precompiled headers Summary: old gccs don't support precompiled headers so have to supply includes Reviewed-by: phh, kamg ! src/share/vm/utilities/errorReporter.hpp Changeset: 54df4702df97 Author: rottenha Date: 2011-02-14 03:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/54df4702df97 Merge - make/windows/platform_amd64 - make/windows/platform_i486 - make/windows/platform_ia64 - src/share/tools/ProjectCreator/Macro.java - src/share/tools/ProjectCreator/MacroDefinitions.java Changeset: de14f1eee390 Author: dcubed Date: 2011-02-15 19:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/de14f1eee390 6954420: 2/4 jps shows "process information unavailable" sometimes Summary: Make sure the backing store file is flushed in create_sharedmem_resources() and get_user_name_slow() no longer checks the size of the backing store file. Reviewed-by: briand, swamyv, acorn, poonam ! src/os/windows/vm/perfMemory_windows.cpp Changeset: b76d12f4ab2d Author: dholmes Date: 2011-02-14 19:27 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b76d12f4ab2d 7018429: JPRT: Update Makefile to use ALT_JDK_TARGET_IMPORT_PATH for copying JDK Summary: Set JDK_IMPORT_PATH to ALT_JDK_TARGET_IMPORT_PATH if it is defined Reviewed-by: phh, ohair ! make/Makefile ! make/defs.make Changeset: 5415131bc5ab Author: dholmes Date: 2011-02-16 01:42 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5415131bc5ab Merge Changeset: c08677f98289 Author: coleenp Date: 2011-02-16 11:34 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c08677f98289 6840152: JVM crashes when heavyweight monitors are used Summary: Turn off biased locking if !UseFastLocking or UseHeavyMonitors options are requested. Reviewed-by: phh, never, dcubed, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 3adec115d40d Author: coleenp Date: 2011-02-16 17:12 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3adec115d40d 7019689: Non-dependent name is found in dependent base class although it should be rejected Summary: fix hashtable.hpp to qualify non-dependant name with "this" Reviewed-by: phh, never, poonam Contributed-by: volker.simonis at gmail.com ! src/share/vm/utilities/hashtable.hpp Changeset: a959935a5732 Author: coleenp Date: 2011-02-16 16:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a959935a5732 Merge Changeset: 6e70f1bb7f6f Author: coleenp Date: 2011-02-18 18:26 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6e70f1bb7f6f 7019557: SharedMiscDataSize too small for 64-bit fastdebug JVM Summary: Increase default SharedMiscDataSize Reviewed-by: dcubed, kamg ! src/share/vm/runtime/globals.hpp Changeset: f77b3ec064b0 Author: rottenha Date: 2011-02-21 04:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f77b3ec064b0 Merge - make/windows/platform_amd64 - make/windows/platform_i486 - make/windows/platform_ia64 - src/share/tools/ProjectCreator/Macro.java - src/share/tools/ProjectCreator/MacroDefinitions.java ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a97fd181b813 Author: kvn Date: 2011-02-23 11:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a97fd181b813 Merge - make/windows/platform_amd64 - make/windows/platform_i486 - make/windows/platform_ia64 - src/share/tools/ProjectCreator/Macro.java - src/share/tools/ProjectCreator/MacroDefinitions.java ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/runtime/globals.hpp Changeset: ba5d119730dd Author: kvn Date: 2011-02-23 12:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ba5d119730dd Merge From vladimir.kozlov at oracle.com Wed Feb 23 20:18:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Feb 2011 20:18:33 -0800 Subject: Request for reviews (XS): 6812217: Base memory of MergeMem node violates assert during killing expanded AllocateArray node Message-ID: <4D65DC19.4080300@oracle.com> http://cr.openjdk.java.net/~kvn/6812217/webrev Fixed 6812217: Base memory of MergeMem node violates assert during killing expanded AllocateArray node The assert in MergeMemNode::memory_at() misses the case when address is TOP. From tom.rodriguez at oracle.com Wed Feb 23 23:22:24 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 24 Feb 2011 07:22:24 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7012072: CompileTheWorld causes incorrect class initialization Message-ID: <20110224072226.0021E479F6@hg.openjdk.java.net> Changeset: d411927672ed Author: never Date: 2011-02-23 19:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d411927672ed 7012072: CompileTheWorld causes incorrect class initialization Reviewed-by: kvn, twisti ! src/share/vm/prims/unsafe.cpp From tom.rodriguez at oracle.com Thu Feb 24 10:24:55 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 24 Feb 2011 10:24:55 -0800 Subject: Request for reviews (XS): 6812217: Base memory of MergeMem node violates assert during killing expanded AllocateArray node In-Reply-To: <4D65DC19.4080300@oracle.com> References: <4D65DC19.4080300@oracle.com> Message-ID: Seems ok. tom On Feb 23, 2011, at 8:18 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6812217/webrev > > Fixed 6812217: Base memory of MergeMem node violates assert during killing expanded AllocateArray node > > The assert in MergeMemNode::memory_at() misses the case when address is TOP. > From vladimir.kozlov at oracle.com Thu Feb 24 10:21:59 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Feb 2011 10:21:59 -0800 Subject: Request for reviews (XS): 6812217: Base memory of MergeMem node violates assert during killing expanded AllocateArray node In-Reply-To: References: <4D65DC19.4080300@oracle.com> Message-ID: <4D66A1C7.9060806@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Seems ok. > > tom > > On Feb 23, 2011, at 8:18 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6812217/webrev >> >> Fixed 6812217: Base memory of MergeMem node violates assert during killing expanded AllocateArray node >> >> The assert in MergeMemNode::memory_at() misses the case when address is TOP. >> > From igor.veresov at oracle.com Thu Feb 24 12:37:26 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 24 Feb 2011 12:37:26 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking Message-ID: <4D66C186.4070201@oracle.com> Bulk zeroing reduction didn't work with G1, because arraycopy would call pre-barriers on uninitialized oops. The solution is to have version of arraycopy stubs that don't have pre-barriers. Also refactored arraycopy stubs generation on SPARC to be more readable and reduced the number of stubs necessary in some cases. Webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.00/ Thanks, igor From john.r.rose at oracle.com Thu Feb 24 14:40:19 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 24 Feb 2011 14:40:19 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D66C186.4070201@oracle.com> References: <4D66C186.4070201@oracle.com> Message-ID: <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> Looks good. You have typo: s/alinged/aligned/ in the sparc code. I can't tell from the patch, so I'll ask: How did you locate all the points that needed the extra "false" argument? Also, is there a stress test that reliably produces the bug? -- John On Feb 24, 2011, at 12:37 PM, Igor Veresov wrote: > Bulk zeroing reduction didn't work with G1, because arraycopy would call pre-barriers on uninitialized oops. The solution is to have version of arraycopy stubs that don't have pre-barriers. > Also refactored arraycopy stubs generation on SPARC to be more readable and reduced the number of stubs necessary in some cases. > > Webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.00/ > > Thanks, > igor From vladimir.kozlov at oracle.com Thu Feb 24 14:46:51 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 24 Feb 2011 22:46:51 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6812217: Base memory of MergeMem node violates assert during killing expanded AllocateArray node Message-ID: <20110224224654.855D847A21@hg.openjdk.java.net> Changeset: 5a41a201d08c Author: kvn Date: 2011-02-24 10:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5a41a201d08c 6812217: Base memory of MergeMem node violates assert during killing expanded AllocateArray node Summary: The assert in MergeMemNode::memory_at() misses the case when address is TOP. Reviewed-by: never ! src/share/vm/opto/memnode.cpp From igor.veresov at oracle.com Thu Feb 24 16:49:39 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 24 Feb 2011 16:49:39 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> Message-ID: <4D66FCA3.2030700@oracle.com> On 2/24/11 2:40 PM, John Rose wrote: > Looks good. You have typo: s/alinged/aligned/ in the sparc code. Thanks, John! > > I can't tell from the patch, so I'll ask: How did you locate all the points that needed the extra "false" argument? Just by code analysis. Did I miss something? > > Also, is there a stress test that reliably produces the bug? Originally it reproduced quite easily with GCBasher. I haven't tried making fail it again, since I knew the cause, but I verified that after the fix it works fine. igor > > -- John > > On Feb 24, 2011, at 12:37 PM, Igor Veresov wrote: > >> Bulk zeroing reduction didn't work with G1, because arraycopy would call pre-barriers on uninitialized oops. The solution is to have version of arraycopy stubs that don't have pre-barriers. >> Also refactored arraycopy stubs generation on SPARC to be more readable and reduced the number of stubs necessary in some cases. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.00/ >> >> Thanks, >> igor > From tom.rodriguez at oracle.com Thu Feb 24 17:18:36 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 25 Feb 2011 01:18:36 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110225011844.BAE6147A35@hg.openjdk.java.net> Changeset: 6f3746e69a78 Author: never Date: 2011-02-24 11:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6f3746e69a78 7021603: crash in fill_sync_handler with ExtendedDTrace probes Reviewed-by: iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: 8190d4b75e09 Author: never Date: 2011-02-24 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8190d4b75e09 Merge From john.r.rose at oracle.com Thu Feb 24 17:27:00 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 24 Feb 2011 17:27:00 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D66FCA3.2030700@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> Message-ID: On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: > Just by code analysis. Did I miss something? I felt a slight doubt because there are tricky paths through the various subroutine layers in library_call. I see you converted "must_clear_dest" to "suppress_pre_barrier" along two paths. There's a path through generate_block_arraycopy which *almost* needs the flag also, but it allows the flag to default. To make the code more obviously correct, I suggest making the flag non-optional in library_call. And when the role of the flag changes, a line or two of code could mark the transition like this: bool use_pre_barrier = (bt == T_OBJECT); // usual case if (must_clear_dest) use_pre_barrier = false; // 6627983 suppress pre_barrier, if any ... foo(..., use_pre_barrier); If it is simply foo(..., !must_clear_dest), it becomes hard for maintainers to see what the argument means. In the stub generator the optional boolean is OK as is, although I generally prefer optional booleans to default to 'false'. Given the way the bug is structured, I keep wanting to call it 'suppress_pre_barrier', meaning "just this once, trust me when I tell you not to emit the pre-barrier, if there is one." -- John From igor.veresov at oracle.com Thu Feb 24 18:02:46 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 24 Feb 2011 18:02:46 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> Message-ID: <4D670DC6.7020409@oracle.com> On 2/24/11 5:27 PM, John Rose wrote: > On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: > >> Just by code analysis. Did I miss something? > > I felt a slight doubt because there are tricky paths through the various subroutine layers in library_call. I see you converted "must_clear_dest" to "suppress_pre_barrier" along two paths. There's a path through generate_block_arraycopy which *almost* needs the flag also, but it allows the flag to default. > > To make the code more obviously correct, I suggest making the flag non-optional in library_call. And when the role of the flag changes, a line or two of code could mark the transition like this: > bool use_pre_barrier = (bt == T_OBJECT); // usual case > if (must_clear_dest) use_pre_barrier = false; // 6627983 suppress pre_barrier, if any > ... > foo(..., use_pre_barrier); > > If it is simply foo(..., !must_clear_dest), it becomes hard for maintainers to see what the argument means. I can see your point but I just didn't want to introduce additional clutter. For example generate_block_arraycopy() never requires barrier suppression, so why do we need to add an argument there? From the debugging standpoint it's way better to emit a barrier than not to. Missing barriers will be a nightmare to find. So, I'd rather have a barrier erroneously emitted in some path by default, which would make the marking crash almost immediately. As for using !must_clear_dest as a gate, I thought it would more clearly convey to the reader the reason why the barrier is suppressed - because the dest array is not cleared and contains garbage, so the reader won't have to go back to see in which cases use_pre_barrier is set. Perhaps I should add more comments. > > In the stub generator the optional boolean is OK as is, although I generally prefer optional booleans to default to 'false'. Given the way the bug is structured, I keep wanting to call it 'suppress_pre_barrier', meaning "just this once, trust me when I tell you not to emit the pre-barrier, if there is one." > That's pretty much equivalent. I don't have strong feelings about this and will change it if you think it's more readable. igor > -- John From john.r.rose at oracle.com Thu Feb 24 18:28:58 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 24 Feb 2011 18:28:58 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D670DC6.7020409@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> Message-ID: On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: > On 2/24/11 5:27 PM, John Rose wrote: >> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >> >> If it is simply foo(..., !must_clear_dest), it becomes hard for maintainers to see what the argument means. > > I can see your point but I just didn't want to introduce additional clutter. For example generate_block_arraycopy() never requires barrier suppression, so why do we need to add an argument there? There's not a strong need. An extra "true" or "false" would be a little clutter, but it would also hint to programmers what's going on. It's a esthetic call mostly... (Here's some meandering on the subject. While reading the code, if I am tracing the flow from caller definition to callee definition, when arguments are explicit I can observe them directly. But if they are defaulted, then I have to visit the callee's declaration as well. I have to visit three locations in the source instead of two. I personally find this awkward unless the meaning of the defaulted argument is immediately and intuitively obvious. In this case the meaning of the argument is subtly related to other parts of the system.) > From the debugging standpoint it's way better to emit a barrier than not to. Missing barriers will be a nightmare to find. So, I'd rather have a barrier erroneously emitted in some path by default, which would make the marking crash almost immediately. Good point. > As for using !must_clear_dest as a gate, I thought it would more clearly convey to the reader the reason why the barrier is suppressed - because the dest array is not cleared and contains garbage, so the reader won't have to go back to see in which cases use_pre_barrier is set. Perhaps I should add more comments. The bug number would help a lot, I think. It's a subtle interaction between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 invariants. >> In the stub generator the optional boolean is OK as is, although I generally prefer optional booleans to default to 'false'. Given the way the bug is structured, I keep wanting to call it 'suppress_pre_barrier', meaning "just this once, trust me when I tell you not to emit the pre-barrier, if there is one." >> > > That's pretty much equivalent. I don't have strong feelings about this and will change it if you think it's more readable. I do think it would be more readable. It could be just an old Lisper bias, though: Optional arguments default to NULL, which is the false value in Lisp. -- John From igor.veresov at oracle.com Fri Feb 25 20:25:14 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 25 Feb 2011 20:25:14 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> Message-ID: <4D6880AA.6000700@oracle.com> I think my fix is not good enough for the case when we'll need prebarriers that will not require the previous value and these could be a reality in the future. So, it is generally incorrect to elide prebarriers but is only ok for a specific flavor. I'm working to alleviate this problem a little bit and will post the updated version early next week. John, I will also address your recommendations. Thanks, igor On 2/24/11 6:28 PM, John Rose wrote: > On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: > >> On 2/24/11 5:27 PM, John Rose wrote: >>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>> >>> If it is simply foo(..., !must_clear_dest), it becomes hard for maintainers to see what the argument means. >> >> I can see your point but I just didn't want to introduce additional clutter. For example generate_block_arraycopy() never requires barrier suppression, so why do we need to add an argument there? > > There's not a strong need. An extra "true" or "false" would be a little clutter, but it would also hint to programmers what's going on. It's a esthetic call mostly... > > (Here's some meandering on the subject. While reading the code, if I am tracing the flow from caller definition to callee definition, when arguments are explicit I can observe them directly. But if they are defaulted, then I have to visit the callee's declaration as well. I have to visit three locations in the source instead of two. I personally find this awkward unless the meaning of the defaulted argument is immediately and intuitively obvious. In this case the meaning of the argument is subtly related to other parts of the system.) > >> From the debugging standpoint it's way better to emit a barrier than not to. Missing barriers will be a nightmare to find. So, I'd rather have a barrier erroneously emitted in some path by default, which would make the marking crash almost immediately. > > Good point. > >> As for using !must_clear_dest as a gate, I thought it would more clearly convey to the reader the reason why the barrier is suppressed - because the dest array is not cleared and contains garbage, so the reader won't have to go back to see in which cases use_pre_barrier is set. Perhaps I should add more comments. > > The bug number would help a lot, I think. It's a subtle interaction between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 invariants. > >>> In the stub generator the optional boolean is OK as is, although I generally prefer optional booleans to default to 'false'. Given the way the bug is structured, I keep wanting to call it 'suppress_pre_barrier', meaning "just this once, trust me when I tell you not to emit the pre-barrier, if there is one." >>> >> >> That's pretty much equivalent. I don't have strong feelings about this and will change it if you think it's more readable. > > I do think it would be more readable. It could be just an old Lisper bias, though: Optional arguments default to NULL, which is the false value in Lisp. > > -- John From vladimir.kozlov at oracle.com Sat Feb 26 14:19:31 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 26 Feb 2011 22:19:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6942326: x86 code in string_indexof() could read beyond reserved heap space Message-ID: <20110226221933.B16C047AB0@hg.openjdk.java.net> Changeset: 41d4973cf100 Author: kvn Date: 2011-02-26 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/41d4973cf100 6942326: x86 code in string_indexof() could read beyond reserved heap space Summary: copy small (<8) strings on stack if str+16 crosses a page boundary and load from stack into XMM. Back up pointer when loading string's tail. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp + test/compiler/6942326/Test.java From john.r.rose at oracle.com Sun Feb 27 02:24:16 2011 From: john.r.rose at oracle.com (John Rose) Date: Sun, 27 Feb 2011 02:24:16 -0800 Subject: Fwd: review request (XL): 6839872: remove implementation inheritance from JSR 292 APIs References: <646C6113-FBCB-4A03-B69B-58E493C7CA8D@oracle.com> Message-ID: <33EF0DED-2F58-4AE2-8647-BA4187DF4321@oracle.com> There will be a corresponding set of JVM changes out for review soon. A draft of them is already pushed to the patch repo: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-impl-6839872.patch -- John From: John Rose Date: February 27, 2011 2:18:46 AM PST To: Da Vinci Machine Project Subject: review request (XL): 6839872: remove implementation inheritance from JSR 292 APIs http://cr.openjdk.java.net/~jrose/6839872/jdk-webrev.00/ Summary: move everything into a single package; remove all multi-package machinery This is a complex change which consolidates the code into a single package, to prepare for a clean rename from java.dyn to java.lang.invoke. This also fixes some defects in the API which arise from dependencies between multiple packages. That was the original motivation of bug 6839872. For ease of review, this change may be reviewed in seven parts: - meth-impl-6839872.1-rename.patch moves files between packages - meth-impl-6839872.2-super.patch merges sun.dyn superclasses into java.dyn subclasses - meth-impl-6839872.3-moves.patch moves some method code around in java.dyn classes - meth-impl-6839872.4-vconv.patch addresses a dependency from ValueConversions - meth-impl-6839872.5-mtform.patch removes a cross-package wormhole from MethodType & MethodTypeForm - meth-impl-6839872.6-access.patch removes cross-package access checking - meth-impl-6839872.7-misc.patch is a few more miscellaneous changes These individual patches may be found in the mlvm repository: http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/ -rw-r--r-- 36661 meth-impl-6839872.1-rename.patch file | revisions | annotate -rw-r--r-- 24772 meth-impl-6839872.2-super.patch file | revisions | annotate -rw-r--r-- 45216 meth-impl-6839872.3-moves.patch file | revisions | annotate -rw-r--r-- 6895 meth-impl-6839872.4-vconv.patch file | revisions | annotate -rw-r--r-- 23819 meth-impl-6839872.5-mtform.patch file | revisions | annotate -rw-r--r-- 89039 meth-impl-6839872.6-access.patch file | revisions | annotate -rw-r--r-- 19404 meth-impl-6839872.7-misc.patch file | revisions | annotate ____________________________________________________________ http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-impl-6839872.1-rename.patch rev 3506 : factored part of meth-impl-6839872.patch Move almost all files from sun.dyn.* to java.dyn. Exceptions: - WrapperInstance needs to be a public interface, but is not part of API, so must be in sun.dyn. - sun.dyn.Access is going away in a subsequent part of this change set - package-info.java stays Other changes: - change occurrences of Access.TOKEN to IMPL_TOKEN - added java.dyn.MethodHandleStatics to hold IMPL_TOKEN, temporarily - asked NetBeans to fix imports in all files - remove MemberName-based test - remove MethodTypeForm (*) The removal of MethodTypeForm is a breaking change. Apart from this change, the software continues to build correctly after this patch. ____________________________________________________________ http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-impl-6839872.2-super.patch rev 3507 : factored part of meth-impl-6839872.patch - After move from sun.dyn.* to java.dyn, merge sun.dyn superclasses into java.dyn subclasses. - Move fields and constructor for MethodHandleImpl into MethodHandle. Keep factory methods. - Rename MethodTypeImpl to MethodTypeForm, thereby moving fields and constructor. After this change, this JDK software builds and passes basic unit tests with the corresponding JVM. ____________________________________________________________ http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-impl-6839872.3-moves.patch rev 3508 : factored part of meth-impl-6839872.patch Move some misplaced methods and constants between classes. Also: - Move some functions verbatim into MethodHandleStatics. - Move raiseException and checkSpreadArgument into MethodHandleNatives, for the JVM. - Move all of CallSiteImpl into CallSite. - Move some exception creation functions from MemberName into MethodHandleStatics, with light refactoring. - Change newNoAccessException to a virtual function MemberName.makeAccessException. - Remove an extra copy of IMPL_LOOKUP; import it regularly from MethodHandles.Lookup. - Remove an inconvenient dependency from MethodHandles. to IMPL_LOOKUP. After this change, this JDK software builds and passes basic unit tests with the corresponding JVM. ____________________________________________________________ http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-impl-6839872.4-vconv.patch rev 3509 : factored part of meth-impl-6839872.patch Deal with an external dependency from sun.dyn.util.ValueConversions to privileged MH access. Remove "raw retype" capabilities from ValueConversions, moving them into the trusted package. After this change, this JDK software builds and passes basic unit tests with the corresponding JVM. ____________________________________________________________ http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-impl-6839872.5-mtform.patch rev 3510 : Remove MethodTypeFriend, a "wormhole" for privileged communication between a MethodType and its Form. Use trusted package-private methods on MethodType for such communication instead. Also, put the internal Invokers struct from a virtual method on MethodType. After this change, this JDK software builds and passes basic unit tests with the corresponding JVM. ____________________________________________________________ http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-impl-6839872.6-access.patch rev 3511 : factored part of meth-impl-6839872.patch - Remove the Access class and all uses. - Remove most public access modifiers on non-public class members. This is a large volume of simple change. All privileged methods become non-public, and lose their first "Access token" arguments. After this change, this JDK software builds and passes basic unit tests with the corresponding JVM. ____________________________________________________________ http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-impl-6839872.7-misc.patch rev 3512 : Miscellaneous changes. After this change, this JDK software builds and passes basic unit tests with the corresponding JVM. _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110227/acb1f42c/attachment-0001.html From forax at univ-mlv.fr Sun Feb 27 10:16:33 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 27 Feb 2011 19:16:33 +0100 Subject: ArrayList loop regression ? Message-ID: <4D6A9501.9050508@univ-mlv.fr> A student sent me a micro-benchmark that shows a regression in the way hotspot compiles indexed loop on linux x64. Basically jdk7: java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b129) Java HotSpot(TM) 64-Bit Server VM (build 21.0-b01, mixed mode) is really slow compared to jdk6: java version "1.6.0_21" Java(TM) SE Runtime Environment (build 1.6.0_21-b06) Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode) [forax at localhost src]$ java -server -Xbatch ArrayListIteration2 495000000 23562949 495000000 28475066 495000000 10691187 495000000 17820582 495000000 17910601 495000000 17231943 495000000 17834819 495000000 17444713 495000000 17831591 495000000 17880947 495000000 17405874 495000000 17823323 495000000 17254145 495000000 17815812 495000000 17534777 495000000 17589371 495000000 17830668 495000000 17389534 495000000 17884535 495000000 17484575 [forax at localhost src]$ /usr/jdk/jdk1.6.0_21/bin/java -server -Xbatch ArrayListIteration2 495000000 28299043 495000000 23543527 495000000 11718848 495000000 12008201 495000000 12821666 495000000 11661011 495000000 12502804 495000000 11763580 495000000 11663503 495000000 12620776 495000000 11649228 495000000 12593051 495000000 11805152 495000000 11702461 495000000 12368391 495000000 11615139 495000000 12511620 495000000 11726843 495000000 11796660 495000000 12379443 I've also tested with an older 32bit VM that doesn't show any regression on 32bits : java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b123) Java HotSpot(TM) Server VM (build 20.0-b04, mixed mode) R?mi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ArrayListIteration2.java Url: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110227/61815d26/attachment.ksh From christian.thalinger at oracle.com Mon Feb 28 05:35:22 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Feb 2011 14:35:22 +0100 Subject: Request for reviews (L): 7012914: JSR 292 MethodHandlesTest C1: frame::verify_return_pc(return_address) failed: must be a return pc In-Reply-To: <74EA707F-0EEA-4CE5-AD9D-40B77A036A35@oracle.com> References: <0F3C7F7F-3390-49C1-8724-230596BA77DB@oracle.com> <74EA707F-0EEA-4CE5-AD9D-40B77A036A35@oracle.com> Message-ID: On Feb 21, 2011, at 8:05 PM, Tom Rodriguez wrote: > > On Feb 21, 2011, at 9:15 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7012914/webrev.01/ >> >> 7012914: JSR 292 MethodHandlesTest C1: frame::verify_return_pc(return_address) failed: must be a return pc >> Reviewed-by: >> >> The changes of 7007377 changed the way >> MethodHandlesImpl.raiseException is called from the raise_exception >> method handle adapter as it calls the C2I adapter. Since >> MethodHandlesImpl.raiseException has three arguments, on 32-bit x86 we >> need to pass one argument on the stack. This additional word on the >> stack needs to be removed when we return to the actual callee during >> unwinding. >> >> Since the call site that triggers the exception is a method handle >> call site we just need to restore the saved SP from BP. >> >> Right now this is only a problem on 32-bit x86 because of the way we >> implement the raise_exception method handle adapter. But I assume >> it's not impossible that in the future there are stack manipulations >> before we throw an exception. So a fix for all architectures seems >> reasonable. >> >> This change removes some unused code in >> StubGenerator::generate_forward_exception as this stub is only used >> for runtime calls with a pending exception and runtime calls can't be >> method handle call sites. It also removes the unused >> ExceptionCache::_unwind_handler. >> >> Additionally there is a small cleanup of >> SharedRuntime::raw_exception_handler_for_return_address to not call >> CodeCache::find_blob twice. > > Isn't the second call unreachable? If nm != null then we will already have returned. So can't the whole block be replaced with: > > guarantee(blob == NULL || !blob->is_runtime_stub(), "caller should have skipped stub"); You're right. I changed that. > > Otherwise it looks fine. Thank you. -- Christian From volker.simonis at gmail.com Mon Feb 28 07:48:50 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 28 Feb 2011 16:48:50 +0100 Subject: The fix for 6989984 broke the build of hsdis Message-ID: The change "6989984: Use standard include model for Hospot" broke the hsdisbuild under src/share/tools/hsdis. The fix ix easy, just remove the dependency on "precompiled.hpp" from hsdis.c: diff -r 79fe787a0420 src/share/tools/hsdis/hsdis.c --- a/src/share/tools/hsdis/hsdis.c Fri Feb 25 16:40:03 2011 +0100 +++ b/src/share/tools/hsdis/hsdis.c Mon Feb 28 16:17:00 2011 +0100 @@ -22,8 +22,6 @@ * */ -#include "precompiled.hpp" - /* hsdis.c -- dump a range of addresses as native instructions This implements the plugin protocol required by the HotSpot PrintAssembly option. From christian.thalinger at oracle.com Mon Feb 28 08:18:19 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 28 Feb 2011 16:18:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7012914: JSR 292 MethodHandlesTest C1: frame::verify_return_pc(return_address) failed: must be a return pc Message-ID: <20110228161821.2912947B16@hg.openjdk.java.net> Changeset: 1b4e6a5d98e0 Author: twisti Date: 2011-02-28 06:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1b4e6a5d98e0 7012914: JSR 292 MethodHandlesTest C1: frame::verify_return_pc(return_address) failed: must be a return pc Reviewed-by: never, bdelsart ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/macros.hpp From tom.rodriguez at oracle.com Mon Feb 28 16:30:26 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 28 Feb 2011 16:30:26 -0800 Subject: The fix for 6989984 broke the build of hsdis In-Reply-To: References: Message-ID: I filed 7023229 for this and will fix it. Thanks! tom On Feb 28, 2011, at 7:48 AM, Volker Simonis wrote: > The change "6989984: Use standard include model for Hospot" broke the > hsdisbuild under src/share/tools/hsdis. > > The fix ix easy, just remove the dependency on "precompiled.hpp" from hsdis.c: > > > diff -r 79fe787a0420 src/share/tools/hsdis/hsdis.c > --- a/src/share/tools/hsdis/hsdis.c Fri Feb 25 16:40:03 2011 +0100 > +++ b/src/share/tools/hsdis/hsdis.c Mon Feb 28 16:17:00 2011 +0100 > @@ -22,8 +22,6 @@ > * > */ > > -#include "precompiled.hpp" > - > /* hsdis.c -- dump a range of addresses as native instructions > This implements the plugin protocol required by the > HotSpot PrintAssembly option. From tom.rodriguez at oracle.com Mon Feb 28 16:44:44 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 28 Feb 2011 16:44:44 -0800 Subject: The fix for 6989984 broke the build of hsdis In-Reply-To: References: Message-ID: <1D7E9313-705A-496E-BEF7-C689E0E1F4D4@oracle.com> http://cr.openjdk.java.net/~never/7023229 7023229: extraneous include of precompiled.hpp in hsdis.c Reviewed-by: never Contributed-by: volker.simonis at gmail.com The fix for 6989984 added an include of precompiled.hpp to hsdis.c which it shouldn't have. The fix to simply remove it. hsdis-demo.c had the same problem. I checked the other files in src/share/tools for mention of precompiled.hpp and those were the only ones I found. Tested by building hsdis and hsdis-demo. On Feb 28, 2011, at 7:48 AM, Volker Simonis wrote: > The change "6989984: Use standard include model for Hospot" broke the > hsdisbuild under src/share/tools/hsdis. > > The fix ix easy, just remove the dependency on "precompiled.hpp" from hsdis.c: > > > diff -r 79fe787a0420 src/share/tools/hsdis/hsdis.c > --- a/src/share/tools/hsdis/hsdis.c Fri Feb 25 16:40:03 2011 +0100 > +++ b/src/share/tools/hsdis/hsdis.c Mon Feb 28 16:17:00 2011 +0100 > @@ -22,8 +22,6 @@ > * > */ > > -#include "precompiled.hpp" > - > /* hsdis.c -- dump a range of addresses as native instructions > This implements the plugin protocol required by the > HotSpot PrintAssembly option. From john.r.rose at oracle.com Mon Feb 28 16:56:11 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 28 Feb 2011 16:56:11 -0800 Subject: The fix for 6989984 broke the build of hsdis In-Reply-To: <1D7E9313-705A-496E-BEF7-C689E0E1F4D4@oracle.com> References: <1D7E9313-705A-496E-BEF7-C689E0E1F4D4@oracle.com> Message-ID: Reviewed. Thanks, Tom and Volker. -- John On Feb 28, 2011, at 4:44 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7023229 From tom.rodriguez at oracle.com Mon Feb 28 17:37:54 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 28 Feb 2011 17:37:54 -0800 Subject: review (S) for 6965570: assert(!needs_patching && x->is_loaded(), "how do we know it's volatile if it's not loaded") Message-ID: <4176D8A3-4856-4B5C-A316-F17D6C720C30@oracle.com> http://cr.openjdk.java.net/~never/6965570 6965570: assert(!needs_patching && x->is_loaded(),"how do we know it's volatile if it's not loaded") Reviewed-by: During code generation for a volatile getfield in an outer class we've managed to resolve the inner class symbolically but the constant pool reference hasn't actually been resolved. This results in a field reference that should be patched so that the proper access checks are performed by constant pool resolution. In this case the field is volatile and LIRGenerator expects that if the class was loaded and we can see that's it actually volatile that a patch must not be needed. In debug mode this asserts but in product mode it generates code to uses max_jint for the field offset. The fix is to always respect the needs_patching flag. We could makes the patching machinery handle this more normally but that would complicate patching even more. It's a rare case so allowing deopt in Runtime1::patch_code to handle it is the easiest way to go. Part of the confusion stems from the is_loaded flag on AccessField which doesn't really mean what it says, so I've removed it and pushed all the needs_patching logic up into GraphBuilder. is_initialized() is similarly confusing since it really means does this static field need patching. I've eliminated that flag from AccessField and captured that logic in a new method that is used instead. Tested with runthese with and without PatchALot, ctw, and the nsk jvmti tests From tom.rodriguez at oracle.com Mon Feb 28 17:39:47 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 28 Feb 2011 17:39:47 -0800 Subject: review (XS) for 6725983: Assertion "method->method_holder())->is_not_initialized(), "method holder must be initialized" Message-ID: <2BAAE973-5DF9-4C99-B459-6FB4DE8E5841@oracle.com> http://cr.openjdk.java.net/~never/6725983 6725983: Assertion "method->method_holder())->is_not_initialized(),"method holder must be initialized" Reviewed-by: CompileTheWorldIgnoreInitErrors is unsafe to use since it violates a lot of assumptions in the compiler, it should be removed. Tested by compiling. src/share/vm/runtime/globals.hpp src/share/vm/classfile/classLoader.cpp From vladimir.kozlov at oracle.com Mon Feb 28 18:34:28 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Feb 2011 18:34:28 -0800 Subject: review (XS) for 6725983: Assertion "method->method_holder())->is_not_initialized(), "method holder must be initialized" In-Reply-To: <2BAAE973-5DF9-4C99-B459-6FB4DE8E5841@oracle.com> References: <2BAAE973-5DF9-4C99-B459-6FB4DE8E5841@oracle.com> Message-ID: <4D6C5B34.5010903@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6725983 > > 6725983: Assertion "method->method_holder())->is_not_initialized(),"method holder must be initialized" > Reviewed-by: > > CompileTheWorldIgnoreInitErrors is unsafe to use since it violates a > lot of assumptions in the compiler, it should be removed. Tested by > compiling. > > src/share/vm/runtime/globals.hpp > src/share/vm/classfile/classLoader.cpp From igor.veresov at oracle.com Mon Feb 28 18:50:25 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 28 Feb 2011 18:50:25 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6880AA.6000700@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> Message-ID: <4D6C5EF1.70801@oracle.com> John, all, I've updated the change, making corrections that John recommended. Also, now the decision about what to do with the barrier is deferred to the barrier emitting procedure. Thus, if a new pre-barrier is added that would need to do something even in case if the destination array is uninitialized it can be handled properly. New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 Thanks, igor On 2/25/11 8:25 PM, Igor Veresov wrote: > I think my fix is not good enough for the case when we'll need > prebarriers that will not require the previous value and these could be > a reality in the future. So, it is generally incorrect to elide > prebarriers but is only ok for a specific flavor. I'm working to > alleviate this problem a little bit and will post the updated version > early next week. John, I will also address your recommendations. > > Thanks, > igor > > > On 2/24/11 6:28 PM, John Rose wrote: >> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >> >>> On 2/24/11 5:27 PM, John Rose wrote: >>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>> >>>> If it is simply foo(..., !must_clear_dest), it becomes hard for >>>> maintainers to see what the argument means. >>> >>> I can see your point but I just didn't want to introduce additional >>> clutter. For example generate_block_arraycopy() never requires >>> barrier suppression, so why do we need to add an argument there? >> >> There's not a strong need. An extra "true" or "false" would be a >> little clutter, but it would also hint to programmers what's going on. >> It's a esthetic call mostly... >> >> (Here's some meandering on the subject. While reading the code, if I >> am tracing the flow from caller definition to callee definition, when >> arguments are explicit I can observe them directly. But if they are >> defaulted, then I have to visit the callee's declaration as well. I >> have to visit three locations in the source instead of two. I >> personally find this awkward unless the meaning of the defaulted >> argument is immediately and intuitively obvious. In this case the >> meaning of the argument is subtly related to other parts of the system.) >> >>> From the debugging standpoint it's way better to emit a barrier than >>> not to. Missing barriers will be a nightmare to find. So, I'd rather >>> have a barrier erroneously emitted in some path by default, which >>> would make the marking crash almost immediately. >> >> Good point. >> >>> As for using !must_clear_dest as a gate, I thought it would more >>> clearly convey to the reader the reason why the barrier is suppressed >>> - because the dest array is not cleared and contains garbage, so the >>> reader won't have to go back to see in which cases use_pre_barrier is >>> set. Perhaps I should add more comments. >> >> The bug number would help a lot, I think. It's a subtle interaction >> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >> invariants. >> >>>> In the stub generator the optional boolean is OK as is, although I >>>> generally prefer optional booleans to default to 'false'. Given the >>>> way the bug is structured, I keep wanting to call it >>>> 'suppress_pre_barrier', meaning "just this once, trust me when I >>>> tell you not to emit the pre-barrier, if there is one." >>>> >>> >>> That's pretty much equivalent. I don't have strong feelings about >>> this and will change it if you think it's more readable. >> >> I do think it would be more readable. It could be just an old Lisper >> bias, though: Optional arguments default to NULL, which is the false >> value in Lisp. >> >> -- John > From igor.veresov at oracle.com Mon Feb 28 18:51:19 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 28 Feb 2011 18:51:19 -0800 Subject: review (XS) for 6725983: Assertion "method->method_holder())->is_not_initialized(), "method holder must be initialized" In-Reply-To: <2BAAE973-5DF9-4C99-B459-6FB4DE8E5841@oracle.com> References: <2BAAE973-5DF9-4C99-B459-6FB4DE8E5841@oracle.com> Message-ID: <4D6C5F27.2020502@oracle.com> Looks good. igor On 2/28/11 5:39 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6725983 > > 6725983: Assertion "method->method_holder())->is_not_initialized(),"method holder must be initialized" > Reviewed-by: > > CompileTheWorldIgnoreInitErrors is unsafe to use since it violates a > lot of assumptions in the compiler, it should be removed. Tested by > compiling. > > src/share/vm/runtime/globals.hpp > src/share/vm/classfile/classLoader.cpp