From tom.rodriguez at oracle.com Thu Apr 1 13:03:39 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 1 Apr 2010 13:03:39 -0700 Subject: review (S) for 6936709: AsyncGetCallTrace doesn't handle inexact stack walking properly Message-ID: http://cr.openjdk.java.net/~never/6936709 This is for hs17 and hs18. 6936709: AsyncGetCallTrace doesn't handle inexact stack walking properly Reviewed-by: When trying to stack walk a frame for AsyncGetCallTrace there is existing logic that tries to make sure that the current pc in the frame maps some PcDesc so that the vframeStream logic will properly walk it. That code uses pc_desc_at to perform the lookup which requires an exact match. Since AsyncGetCallTrace is driven by a timer there's no guarantee that the pc of the topmost frame is pointing at a PcDesc. There's is code that tries to handle this but since it's logic is reversed it never triggering. This means that when we go to walk the stack the vframeStream code won't find a PcDesc and it will report 0 as the bci for that frame. The fix is to correct the AsyncGetCallTrace logic to correctly update the pc in the frame to point at a valid PcDesc. I also corrected some signatures and restructured the logic a bit to make it clearer. Tested with the Sun Studio Analyzer in user mode. src/share/vm/prims/forte.cpp From vladimir.kozlov at oracle.com Thu Apr 1 14:18:29 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 01 Apr 2010 14:18:29 -0700 Subject: review (S) for 6936709: AsyncGetCallTrace doesn't handle inexact stack walking properly In-Reply-To: References: Message-ID: <4BB50DA5.3070900@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6936709 > > This is for hs17 and hs18. > > 6936709: AsyncGetCallTrace doesn't handle inexact stack walking properly > Reviewed-by: > > When trying to stack walk a frame for AsyncGetCallTrace there is > existing logic that tries to make sure that the current pc in the > frame maps some PcDesc so that the vframeStream logic will properly > walk it. That code uses pc_desc_at to perform the lookup which > requires an exact match. Since AsyncGetCallTrace is driven by a timer > there's no guarantee that the pc of the topmost frame is pointing at a > PcDesc. There's is code that tries to handle this but since it's > logic is reversed it never triggering. This means that when we go to > walk the stack the vframeStream code won't find a PcDesc and it will > report 0 as the bci for that frame. The fix is to correct the > AsyncGetCallTrace logic to correctly update the pc in the frame to > point at a valid PcDesc. I also corrected some signatures and > restructured the logic a bit to make it clearer. Tested with the Sun > Studio Analyzer in user mode. > > src/share/vm/prims/forte.cpp From Christian.Thalinger at Sun.COM Fri Apr 2 05:39:15 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 02 Apr 2010 14:39:15 +0200 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations Message-ID: <1270211955.23285.8.camel@macbook> http://cr.openjdk.java.net/~twisti/6940520/webrev.01/ 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. Reviewed-by: During testing of JSR 292's SPARC C2 port I found a couple of crashes which came from unfixed code-embedded oops. This can be triggered with ScavengeRootsInCode={1,2}. The fix is to call fix_oop_relocations in CodeCache::scavenge_root_nmethods_do after oops may have been updated. src/share/vm/code/codeCache.cpp From thomas.rodriguez at sun.com Thu Apr 1 18:12:21 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 02 Apr 2010 01:12:21 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6936709: AsyncGetCallTrace doesn't handle inexact stack walking properly Message-ID: <20100402011239.8AE6B44D77@hg.openjdk.java.net> Changeset: 547cbe6dacc5 Author: never Date: 2010-04-01 16:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/547cbe6dacc5 6936709: AsyncGetCallTrace doesn't handle inexact stack walking properly Reviewed-by: kvn ! src/share/vm/prims/forte.cpp From vladimir.kozlov at oracle.com Fri Apr 2 08:50:52 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Apr 2010 08:50:52 -0700 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: <1270211955.23285.8.camel@macbook> References: <1270211955.23285.8.camel@macbook> Message-ID: <4BB6125C.8080909@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6940520/webrev.01/ > > 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations > Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. > Reviewed-by: > > During testing of JSR 292's SPARC C2 port I found a couple of crashes > which came from unfixed code-embedded oops. > > This can be triggered with ScavengeRootsInCode={1,2}. > > The fix is to call fix_oop_relocations in > CodeCache::scavenge_root_nmethods_do after oops may have been updated. > > src/share/vm/code/codeCache.cpp > > From vladimir.kozlov at oracle.com Fri Apr 2 10:53:31 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Apr 2010 10:53:31 -0700 Subject: Request for reviews (XS): 6939804: ciConstant::print() prints incorrect bool value Message-ID: <4BB62F1B.3030700@oracle.com> http://cr.openjdk.java.net/~kvn/6939804/webrev Fixed 6939804: ciConstant::print() prints incorrect bool value Fix typo. From tom.rodriguez at oracle.com Fri Apr 2 11:12:32 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Apr 2010 11:12:32 -0700 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: <1270211955.23285.8.camel@macbook> References: <1270211955.23285.8.camel@macbook> Message-ID: That looks good. We still need logic to prune the list of scavengeable nmethods since over time the oops should move out of eden and we can then stop scanning those nmethods. Additionally we may want GC to automatically promote oops referenced by nmethods since they are pretty much guaranteed to be long lived. I don't know if there's any easy way to do that. tom On Apr 2, 2010, at 5:39 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6940520/webrev.01/ > > 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations > Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. > Reviewed-by: > > During testing of JSR 292's SPARC C2 port I found a couple of crashes > which came from unfixed code-embedded oops. > > This can be triggered with ScavengeRootsInCode={1,2}. > > The fix is to call fix_oop_relocations in > CodeCache::scavenge_root_nmethods_do after oops may have been updated. > > src/share/vm/code/codeCache.cpp > > From tom.rodriguez at oracle.com Fri Apr 2 11:16:25 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Apr 2010 11:16:25 -0700 Subject: Request for reviews (XS): 6939804: ciConstant::print() prints incorrect bool value In-Reply-To: <4BB62F1B.3030700@oracle.com> References: <4BB62F1B.3030700@oracle.com> Message-ID: Looks good. tom On Apr 2, 2010, at 10:53 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6939804/webrev > > Fixed 6939804: ciConstant::print() prints incorrect bool value > > Fix typo. > From tom.rodriguez at oracle.com Fri Apr 2 11:29:26 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Apr 2010 11:29:26 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <0A302787-F390-40D1-A4EF-D3952E437808@ssw.jku.at> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> <94A3DE52-E9C4-4735-AD73-96D1236CB662@ssw.jku.at> <0A302787-F390-40D1-A4EF-D3952E437808@ssw.jku.at> Message-ID: http://cr.openjdk.java.net/~never/6939930 is a full solution. 6939930: exception unwind changes in 6919934 hurts compilation speed Reviewed-by: The fix 6919934 created a synthetic handler that was used to unwind the frame during exception dispatch but the addition of this handler slowed down compilation significantly. Additionally it increased the size of the nmethod by about 15% because of the extra exception handler entries. This change moves all the unwind logic down into the assembler and adds a field in the nmethod which points at the unwind handler. This removes both the speed and space penalty. The new assembly unwind code is slightly tighter than what we used to emit. I also simplified the unwind LIR op slightly and separated it out. It also dispatches directly to the new unwind handler instead of performing the unwind itself. tom On Mar 31, 2010, at 4:56 PM, Christian Wimmer wrote: >>> A unified solution could be to always keep the synthetic exception handler, but don't generate all the unnecessary exception edges. Instead, it should be enough to just link it once from the the entry block (so that the exception handler is considered reachable). The entry point of this handler is then again remembered and faked into all exception handler tables. >> >> I played a little bit with something like that but getting it properly hooked up seemed problematic. I didn't try simply hooking it off the . I do like the idea of a unified solution. That's really what I was trying to get with the original changes. Where do you think I would hook that up? I'd have to do it at after parsing all the blocks wouldn't I? Otherwise I assume that xhandler would propagate to following blocks. Maybe hook it up just before the fill_sync_handler? > > Yes, after IR construction would be the best place to hook it up. The only tricky thing is to not register the default exception handler as an exception handler of itself. > > Another idea: put the unlocking code for synchronized methods also in the special exception handling code that you sent. That way, we have no synthetic exception handler at all in the IR. In some sense, that is going back to the state before we introduced the synthetic exception handler, but this time the locking and unlocking for normal method entries and exits of course remains explicit in the IR. > > In any case, it is no longer legal to unwind directly at a throw instruction where exception_handlers()->length() == 0 > > Christian > From y.s.ramakrishna at oracle.com Fri Apr 2 11:45:26 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Fri, 02 Apr 2010 11:45:26 -0700 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: References: <1270211955.23285.8.camel@macbook> Message-ID: <4BB63B46.7080900@oracle.com> Ah, good point. Yes this should be possible without too much trouble [1] (both the automatic promotion and/or the pruning) because the scavangable nmethods list seems to be processed as a separate root-set, so we can for example send it a special "always promote" scanner and/or tell the scanner to drop nmethods that (no longer) have any young refs, the latter kinda like we do for card scanning. Christian or Tom, could one of you please open a CR to track this work so it isn't forgotten? thanks. -- ramki [1] famous last words? On 04/02/10 11:12, Tom Rodriguez wrote: > That looks good. We still need logic to prune the list of scavengeable nmethods since over time the oops should move out of eden and we can then stop scanning those nmethods. Additionally we may want GC to automatically promote oops referenced by nmethods since they are pretty much guaranteed to be long lived. I don't know if there's any easy way to do that. > > tom > > On Apr 2, 2010, at 5:39 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/6940520/webrev.01/ >> >> 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations >> Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. >> Reviewed-by: >> >> During testing of JSR 292's SPARC C2 port I found a couple of crashes >> which came from unfixed code-embedded oops. >> >> This can be triggered with ScavengeRootsInCode={1,2}. >> >> The fix is to call fix_oop_relocations in >> CodeCache::scavenge_root_nmethods_do after oops may have been updated. >> >> src/share/vm/code/codeCache.cpp >> >> > From tony.printezis at oracle.com Fri Apr 2 12:27:53 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 02 Apr 2010 15:27:53 -0400 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: <4BB63B46.7080900@oracle.com> References: <1270211955.23285.8.camel@macbook> <4BB63B46.7080900@oracle.com> Message-ID: <4BB64539.4090508@oracle.com> Y. Srinivas Ramakrishna wrote: > Ah, good point. Yes this should be possible without too much trouble [1] > (both the automatic promotion and/or the pruning) because the scavangable > nmethods list seems to be processed as a separate root-set, so we can > for example send it a special "always promote" Alternatively, we can also set the age of those objects to max_age before passing them to the standard closures. But maybe your suggestion to use a special "always promote" closure is a bit better. Tony > scanner and/or tell the scanner > to drop nmethods that (no longer) have any young refs, the > latter kinda like we do for card scanning. > > Christian or Tom, could one of you please open a CR to track this work > so it isn't > forgotten? > > thanks. > -- ramki > > [1] famous last words? > > > On 04/02/10 11:12, Tom Rodriguez wrote: >> That looks good. We still need logic to prune the list of >> scavengeable nmethods since over time the oops should move out of >> eden and we can then stop scanning those nmethods. Additionally we >> may want GC to automatically promote oops referenced by nmethods >> since they are pretty much guaranteed to be long lived. I don't know >> if there's any easy way to do that. >> >> tom >> >> On Apr 2, 2010, at 5:39 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/6940520/webrev.01/ >>> >>> 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations >>> Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. >>> Reviewed-by: >>> >>> During testing of JSR 292's SPARC C2 port I found a couple of crashes >>> which came from unfixed code-embedded oops. >>> >>> This can be triggered with ScavengeRootsInCode={1,2}. >>> >>> The fix is to call fix_oop_relocations in >>> CodeCache::scavenge_root_nmethods_do after oops may have been updated. >>> >>> src/share/vm/code/codeCache.cpp >>> >>> >> > From vladimir.kozlov at sun.com Fri Apr 2 14:16:33 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 02 Apr 2010 21:16:33 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6939804: ciConstant::print() prints incorrect bool value Message-ID: <20100402211638.78B5A44EAD@hg.openjdk.java.net> Changeset: 1c9c45172908 Author: kvn Date: 2010-04-02 11:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1c9c45172908 6939804: ciConstant::print() prints incorrect bool value Summary: Fix typo. Reviewed-by: never ! src/share/vm/ci/ciConstant.cpp From wimmer at ssw.jku.at Fri Apr 2 16:01:00 2010 From: wimmer at ssw.jku.at (Christian Wimmer) Date: Fri, 2 Apr 2010 16:01:00 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> <94A3DE52-E9C4-4735-AD73-96D1236CB662@ssw.jku.at> <0A302787-F390-40D1-A4EF-D3952E437808@ssw.jku.at> Message-ID: > http://cr.openjdk.java.net/~never/6939930 is a full solution. > > 6939930: exception unwind changes in 6919934 hurts compilation speed > Reviewed-by: I think that is a good unified solution now, and works in my workspace. I have two small comments: * LIRAssembler_sparc.cpp: There is no "stub->emit_code(this);" like in the x86 code * LIR.hpp: lir_unwind can now be a LIR_Op1. In LIR.cpp you assert that the second operand of the current LIR_Op2 is never used, which is weird. Christian From vladimir.kozlov at sun.com Fri Apr 2 18:31:11 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Sat, 03 Apr 2010 01:31:11 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 59 new changesets Message-ID: <20100403013419.99DE744EED@hg.openjdk.java.net> Changeset: 26ecc6fa29e6 Author: mikejwre Date: 2010-02-04 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/26ecc6fa29e6 Added tag jdk7-b82 for changeset 1999f5b12482 ! .hgtags Changeset: 1e3c5d0474d4 Author: trims Date: 2010-02-05 16:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1e3c5d0474d4 Merge Changeset: 39e0a32bc49b Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/39e0a32bc49b Added tag hs17-b01 for changeset a94714c55065 ! .hgtags Changeset: bd1260aafd87 Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bd1260aafd87 Added tag hs17-b02 for changeset faf94d94786b ! .hgtags Changeset: d9c445aa7bb1 Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d9c445aa7bb1 Added tag hs17-b03 for changeset f4b900403d6e ! .hgtags Changeset: 3940517a1f13 Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3940517a1f13 Added tag hs17-b04 for changeset d8dd291a362a ! .hgtags Changeset: 4458e32d9125 Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4458e32d9125 Added tag hs17-b05 for changeset 9174bb32e934 ! .hgtags Changeset: 36a78dac746f Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/36a78dac746f Added tag hs17-b06 for changeset a5a6adfca6ec ! .hgtags Changeset: bfa6d67a7a29 Author: trims Date: 2010-02-11 19:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bfa6d67a7a29 Added tag hs17-b07 for changeset 3003ddd1d433 ! .hgtags Changeset: 73047d0b13cf Author: trims Date: 2010-02-11 19:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/73047d0b13cf Added tag hs17-b08 for changeset 1f9b07674480 ! .hgtags Changeset: 12076a98a540 Author: trims Date: 2010-02-11 19:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/12076a98a540 Added tag hs17-b09 for changeset ff3232b68fbb ! .hgtags Changeset: 704a172a0918 Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/704a172a0918 Added tag hs16-b01 for changeset 981375ca07b7 ! .hgtags Changeset: e114a6374471 Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e114a6374471 Added tag hs16-b02 for changeset f4cbf78110c7 ! .hgtags Changeset: 3469eafe9bf4 Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3469eafe9bf4 Added tag hs16-b03 for changeset 07c1c01e0315 ! .hgtags Changeset: 26dba59fc9ec Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/26dba59fc9ec Added tag hs16-b04 for changeset 08f86fa55a31 ! .hgtags Changeset: 8b0989046c93 Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8b0989046c93 Added tag hs16-b05 for changeset 32c83fb84370 ! .hgtags Changeset: 5fe06b3f6753 Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5fe06b3f6753 Added tag hs16-b06 for changeset ba313800759b ! .hgtags Changeset: 36ae83035b8e Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/36ae83035b8e Added tag hs16-b07 for changeset 3c0f72981560 ! .hgtags Changeset: 89ef87b378cd Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/89ef87b378cd Added tag hs16-b08 for changeset ac59d4e6dae5 ! .hgtags Changeset: cd89ef31a9c8 Author: trims Date: 2010-02-11 20:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cd89ef31a9c8 Added tag hs15-b01 for changeset 3f844a28c5f4 ! .hgtags Changeset: 2099657b92a1 Author: trims Date: 2010-02-11 20:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2099657b92a1 Added tag hs15-b02 for changeset 1605bb4eb5a7 ! .hgtags Changeset: 9dcad51c5c70 Author: trims Date: 2010-02-11 20:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9dcad51c5c70 Added tag hs15-b03 for changeset 2581d90c6c9b ! .hgtags Changeset: 07118aaebf50 Author: trims Date: 2010-02-11 20:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/07118aaebf50 Added tag hs15-b04 for changeset 9ab385cb0c42 ! .hgtags Changeset: 3f370a32906e Author: trims Date: 2010-02-11 20:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3f370a32906e Added tag hs15-b05 for changeset fafab5d5349c ! .hgtags Changeset: ffc8d176b84b Author: mikejwre Date: 2010-02-12 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ffc8d176b84b Added tag jdk7-b83 for changeset 3f370a32906e ! .hgtags Changeset: 125eb6a9fccf Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/125eb6a9fccf Added tag jdk7-b84 for changeset ffc8d176b84b ! .hgtags Changeset: 1f341bb67b5b Author: trims Date: 2010-02-18 22:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1f341bb67b5b Merge Changeset: 6c9796468b91 Author: trims Date: 2010-02-18 22:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6c9796468b91 6927886: Bump the HS17 build number to 10 Summary: Update the HS17 build number to 10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 418bc80ce139 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/418bc80ce139 Added tag jdk7-b85 for changeset 6c9796468b91 ! .hgtags Changeset: bf823ef06b4f Author: trims Date: 2010-03-08 15:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bf823ef06b4f Added tag hs17-b10 for changeset 418bc80ce139 ! .hgtags Changeset: 6c94fe3c8df3 Author: trims Date: 2010-03-18 16:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6c94fe3c8df3 Merge Changeset: 2a1472c30599 Author: jcoomes Date: 2010-03-03 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2a1472c30599 4396719: Mark Sweep stack overflow on deeply nested Object arrays Summary: Use an explicit stack for object arrays and process them in chunks. Reviewed-by: iveresov, apetrusenko ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp + src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_gc_parallel ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp + src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 94946bdf36bd Author: apetrusenko Date: 2010-03-15 02:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/94946bdf36bd Merge Changeset: 664ae0c5e0e5 Author: johnc Date: 2010-03-11 11:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/664ae0c5e0e5 6755988: G1: assert(new_obj != 0 || ... "should be forwarded") Summary: A TLAB became large enough to be considered a humongous object allowing multiple objects to be allocated in a humongous region, which violates a basic assumption about humongous regions. The changes ensure that TLABs cannot be regarded as humongous. Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 3f0549ed0c98 Author: apetrusenko Date: 2010-03-18 01:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3f0549ed0c98 6921710: G1: assert(new_finger >= _finger && new_finger < _region_limit,"invariant") Summary: If CM task was aborted while scanning the last object of the specified region and the size of that object is equal to bitmap's granularity then the next offset would be equal or over the region limit which is exactly what the assertion states. Reviewed-by: ysr, tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: c385bf94cfb8 Author: jcoomes Date: 2010-03-18 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c385bf94cfb8 6935839: excessive marking stack growth during full gcs Summary: process one item at a time from the objarray stack/queue Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: cc98cc548f51 Author: apetrusenko Date: 2010-03-22 02:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cc98cc548f51 Merge ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp Changeset: d4197f8d516a Author: tonyp Date: 2010-03-18 12:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d4197f8d516a 6935821: G1: threads created during marking do not active their SATB queues Summary: Newly-created threads always had the active field of their SATB queue initialized to false, even if they were created during marking. As a result, updates from threads created during a marking cycle were never enqueued and never processed. The fix includes remaining a method from active() to is_active() for readability and naming consistency. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 4b58861a3570 Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4b58861a3570 Added tag jdk7-b86 for changeset bf823ef06b4f ! .hgtags Changeset: 07226e9eab8f Author: trims Date: 2010-03-18 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/07226e9eab8f 6936366: Fork HS17 to HS18 - renumber Major and build numbers of JVM Summary: Update the Major and build numbers for HS18 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3deb84ecd19d Author: trims Date: 2010-03-23 20:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3deb84ecd19d Added tag hs18-b01 for changeset 07226e9eab8f ! .hgtags Changeset: e7e7e36ccdb5 Author: trims Date: 2010-03-23 20:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e7e7e36ccdb5 Merge ! .hgtags Changeset: 465c39e1fb46 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/465c39e1fb46 Added tag jdk7-b87 for changeset e7e7e36ccdb5 ! .hgtags Changeset: 5c9df1575c39 Author: trims Date: 2010-04-01 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5c9df1575c39 Merge Changeset: 096b18156d91 Author: trims Date: 2010-04-01 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/096b18156d91 6940419: Bump the HS18 build number to 02 Summary: Update the HS18 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3b3d12e645e7 Author: coleenp Date: 2010-03-12 10:42 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3b3d12e645e7 6929067: Stack guard pages should be removed when thread is detached Summary: Add code to unmap stack guard area when thread is detached. Reviewed-by: coleenp, kamg ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp + test/runtime/6929067/T.java + test/runtime/6929067/Test6929067.sh + test/runtime/6929067/invoke.c Changeset: 0f6600cee529 Author: xlu Date: 2010-03-13 16:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0f6600cee529 6934758: Expose the break down of clean up task time during safepoint. Summary: Use -XX:+TraceSafepointCleanupTime to print out the details of each clean up tasks. Reviewed-by: dholmes, ysr ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp Changeset: 21141e23627a Author: dcubed Date: 2010-03-16 17:47 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/21141e23627a 6923488: 4/4 need minor tweaks to HotSpot build for Cygwin Summary: Clean up get_msc_ver, build.bat and build.make in general and for Cygwin. Reviewed-by: ohair ! make/windows/build.bat ! make/windows/build.make ! make/windows/get_msc_ver.sh Changeset: cd20a6f46fec Author: dcubed Date: 2010-03-16 20:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cd20a6f46fec Merge Changeset: e392695de029 Author: fparain Date: 2010-03-17 11:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e392695de029 6935224: Adding new DTrace probes to work with Palantir Summary: Adding probes related to thread scheduling and class initialization Reviewed-by: kamg, never ! src/os/solaris/dtrace/hotspot.d ! src/os/solaris/vm/attachListener_solaris.cpp ! src/share/vm/includeDB_core ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/dtraceAttacher.hpp Changeset: 98ba8ca25feb Author: coleenp Date: 2010-03-18 16:47 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/98ba8ca25feb 6936168: Recent fix for unmapping stack guard pages doesn't close /proc/self/maps Summary: Add close to returns (fix for 6929067 also contributed by aph) Reviewed-by: aph, dcubed, andrew, acorn Contributed-by: aph at redhat.com, andreas.kohn at fredhopper.com ! src/os/linux/vm/os_linux.cpp Changeset: 4f7af0dc447b Author: dcubed Date: 2010-03-23 14:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4f7af0dc447b 6915365: 3/4 assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 Summary: Remove assert to decouple JDK and HotSpot additions of known types. Reviewed-by: mchung ! src/share/vm/services/management.cpp Changeset: 5d393243d487 Author: dcubed Date: 2010-03-23 17:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5d393243d487 Merge Changeset: 39e409a664b3 Author: dcubed Date: 2010-03-25 16:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/39e409a664b3 6938185: 3/4 6923488 breaks Windows command shell builds Summary: Fix build.bat so invoking command shell doesn't exit on error. Fix dirname assumptions. Document some MKS environment dependencies. Reviewed-by: coleenp ! make/windows/build.bat ! make/windows/build.make ! make/windows/create.bat ! make/windows/get_msc_ver.sh Changeset: 84043c7507b9 Author: dcubed Date: 2010-03-25 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/84043c7507b9 Merge Changeset: 4a9cc99938e3 Author: acorn Date: 2010-03-26 11:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4a9cc99938e3 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp Changeset: 7c358fbb6a84 Author: acorn Date: 2010-04-01 11:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7c358fbb6a84 Merge Changeset: 4b60f23c4223 Author: acorn Date: 2010-04-01 20:48 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4b60f23c4223 Merge Changeset: 9bb91718aaf2 Author: kvn Date: 2010-04-02 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9bb91718aaf2 Merge ! src/share/vm/runtime/globals.hpp From tom.rodriguez at oracle.com Mon Apr 5 15:13:47 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 5 Apr 2010 15:13:47 -0700 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: <4BB63B46.7080900@oracle.com> References: <1270211955.23285.8.camel@macbook> <4BB63B46.7080900@oracle.com> Message-ID: <08B111BC-FE8C-4596-84C3-221875B9D81D@oracle.com> I filed 6940976 for this. tom On Apr 2, 2010, at 11:45 AM, Y. Srinivas Ramakrishna wrote: > Ah, good point. Yes this should be possible without too much trouble [1] > (both the automatic promotion and/or the pruning) because the scavangable > nmethods list seems to be processed as a separate root-set, so we can > for example send it a special "always promote" scanner and/or tell the scanner > to drop nmethods that (no longer) have any young refs, the > latter kinda like we do for card scanning. > > Christian or Tom, could one of you please open a CR to track this work so it isn't > forgotten? > > thanks. > -- ramki > > [1] famous last words? > > > On 04/02/10 11:12, Tom Rodriguez wrote: >> That looks good. We still need logic to prune the list of scavengeable nmethods since over time the oops should move out of eden and we can then stop scanning those nmethods. Additionally we may want GC to automatically promote oops referenced by nmethods since they are pretty much guaranteed to be long lived. I don't know if there's any easy way to do that. >> tom >> On Apr 2, 2010, at 5:39 AM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/6940520/webrev.01/ >>> >>> 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations >>> Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. >>> Reviewed-by: >>> >>> During testing of JSR 292's SPARC C2 port I found a couple of crashes >>> which came from unfixed code-embedded oops. >>> >>> This can be triggered with ScavengeRootsInCode={1,2}. >>> >>> The fix is to call fix_oop_relocations in >>> CodeCache::scavenge_root_nmethods_do after oops may have been updated. >>> >>> src/share/vm/code/codeCache.cpp >>> >>> > From john.r.rose at oracle.com Tue Apr 6 02:00:27 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Apr 2010 02:00:27 -0700 Subject: Request for reviews (L): 6939207: refactor constant pool index processing In-Reply-To: References: Message-ID: I have completed this change by centralizing the byte-swapping logic for bytecode instruction operands. Here is the updated webrev: http://cr.openjdk.java.net/~jrose/6939207/webrev.00 The result has three advantages: (a) It is more regular, (b) it has less duplicated code, and (c) it is a more robust basis for adding new bytecode operands (i.e., constant pool types). -- John On Mar 30, 2010, at 4:18 AM, John Rose wrote: > 6939207: refactor constant pool index processing > Summary: Factored cleanup which prepares for enhanced ldc semantics. > > http://cr.openjdk.java.net/~jrose/6939207/webrev.00 > > Bug 6939203 (JSR 292 needs method handle constants) requires an extension to the construct pool structure and the ldc bytecode. In particular, it needs to use the CP cache to manage method references, and therefore the ldc bytecode (when used by the new functionality) need to refer to a CP cache index. > > To do this safely, the JVM's bytecode parsing modules must make a more rigorous distinction between types of bytecode indexes. This change makes clear the difference between (a) a CP index and (b) a CP cache index, and also (1) a network-byte-order index and (2) a native-byte-order index. With clarified distinctions, enforced mechanically, we can safely make the needed modifications. > > This change may be incomplete. I'd like advice on whether to push the change farther. Specifically, we should push all byte swapping to the point where data > is loaded, because the byte order is known most accurately at that point. Currently, we swap it in the CP accessors. See the temporary function 'get_index_native_swap' and the FIXME comments nearby. > > -- John From Christian.Thalinger at Sun.COM Tue Apr 6 02:18:04 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 06 Apr 2010 11:18:04 +0200 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: <08B111BC-FE8C-4596-84C3-221875B9D81D@oracle.com> References: <1270211955.23285.8.camel@macbook> <4BB63B46.7080900@oracle.com> <08B111BC-FE8C-4596-84C3-221875B9D81D@oracle.com> Message-ID: <1270545484.2639.7.camel@macbook> On Mon, 2010-04-05 at 15:13 -0700, Tom Rodriguez wrote: > I filed 6940976 for this. Thanks. -- Christian From Christian.Thalinger at Sun.COM Tue Apr 6 06:41:50 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 06 Apr 2010 15:41:50 +0200 Subject: Request for reviews (M): 6939196: method handle signatures off the boot class path get linkage errors In-Reply-To: References: Message-ID: <1270561310.2639.74.camel@macbook> On Tue, 2010-03-30 at 04:06 -0700, John Rose wrote: > 6939196: method handle signatures off the boot class path get linkage errors > > http://cr.openjdk.java.net/~jrose/6939196/hs-webrev.00/ > http://cr.openjdk.java.net/~jrose/6939196/jdk-webrev.00/ > > The bugtraq description is copied below. > > - Adjust MethodType lookup logic to search off the BCP, but not to cache those results. > - Pass accessing class where it needs to be seen. > - A SignatureStream idiom "as_klass" for class lookup has been refactored. src/share/vm/classfile/systemDictionary.cpp: 2382 bool is_on_bcp; // keep this true as long as we can materialize from the boot classloader Why do need an extra flag? return_bcp_flag seems to always be set to the same value. src/share/vm/prims/methodHandles.cpp: 441 (//defc() == SystemDictionary::InvokeDynamic_klass() || //FIXME What is the problem here? Otherwise looks good. > > Please review the JDK changes along with the JVM changes. They are very simple: > - Remove workaround from MethodHandleImpl lookup code > - Add JUnit regression test to MethodHandlesTest These changes look good. -- Christian From Christian.Thalinger at Sun.COM Tue Apr 6 07:02:22 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 06 Apr 2010 14:02:22 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations Message-ID: <20100406140234.E91AB4440F@hg.openjdk.java.net> Changeset: ed4f78aa9282 Author: twisti Date: 2010-04-06 13:39 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ed4f78aa9282 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. Reviewed-by: kvn, never ! src/share/vm/code/codeCache.cpp From Christian.Thalinger at Sun.COM Tue Apr 6 08:07:05 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 06 Apr 2010 17:07:05 +0200 Subject: Request for reviews (L): 6939203: JSR 292 needs method handle constants In-Reply-To: References: Message-ID: <1270566425.2639.118.camel@macbook> On Tue, 2010-03-30 at 04:24 -0700, John Rose wrote: > 6939203: JSR 292 needs method handle constants > Summary: Add new CP types CONSTANT_MethodHandle, CONSTANT_MethodType; extend 'ldc' bytecode. > http://cr.openjdk.java.net/~jrose/6939203/hs-webrev.00 src/share/vm/interpreter/bytecode.hpp: 404 inline friend Bytecode_loadconstant* Bytecode_loadconstant_at(address bcp, methodHandle method); 405 inline friend Bytecode_loadconstant* Bytecode_loadconstant_at(methodHandle method, int bci); Why are the arguments swapped? int and address should be different types. src/share/vm/interpreter/rewriter.cpp: 142 Bytecodes::Code fastc = Bytecodes::_nop; 143 if (tag.is_method_handle() || tag.is_method_type()) { 144 fastc = (is_wide 145 ? Bytecodes::_fast_aldc_w 146 : Bytecodes::_fast_aldc); 147 } 148 if (fastc != Bytecodes::_nop) { Why do you have a second if here? src/share/vm/prims/jvm.h: + JVM_CONSTANT_MethodHandle = 15, // JSR 292 + JVM_CONSTANT_MethodType = 16 // JSR 292 Is there a particular reason I don't see why this is 15 and 16? > Please review this small JDK change along with it: > http://cr.openjdk.java.net/~jrose/6939203/jdk-webrev.00 Looks good. -- Christian From gbenson at redhat.com Tue Apr 6 08:09:18 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 6 Apr 2010 16:09:18 +0100 Subject: Review Request: Improved stack overflow handling for Zero Message-ID: <20100406150918.GA26320@redhat.com> Hi all, I recently started adding stack overflow checking to Shark, which brought to light a bunch of deficiencies in Zero's stack overflow code. Zero had this really odd, look-ahead overflow handling which was pretty strange, easily fooled, and in retrospect totally unnecessary. I'm pretty sure whoever wrote it was an idiot. This webrev removes the old overflow detection and replaces it with something more straightforward and complete: http://cr.openjdk.java.net/~gbenson/zero-stack-overflow-checks/ Note that a number of calls to Unimplemented have been removed. It shouldn't be possible to have an unhandled stack overflow error with the new code. As a bonus, the new code is mildly faster (about 2%) due to the checks being inlined. I don't have a bug id for this. Cheers, Gary PS I am on vacation for the rest of the week, back Monday 12. -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Tue Apr 6 08:41:41 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 06 Apr 2010 17:41:41 +0200 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: <5166E91B-B858-404F-BAB5-D34E42B8C91C@oracle.com> References: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> <1269942561.982.126.camel@macbook> <5166E91B-B858-404F-BAB5-D34E42B8C91C@oracle.com> Message-ID: <1270568501.2639.122.camel@macbook> On Wed, 2010-03-31 at 12:46 -0700, John Rose wrote: > Christian's comments, plus the move mentioned below, are incorporated in the updated webrev: > http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.01 I guess we also need a SPARC version of MethodHandles::adapter_conversion_ops_supported_mask. Should we add that one here or with one of my SPARC changes? -- Christian From Christian.Thalinger at Sun.COM Tue Apr 6 08:49:15 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 06 Apr 2010 17:49:15 +0200 Subject: Review Request: Improved stack overflow handling for Zero In-Reply-To: <20100406150918.GA26320@redhat.com> References: <20100406150918.GA26320@redhat.com> Message-ID: <1270568955.2639.123.camel@macbook> On Tue, 2010-04-06 at 16:09 +0100, Gary Benson wrote: > Hi all, > > I recently started adding stack overflow checking to Shark, > which brought to light a bunch of deficiencies in Zero's > stack overflow code. Zero had this really odd, look-ahead > overflow handling which was pretty strange, easily fooled, > and in retrospect totally unnecessary. I'm pretty sure > whoever wrote it was an idiot. > > This webrev removes the old overflow detection and replaces > it with something more straightforward and complete: > > http://cr.openjdk.java.net/~gbenson/zero-stack-overflow-checks/ > > Note that a number of calls to Unimplemented have been removed. > It shouldn't be possible to have an unhandled stack overflow > error with the new code. > > As a bonus, the new code is mildly faster (about 2%) due to > the checks being inlined. > > I don't have a bug id for this. I created: 6941224: Improved stack overflow handling for Zero -- Christian From gbenson at redhat.com Tue Apr 6 09:04:21 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 6 Apr 2010 17:04:21 +0100 Subject: Review Request: Improved stack overflow handling for Zero In-Reply-To: <1270568955.2639.123.camel@macbook> References: <20100406150918.GA26320@redhat.com> <1270568955.2639.123.camel@macbook> Message-ID: <20100406160421.GB26320@redhat.com> Christian Thalinger wrote: > On Tue, 2010-04-06 at 16:09 +0100, Gary Benson wrote: > > I recently started adding stack overflow checking to Shark, > > which brought to light a bunch of deficiencies in Zero's > > stack overflow code. Zero had this really odd, look-ahead > > overflow handling which was pretty strange, easily fooled, > > and in retrospect totally unnecessary. I'm pretty sure > > whoever wrote it was an idiot. > > > > This webrev removes the old overflow detection and replaces > > it with something more straightforward and complete: > > > > http://cr.openjdk.java.net/~gbenson/zero-stack-overflow-checks/ > > > > Note that a number of calls to Unimplemented have been removed. > > It shouldn't be possible to have an unhandled stack overflow > > error with the new code. > > > > As a bonus, the new code is mildly faster (about 2%) due to > > the checks being inlined. > > > > I don't have a bug id for this. > > I created: > > 6941224: Improved stack overflow handling for Zero Thank you. Cheers, Gary -- http://gbenson.net/ From john.r.rose at oracle.com Tue Apr 6 11:16:54 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Apr 2010 11:16:54 -0700 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: <1270568501.2639.122.camel@macbook> References: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> <1269942561.982.126.camel@macbook> <5166E91B-B858-404F-BAB5-D34E42B8C91C@oracle.com> <1270568501.2639.122.camel@macbook> Message-ID: On Apr 6, 2010, at 8:41 AM, Christian Thalinger wrote: > On Wed, 2010-03-31 at 12:46 -0700, John Rose wrote: >> Christian's comments, plus the move mentioned below, are incorporated in the updated webrev: >> http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.01 > > I guess we also need a SPARC version of > MethodHandles::adapter_conversion_ops_supported_mask. Should we add > that one here or with one of my SPARC changes? Whichever way makes sense to you is fine with me. I suggest you merge the SPARC support with my changes, and if there is something (like the mask) which belongs in my changes, send me a diff and I'll add it in. -- John From John.Rose at Sun.COM Tue Apr 6 14:44:19 2010 From: John.Rose at Sun.COM (John Rose) Date: Tue, 06 Apr 2010 14:44:19 -0700 Subject: Request for reviews (L): 6939203: JSR 292 needs method handle constants In-Reply-To: <1270566425.2639.118.camel@macbook> References: <1270566425.2639.118.camel@macbook> Message-ID: On Apr 6, 2010, at 8:07 AM, Christian Thalinger wrote: > On Tue, 2010-03-30 at 04:24 -0700, John Rose wrote: >> 6939203: JSR 292 needs method handle constants >> Summary: Add new CP types CONSTANT_MethodHandle, CONSTANT_MethodType; extend 'ldc' bytecode. >> http://cr.openjdk.java.net/~jrose/6939203/hs-webrev.00 > > src/share/vm/interpreter/bytecode.hpp: > > 404 inline friend Bytecode_loadconstant* Bytecode_loadconstant_at(address bcp, methodHandle method); > 405 inline friend Bytecode_loadconstant* Bytecode_loadconstant_at(methodHandle method, int bci); > > Why are the arguments swapped? int and address should be different > types. The (bcp, optional method) pattern mimics Bytecodes::code_at. The (method, bci) pattern mimics a methodOop accessor. The patterns don't mix well. I'll try to boil this down to fewer overloadings. > src/share/vm/interpreter/rewriter.cpp: > > 142 Bytecodes::Code fastc = Bytecodes::_nop; > 143 if (tag.is_method_handle() || tag.is_method_type()) { > 144 fastc = (is_wide > 145 ? Bytecodes::_fast_aldc_w > 146 : Bytecodes::_fast_aldc); > 147 } > 148 if (fastc != Bytecodes::_nop) { > > Why do you have a second if here? No particular reason, other than leaving open an option to extend the aldc treatment to classes or other (future) constant types. I'll merge the two blocks. > src/share/vm/prims/jvm.h: > > + JVM_CONSTANT_MethodHandle = 15, // JSR 292 > + JVM_CONSTANT_MethodType = 16 // JSR 292 > > Is there a particular reason I don't see why this is 15 and 16? Yes; I think the modules project is going to use the code point 13 and I wanted to leave a little extra room after it (14) in case they suddenly invent a second CP tag. This will all look very funny in ten years. >> Please review this small JDK change along with it: >> http://cr.openjdk.java.net/~jrose/6939203/jdk-webrev.00 > > Looks good. Thanks! -- John From John.Rose at Sun.COM Tue Apr 6 14:54:21 2010 From: John.Rose at Sun.COM (John Rose) Date: Tue, 06 Apr 2010 14:54:21 -0700 Subject: Request for reviews (M): 6939196: method handle signatures off the boot class path get linkage errors In-Reply-To: <1270561310.2639.74.camel@macbook> References: <1270561310.2639.74.camel@macbook> Message-ID: <4B0D7382-DA78-4BEE-9C4C-69902165CD33@Sun.COM> On Apr 6, 2010, at 6:41 AM, Christian Thalinger wrote: > On Tue, 2010-03-30 at 04:06 -0700, John Rose wrote: >> 6939196: method handle signatures off the boot class path get linkage errors >> >> http://cr.openjdk.java.net/~jrose/6939196/hs-webrev.00/ >> http://cr.openjdk.java.net/~jrose/6939196/jdk-webrev.00/ >> >> The bugtraq description is copied below. >> >> - Adjust MethodType lookup logic to search off the BCP, but not to cache those results. >> - Pass accessing class where it needs to be seen. >> - A SignatureStream idiom "as_klass" for class lookup has been refactored. > > src/share/vm/classfile/systemDictionary.cpp: > > 2382 bool is_on_bcp; // keep this true as long as we can materialize from the boot classloader > > Why do need an extra flag? return_bcp_flag seems to always be set to > the same value. Just a style thing mainly: Because return_bcp_flag is an out parameter, it is write-only. Also, is_on_bcp is a local variable that the C++ optimizer can control fully. (I don't like putting loop control in unknown reference variables.) I'll move the write of return_bcp_flag out of the loop, to make its role more clear. > src/share/vm/prims/methodHandles.cpp: > > 441 (//defc() == SystemDictionary::InvokeDynamic_klass() || //FIXME > > What is the problem here? Oops, thanks for noticing that. There is no problem at that point, so I'll remove the "//". The note is to remind me of Lookup.findStatic(InvokeDynamic.class, "x", T). It's a corner case that needs some attention. (There's a similar issue with Class.getDeclaredMethod on those magic classes.) > Otherwise looks good. Thanks! >> Please review the JDK changes along with the JVM changes. They are very simple: >> - Remove workaround from MethodHandleImpl lookup code >> - Add JUnit regression test to MethodHandlesTest > > These changes look good. Good; thanks again. Working on invokeGeneric now... -- John From vladimir.kozlov at sun.com Wed Apr 7 01:53:44 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 07 Apr 2010 08:53:44 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6940677: Use 64 bytes chunk copy for arraycopy on Sparc Message-ID: <20100407085401.8DE284442F@hg.openjdk.java.net> Changeset: 0dc88ad3244e Author: kvn Date: 2010-04-06 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0dc88ad3244e 6940677: Use 64 bytes chunk copy for arraycopy on Sparc Summary: For large arrays we should use 64 bytes chunks copy. Reviewed-by: twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp From Christian.Thalinger at Sun.COM Wed Apr 7 02:16:35 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 07 Apr 2010 11:16:35 +0200 Subject: Request for reviews (L): 6939207: refactor constant pool index processing In-Reply-To: References: Message-ID: <1270631795.2639.207.camel@macbook> On Tue, 2010-04-06 at 02:00 -0700, John Rose wrote: > I have completed this change by centralizing the byte-swapping logic for bytecode instruction operands. > > Here is the updated webrev: > http://cr.openjdk.java.net/~jrose/6939207/webrev.00 src/cpu/x86/vm/templateTable_x86_32.cpp, src/cpu/x86/vm/templateTable_x86_64.cpp: 2119 // This kind of CP cache entry does not need t match the byte, because Typo. 2190 bool is_invokevfinal, /*unused*/ I guess the /*unused*/ is for is_invokevfinal, so the "," should be after the comment. src/share/vm/ci/ciStreams.hpp: int get_index_giant() const { - assert_index_size(4); + assert_index_size(4); assert_native_index(); return Bytes::get_native_u4(_bc_start+1); } Should we assert on has_giant_index in this one? src/share/vm/interpreter/templateTable.hpp: + size_t index_size); // one of 1,2,4 What do you think about using enum values instead of sizeof(u?) in the code? And there are a couple of copyright year updates missing. Otherwise looks good and I like the change. -- Christian From Christian.Thalinger at Sun.COM Wed Apr 7 04:02:27 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 07 Apr 2010 13:02:27 +0200 Subject: Request for reviews (M): 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag Message-ID: <1270638147.2639.209.camel@macbook> http://cr.openjdk.java.net/~twisti/6941529/webrev.01/ 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag Summary: During testing a bug was hit when an exception returned to the interpreter and the SP was wrong. Reviewed-by: During SPARC JSR 292 testing I hit a bug when an exception returned to the interpreter and the SP was wrong. That happened because the is_method_handle_exception flag in thread was not reset and still true. The suggested fix is to reset the flag on method entry. Additionally with this fix I'd like to rename is_method_handle_exception to is_method_handle_return since that name fits better. src/cpu/x86/vm/c1_Runtime1_x86.cpp src/cpu/x86/vm/runtime_x86_32.cpp src/cpu/x86/vm/sharedRuntime_x86_64.cpp src/cpu/x86/vm/stubGenerator_x86_32.cpp src/share/vm/opto/runtime.cpp src/share/vm/runtime/sharedRuntime.cpp src/share/vm/runtime/thread.hpp From Christian.Thalinger at Sun.COM Wed Apr 7 06:28:45 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 07 Apr 2010 15:28:45 +0200 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: References: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> <1269942561.982.126.camel@macbook> <5166E91B-B858-404F-BAB5-D34E42B8C91C@oracle.com> <1270568501.2639.122.camel@macbook> Message-ID: <1270646925.2639.213.camel@macbook> On Tue, 2010-04-06 at 11:16 -0700, John Rose wrote: > On Apr 6, 2010, at 8:41 AM, Christian Thalinger wrote: > > > On Wed, 2010-03-31 at 12:46 -0700, John Rose wrote: > >> Christian's comments, plus the move mentioned below, are incorporated in the updated webrev: > >> http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.01 > > > > I guess we also need a SPARC version of > > MethodHandles::adapter_conversion_ops_supported_mask. Should we add > > that one here or with one of my SPARC changes? > > Whichever way makes sense to you is fine with me. I suggest you merge > the SPARC support with my changes, and if there is something (like the > mask) which belongs in my changes, send me a diff and I'll add it in. It seems only the following one is required. I pushed the SPARC C1 and C2 patches to the MLVM repository today so you can also give it a try. diff --git a/src/cpu/sparc/vm/methodHandles_sparc.cpp b/src/cpu/sparc/vm/methodHandles_sparc.cpp --- a/src/cpu/sparc/vm/methodHandles_sparc.cpp +++ b/src/cpu/sparc/vm/methodHandles_sparc.cpp @@ -289,6 +289,23 @@ #endif // PRODUCT +// which conversion op types are implemented here? +int MethodHandles::adapter_conversion_ops_supported_mask() { + return ((1< References: <1270638147.2639.209.camel@macbook> Message-ID: <4BBCB797.6090108@oracle.com> Christian, Why you use int type to save boolean value? Next was confusing: + // Reset MethodHandle flag. + thread->set_is_method_handle_return(false); since: ! void set_is_method_handle_return(int value) { _is_method_handle_return = value; } Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6941529/webrev.01/ > > 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag > Summary: During testing a bug was hit when an exception returned to the interpreter and the SP was wrong. > Reviewed-by: > > During SPARC JSR 292 testing I hit a bug when an exception returned to > the interpreter and the SP was wrong. That happened because the > is_method_handle_exception flag in thread was not reset and still > true. > > The suggested fix is to reset the flag on method entry. > > Additionally with this fix I'd like to rename > is_method_handle_exception to is_method_handle_return since that name > fits better. > > src/cpu/x86/vm/c1_Runtime1_x86.cpp > src/cpu/x86/vm/runtime_x86_32.cpp > src/cpu/x86/vm/sharedRuntime_x86_64.cpp > src/cpu/x86/vm/stubGenerator_x86_32.cpp > src/share/vm/opto/runtime.cpp > src/share/vm/runtime/sharedRuntime.cpp > src/share/vm/runtime/thread.hpp > > From Christian.Thalinger at Sun.COM Wed Apr 7 10:18:34 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 07 Apr 2010 19:18:34 +0200 Subject: Request for reviews (M): 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag In-Reply-To: <4BBCB797.6090108@oracle.com> References: <1270638147.2639.209.camel@macbook> <4BBCB797.6090108@oracle.com> Message-ID: <1270660714.2639.233.camel@macbook> On Wed, 2010-04-07 at 09:49 -0700, Vladimir Kozlov wrote: > Christian, > > Why you use int type to save boolean value? The problem is that not all C compilers use the same data type size for a boolean. So I use an int here. > > Next was confusing: > > + // Reset MethodHandle flag. > + thread->set_is_method_handle_return(false); > > since: > > ! void set_is_method_handle_return(int value) { _is_method_handle_return = value; } Maybe I should change the argument type and do something like: void set_is_method_handle_return(bool value) { _is_method_handle_return = value ? 1 : 0; } -- Christian From vladimir.kozlov at oracle.com Wed Apr 7 10:25:54 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Apr 2010 10:25:54 -0700 Subject: Request for reviews (M): 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag In-Reply-To: <1270660714.2639.233.camel@macbook> References: <1270638147.2639.209.camel@macbook> <4BBCB797.6090108@oracle.com> <1270660714.2639.233.camel@macbook> Message-ID: <4BBCC022.9020109@oracle.com> >> ! void set_is_method_handle_return(int value) { _is_method_handle_return = value; } > > Maybe I should change the argument type and do something like: > > void set_is_method_handle_return(bool value) { _is_method_handle_return = value ? 1 : 0; } Yes, it would be nice. Smart C++ compilers should fold it so the code should be the same as before. Thanks, Vladimir > > -- Christian > From vladimir.kozlov at sun.com Wed Apr 7 10:39:52 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 07 Apr 2010 17:39:52 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6940701: Don't align loops in stubs for Niagara sparc Message-ID: <20100407173959.8785E44440@hg.openjdk.java.net> Changeset: 6476042f815c Author: kvn Date: 2010-04-07 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6476042f815c 6940701: Don't align loops in stubs for Niagara sparc Summary: Don't align loops in stubs for Niagara sparc since NOPs are expensive. Reviewed-by: twisti, never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/globals.hpp From Christian.Thalinger at Sun.COM Wed Apr 7 10:58:32 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 07 Apr 2010 19:58:32 +0200 Subject: Request for reviews (M): 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag In-Reply-To: <4BBCC022.9020109@oracle.com> References: <1270638147.2639.209.camel@macbook> <4BBCB797.6090108@oracle.com> <1270660714.2639.233.camel@macbook> <4BBCC022.9020109@oracle.com> Message-ID: <1270663112.2639.234.camel@macbook> On Wed, 2010-04-07 at 10:25 -0700, Vladimir Kozlov wrote: > >> ! void set_is_method_handle_return(int value) { _is_method_handle_return = value; } > > > > Maybe I should change the argument type and do something like: > > > > void set_is_method_handle_return(bool value) { _is_method_handle_return = value ? 1 : 0; } > > Yes, it would be nice. Smart C++ compilers should fold it so the code > should be the same as before. This should be better: http://cr.openjdk.java.net/~twisti/6941529/webrev.02/ -- Christian From vladimir.kozlov at oracle.com Wed Apr 7 11:00:40 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Apr 2010 11:00:40 -0700 Subject: Request for reviews (M): 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag In-Reply-To: <1270663112.2639.234.camel@macbook> References: <1270638147.2639.209.camel@macbook> <4BBCB797.6090108@oracle.com> <1270660714.2639.233.camel@macbook> <4BBCC022.9020109@oracle.com> <1270663112.2639.234.camel@macbook> Message-ID: <4BBCC848.2040504@oracle.com> Yes. Looks good. Thanks, Vladimir Christian Thalinger wrote: > On Wed, 2010-04-07 at 10:25 -0700, Vladimir Kozlov wrote: >>>> ! void set_is_method_handle_return(int value) { _is_method_handle_return = value; } >>> Maybe I should change the argument type and do something like: >>> >>> void set_is_method_handle_return(bool value) { _is_method_handle_return = value ? 1 : 0; } >> Yes, it would be nice. Smart C++ compilers should fold it so the code >> should be the same as before. > > This should be better: > > http://cr.openjdk.java.net/~twisti/6941529/webrev.02/ > > -- Christian > From tom.rodriguez at oracle.com Wed Apr 7 11:06:53 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Apr 2010 11:06:53 -0700 Subject: Request for reviews (M): 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag In-Reply-To: <1270660714.2639.233.camel@macbook> References: <1270638147.2639.209.camel@macbook> <4BBCB797.6090108@oracle.com> <1270660714.2639.233.camel@macbook> Message-ID: This looks good. Thanks for the rename. tom On Apr 7, 2010, at 10:18 AM, Christian Thalinger wrote: > On Wed, 2010-04-07 at 09:49 -0700, Vladimir Kozlov wrote: >> Christian, >> >> Why you use int type to save boolean value? > > The problem is that not all C compilers use the same data type size for > a boolean. So I use an int here. > >> >> Next was confusing: >> >> + // Reset MethodHandle flag. >> + thread->set_is_method_handle_return(false); >> >> since: >> >> ! void set_is_method_handle_return(int value) { _is_method_handle_return = value; } > > Maybe I should change the argument type and do something like: > > void set_is_method_handle_return(bool value) { _is_method_handle_return = value ? 1 : 0; } > > -- Christian > From Christian.Thalinger at Sun.COM Wed Apr 7 11:16:11 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 07 Apr 2010 20:16:11 +0200 Subject: Request for reviews (M): 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag In-Reply-To: References: <1270638147.2639.209.camel@macbook> <4BBCB797.6090108@oracle.com> <1270660714.2639.233.camel@macbook> Message-ID: <1270664171.2639.236.camel@macbook> On Wed, 2010-04-07 at 11:06 -0700, Tom Rodriguez wrote: > This looks good. Thanks for the rename. Sure :-) -- Christian From vladimir.kozlov at sun.com Wed Apr 7 11:37:53 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 07 Apr 2010 18:37:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6940733: allocate non static oop fields in super and sub classes together Message-ID: <20100407183756.A796044441@hg.openjdk.java.net> Changeset: b9d85fcdf743 Author: kvn Date: 2010-04-07 10:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b9d85fcdf743 6940733: allocate non static oop fields in super and sub classes together Summary: Use FieldsAllocationStyle=2 to allocate non static oop fields in super and sub classes together Reviewed-by: twisti ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/globals.hpp From tom.rodriguez at oracle.com Wed Apr 7 12:15:22 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Apr 2010 12:15:22 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> <94A3DE52-E9C4-4735-AD73-96D1236CB662@ssw.jku.at> <0A302787-F390-40D1-A4EF-D3952E437808@ssw.jku.at> Message-ID: On Apr 2, 2010, at 4:01 PM, Christian Wimmer wrote: >> http://cr.openjdk.java.net/~never/6939930 is a full solution. >> >> 6939930: exception unwind changes in 6919934 hurts compilation speed >> Reviewed-by: > > I think that is a good unified solution now, and works in my workspace. I have two small comments: > > * LIRAssembler_sparc.cpp: There is no "stub->emit_code(this);" like in the x86 code Thanks for catching that. > * LIR.hpp: lir_unwind can now be a LIR_Op1. In LIR.cpp you assert that the second operand of the current LIR_Op2 is never used, which is weird. Yeah, I wimped out on the that. I've fixed that and updated the webrev. tom > > Christian > From vladimir.kozlov at sun.com Wed Apr 7 18:15:24 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 08 Apr 2010 01:15:24 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6940726: Use BIS instruction for allocation prefetch on Sparc Message-ID: <20100408011542.4158844448@hg.openjdk.java.net> Changeset: 9e321dcfa5b7 Author: kvn Date: 2010-04-07 12:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9e321dcfa5b7 6940726: Use BIS instruction for allocation prefetch on Sparc Summary: Use BIS instruction for allocation prefetch on Sparc Reviewed-by: twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/globals.hpp From Christian.Thalinger at Sun.COM Thu Apr 8 01:33:55 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 08 Apr 2010 10:33:55 +0200 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> <94A3DE52-E9C4-4735-AD73-96D1236CB662@ssw.jku.at> <0A302787-F390-40D1-A4EF-D3952E437808@ssw.jku.at> Message-ID: <1270715635.2639.242.camel@macbook> On Wed, 2010-04-07 at 12:15 -0700, Tom Rodriguez wrote: > On Apr 2, 2010, at 4:01 PM, Christian Wimmer wrote: > > >> http://cr.openjdk.java.net/~never/6939930 is a full solution. > >> > >> 6939930: exception unwind changes in 6919934 hurts compilation speed > >> Reviewed-by: > > > > I think that is a good unified solution now, and works in my workspace. I have two small comments: > > > > * LIRAssembler_sparc.cpp: There is no "stub->emit_code(this);" like in the x86 code > > Thanks for catching that. > > > * LIR.hpp: lir_unwind can now be a LIR_Op1. In LIR.cpp you assert that the second operand of the current LIR_Op2 is never used, which is weird. > > Yeah, I wimped out on the that. I've fixed that and updated the webrev. src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp: 2123 __ br(Assembler::always, false, Assembler::pn, _unwind_handler_entry); Why do you use Assembler::pn for this branch? Wouldn't a __ ba(...) be the right instruction here? Otherwise looks good. -- Christian From Christian.Thalinger at Sun.COM Thu Apr 8 04:24:58 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 08 Apr 2010 13:24:58 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1269027319.2224.10.camel@macbook> References: <1269027319.2224.10.camel@macbook> Message-ID: <1270725898.2639.267.camel@macbook> On Fri, 2010-03-19 at 20:35 +0100, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6829193/webrev.01/ > > There are unimplemented portions of the hotspot code for method > handles and invokedynamic specific to SPARC. They need to be filled > in. > > This change adds SPARC interpreter support. > > src/cpu/sparc/vm/assembler_sparc.cpp > src/cpu/sparc/vm/assembler_sparc.hpp > src/cpu/sparc/vm/interp_masm_sparc.cpp > src/cpu/sparc/vm/interp_masm_sparc.hpp > src/cpu/sparc/vm/interpreter_sparc.cpp > src/cpu/sparc/vm/methodHandles_sparc.cpp > src/cpu/sparc/vm/stubGenerator_sparc.cpp > src/cpu/sparc/vm/templateInterpreter_sparc.cpp > src/cpu/sparc/vm/templateTable_sparc.cpp > src/share/vm/prims/methodHandles.hpp Can I get some reviews on this one? As I'm sending out C1 and C2 reviews today. -- Christian From Christian.Thalinger at Sun.COM Thu Apr 8 04:25:14 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 08 Apr 2010 13:25:14 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 Message-ID: <1270725914.2639.268.camel@macbook> http://cr.openjdk.java.net/~twisti/6930772/webrev.01/ 6930772: JSR 292 needs to support SPARC C1 Summary: C1 for SPARC needs to support JSR 292. Reviewed-by: C1 for SPARC needs to support JSR 292. src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp src/cpu/sparc/vm/c1_Runtime1_sparc.cpp src/cpu/sparc/vm/frame_sparc.cpp src/cpu/sparc/vm/sharedRuntime_sparc.cpp src/share/vm/c1/c1_LIR.hpp From Christian.Thalinger at Sun.COM Thu Apr 8 04:25:16 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 08 Apr 2010 13:25:16 +0200 Subject: Request for reviews (S): 6934104: JSR 292 needs to support SPARC C2 Message-ID: <1270725916.2639.269.camel@macbook> http://cr.openjdk.java.net/~twisti/6934104/webrev.01/ 6934104: JSR 292 needs to support SPARC C2 Summary: C2 for SPARC needs to support JSR 292. Reviewed-by: C2 for SPARC needs to support JSR 292. src/cpu/sparc/vm/runtime_sparc.cpp src/cpu/sparc/vm/sparc.ad From Christian.Thalinger at Sun.COM Thu Apr 8 04:34:45 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 08 Apr 2010 11:34:45 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag Message-ID: <20100408113501.A47AC4445B@hg.openjdk.java.net> Changeset: 93767e6a2dfd Author: twisti Date: 2010-04-08 10:55 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/93767e6a2dfd 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag Summary: During testing a bug was hit when an exception returned to the interpreter and the SP was wrong. Reviewed-by: kvn, never ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.hpp From tom.rodriguez at oracle.com Thu Apr 8 09:47:48 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Apr 2010 09:47:48 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <1270715635.2639.242.camel@macbook> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> <94A3DE52-E9C4-4735-AD73-96D1236CB662@ssw.jku.at> <0A302787-F390-40D1-A4EF-D3952E437808@ssw.jku.at> <1270715635.2639.242.camel@macbook> Message-ID: On Apr 8, 2010, at 1:33 AM, Christian Thalinger wrote: > On Wed, 2010-04-07 at 12:15 -0700, Tom Rodriguez wrote: >> On Apr 2, 2010, at 4:01 PM, Christian Wimmer wrote: >> >>>> http://cr.openjdk.java.net/~never/6939930 is a full solution. >>>> >>>> 6939930: exception unwind changes in 6919934 hurts compilation speed >>>> Reviewed-by: >>> >>> I think that is a good unified solution now, and works in my workspace. I have two small comments: >>> >>> * LIRAssembler_sparc.cpp: There is no "stub->emit_code(this);" like in the x86 code >> >> Thanks for catching that. >> >>> * LIR.hpp: lir_unwind can now be a LIR_Op1. In LIR.cpp you assert that the second operand of the current LIR_Op2 is never used, which is weird. >> >> Yeah, I wimped out on the that. I've fixed that and updated the webrev. > > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp: > > 2123 __ br(Assembler::always, false, Assembler::pn, _unwind_handler_entry); > > Why do you use Assembler::pn for this branch? Wouldn't a __ ba(...) be > the right instruction here? It's a copy paste from somewhere else. I don't think it really matters but I fixed that one and the place I copied it from. I've updated the webrev. Thanks! tom > > Otherwise looks good. > > -- Christian > From igor.veresov at oracle.com Thu Apr 8 11:38:22 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 08 Apr 2010 11:38:22 -0700 Subject: Request for review(S): c1 64 bit fixes Message-ID: <4BBE229E.4010602@oracle.com> This fixes lir_cmp_l2i on x64 and sparc 64bit, and the debug info generation. Webrev: http://cr.openjdk.java.net/~iveresov/6942223/webrev/ From tom.rodriguez at oracle.com Thu Apr 8 11:38:51 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Apr 2010 11:38:51 -0700 Subject: Request for reviews (S): 6934104: JSR 292 needs to support SPARC C2 In-Reply-To: <1270725916.2639.269.camel@macbook> References: <1270725916.2639.269.camel@macbook> Message-ID: Looks good. tom On Apr 8, 2010, at 4:25 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6934104/webrev.01/ > > 6934104: JSR 292 needs to support SPARC C2 > Summary: C2 for SPARC needs to support JSR 292. > Reviewed-by: > > C2 for SPARC needs to support JSR 292. > > src/cpu/sparc/vm/runtime_sparc.cpp > src/cpu/sparc/vm/sparc.ad > > From tom.rodriguez at oracle.com Thu Apr 8 11:43:20 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Apr 2010 11:43:20 -0700 Subject: Request for review(S): c1 64 bit fixes In-Reply-To: <4BBE229E.4010602@oracle.com> References: <4BBE229E.4010602@oracle.com> Message-ID: <213498D4-278A-4DB1-B0CD-2DB6B544B6FE@oracle.com> assembler_x86.cpp: + int enc =3D prefix_and_encode(dst->encoding(), true); What's with the 3D? Otherwise it looks good. tom On Apr 8, 2010, at 11:38 AM, Igor Veresov wrote: > This fixes lir_cmp_l2i on x64 and sparc 64bit, and the debug info generation. > > Webrev: http://cr.openjdk.java.net/~iveresov/6942223/webrev/ From vladimir.kozlov at oracle.com Thu Apr 8 11:45:08 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Apr 2010 11:45:08 -0700 Subject: Request for reviews (S): 6934104: JSR 292 needs to support SPARC C2 In-Reply-To: <1270725916.2639.269.camel@macbook> References: <1270725916.2639.269.camel@macbook> Message-ID: <4BBE2434.8010404@oracle.com> Good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6934104/webrev.01/ > > 6934104: JSR 292 needs to support SPARC C2 > Summary: C2 for SPARC needs to support JSR 292. > Reviewed-by: > > C2 for SPARC needs to support JSR 292. > > src/cpu/sparc/vm/runtime_sparc.cpp > src/cpu/sparc/vm/sparc.ad > > From igor.veresov at oracle.com Thu Apr 8 11:54:32 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 08 Apr 2010 11:54:32 -0700 Subject: Request for review(S): c1 64 bit fixes In-Reply-To: <213498D4-278A-4DB1-B0CD-2DB6B544B6FE@oracle.com> References: <4BBE229E.4010602@oracle.com> <213498D4-278A-4DB1-B0CD-2DB6B544B6FE@oracle.com> Message-ID: <4BBE2668.4020304@oracle.com> On 4/8/10 11:43 AM, Tom Rodriguez wrote: > assembler_x86.cpp: > > + int enc =3D prefix_and_encode(dst->encoding(), true); > > What's with the 3D? Otherwise it looks good. Oops, bad transplating from another workspace. Thanks, igor > > tom > > On Apr 8, 2010, at 11:38 AM, Igor Veresov wrote: > >> This fixes lir_cmp_l2i on x64 and sparc 64bit, and the debug info generation. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6942223/webrev/ > From tom.rodriguez at oracle.com Thu Apr 8 12:01:21 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Apr 2010 12:01:21 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1270725914.2639.268.camel@macbook> References: <1270725914.2639.268.camel@macbook> Message-ID: <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> It says that lir_dynamic_call already has a filled delay slot but I don't see where that's happening. If there's special work that should be inserted in the delay slot then I think it should be inserted here. Otherwise this looks ok. tom On Apr 8, 2010, at 4:25 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6930772/webrev.01/ > > 6930772: JSR 292 needs to support SPARC C1 > Summary: C1 for SPARC needs to support JSR 292. > Reviewed-by: > > C1 for SPARC needs to support JSR 292. > > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp > src/cpu/sparc/vm/c1_Runtime1_sparc.cpp > src/cpu/sparc/vm/frame_sparc.cpp > src/cpu/sparc/vm/sharedRuntime_sparc.cpp > src/share/vm/c1/c1_LIR.hpp > > From igor.veresov at sun.com Thu Apr 8 14:27:13 2010 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Thu, 08 Apr 2010 21:27:13 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6942223: c1 64 bit fixes Message-ID: <20100408212716.B1AF044469@hg.openjdk.java.net> Changeset: 0a43776437b6 Author: iveresov Date: 2010-04-08 12:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0a43776437b6 6942223: c1 64 bit fixes Summary: This fixes lir_cmp_l2i on x64 and sparc 64bit, and the debug info generation. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LinearScan.cpp From vladimir.kozlov at oracle.com Thu Apr 8 15:50:33 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Apr 2010 15:50:33 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1270725898.2639.267.camel@macbook> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> Message-ID: <4BBE5DB9.8090203@oracle.com> Next new method is missing assert_different_registers: MacroAssembler::load_method_handle_vmslots New parameter receiver_can_be_null is not used in profile_virtual_call(). Could you rename Rtmp and Rdst into cache and tmp in IntRtmperpreterMacroAssembler::get_index_at_bcp() since it is confusing? I known that get_{2|4}_byte_integer_at_bcp() use Rtmp and Rdst but callers used cache and tmp. MethodHandles::generate_method_handle_interpreter_entry(): ! Register tem = G5_method; ! for (jint* pchase = methodOopDesc::method_type_offsets_chain(); (*pchase) != -1; pchase++) { ! __ ld_ptr(tem, *pchase, G5_method_type); ! tem = G5_method_type; // yes, it's the same register... ^ it is loop invariant, why you put it inside? ! } MethodHandles::generate_method_handle_interpreter_entry() has next code but I don't see O1 initialization and the comment says "O0, O1: garbage temps, blown away" ! // given the MethodType, find out where the MH argument is buried ! __ ld_ptr(G5_method_type, __ delayed_value(java_dyn_MethodType::form_offset_in_bytes, O1_scratch), O0_argslot); ! __ ld(O0_argslot, __ delayed_value(java_dyn_MethodTypeForm::vmslots_offset_in_bytes, O1_scratch), O0_argslot); ! __ ld_ptr(__ argument_address(O0_argslot), G3_method_handle); ! ! __ check_method_handle_type(G5_method_type, G3_method_handle, O1_scratch, wrong_method_type); ! __ jump_to_method_handle_entry(G3_method_handle, O1_scratch); ! ! return entry_point; ! } Also MacroAssembler::load_method_handle_vmslots() has next code which looks similar to above but has the check "!= 0" ! if (java_dyn_MethodHandle::vmslots_offset_in_bytes() != 0) { ! // hoist vmslots into every mh to avoid dependent load chain ! ld( Address(mh_reg, delayed_value(java_dyn_MethodHandle::vmslots_offset_in_bytes, temp_reg)), vmslots_reg); ! } else { ! Register temp2_reg = vmslots_reg; ! ld_ptr(Address(mh_reg, delayed_value(java_dyn_MethodHandle::type_offset_in_bytes, temp_reg)), temp2_reg); ! ld_ptr(Address(temp2_reg, delayed_value(java_dyn_MethodType::form_offset_in_bytes, temp_reg)), temp2_reg); ! ld( Address(temp2_reg, delayed_value(java_dyn_MethodTypeForm::vmslots_offset_in_bytes, temp_reg)), vmslots_reg); ! } In verify_argslot() and other places where you are comparing 64 bit values (in 64 bit VM) you need to use brx() instead of br(). Vladimir Christian Thalinger wrote: > On Fri, 2010-03-19 at 20:35 +0100, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6829193/webrev.01/ >> >> There are unimplemented portions of the hotspot code for method >> handles and invokedynamic specific to SPARC. They need to be filled >> in. >> >> This change adds SPARC interpreter support. >> >> src/cpu/sparc/vm/assembler_sparc.cpp >> src/cpu/sparc/vm/assembler_sparc.hpp >> src/cpu/sparc/vm/interp_masm_sparc.cpp >> src/cpu/sparc/vm/interp_masm_sparc.hpp >> src/cpu/sparc/vm/interpreter_sparc.cpp >> src/cpu/sparc/vm/methodHandles_sparc.cpp >> src/cpu/sparc/vm/stubGenerator_sparc.cpp >> src/cpu/sparc/vm/templateInterpreter_sparc.cpp >> src/cpu/sparc/vm/templateTable_sparc.cpp >> src/share/vm/prims/methodHandles.hpp > > Can I get some reviews on this one? As I'm sending out C1 and C2 > reviews today. > > -- Christian > From john.rose at sun.com Thu Apr 8 21:20:01 2010 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 09 Apr 2010 04:20:01 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 8 new changesets Message-ID: <20100409042028.B41F544491@hg.openjdk.java.net> Changeset: b5d78a3b8843 Author: kvn Date: 2009-12-03 14:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b5d78a3b8843 6892265: System.arraycopy unable to reference elements beyond Integer.MAX_VALUE bytes Summary: Use size_t type cast to widen int values in typeArrayKlass::copy_array(). Reviewed-by: never, jcoomes ! src/share/vm/oops/typeArrayKlass.cpp + test/compiler/6892265/Test.java Changeset: ae4032fb0a5b Author: kvn Date: 2010-01-21 10:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ae4032fb0a5b 6894807: No ClassCastException for HashAttributeSet constructors if run with -Xcomp Summary: Return interface klass type if it is exact. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/type.cpp Changeset: 0c3f888b7636 Author: acorn Date: 2010-01-19 16:03 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0c3f888b7636 6626217: Fixed loader constraint array handling Summary: Loader constraints track array elements, not arrays themselves. Reviewed-by: dcubed, kevinw ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3d531bbe5917 Author: acorn Date: 2010-01-28 13:59 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3d531bbe5917 Merge Changeset: f5dd08ad65df Author: acorn Date: 2010-03-15 15:51 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f5dd08ad65df 6932480: Fix crash in CompilerThread/Parser. Unloaded array klass? Summary: Restore code deleted in 6626217 Reviewed-by: asaha, kevinw ! src/share/vm/ci/ciEnv.cpp Changeset: 09ac706c2623 Author: asaha Date: 2010-03-24 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/09ac706c2623 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp - src/share/vm/gc_implementation/g1/ptrQueue.inline.hpp ! src/share/vm/opto/type.cpp Changeset: 895d9ade6111 Author: asaha Date: 2010-04-06 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/895d9ade6111 Merge ! src/share/vm/opto/type.cpp Changeset: 213fbcf54799 Author: jrose Date: 2010-04-08 17:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/213fbcf54799 Merge From Christian.Thalinger at Sun.COM Fri Apr 9 01:22:46 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 09 Apr 2010 10:22:46 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> Message-ID: <1270801366.1510.6.camel@macbook> On Thu, 2010-04-08 at 12:01 -0700, Tom Rodriguez wrote: > It says that lir_dynamic_call already has a filled delay slot but I > don't see where that's happening. If there's special work that should > be inserted in the delay slot then I think it should be inserted here. > Otherwise this looks ok. Oops, thanks. I missed something during the merge. I updated the webrev. -- Christian From john.coomes at sun.com Fri Apr 9 01:54:20 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 09 Apr 2010 08:54:20 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b88 for changeset 82135c848d5f Message-ID: <20100409085421.13C524449F@hg.openjdk.java.net> Changeset: 9d9097eb4b5a Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/9d9097eb4b5a Added tag jdk7-b88 for changeset 82135c848d5f ! .hgtags From john.coomes at sun.com Fri Apr 9 01:54:26 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 09 Apr 2010 08:54:26 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b88 for changeset 39e14d2da687 Message-ID: <20100409085430.96A1F444A0@hg.openjdk.java.net> Changeset: bb4424c5e778 Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/bb4424c5e778 Added tag jdk7-b88 for changeset 39e14d2da687 ! .hgtags From john.coomes at sun.com Fri Apr 9 01:57:27 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 09 Apr 2010 08:57:27 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b88 for changeset d8ebd1591003 Message-ID: <20100409085728.0EE2E444A1@hg.openjdk.java.net> Changeset: d2818fd2b036 Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/d2818fd2b036 Added tag jdk7-b88 for changeset d8ebd1591003 ! .hgtags From john.coomes at sun.com Fri Apr 9 01:57:35 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 09 Apr 2010 08:57:35 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b88 for changeset 8c666f8f3565 Message-ID: <20100409085735.5065D444A2@hg.openjdk.java.net> Changeset: bf3675aa7f20 Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/bf3675aa7f20 Added tag jdk7-b88 for changeset 8c666f8f3565 ! .hgtags From john.coomes at sun.com Fri Apr 9 01:57:43 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 09 Apr 2010 08:57:43 +0000 Subject: hg: jdk7/hotspot-comp/jdk: Added tag jdk7-b88 for changeset b3c69282f6d3 Message-ID: <20100409085828.0C493444A3@hg.openjdk.java.net> Changeset: b50cfd4479fa Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b50cfd4479fa Added tag jdk7-b88 for changeset b3c69282f6d3 ! .hgtags From john.coomes at sun.com Fri Apr 9 02:01:23 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 09 Apr 2010 09:01:23 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b88 for changeset f9b5d4867a26 Message-ID: <20100409090130.AC032444A4@hg.openjdk.java.net> Changeset: 737185f3300f Author: mikejwre Date: 2010-04-08 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/737185f3300f Added tag jdk7-b88 for changeset f9b5d4867a26 ! .hgtags From Christian.Thalinger at Sun.COM Fri Apr 9 08:13:24 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 09 Apr 2010 17:13:24 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <4BBE5DB9.8090203@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> Message-ID: <1270826004.1510.263.camel@macbook> On Thu, 2010-04-08 at 15:50 -0700, Vladimir Kozlov wrote: > Next new method is missing assert_different_registers: > MacroAssembler::load_method_handle_vmslots I added it to the x86 version too. > > New parameter receiver_can_be_null is not used in profile_virtual_call(). Oops, I missed that during the port. Thanks. > > Could you rename Rtmp and Rdst into cache and tmp in > > IntRtmperpreterMacroAssembler::get_index_at_bcp() > > since it is confusing? > I known that get_{2|4}_byte_integer_at_bcp() use Rtmp and Rdst > but callers used cache and tmp. Good point, I changed that. Additionally I renamed the method to get_cache_index_at_bcp to be in sync with x86. > > MethodHandles::generate_method_handle_interpreter_entry(): > > ! Register tem = G5_method; > ! for (jint* pchase = methodOopDesc::method_type_offsets_chain(); (*pchase) != -1; pchase++) { > ! __ ld_ptr(tem, *pchase, G5_method_type); > ! tem = G5_method_type; // yes, it's the same register... > ^ it is loop invariant, why you put it inside? > ! } I'm not sure I understand. G5_method_type is loaded in the ld-ptr instruction from Address(tem, *pchase). > > > MethodHandles::generate_method_handle_interpreter_entry() has next > code but I don't see O1 initialization > and the comment says "O0, O1: garbage temps, blown away" > > ! // given the MethodType, find out where the MH argument is buried > ! __ ld_ptr(G5_method_type, __ delayed_value(java_dyn_MethodType::form_offset_in_bytes, O1_scratch), O0_argslot); > ! __ ld(O0_argslot, __ delayed_value(java_dyn_MethodTypeForm::vmslots_offset_in_bytes, O1_scratch), O0_argslot); > ! __ ld_ptr(__ argument_address(O0_argslot), G3_method_handle); > ! > ! __ check_method_handle_type(G5_method_type, G3_method_handle, O1_scratch, wrong_method_type); > ! __ jump_to_method_handle_entry(G3_method_handle, O1_scratch); > ! > ! return entry_point; > ! } It's set in delayed_value. > > Also MacroAssembler::load_method_handle_vmslots() has next code which > looks similar to above but has the check "!= 0" > > ! if (java_dyn_MethodHandle::vmslots_offset_in_bytes() != 0) { > ! // hoist vmslots into every mh to avoid dependent load chain > ! ld( Address(mh_reg, delayed_value(java_dyn_MethodHandle::vmslots_offset_in_bytes, temp_reg)), vmslots_reg); > ! } else { > ! Register temp2_reg = vmslots_reg; > ! ld_ptr(Address(mh_reg, delayed_value(java_dyn_MethodHandle::type_offset_in_bytes, temp_reg)), temp2_reg); > ! ld_ptr(Address(temp2_reg, delayed_value(java_dyn_MethodType::form_offset_in_bytes, temp_reg)), temp2_reg); > ! ld( Address(temp2_reg, delayed_value(java_dyn_MethodTypeForm::vmslots_offset_in_bytes, temp_reg)), vmslots_reg); > ! } You want me to reuse that code? > > In verify_argslot() and other places where you are comparing 64 bit > values (in 64 bit VM) you need to use brx() instead of br(). Done. Here is the updated webrev: http://cr.openjdk.java.net/~twisti/6829193/webrev.02/ -- Christian From vladimir.kozlov at oracle.com Fri Apr 9 09:34:18 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Apr 2010 09:34:18 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1270826004.1510.263.camel@macbook> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> Message-ID: <4BBF570A.5080903@oracle.com> On 4/9/10 8:13 AM, Christian Thalinger wrote: >> >> MethodHandles::generate_method_handle_interpreter_entry(): >> >> ! Register tem = G5_method; >> ! for (jint* pchase = methodOopDesc::method_type_offsets_chain(); (*pchase) != -1; pchase++) { >> ! __ ld_ptr(tem, *pchase, G5_method_type); >> ! tem = G5_method_type; // yes, it's the same register... >> ^ it is loop invariant, why you put it inside? >> ! } > > I'm not sure I understand. G5_method_type is loaded in the ld-ptr > instruction from Address(tem, *pchase). tem = G5_method_type is register renaming - it is not moving value, so you don't need to do renaming inside loop. > >> >> >> MethodHandles::generate_method_handle_interpreter_entry() has next >> code but I don't see O1 initialization >> and the comment says "O0, O1: garbage temps, blown away" >> >> ! // given the MethodType, find out where the MH argument is buried >> ! __ ld_ptr(G5_method_type, __ delayed_value(java_dyn_MethodType::form_offset_in_bytes, O1_scratch), O0_argslot); >> ! __ ld(O0_argslot, __ delayed_value(java_dyn_MethodTypeForm::vmslots_offset_in_bytes, O1_scratch), O0_argslot); >> ! __ ld_ptr(__ argument_address(O0_argslot), G3_method_handle); >> ! >> ! __ check_method_handle_type(G5_method_type, G3_method_handle, O1_scratch, wrong_method_type); >> ! __ jump_to_method_handle_entry(G3_method_handle, O1_scratch); >> ! >> ! return entry_point; >> ! } > > It's set in delayed_value. OK, I see it now. > >> >> Also MacroAssembler::load_method_handle_vmslots() has next code which >> looks similar to above but has the check "!= 0" >> >> ! if (java_dyn_MethodHandle::vmslots_offset_in_bytes() != 0) { >> ! // hoist vmslots into every mh to avoid dependent load chain >> ! ld( Address(mh_reg, delayed_value(java_dyn_MethodHandle::vmslots_offset_in_bytes, temp_reg)), vmslots_reg); >> ! } else { >> ! Register temp2_reg = vmslots_reg; >> ! ld_ptr(Address(mh_reg, delayed_value(java_dyn_MethodHandle::type_offset_in_bytes, temp_reg)), temp2_reg); >> ! ld_ptr(Address(temp2_reg, delayed_value(java_dyn_MethodType::form_offset_in_bytes, temp_reg)), temp2_reg); >> ! ld( Address(temp2_reg, delayed_value(java_dyn_MethodTypeForm::vmslots_offset_in_bytes, temp_reg)), vmslots_reg); >> ! } > > You want me to reuse that code? No. I was confused that in load_method_handle_vmslots() there is separate code when vmslots_offset_in_bytes() != 0 and generate_method_handle_interpreter_entry() does not have such code. Vladimir > >> >> In verify_argslot() and other places where you are comparing 64 bit >> values (in 64 bit VM) you need to use brx() instead of br(). > > Done. > > Here is the updated webrev: > > http://cr.openjdk.java.net/~twisti/6829193/webrev.02/ > > -- Christian > From tom.rodriguez at oracle.com Fri Apr 9 11:06:31 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 9 Apr 2010 11:06:31 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1270801366.1510.6.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> Message-ID: <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> I don't like the way this is structured. Why not move the preserve/restore SP logic up into the LIR as regular moves? Then you don't need any of this special handling. In fact the delay slot filling will likely move the preserve SP logic into the delay slot as you would like it to be. tom On Apr 9, 2010, at 1:22 AM, Christian Thalinger wrote: > On Thu, 2010-04-08 at 12:01 -0700, Tom Rodriguez wrote: >> It says that lir_dynamic_call already has a filled delay slot but I >> don't see where that's happening. If there's special work that should >> be inserted in the delay slot then I think it should be inserted here. >> Otherwise this looks ok. > > Oops, thanks. I missed something during the merge. I updated the > webrev. > > -- Christian > From tom.rodriguez at oracle.com Mon Apr 12 13:46:26 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 12 Apr 2010 13:46:26 -0700 Subject: review (XS) for 6938026: C2 compiler fails in Node::rematerialize()const Message-ID: <1E2BF563-51B0-4227-A411-30F1C67F71E0@oracle.com> http://cr.openjdk.java.net/~never/6938026/ 6938026: C2 compiler fails in Node::rematerialize()const Reviewed-by: This appears to be a long standing issue with OSR entry points. If ciTypeFlow proves that some local is null at the OSR entry it reports TypePtr::NULL_PTR as its type. Type::basic_type report T_ADDRESS for NULL_PTR so fetch_interpreter_stacke thinks this local is a jsr/ret address and emits a load that is typed as TypeRawPtr::BOTTOM but the bytecodes think this is an oop of some kind. Once this gets into the graph it can cause the graph to collapse in funny ways, in this case it allowed top into the final graph which causes us to die during register allocation. The bug is triggered because the use of an agent in the program keeps more of the locals alive. Without the use of the agent this local would be dead in the case where it went wrong and nothing would have happened. As far as I can tell this has always been an issue but it took the right bytecodes to expose it. I was unable to build a test case to expose the problem though asserts that checked for NULL_PTR in OSR entry points found it to be pretty common. src/share/vm/opto/parse1.cpp From Christian.Thalinger at Sun.COM Tue Apr 13 00:07:20 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 13 Apr 2010 09:07:20 +0200 Subject: review (XS) for 6938026: C2 compiler fails in Node::rematerialize()const In-Reply-To: <1E2BF563-51B0-4227-A411-30F1C67F71E0@oracle.com> References: <1E2BF563-51B0-4227-A411-30F1C67F71E0@oracle.com> Message-ID: <1271142440.2134.11.camel@macbook> On Mon, 2010-04-12 at 13:46 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6938026/ > > 6938026: C2 compiler fails in Node::rematerialize()const > Reviewed-by: > > This appears to be a long standing issue with OSR entry points. If > ciTypeFlow proves that some local is null at the OSR entry it reports > TypePtr::NULL_PTR as its type. Type::basic_type report T_ADDRESS for > NULL_PTR so fetch_interpreter_stacke thinks this local is a jsr/ret > address and emits a load that is typed as TypeRawPtr::BOTTOM but the > bytecodes think this is an oop of some kind. Once this gets into the > graph it can cause the graph to collapse in funny ways, in this case > it allowed top into the final graph which causes us to die during > register allocation. The bug is triggered because the use of an agent > in the program keeps more of the locals alive. Without the use of the > agent this local would be dead in the case where it went wrong and > nothing would have happened. As far as I can tell this has always > been an issue but it took the right bytecodes to expose it. I was > unable to build a test case to expose the problem though asserts that > checked for NULL_PTR in OSR entry points found it to be pretty common. > > src/share/vm/opto/parse1.cpp Looks good. -- Christian From yamauchi at google.com Tue Apr 13 12:11:29 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 13 Apr 2010 12:11:29 -0700 Subject: Short/Character.reverseBytes intrinsics Message-ID: Hi there, I'd like to contribute this patch that implements the intrinsics for Short/Character.reverseBytes (in C2): http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ (Patch 1) (Thanks to Chuck for reviewing it and creating the webrev on my behalf.) This adds new siblings for the existing Integer/Long.reverseBytes intrinsics. Note: I did my best for the sparc implementation (sparc.ad) but haven't been able to build or test it (I don't have access to a sparc machine.) An impact of this patch can be seen in the microbenchmark jdk/test/java/nio/Buffer/SwapMicroBenchmark (which was written by Martin) with an experimental patch that lets DirectByteBuffer use those intrinsics (instead of simple Java implementations) on non-native endian operations: http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ (Patch 2) This patch hasn't been checked in yet but is being worked on by Martin and Ulf. The numbers from my measurements on x86 32 bit follow. Note the numbers for BIG_ENDIAN. ----------Unmodified---------- Method Millis Ratio swap char BIG_ENDIAN 64 1.000 swap char LITTLE_ENDIAN 31 0.492 swap short BIG_ENDIAN 75 1.176 swap short LITTLE_ENDIAN 31 0.496 swap int BIG_ENDIAN 45 0.711 swap int LITTLE_ENDIAN 8 0.125 swap long BIG_ENDIAN 72 1.131 swap long LITTLE_ENDIAN 17 0.277 ----------Modified (with Patches 1 and 2)---------- Method Millis Ratio swap char BIG_ENDIAN 44 1.000 swap char LITTLE_ENDIAN 31 0.709 swap short BIG_ENDIAN 44 1.004 swap short LITTLE_ENDIAN 31 0.708 swap int BIG_ENDIAN 18 0.423 swap int LITTLE_ENDIAN 8 0.180 swap long BIG_ENDIAN 24 0.544 swap long LITTLE_ENDIAN 17 0.400 The speedups are clearly non-trivial. The speedup for int/long is due to the use of the existing Integer/Long.reverseBytes intrinsics in DirectByteBuffer (Patch 2). The speedup for short/char is due to the use of the new Character/Short.reverseBytes intrinsics in DirectByteBuffer (Patch 1) and Patch 2. Anyone willing to review it (Patch 1)? Thanks, Hiroshi From Ulf.Zibis at gmx.de Tue Apr 13 13:50:36 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 13 Apr 2010 22:50:36 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: Message-ID: <4BC4D91C.3000000@gmx.de> +1 I would like to see this enhancement. But we could do better on x86, as I guess those swap instructions would likely come accompanied with a move: 0x00b95d79: bswap %ebx ;*invokevirtual putInt ... 0x00b95d8d: mov %ebx,(%eax,%ecx,1) ;*invokevirtual putInt could be shorter: ... 0x00b95d8b: movbe %ebx,(%eax,%ecx,1) ;*invokevirtual putInt On char/short there could be an additional win: swap(x) { return (char)(Integer.reverseBytes(x) >>> 16); }: 0x00b8965d: bswap %edx 0x00b8965f: shr $0x10,%edx ... 0x00b8966c: mov %dx,(%eax) ;*invokevirtual putChar ; - java.nio.DirectByteBuffer::putChar at 30 (line 482) ... but best would be: 0x00b89667: movbe %dx,(%eax) ;*invokevirtual putChar ; - java.nio.DirectByteBuffer::putChar at 30 (line 482) Same thoughts on getInt, getChar/Short. On SPARC I don't know. -Ulf Am 13.04.2010 21:11, schrieb Hiroshi Yamauchi: > Hi there, > > I'd like to contribute this patch that implements the intrinsics for > Short/Character.reverseBytes (in C2): > > http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ (Patch 1) > > (Thanks to Chuck for reviewing it and creating the webrev on my behalf.) > > This adds new siblings for the existing Integer/Long.reverseBytes > intrinsics. Note: I did my best for the sparc implementation > (sparc.ad) but haven't been able to build or test it (I don't have > access to a sparc machine.) > > An impact of this patch can be seen in the microbenchmark > jdk/test/java/nio/Buffer/SwapMicroBenchmark (which was written by > Martin) with an experimental patch that lets DirectByteBuffer use > those intrinsics (instead of simple Java implementations) on > non-native endian operations: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ > (Patch 2) > > This patch hasn't been checked in yet but is being worked on by Martin and Ulf. > > The numbers from my measurements on x86 32 bit follow. Note the > numbers for BIG_ENDIAN. > > ----------Unmodified---------- > Method Millis Ratio > swap char BIG_ENDIAN 64 1.000 > swap char LITTLE_ENDIAN 31 0.492 > swap short BIG_ENDIAN 75 1.176 > swap short LITTLE_ENDIAN 31 0.496 > swap int BIG_ENDIAN 45 0.711 > swap int LITTLE_ENDIAN 8 0.125 > swap long BIG_ENDIAN 72 1.131 > swap long LITTLE_ENDIAN 17 0.277 > > ----------Modified (with Patches 1 and 2)---------- > Method Millis Ratio > swap char BIG_ENDIAN 44 1.000 > swap char LITTLE_ENDIAN 31 0.709 > swap short BIG_ENDIAN 44 1.004 > swap short LITTLE_ENDIAN 31 0.708 > swap int BIG_ENDIAN 18 0.423 > swap int LITTLE_ENDIAN 8 0.180 > swap long BIG_ENDIAN 24 0.544 > swap long LITTLE_ENDIAN 17 0.400 > > The speedups are clearly non-trivial. The speedup for int/long is due > to the use of the existing Integer/Long.reverseBytes intrinsics in > DirectByteBuffer (Patch 2). The speedup for short/char is due to the > use of the new Character/Short.reverseBytes intrinsics in > DirectByteBuffer (Patch 1) and Patch 2. > > Anyone willing to review it (Patch 1)? > > Thanks, > Hiroshi > > > From Ulf.Zibis at gmx.de Tue Apr 13 14:14:25 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 13 Apr 2010 23:14:25 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <4BC4D91C.3000000@gmx.de> References: <4BC4D91C.3000000@gmx.de> Message-ID: <4BC4DEB1.8090608@gmx.de> Maybe it's an option to have and intrinsify Unsafe.putSwappedInt(...) etc. Unsafe.getSwappedInt(...) etc. Additionally I see, we don't have Float/Double.reverseBytes(), so a swapped move becomes a nightmare using e.g.: unsafe.putLong(ix(nextPutIndex()), Long.reverseBytes(Double.doubleToRawLongBits(x)));. -Ulf Am 13.04.2010 22:50, schrieb Ulf Zibis: > +1 > I would like to see this enhancement. > > But we could do better on x86, as I guess those swap instructions > would likely come accompanied with a move: > 0x00b95d79: bswap %ebx ;*invokevirtual putInt > ... > 0x00b95d8d: mov %ebx,(%eax,%ecx,1) ;*invokevirtual putInt > > could be shorter: > ... > 0x00b95d8b: movbe %ebx,(%eax,%ecx,1) ;*invokevirtual putInt > > On char/short there could be an additional win: > swap(x) { return (char)(Integer.reverseBytes(x) >>> 16); }: > 0x00b8965d: bswap %edx > 0x00b8965f: shr $0x10,%edx > ... > 0x00b8966c: mov %dx,(%eax) ;*invokevirtual putChar > ; - > java.nio.DirectByteBuffer::putChar at 30 (line 482) > > ... but best would be: > 0x00b89667: movbe %dx,(%eax) ;*invokevirtual putChar > ; - > java.nio.DirectByteBuffer::putChar at 30 (line 482) > > Same thoughts on getInt, getChar/Short. > On SPARC I don't know. > > -Ulf > > > Am 13.04.2010 21:11, schrieb Hiroshi Yamauchi: >> Hi there, >> >> I'd like to contribute this patch that implements the intrinsics for >> Short/Character.reverseBytes (in C2): >> >> >> http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ >> (Patch 1) >> >> (Thanks to Chuck for reviewing it and creating the webrev on my behalf.) >> >> This adds new siblings for the existing Integer/Long.reverseBytes >> intrinsics. Note: I did my best for the sparc implementation >> (sparc.ad) but haven't been able to build or test it (I don't have >> access to a sparc machine.) >> >> An impact of this patch can be seen in the microbenchmark >> jdk/test/java/nio/Buffer/SwapMicroBenchmark (which was written by >> Martin) with an experimental patch that lets DirectByteBuffer use >> those intrinsics (instead of simple Java implementations) on >> non-native endian operations: >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ >> (Patch 2) >> >> This patch hasn't been checked in yet but is being worked on by >> Martin and Ulf. >> >> The numbers from my measurements on x86 32 bit follow. Note the >> numbers for BIG_ENDIAN. >> >> ----------Unmodified---------- >> Method Millis Ratio >> swap char BIG_ENDIAN 64 1.000 >> swap char LITTLE_ENDIAN 31 0.492 >> swap short BIG_ENDIAN 75 1.176 >> swap short LITTLE_ENDIAN 31 0.496 >> swap int BIG_ENDIAN 45 0.711 >> swap int LITTLE_ENDIAN 8 0.125 >> swap long BIG_ENDIAN 72 1.131 >> swap long LITTLE_ENDIAN 17 0.277 >> >> ----------Modified (with Patches 1 and 2)---------- >> Method Millis Ratio >> swap char BIG_ENDIAN 44 1.000 >> swap char LITTLE_ENDIAN 31 0.709 >> swap short BIG_ENDIAN 44 1.004 >> swap short LITTLE_ENDIAN 31 0.708 >> swap int BIG_ENDIAN 18 0.423 >> swap int LITTLE_ENDIAN 8 0.180 >> swap long BIG_ENDIAN 24 0.544 >> swap long LITTLE_ENDIAN 17 0.400 >> >> The speedups are clearly non-trivial. The speedup for int/long is due >> to the use of the existing Integer/Long.reverseBytes intrinsics in >> DirectByteBuffer (Patch 2). The speedup for short/char is due to the >> use of the new Character/Short.reverseBytes intrinsics in >> DirectByteBuffer (Patch 1) and Patch 2. >> >> Anyone willing to review it (Patch 1)? >> >> Thanks, >> Hiroshi >> >> > > From john.r.rose at oracle.com Tue Apr 13 17:05:46 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 14 Apr 2010 00:05:46 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 11 new changesets Message-ID: <20100414000630.5D6AD44532@hg.openjdk.java.net> Changeset: a2ea687fdc7c Author: coleenp Date: 2010-03-31 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a2ea687fdc7c 6938627: Make temporary directory use property java.io.tmpdir when specified Summary: Get java.io.tmpdir property in os::get_temp_directory() and call this instead of harcoding "/tmp". Don't assume trailing file_separator either. Reviewed-by: dholmes, kamg ! src/os/linux/vm/attachListener_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 0fd6320854d3 Author: jcoomes Date: 2010-04-02 17:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0fd6320854d3 Merge Changeset: 6ccd32c284ac Author: kamg Date: 2010-04-07 12:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6ccd32c284ac Merge Changeset: 56507bcd639e Author: tonyp Date: 2010-03-30 15:36 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/56507bcd639e 6937160: G1: should observe GCTimeRatio Summary: Remove the G1GCPercent parameter, that specifies the desired GC overhead percentage in G1, and observe the GCTimeRatio parameter instead. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 781e29eb8e08 Author: tonyp Date: 2010-04-02 12:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/781e29eb8e08 6677708: G1: re-enable parallel RSet updating and scanning Summary: Enable parallel RSet updating and scanning. Reviewed-by: iveresov, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 72f725c5a7be Author: tonyp Date: 2010-04-05 12:19 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/72f725c5a7be 6940310: G1: MT-unsafe calls to CM::region_stack_push() / CM::region_stack_pop() Summary: Calling the methods region_stack_push() and region_stack_pop() concurrent is not MT-safe. The assumption is that we will only call region_stack_push() during a GC pause and region_stack_pop() during marking. Unfortunately, we also call region_stack_push() during marking which seems to be introducing subtle marking failures. This change introduces lock-based methods for pushing / popping to be called during marking. Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 23b1b27ac76c Author: tonyp Date: 2010-04-06 10:59 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/23b1b27ac76c 6909756: G1: guarantee(G1CollectedHeap::heap()->mark_in_progress(),"Precondition.") Summary: Make sure that two marking cycles do not overlap, i.e., a new one can only start after the concurrent marking thread finishes all its work. In the fix I piggy-back a couple of minor extra fixes: some general code reformatting for consistency (only around the code I modified), the removal of a field (G1CollectorPolicy::_should_initiate_conc_mark) which doesn't seem to be used at all (it's only set but never read), as well as moving the "is GC locker active" test earlier into the G1 pause / Full GC and using a more appropriate method for it. Reviewed-by: johnc, jmasa, jcoomes, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: bda703475ded Author: johnc Date: 2010-04-07 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bda703475ded 6940894: G1: assert(new_obj != 0 || ... "should be forwarded") for compaction tests Summary: Humongous regions may contain multiple objects as a result of being retained as to-space from a previous GC and then re-used as to-space after being tagged as humongous. These changes include a check that causes retained to-space regions that are now tagged as humongous to be disregarded and a new to-space region allocated. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 6b73e879f1c2 Author: tonyp Date: 2010-04-09 13:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6b73e879f1c2 Merge Changeset: e4c77b879561 Author: tonyp Date: 2010-04-09 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e4c77b879561 Merge Changeset: fc3cd2277dc7 Author: jrose Date: 2010-04-13 13:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc3cd2277dc7 Merge From gbenson at redhat.com Wed Apr 14 03:12:59 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 14 Apr 2010 11:12:59 +0100 Subject: Review Request: Improved stack overflow handling for Zero In-Reply-To: <20100406160421.GB26320@redhat.com> References: <20100406150918.GA26320@redhat.com> <1270568955.2639.123.camel@macbook> <20100406160421.GB26320@redhat.com> Message-ID: <20100414101258.GA3544@redhat.com> Hi all, Gary Benson wrote: > Christian Thalinger wrote: > > On Tue, 2010-04-06 at 16:09 +0100, Gary Benson wrote: > > > I recently started adding stack overflow checking to Shark, > > > which brought to light a bunch of deficiencies in Zero's > > > stack overflow code. Zero had this really odd, look-ahead > > > overflow handling which was pretty strange, easily fooled, > > > and in retrospect totally unnecessary. I'm pretty sure > > > whoever wrote it was an idiot. > > > > > > This webrev removes the old overflow detection and replaces > > > it with something more straightforward and complete: > > > > > > http://cr.openjdk.java.net/~gbenson/zero-stack-overflow-checks/ > > > > > > Note that a number of calls to Unimplemented have been removed. > > > It shouldn't be possible to have an unhandled stack overflow > > > error with the new code. > > > > > > As a bonus, the new code is mildly faster (about 2%) due to > > > the checks being inlined. > > > > > > I don't have a bug id for this. > > > > I created: > > > > 6941224: Improved stack overflow handling for Zero > > Thank you. Is anybody looking into this? Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Wed Apr 14 03:46:04 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 14 Apr 2010 12:46:04 +0200 Subject: Review Request: Improved stack overflow handling for Zero In-Reply-To: <20100414101258.GA3544@redhat.com> References: <20100406150918.GA26320@redhat.com> <1270568955.2639.123.camel@macbook> <20100406160421.GB26320@redhat.com> <20100414101258.GA3544@redhat.com> Message-ID: <1271241964.2134.170.camel@macbook> On Wed, 2010-04-14 at 11:12 +0100, Gary Benson wrote: > Is anybody looking into this? Hmm, I think I forgot this one. I will look at the changes. -- Christian From gbenson at redhat.com Wed Apr 14 03:57:34 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 14 Apr 2010 11:57:34 +0100 Subject: Review Request: Improved stack overflow handling for Zero In-Reply-To: <1271241964.2134.170.camel@macbook> References: <20100406150918.GA26320@redhat.com> <1270568955.2639.123.camel@macbook> <20100406160421.GB26320@redhat.com> <20100414101258.GA3544@redhat.com> <1271241964.2134.170.camel@macbook> Message-ID: <20100414105734.GB3544@redhat.com> Christian Thalinger wrote: > On Wed, 2010-04-14 at 11:12 +0100, Gary Benson wrote: > > Is anybody looking into this? > > Hmm, I think I forgot this one. I will look at the changes. Thanks :) -- http://gbenson.net/ From gbenson at redhat.com Wed Apr 14 05:27:29 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 14 Apr 2010 13:27:29 +0100 Subject: Review Request: Improved Zero crash dump Message-ID: <20100414122728.GC3544@redhat.com> Hi all, While investigating a GC crash I noticed that the stack was dumped differently to other crashes. This webrev fixes: http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From Ulf.Zibis at gmx.de Wed Apr 14 06:22:33 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 14 Apr 2010 15:22:33 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <4BC4D91C.3000000@gmx.de> Message-ID: <4BC5C199.70607@gmx.de> Hi Roger, not sure if I understand right. Is 'Atom' meant as an AMD/Intel architecture ? Movbe I found in the instruction set of Intel. -Ulf Am 14.04.2010 01:57, schrieb Ian Rogers: > Hi Ulf, > > movbe is an Atom only instruction. > > Regards, > Ian > > On 13 April 2010 13:50, Ulf Zibis wrote: > >> +1 >> I would like to see this enhancement. >> >> But we could do better on x86, as I guess those swap instructions would >> likely come accompanied with a move: >> 0x00b95d79: bswap %ebx ;*invokevirtual putInt >> ... >> 0x00b95d8d: mov %ebx,(%eax,%ecx,1) ;*invokevirtual putInt >> >> could be shorter: >> ... >> 0x00b95d8b: movbe %ebx,(%eax,%ecx,1) ;*invokevirtual putInt >> >> On char/short there could be an additional win: >> swap(x) { return (char)(Integer.reverseBytes(x)>>> 16); }: >> 0x00b8965d: bswap %edx >> 0x00b8965f: shr $0x10,%edx >> ... >> 0x00b8966c: mov %dx,(%eax) ;*invokevirtual putChar >> ; - >> java.nio.DirectByteBuffer::putChar at 30 (line 482) >> >> ... but best would be: >> 0x00b89667: movbe %dx,(%eax) ;*invokevirtual putChar >> ; - >> java.nio.DirectByteBuffer::putChar at 30 (line 482) >> >> Same thoughts on getInt, getChar/Short. >> On SPARC I don't know. >> >> -Ulf >> >> >> Am 13.04.2010 21:11, schrieb Hiroshi Yamauchi: >> >>> Hi there, >>> >>> I'd like to contribute this patch that implements the intrinsics for >>> Short/Character.reverseBytes (in C2): >>> >>> http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ >>> (Patch 1) >>> >>> (Thanks to Chuck for reviewing it and creating the webrev on my behalf.) >>> >>> This adds new siblings for the existing Integer/Long.reverseBytes >>> intrinsics. Note: I did my best for the sparc implementation >>> (sparc.ad) but haven't been able to build or test it (I don't have >>> access to a sparc machine.) >>> >>> An impact of this patch can be seen in the microbenchmark >>> jdk/test/java/nio/Buffer/SwapMicroBenchmark (which was written by >>> Martin) with an experimental patch that lets DirectByteBuffer use >>> those intrinsics (instead of simple Java implementations) on >>> non-native endian operations: >>> >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ >>> (Patch 2) >>> >>> This patch hasn't been checked in yet but is being worked on by Martin and >>> Ulf. >>> >>> The numbers from my measurements on x86 32 bit follow. Note the >>> numbers for BIG_ENDIAN. >>> >>> ----------Unmodified---------- >>> Method Millis Ratio >>> swap char BIG_ENDIAN 64 1.000 >>> swap char LITTLE_ENDIAN 31 0.492 >>> swap short BIG_ENDIAN 75 1.176 >>> swap short LITTLE_ENDIAN 31 0.496 >>> swap int BIG_ENDIAN 45 0.711 >>> swap int LITTLE_ENDIAN 8 0.125 >>> swap long BIG_ENDIAN 72 1.131 >>> swap long LITTLE_ENDIAN 17 0.277 >>> >>> ----------Modified (with Patches 1 and 2)---------- >>> Method Millis Ratio >>> swap char BIG_ENDIAN 44 1.000 >>> swap char LITTLE_ENDIAN 31 0.709 >>> swap short BIG_ENDIAN 44 1.004 >>> swap short LITTLE_ENDIAN 31 0.708 >>> swap int BIG_ENDIAN 18 0.423 >>> swap int LITTLE_ENDIAN 8 0.180 >>> swap long BIG_ENDIAN 24 0.544 >>> swap long LITTLE_ENDIAN 17 0.400 >>> >>> The speedups are clearly non-trivial. The speedup for int/long is due >>> to the use of the existing Integer/Long.reverseBytes intrinsics in >>> DirectByteBuffer (Patch 2). The speedup for short/char is due to the >>> use of the new Character/Short.reverseBytes intrinsics in >>> DirectByteBuffer (Patch 1) and Patch 2. >>> >>> Anyone willing to review it (Patch 1)? >>> >>> Thanks, >>> Hiroshi >>> >>> >>> >>> >> >> > > From Ulf.Zibis at gmx.de Wed Apr 14 11:29:20 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 14 Apr 2010 20:29:20 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <4BC4D91C.3000000@gmx.de> <4BC5C199.70607@gmx.de> Message-ID: <4BC60980.8050108@gmx.de> Ian, thanks for your explanation. Where you found this information about movbe? I can't find any statement about this in the docs, listed here: http://developer.intel.com/products/processor/manuals/index.htm -Ulf Am 14.04.2010 19:39, schrieb Ian Rogers: > Hi, > > by Atom I mean the Intel Atom netbook processor. No other processor > provides movbe at this moment (AMD or Intel). > > Regards, > Ian > > On 14 April 2010 06:22, Ulf Zibis wrote: > >> Hi Roger, >> >> not sure if I understand right. Is 'Atom' meant as an AMD/Intel architecture >> ? >> >> Movbe I found in the instruction set of Intel. >> >> -Ulf >> >> >> Am 14.04.2010 01:57, schrieb Ian Rogers: >> >>> Hi Ulf, >>> >>> movbe is an Atom only instruction. >>> >>> Regards, >>> Ian >>> >>> On 13 April 2010 13:50, Ulf Zibis wrote: >>> >>> >>>> +1 >>>> I would like to see this enhancement. >>>> >>>> But we could do better on x86, as I guess those swap instructions would >>>> likely come accompanied with a move: >>>> 0x00b95d79: bswap %ebx ;*invokevirtual putInt >>>> ... >>>> 0x00b95d8d: mov %ebx,(%eax,%ecx,1) ;*invokevirtual putInt >>>> >>>> could be shorter: >>>> ... >>>> 0x00b95d8b: movbe %ebx,(%eax,%ecx,1) ;*invokevirtual putInt >>>> >>>> On char/short there could be an additional win: >>>> swap(x) { return (char)(Integer.reverseBytes(x)>>> 16); }: >>>> 0x00b8965d: bswap %edx >>>> 0x00b8965f: shr $0x10,%edx >>>> ... >>>> 0x00b8966c: mov %dx,(%eax) ;*invokevirtual putChar >>>> ; - >>>> java.nio.DirectByteBuffer::putChar at 30 (line 482) >>>> >>>> ... but best would be: >>>> 0x00b89667: movbe %dx,(%eax) ;*invokevirtual putChar >>>> ; - >>>> java.nio.DirectByteBuffer::putChar at 30 (line 482) >>>> >>>> Same thoughts on getInt, getChar/Short. >>>> On SPARC I don't know. >>>> >>>> -Ulf >>>> >>>> >>>> Am 13.04.2010 21:11, schrieb Hiroshi Yamauchi: >>>> >>>> >>>>> Hi there, >>>>> >>>>> I'd like to contribute this patch that implements the intrinsics for >>>>> Short/Character.reverseBytes (in C2): >>>>> >>>>> http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ >>>>> (Patch 1) >>>>> >>>>> (Thanks to Chuck for reviewing it and creating the webrev on my behalf.) >>>>> >>>>> This adds new siblings for the existing Integer/Long.reverseBytes >>>>> intrinsics. Note: I did my best for the sparc implementation >>>>> (sparc.ad) but haven't been able to build or test it (I don't have >>>>> access to a sparc machine.) >>>>> >>>>> An impact of this patch can be seen in the microbenchmark >>>>> jdk/test/java/nio/Buffer/SwapMicroBenchmark (which was written by >>>>> Martin) with an experimental patch that lets DirectByteBuffer use >>>>> those intrinsics (instead of simple Java implementations) on >>>>> non-native endian operations: >>>>> >>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ >>>>> (Patch 2) >>>>> >>>>> This patch hasn't been checked in yet but is being worked on by Martin >>>>> and >>>>> Ulf. >>>>> >>>>> The numbers from my measurements on x86 32 bit follow. Note the >>>>> numbers for BIG_ENDIAN. >>>>> >>>>> ----------Unmodified---------- >>>>> Method Millis Ratio >>>>> swap char BIG_ENDIAN 64 1.000 >>>>> swap char LITTLE_ENDIAN 31 0.492 >>>>> swap short BIG_ENDIAN 75 1.176 >>>>> swap short LITTLE_ENDIAN 31 0.496 >>>>> swap int BIG_ENDIAN 45 0.711 >>>>> swap int LITTLE_ENDIAN 8 0.125 >>>>> swap long BIG_ENDIAN 72 1.131 >>>>> swap long LITTLE_ENDIAN 17 0.277 >>>>> >>>>> ----------Modified (with Patches 1 and 2)---------- >>>>> Method Millis Ratio >>>>> swap char BIG_ENDIAN 44 1.000 >>>>> swap char LITTLE_ENDIAN 31 0.709 >>>>> swap short BIG_ENDIAN 44 1.004 >>>>> swap short LITTLE_ENDIAN 31 0.708 >>>>> swap int BIG_ENDIAN 18 0.423 >>>>> swap int LITTLE_ENDIAN 8 0.180 >>>>> swap long BIG_ENDIAN 24 0.544 >>>>> swap long LITTLE_ENDIAN 17 0.400 >>>>> >>>>> The speedups are clearly non-trivial. The speedup for int/long is due >>>>> to the use of the existing Integer/Long.reverseBytes intrinsics in >>>>> DirectByteBuffer (Patch 2). The speedup for short/char is due to the >>>>> use of the new Character/Short.reverseBytes intrinsics in >>>>> DirectByteBuffer (Patch 1) and Patch 2. >>>>> >>>>> Anyone willing to review it (Patch 1)? >>>>> >>>>> Thanks, >>>>> Hiroshi >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From rasbold at google.com Wed Apr 14 11:58:49 2010 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 14 Apr 2010 11:58:49 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <4BC60980.8050108@gmx.de> References: <4BC4D91C.3000000@gmx.de> <4BC5C199.70607@gmx.de> <4BC60980.8050108@gmx.de> Message-ID: See the document "Intel? 64 and IA-32 Architectures Software Developer's Manual Volume 2A: Instruction Set Reference, A-M" The section on movbe (currently page 732) indicates that the #UD exception is thrown if CPUUID.O1H:ECX.MOVBE[bit 22] = 0. Additionally, the CPUID section (table 3-15, page 261) lists all the bit numbers and specifically the MOVBE bit. -- Chuck On Wed, Apr 14, 2010 at 11:29 AM, Ulf Zibis wrote: > Ian, thanks for your explanation. > > Where you found this information about movbe? > I can't find any statement about this in the docs, listed here: > http://developer.intel.com/products/processor/manuals/index.htm > > -Ulf > > > Am 14.04.2010 19:39, schrieb Ian Rogers: > >> Hi, >> >> by Atom I mean the Intel Atom netbook processor. No other processor >> provides movbe at this moment (AMD or Intel). >> >> Regards, >> Ian >> >> On 14 April 2010 06:22, Ulf Zibis wrote: >> >> >> >>> Hi Roger, >>> >>> not sure if I understand right. Is 'Atom' meant as an AMD/Intel >>> architecture >>> ? >>> >>> Movbe I found in the instruction set of Intel. >>> >>> -Ulf >>> >>> >>> Am 14.04.2010 01:57, schrieb Ian Rogers: >>> >>> >>>> Hi Ulf, >>>> >>>> movbe is an Atom only instruction. >>>> >>>> Regards, >>>> Ian >>>> >>>> On 13 April 2010 13:50, Ulf Zibis wrote: >>>> >>>> >>>> >>>>> +1 >>>>> I would like to see this enhancement. >>>>> >>>>> But we could do better on x86, as I guess those swap instructions would >>>>> likely come accompanied with a move: >>>>> 0x00b95d79: bswap %ebx ;*invokevirtual putInt >>>>> ... >>>>> 0x00b95d8d: mov %ebx,(%eax,%ecx,1) ;*invokevirtual putInt >>>>> >>>>> could be shorter: >>>>> ... >>>>> 0x00b95d8b: movbe %ebx,(%eax,%ecx,1) ;*invokevirtual putInt >>>>> >>>>> On char/short there could be an additional win: >>>>> swap(x) { return (char)(Integer.reverseBytes(x)>>> 16); }: >>>>> 0x00b8965d: bswap %edx >>>>> 0x00b8965f: shr $0x10,%edx >>>>> ... >>>>> 0x00b8966c: mov %dx,(%eax) ;*invokevirtual putChar >>>>> ; - >>>>> java.nio.DirectByteBuffer::putChar at 30 (line 482) >>>>> >>>>> ... but best would be: >>>>> 0x00b89667: movbe %dx,(%eax) ;*invokevirtual putChar >>>>> ; - >>>>> java.nio.DirectByteBuffer::putChar at 30 (line 482) >>>>> >>>>> Same thoughts on getInt, getChar/Short. >>>>> On SPARC I don't know. >>>>> >>>>> -Ulf >>>>> >>>>> >>>>> Am 13.04.2010 21:11, schrieb Hiroshi Yamauchi: >>>>> >>>>> >>>>> >>>>>> Hi there, >>>>>> >>>>>> I'd like to contribute this patch that implements the intrinsics for >>>>>> Short/Character.reverseBytes (in C2): >>>>>> >>>>>> http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ >>>>>> (Patch 1) >>>>>> >>>>>> (Thanks to Chuck for reviewing it and creating the webrev on my >>>>>> behalf.) >>>>>> >>>>>> This adds new siblings for the existing Integer/Long.reverseBytes >>>>>> intrinsics. Note: I did my best for the sparc implementation >>>>>> (sparc.ad) but haven't been able to build or test it (I don't have >>>>>> access to a sparc machine.) >>>>>> >>>>>> An impact of this patch can be seen in the microbenchmark >>>>>> jdk/test/java/nio/Buffer/SwapMicroBenchmark (which was written by >>>>>> Martin) with an experimental patch that lets DirectByteBuffer use >>>>>> those intrinsics (instead of simple Java implementations) on >>>>>> non-native endian operations: >>>>>> >>>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ >>>>>> (Patch 2) >>>>>> >>>>>> This patch hasn't been checked in yet but is being worked on by Martin >>>>>> and >>>>>> Ulf. >>>>>> >>>>>> The numbers from my measurements on x86 32 bit follow. Note the >>>>>> numbers for BIG_ENDIAN. >>>>>> >>>>>> ----------Unmodified---------- >>>>>> Method Millis Ratio >>>>>> swap char BIG_ENDIAN 64 1.000 >>>>>> swap char LITTLE_ENDIAN 31 0.492 >>>>>> swap short BIG_ENDIAN 75 1.176 >>>>>> swap short LITTLE_ENDIAN 31 0.496 >>>>>> swap int BIG_ENDIAN 45 0.711 >>>>>> swap int LITTLE_ENDIAN 8 0.125 >>>>>> swap long BIG_ENDIAN 72 1.131 >>>>>> swap long LITTLE_ENDIAN 17 0.277 >>>>>> >>>>>> ----------Modified (with Patches 1 and 2)---------- >>>>>> Method Millis Ratio >>>>>> swap char BIG_ENDIAN 44 1.000 >>>>>> swap char LITTLE_ENDIAN 31 0.709 >>>>>> swap short BIG_ENDIAN 44 1.004 >>>>>> swap short LITTLE_ENDIAN 31 0.708 >>>>>> swap int BIG_ENDIAN 18 0.423 >>>>>> swap int LITTLE_ENDIAN 8 0.180 >>>>>> swap long BIG_ENDIAN 24 0.544 >>>>>> swap long LITTLE_ENDIAN 17 0.400 >>>>>> >>>>>> The speedups are clearly non-trivial. The speedup for int/long is due >>>>>> to the use of the existing Integer/Long.reverseBytes intrinsics in >>>>>> DirectByteBuffer (Patch 2). The speedup for short/char is due to the >>>>>> use of the new Character/Short.reverseBytes intrinsics in >>>>>> DirectByteBuffer (Patch 1) and Patch 2. >>>>>> >>>>>> Anyone willing to review it (Patch 1)? >>>>>> >>>>>> Thanks, >>>>>> Hiroshi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100414/f3c1041e/attachment.html From tom.rodriguez at oracle.com Wed Apr 14 17:34:36 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 15 Apr 2010 00:34:36 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6938026: C2 compiler fails in Node::rematerialize()const Message-ID: <20100415003448.1E96644564@hg.openjdk.java.net> Changeset: ef74d6d1ac1e Author: never Date: 2010-04-14 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ef74d6d1ac1e 6938026: C2 compiler fails in Node::rematerialize()const Reviewed-by: twisti ! src/share/vm/opto/parse1.cpp From gbenson at redhat.com Thu Apr 15 02:16:57 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Apr 2010 10:16:57 +0100 Subject: Review Request: 6940701 broke Zero Message-ID: <20100415091657.GA3395@redhat.com> Hi all, The fix for 6940701 (whatever that is -- I can't see the bug) broke Zero. This webrev fixes: http://cr.openjdk.java.net/~gbenson/zero-6940701-fix/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Thu Apr 15 02:46:30 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Apr 2010 11:46:30 +0200 Subject: Review Request: Improved stack overflow handling for Zero In-Reply-To: <20100414105734.GB3544@redhat.com> References: <20100406150918.GA26320@redhat.com> <1270568955.2639.123.camel@macbook> <20100406160421.GB26320@redhat.com> <20100414101258.GA3544@redhat.com> <1271241964.2134.170.camel@macbook> <20100414105734.GB3544@redhat.com> Message-ID: <1271324790.2134.192.camel@macbook> On Wed, 2010-04-14 at 11:57 +0100, Gary Benson wrote: > Christian Thalinger wrote: > > On Wed, 2010-04-14 at 11:12 +0100, Gary Benson wrote: > > > Is anybody looking into this? > > > > Hmm, I think I forgot this one. I will look at the changes. > > Thanks :) Changes look good. I didn't look very closely but it only affects zero files, so... It's in the JPRT queue. -- Christian From Ulf.Zibis at gmx.de Thu Apr 15 02:46:44 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 15 Apr 2010 11:46:44 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <4BC4D91C.3000000@gmx.de> <4BC5C199.70607@gmx.de> <4BC60980.8050108@gmx.de> Message-ID: <4BC6E084.40306@gmx.de> Much thanks Chuck, not easy to find. -Ulf Am 14.04.2010 20:58, schrieb Chuck Rasbold: > See the document "Intel? 64 and IA-32 Architectures Software > Developer's Manual Volume 2A: Instruction Set Reference, A-M" > > > > The section on movbe (currently page 732) indicates that the #UD > exception is thrown if CPUUID.O1H:ECX.MOVBE[bit 22] = 0. > > > Additionally, the CPUID section (table 3-15, page 261) lists all the > bit numbers and specifically the MOVBE bit. > > -- Chuck > > On Wed, Apr 14, 2010 at 11:29 AM, Ulf Zibis > wrote: > > Ian, thanks for your explanation. > > Where you found this information about movbe? > I can't find any statement about this in the docs, listed here: > http://developer.intel.com/products/processor/manuals/index.htm > > -Ulf > > > Am 14.04.2010 19:39, schrieb Ian Rogers: > > Hi, > > by Atom I mean the Intel Atom netbook processor. No other > processor > provides movbe at this moment (AMD or Intel). > > Regards, > Ian > > On 14 April 2010 06:22, Ulf Zibis > wrote: > > > Hi Roger, > > not sure if I understand right. Is 'Atom' meant as an > AMD/Intel architecture > ? > > Movbe I found in the instruction set of Intel. > > -Ulf > > > Am 14.04.2010 01:57, schrieb Ian Rogers: > > Hi Ulf, > > movbe is an Atom only instruction. > > Regards, > Ian > > On 13 April 2010 13:50, Ulf Zibis > wrote: > > > +1 > I would like to see this enhancement. > > But we could do better on x86, as I guess those > swap instructions would > likely come accompanied with a move: > 0x00b95d79: bswap %ebx > ;*invokevirtual putInt > ... > 0x00b95d8d: mov %ebx,(%eax,%ecx,1) > ;*invokevirtual putInt > > could be shorter: > ... > 0x00b95d8b: movbe %ebx,(%eax,%ecx,1) > ;*invokevirtual putInt > > On char/short there could be an additional win: > swap(x) { return (char)(Integer.reverseBytes(x)>>> > 16); }: > 0x00b8965d: bswap %edx > 0x00b8965f: shr $0x10,%edx > ... > 0x00b8966c: mov %dx,(%eax) > ;*invokevirtual putChar > ; - > java.nio.DirectByteBuffer::putChar at 30 (line 482) > > ... but best would be: > 0x00b89667: movbe %dx,(%eax) > ;*invokevirtual putChar > ; - > java.nio.DirectByteBuffer::putChar at 30 (line 482) > > Same thoughts on getInt, getChar/Short. > On SPARC I don't know. > > -Ulf > > > Am 13.04.2010 21:11, schrieb Hiroshi Yamauchi: > > > Hi there, > > I'd like to contribute this patch that > implements the intrinsics for > Short/Character.reverseBytes (in C2): > > http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ > > (Patch 1) > > (Thanks to Chuck for reviewing it and creating > the webrev on my behalf.) > > This adds new siblings for the existing > Integer/Long.reverseBytes > intrinsics. Note: I did my best for the sparc > implementation > (sparc.ad ) but haven't been > able to build or test it (I don't have > access to a sparc machine.) > > An impact of this patch can be seen in the > microbenchmark > jdk/test/java/nio/Buffer/SwapMicroBenchmark > (which was written by > Martin) with an experimental patch that lets > DirectByteBuffer use > those intrinsics (instead of simple Java > implementations) on > non-native endian operations: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ > > (Patch 2) > > This patch hasn't been checked in yet but is > being worked on by Martin > and > Ulf. > > The numbers from my measurements on x86 32 bit > follow. Note the > numbers for BIG_ENDIAN. > > ----------Unmodified---------- > Method Millis Ratio > swap char BIG_ENDIAN 64 1.000 > swap char LITTLE_ENDIAN 31 0.492 > swap short BIG_ENDIAN 75 1.176 > swap short LITTLE_ENDIAN 31 0.496 > swap int BIG_ENDIAN 45 0.711 > swap int LITTLE_ENDIAN 8 0.125 > swap long BIG_ENDIAN 72 1.131 > swap long LITTLE_ENDIAN 17 0.277 > > ----------Modified (with Patches 1 and > 2)---------- > Method Millis Ratio > swap char BIG_ENDIAN 44 1.000 > swap char LITTLE_ENDIAN 31 0.709 > swap short BIG_ENDIAN 44 1.004 > swap short LITTLE_ENDIAN 31 0.708 > swap int BIG_ENDIAN 18 0.423 > swap int LITTLE_ENDIAN 8 0.180 > swap long BIG_ENDIAN 24 0.544 > swap long LITTLE_ENDIAN 17 0.400 > > The speedups are clearly non-trivial. The > speedup for int/long is due > to the use of the existing > Integer/Long.reverseBytes intrinsics in > DirectByteBuffer (Patch 2). The speedup for > short/char is due to the > use of the new Character/Short.reverseBytes > intrinsics in > DirectByteBuffer (Patch 1) and Patch 2. > > Anyone willing to review it (Patch 1)? > > Thanks, > Hiroshi > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100415/03542937/attachment.html From Christian.Thalinger at Sun.COM Thu Apr 15 03:18:34 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Apr 2010 12:18:34 +0200 Subject: Review Request: 6940701 broke Zero In-Reply-To: <20100415091657.GA3395@redhat.com> References: <20100415091657.GA3395@redhat.com> Message-ID: <1271326714.2134.204.camel@macbook> On Thu, 2010-04-15 at 10:16 +0100, Gary Benson wrote: > Hi all, > > The fix for 6940701 (whatever that is -- I can't see the bug) > broke Zero. This webrev fixes: > > http://cr.openjdk.java.net/~gbenson/zero-6940701-fix/ > > I don't have a bug id for this. I don't know why the bug can't be seen, it should be. Here is the changeset: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6476042f815c I filed: 6944028: 6940701 broke Zero Changes look good and it's in the queue. -- Christian From gbenson at redhat.com Thu Apr 15 03:24:09 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Apr 2010 11:24:09 +0100 Subject: Review Request: 6940701 broke Zero In-Reply-To: <1271326714.2134.204.camel@macbook> References: <20100415091657.GA3395@redhat.com> <1271326714.2134.204.camel@macbook> Message-ID: <20100415102409.GB3395@redhat.com> Christian Thalinger wrote: > On Thu, 2010-04-15 at 10:16 +0100, Gary Benson wrote: > > The fix for 6940701 (whatever that is -- I can't see the bug) > > broke Zero. This webrev fixes: > > > > http://cr.openjdk.java.net/~gbenson/zero-6940701-fix/ > > > > I don't have a bug id for this. > > I don't know why the bug can't be seen, it should be. Here is the > changeset: > > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6476042f815c > > I filed: > > 6944028: 6940701 broke Zero > > Changes look good and it's in the queue. Awesome, thanks. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Thu Apr 15 04:05:19 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Apr 2010 13:05:19 +0200 Subject: Review Request: Improved Zero crash dump In-Reply-To: <20100414122728.GC3544@redhat.com> References: <20100414122728.GC3544@redhat.com> Message-ID: <1271329519.2134.206.camel@macbook> On Wed, 2010-04-14 at 13:27 +0100, Gary Benson wrote: > Hi all, > > While investigating a GC crash I noticed that the stack was > dumped differently to other crashes. This webrev fixes: > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump/ > > I don't have a bug id for this. FTR, as discussed on IRC we should factor the code into a method to avoid code duplication. -- Christian From Christian.Thalinger at Sun.COM Thu Apr 15 04:25:52 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Apr 2010 13:25:52 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> Message-ID: <1271330753.2134.210.camel@macbook> On Fri, 2010-04-09 at 11:06 -0700, Tom Rodriguez wrote: > I don't like the way this is structured. Why not move the > preserve/restore SP logic up into the LIR as regular moves? Then you > don't need any of this special handling. In fact the delay slot > filling will likely move the preserve SP logic into the delay slot as > you would like it to be. You're right. Here is a new webrev: http://cr.openjdk.java.net/~twisti/6930772/webrev.02/ I'm not sure if the LIR_OpDelay::is_method_handle_invoke is good name choice. Additionally I changed ciMethod::is_method_handle_invoke to use the holder and method name to be able to call it on unloaded methods. John hasn't replied yet on my email if that's OK but my extensive testings show that it should be OK. -- Christian From Christian.Thalinger at Sun.COM Thu Apr 15 05:45:16 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Apr 2010 14:45:16 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <4BC4D91C.3000000@gmx.de> References: <4BC4D91C.3000000@gmx.de> Message-ID: <1271335516.2134.247.camel@macbook> On Tue, 2010-04-13 at 22:50 +0200, Ulf Zibis wrote: > +1 > I would like to see this enhancement. > > But we could do better on x86, as I guess those swap instructions would > likely come accompanied with a move: > 0x00b95d79: bswap %ebx ;*invokevirtual putInt > ... > 0x00b95d8d: mov %ebx,(%eax,%ecx,1) ;*invokevirtual putInt > > could be shorter: > ... > 0x00b95d8b: movbe %ebx,(%eax,%ecx,1) ;*invokevirtual putInt > > On char/short there could be an additional win: > swap(x) { return (char)(Integer.reverseBytes(x) >>> 16); }: > 0x00b8965d: bswap %edx > 0x00b8965f: shr $0x10,%edx > ... > 0x00b8966c: mov %dx,(%eax) ;*invokevirtual putChar > ; - > java.nio.DirectByteBuffer::putChar at 30 (line 482) > > ... but best would be: > 0x00b89667: movbe %dx,(%eax) ;*invokevirtual putChar > ; - > java.nio.DirectByteBuffer::putChar at 30 (line 482) > > Same thoughts on getInt, getChar/Short. > On SPARC I don't know. I filed: 6944091: C2 should use movbe on x86 if available -- Christian From Christian.Thalinger at Sun.COM Thu Apr 15 07:25:29 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Apr 2010 16:25:29 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: Message-ID: <1271341529.2134.352.camel@macbook> On Tue, 2010-04-13 at 12:11 -0700, Hiroshi Yamauchi wrote: > Hi there, > > I'd like to contribute this patch that implements the intrinsics for > Short/Character.reverseBytes (in C2): > > http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ (Patch 1) > > (Thanks to Chuck for reviewing it and creating the webrev on my behalf.) > > This adds new siblings for the existing Integer/Long.reverseBytes > intrinsics. Note: I did my best for the sparc implementation > (sparc.ad) but haven't been able to build or test it (I don't have > access to a sparc machine.) The changes look good. Just a few comments: src/cpu/sparc/vm/sparc.ad (loadC_reversed, loadS_reversed): 9764 ins_cost(MEMORY_REF_COST); 9780 ins_cost(MEMORY_REF_COST); Why are you using MEMORY_REF_COST only when e.g. loadI_reversed uses: 9738 ins_cost(DEFAULT_COST + MEMORY_REF_COST); What about copyright? If you're not adding some Google copyright line we should at least bump the year in Sun's line. I personally would prefer to use US (unsigned short) instead of C (char) in class and method names since we renamed LoadC to LoadUS some time ago. -- Christian From gbenson at redhat.com Thu Apr 15 07:46:09 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Apr 2010 15:46:09 +0100 Subject: Review Request: Improved Zero crash dump In-Reply-To: <1271329519.2134.206.camel@macbook> References: <20100414122728.GC3544@redhat.com> <1271329519.2134.206.camel@macbook> Message-ID: <20100415144609.GC3395@redhat.com> Christian Thalinger wrote: > On Wed, 2010-04-14 at 13:27 +0100, Gary Benson wrote: > > While investigating a GC crash I noticed that the stack was > > dumped differently to other crashes. This webrev fixes: > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump/ > > > > I don't have a bug id for this. > > FTR, as discussed on IRC we should factor the code into a method > to avoid code duplication. How about this: http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump-2/ Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Thu Apr 15 07:55:20 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Apr 2010 16:55:20 +0200 Subject: Review Request: Improved Zero crash dump In-Reply-To: <20100415144609.GC3395@redhat.com> References: <20100414122728.GC3544@redhat.com> <1271329519.2134.206.camel@macbook> <20100415144609.GC3395@redhat.com> Message-ID: <1271343320.2134.353.camel@macbook> On Thu, 2010-04-15 at 15:46 +0100, Gary Benson wrote: > Christian Thalinger wrote: > > On Wed, 2010-04-14 at 13:27 +0100, Gary Benson wrote: > > > While investigating a GC crash I noticed that the stack was > > > dumped differently to other crashes. This webrev fixes: > > > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump/ > > > > > > I don't have a bug id for this. > > > > FTR, as discussed on IRC we should factor the code into a method > > to avoid code duplication. > > How about this: > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump-2/ Looks good. What about the copyright? -- Christian From gbenson at redhat.com Thu Apr 15 07:59:47 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Apr 2010 15:59:47 +0100 Subject: Review Request: Improved Zero crash dump In-Reply-To: <1271343320.2134.353.camel@macbook> References: <20100414122728.GC3544@redhat.com> <1271329519.2134.206.camel@macbook> <20100415144609.GC3395@redhat.com> <1271343320.2134.353.camel@macbook> Message-ID: <20100415145947.GD3395@redhat.com> Christian Thalinger wrote: > On Thu, 2010-04-15 at 15:46 +0100, Gary Benson wrote: > > Christian Thalinger wrote: > > > On Wed, 2010-04-14 at 13:27 +0100, Gary Benson wrote: > > > > While investigating a GC crash I noticed that the stack was > > > > dumped differently to other crashes. This webrev fixes: > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump/ > > > > > > > > I don't have a bug id for this. > > > > > > FTR, as discussed on IRC we should factor the code into a method > > > to avoid code duplication. > > > > How about this: > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump-2/ > > Looks good. What about the copyright? What should I do to it, update the Sun one, or add a Red Hat line? Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Thu Apr 15 08:05:44 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Apr 2010 17:05:44 +0200 Subject: Review Request: Improved Zero crash dump In-Reply-To: <20100415145947.GD3395@redhat.com> References: <20100414122728.GC3544@redhat.com> <1271329519.2134.206.camel@macbook> <20100415144609.GC3395@redhat.com> <1271343320.2134.353.camel@macbook> <20100415145947.GD3395@redhat.com> Message-ID: <1271343945.2134.354.camel@macbook> On Thu, 2010-04-15 at 15:59 +0100, Gary Benson wrote: > Christian Thalinger wrote: > > On Thu, 2010-04-15 at 15:46 +0100, Gary Benson wrote: > > > Christian Thalinger wrote: > > > > On Wed, 2010-04-14 at 13:27 +0100, Gary Benson wrote: > > > > > While investigating a GC crash I noticed that the stack was > > > > > dumped differently to other crashes. This webrev fixes: > > > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump/ > > > > > > > > > > I don't have a bug id for this. > > > > > > > > FTR, as discussed on IRC we should factor the code into a method > > > > to avoid code duplication. > > > > > > How about this: > > > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump-2/ > > > > Looks good. What about the copyright? > > What should I do to it, update the Sun one, or add a Red Hat line? As you like. If you just want to update the Sun one I can do that for you when I commit it. -- Christian From gbenson at redhat.com Thu Apr 15 08:34:00 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Apr 2010 16:34:00 +0100 Subject: Review Request: Improved Zero crash dump In-Reply-To: <1271343945.2134.354.camel@macbook> References: <20100414122728.GC3544@redhat.com> <1271329519.2134.206.camel@macbook> <20100415144609.GC3395@redhat.com> <1271343320.2134.353.camel@macbook> <20100415145947.GD3395@redhat.com> <1271343945.2134.354.camel@macbook> Message-ID: <20100415153359.GE3395@redhat.com> Christian Thalinger wrote: > On Thu, 2010-04-15 at 15:59 +0100, Gary Benson wrote: > > Christian Thalinger wrote: > > > On Thu, 2010-04-15 at 15:46 +0100, Gary Benson wrote: > > > > Christian Thalinger wrote: > > > > > On Wed, 2010-04-14 at 13:27 +0100, Gary Benson wrote: > > > > > > While investigating a GC crash I noticed that the stack was > > > > > > dumped differently to other crashes. This webrev fixes: > > > > > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump/ > > > > > > > > > > > > I don't have a bug id for this. > > > > > > > > > > FTR, as discussed on IRC we should factor the code into a method > > > > > to avoid code duplication. > > > > > > > > How about this: > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump-2/ > > > > > > Looks good. What about the copyright? > > > > What should I do to it, update the Sun one, or add a Red Hat line? > > As you like. If you just want to update the Sun one I can do that for > you when I commit it. Please. Cheers, Gary -- http://gbenson.net/ From Ulf.Zibis at gmx.de Thu Apr 15 09:40:07 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 15 Apr 2010 18:40:07 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <1271335516.2134.247.camel@macbook> References: <4BC4D91C.3000000@gmx.de> <1271335516.2134.247.camel@macbook> Message-ID: <4BC74167.2000904@gmx.de> > > I filed: > > 6944091: C2 should use movbe on x86 if available > > -- Christian > > > Thanks, Ulf From tom.rodriguez at oracle.com Thu Apr 15 10:30:41 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Apr 2010 10:30:41 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <1271341529.2134.352.camel@macbook> References: <1271341529.2134.352.camel@macbook> Message-ID: Can we use the macroassembler loads instead of emit_form on sparc? tom On Apr 15, 2010, at 7:25 AM, Christian Thalinger wrote: > On Tue, 2010-04-13 at 12:11 -0700, Hiroshi Yamauchi wrote: >> Hi there, >> >> I'd like to contribute this patch that implements the intrinsics for >> Short/Character.reverseBytes (in C2): >> >> http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ (Patch 1) >> >> (Thanks to Chuck for reviewing it and creating the webrev on my behalf.) >> >> This adds new siblings for the existing Integer/Long.reverseBytes >> intrinsics. Note: I did my best for the sparc implementation >> (sparc.ad) but haven't been able to build or test it (I don't have >> access to a sparc machine.) > > The changes look good. Just a few comments: > > src/cpu/sparc/vm/sparc.ad (loadC_reversed, loadS_reversed): > > 9764 ins_cost(MEMORY_REF_COST); > 9780 ins_cost(MEMORY_REF_COST); > > Why are you using MEMORY_REF_COST only when e.g. loadI_reversed uses: > > 9738 ins_cost(DEFAULT_COST + MEMORY_REF_COST); > > What about copyright? If you're not adding some Google copyright line > we should at least bump the year in Sun's line. > > I personally would prefer to use US (unsigned short) instead of C (char) > in class and method names since we renamed LoadC to LoadUS some time > ago. > > -- Christian > From tom.rodriguez at oracle.com Thu Apr 15 10:31:56 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Apr 2010 10:31:56 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1271330753.2134.210.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> Message-ID: <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> Could the is_method_handle_invoke become part of CodeEmitInfo instead? That would make more sense to me. tom On Apr 15, 2010, at 4:25 AM, Christian Thalinger wrote: > On Fri, 2010-04-09 at 11:06 -0700, Tom Rodriguez wrote: >> I don't like the way this is structured. Why not move the >> preserve/restore SP logic up into the LIR as regular moves? Then you >> don't need any of this special handling. In fact the delay slot >> filling will likely move the preserve SP logic into the delay slot as >> you would like it to be. > > You're right. Here is a new webrev: > > http://cr.openjdk.java.net/~twisti/6930772/webrev.02/ > > I'm not sure if the LIR_OpDelay::is_method_handle_invoke is good name > choice. > > Additionally I changed ciMethod::is_method_handle_invoke to use the > holder and method name to be able to call it on unloaded methods. John > hasn't replied yet on my email if that's OK but my extensive testings > show that it should be OK. > > -- Christian > From john.r.rose at oracle.com Thu Apr 15 10:18:54 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 15 Apr 2010 10:18:54 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1271330753.2134.210.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> Message-ID: On Apr 15, 2010, at 4:25 AM, Christian Thalinger wrote: > Additionally I changed ciMethod::is_method_handle_invoke to use the > holder and method name to be able to call it on unloaded methods. John > hasn't replied yet on my email if that's OK but my extensive testings > show that it should be OK. Yes, that's fine. -- John From tom.rodriguez at oracle.com Thu Apr 15 20:13:25 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 16 Apr 2010 03:13:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6939930: exception unwind changes in 6919934 hurts compilation speed Message-ID: <20100416031328.E68404458B@hg.openjdk.java.net> Changeset: 9f5b60a14736 Author: never Date: 2010-04-15 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9f5b60a14736 6939930: exception unwind changes in 6919934 hurts compilation speed Reviewed-by: twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/runtime/sharedRuntime.cpp From Christian.Thalinger at Sun.COM Fri Apr 16 02:52:54 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 16 Apr 2010 09:52:54 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20100416095303.7CB784459D@hg.openjdk.java.net> Changeset: f9271ff9d324 Author: twisti Date: 2010-04-15 02:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f9271ff9d324 6941224: Improved stack overflow handling for Zero Summary: Adding stack overflow checking to Shark brought to light a bunch of deficiencies in Zero's stack overflow code. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/fakeStubFrame_zero.hpp ! src/cpu/zero/vm/interpreterFrame_zero.hpp ! src/cpu/zero/vm/interpreterRT_zero.cpp ! src/cpu/zero/vm/stack_zero.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp ! src/share/vm/includeDB_zero Changeset: badea972a310 Author: twisti Date: 2010-04-16 00:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/badea972a310 Merge From Christian.Thalinger at Sun.COM Fri Apr 16 04:01:48 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 16 Apr 2010 13:01:48 +0200 Subject: Review Request: Improved stack overflow handling for Zero In-Reply-To: <1271324790.2134.192.camel@macbook> References: <20100406150918.GA26320@redhat.com> <1270568955.2639.123.camel@macbook> <20100406160421.GB26320@redhat.com> <20100414101258.GA3544@redhat.com> <1271241964.2134.170.camel@macbook> <20100414105734.GB3544@redhat.com> <1271324790.2134.192.camel@macbook> Message-ID: <1271415708.899.107.camel@macbook> On Thu, 2010-04-15 at 11:46 +0200, Christian Thalinger wrote: > On Wed, 2010-04-14 at 11:57 +0100, Gary Benson wrote: > > Christian Thalinger wrote: > > > On Wed, 2010-04-14 at 11:12 +0100, Gary Benson wrote: > > > > Is anybody looking into this? > > > > > > Hmm, I think I forgot this one. I will look at the changes. > > > > Thanks :) > > Changes look good. I didn't look very closely but it only affects zero > files, so... It's in the JPRT queue. Gary just pointed out that I missed the new files in this changeset. I created another CR to add these two missing files: 6944473: 6941224 misses new files Sorry for the inconvenience. -- Christian From Christian.Thalinger at Sun.COM Fri Apr 16 05:01:35 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 16 Apr 2010 12:01:35 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20100416120146.9FEAC4459E@hg.openjdk.java.net> Changeset: a9584793da0f Author: twisti Date: 2010-04-15 03:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a9584793da0f 6944028: 6940701 broke Zero Summary: The fix for 6940701 broke Zero. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/globals_zero.hpp Changeset: d32d2a2f62cd Author: twisti Date: 2010-04-16 02:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d32d2a2f62cd Merge From Christian.Thalinger at Sun.COM Fri Apr 16 05:41:38 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 16 Apr 2010 14:41:38 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> Message-ID: <1271421698.899.146.camel@macbook> On Thu, 2010-04-15 at 10:31 -0700, Tom Rodriguez wrote: > Could the is_method_handle_invoke become part of CodeEmitInfo instead? > That would make more sense to me. Right. This looks much better: http://cr.openjdk.java.net/~twisti/6930772/webrev.03/ -- Christian From Christian.Thalinger at Sun.COM Fri Apr 16 07:09:55 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 16 Apr 2010 14:09:55 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6944473: 6941224 misses new files Message-ID: <20100416141000.DC5934459F@hg.openjdk.java.net> Changeset: aa9c266de52a Author: twisti Date: 2010-04-16 05:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/aa9c266de52a 6944473: 6941224 misses new files Summary: Two new files are missing in the push for 6941224. Reviewed-by: twisti Contributed-by: Gary Benson + src/cpu/zero/vm/stack_zero.cpp + src/cpu/zero/vm/stack_zero.inline.hpp From tom.rodriguez at oracle.com Fri Apr 16 09:37:21 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 16 Apr 2010 09:37:21 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1271421698.899.146.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> Message-ID: <9AE3A7ED-1D32-46CF-98B5-2985A8982C74@oracle.com> That looks good. tom On Apr 16, 2010, at 5:41 AM, Christian Thalinger wrote: > On Thu, 2010-04-15 at 10:31 -0700, Tom Rodriguez wrote: >> Could the is_method_handle_invoke become part of CodeEmitInfo instead? >> That would make more sense to me. > > Right. This looks much better: > > http://cr.openjdk.java.net/~twisti/6930772/webrev.03/ > > -- Christian > From john.coomes at oracle.com Fri Apr 16 12:33:51 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 19:33:51 +0000 Subject: hg: jdk7/hotspot-comp: 7 new changesets Message-ID: <20100416193351.4D4C5445BA@hg.openjdk.java.net> Changeset: bbd817429100 Author: jjg Date: 2010-03-12 15:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/bbd817429100 6934712: run langtools jtreg tests from top level test/Makefile Reviewed-by: ohair ! test/Makefile Changeset: c60ed0f6d91a Author: ohair Date: 2010-03-12 17:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/c60ed0f6d91a 6934759: Add langtools testing to jprt control builds Reviewed-by: jjg ! make/jprt.properties Changeset: 98505d97a822 Author: lana Date: 2010-03-18 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/98505d97a822 Merge Changeset: 35d272ef7598 Author: ohair Date: 2010-03-19 18:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/35d272ef7598 6936788: Minor adjustment to top repo test/Makefile, missing non-zero exit case Reviewed-by: jjg ! test/Makefile Changeset: b1c3b0e44b9d Author: lana Date: 2010-04-08 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/b1c3b0e44b9d Merge Changeset: 7f1ba4459972 Author: lana Date: 2010-04-13 16:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/7f1ba4459972 Merge Changeset: 425ba3efabbf Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/425ba3efabbf Added tag jdk7-b89 for changeset 7f1ba4459972 ! .hgtags From john.coomes at oracle.com Fri Apr 16 12:33:56 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 19:33:56 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b89 for changeset bb4424c5e778 Message-ID: <20100416193400.F03B3445BB@hg.openjdk.java.net> Changeset: 56ce07b0eb47 Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/56ce07b0eb47 Added tag jdk7-b89 for changeset bb4424c5e778 ! .hgtags From john.coomes at oracle.com Fri Apr 16 12:36:55 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 19:36:55 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b89 for changeset d2818fd2b036 Message-ID: <20100416193655.C0817445BC@hg.openjdk.java.net> Changeset: c5d932ee326d Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/c5d932ee326d Added tag jdk7-b89 for changeset d2818fd2b036 ! .hgtags From john.coomes at oracle.com Fri Apr 16 12:37:01 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 19:37:01 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b89 for changeset bf3675aa7f20 Message-ID: <20100416193701.90C8A445BD@hg.openjdk.java.net> Changeset: ead7c4566a00 Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/ead7c4566a00 Added tag jdk7-b89 for changeset bf3675aa7f20 ! .hgtags From john.coomes at oracle.com Fri Apr 16 12:41:00 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 19:41:00 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 77 new changesets Message-ID: <20100416200533.9667B445BE@hg.openjdk.java.net> Changeset: 0137b5857c63 Author: okutsu Date: 2010-03-10 14:32 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0137b5857c63 6932473: (tz) javazic produces incorrect SimpleTimeZone parameters with Sun<=7 Reviewed-by: peytoia ! make/tools/src/build/tools/javazic/RuleDay.java Changeset: 0e0ce1aa1bba Author: peytoia Date: 2010-03-11 11:54 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0e0ce1aa1bba 6933032: (tz) Support tzdata2010e Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/southamerica Changeset: ce3770eadf85 Author: malenkov Date: 2010-03-11 17:39 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ce3770eadf85 6707226: java.beans.Statement & java.beans.Expression miss one important usecase Reviewed-by: rupashka ! src/share/classes/java/beans/Expression.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Statement/Test6707226.java Changeset: d86c053ca938 Author: rupashka Date: 2010-03-15 16:16 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d86c053ca938 6931347: SynthTabbedPaneUI.paintTabArea() is not called when tabbed pane is painted Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java Changeset: 1224c1388e86 Author: rupashka Date: 2010-03-17 12:48 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1224c1388e86 6933784: NIMBUS: ImageView getNoImageIcon and getLoadingImageIcon returns nulls instead of an icon Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java + test/javax/swing/plaf/synth/Test6933784.java Changeset: ac4c8e3bf93f Author: lana Date: 2010-03-17 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ac4c8e3bf93f Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: 325823a26aac Author: peterz Date: 2010-03-18 12:02 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/325823a26aac 6932524: NIMBUS: 3 constructors of JSplitPane creates new jsp with continuous layout - they should not. Reviewed-by: alexp ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/plaf/nimbus/skin.laf Changeset: ef892cd084ec Author: rupashka Date: 2010-03-24 15:14 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ef892cd084ec 6922214: SynthTextPaneUI.installUI() doesn't install the default caret and highlighter Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java Changeset: f799c62ad4f8 Author: peytoia Date: 2010-03-30 18:35 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f799c62ad4f8 6939021: (tz) Support tzdata2010g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java Changeset: dbde35ddda78 Author: peytoia Date: 2010-03-30 21:16 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dbde35ddda78 6907881: Different undesired behavior for entering Asian characters in Windows IME starting with Java 6.0 Reviewed-by: okutsu ! src/windows/native/sun/windows/awt_Component.cpp Changeset: eb39ccbd95f9 Author: lana Date: 2010-04-08 15:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eb39ccbd95f9 Merge Changeset: d23dcd3e3ce4 Author: andrew Date: 2010-03-12 01:09 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d23dcd3e3ce4 6934327: Update linux fontconfigs for Ubuntu and Fedora. Summary: Use fontconfigs suitable for recent Fedora, Ubuntu and Debian releases. Reviewed-by: prr ! src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties ! src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties Changeset: 45bd445f6250 Author: lana Date: 2010-03-19 18:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/45bd445f6250 Merge - make/java/text/FILES_java.gmk - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: bf23bec88222 Author: lana Date: 2010-04-08 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bf23bec88222 Merge Changeset: 47958f76babc Author: chegar Date: 2010-03-10 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/47958f76babc 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun Reviewed-by: alanb ! test/java/net/MulticastSocket/NoLoopbackPackets.java Changeset: 467484e025d6 Author: martin Date: 2010-03-10 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/467484e025d6 6931812: A better implementation of sun.nio.cs.Surrogate.isBMP(int) Summary: uc >> 16 == 0 is superior to (int) (char) uc == uc Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/sun/nio/cs/Surrogate.java Changeset: 07e1c5a90c6a Author: chegar Date: 2010-03-11 16:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/07e1c5a90c6a 6934054: java/net/Socket/FDClose.java return error in samevm Summary: test is no longer useful Reviewed-by: alanb ! test/ProblemList.txt - test/java/net/Socket/FDClose.java Changeset: c342735a3e58 Author: chegar Date: 2010-03-11 17:37 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c342735a3e58 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/CookieHandler/CookieHandlerTest.java Changeset: c6f8c58ed51a Author: chegar Date: 2010-03-11 17:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c6f8c58ed51a 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy Reviewed-by: michaelm, chegar Contributed-by: damjan.jov at gmail.com ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocksSocketImpl.java + test/java/net/Socket/SocksConnectTimeout.java Changeset: ee385b4e2ffb Author: sherman Date: 2010-03-11 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ee385b4e2ffb 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile Summary: system property sun.zip.disableMemoryMapping to disable mmap use Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h Changeset: bf6eb240e718 Author: ohair Date: 2010-03-12 09:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bf6eb240e718 6933294: Fix some test/Makefile issues around Linux ARCH settings, better defaults Reviewed-by: jjg ! test/Makefile ! test/ProblemList.txt Changeset: cda90ceb7176 Author: ohair Date: 2010-03-12 09:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cda90ceb7176 Merge ! test/ProblemList.txt Changeset: f88f6f8ddd21 Author: chegar Date: 2010-03-16 10:05 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f88f6f8ddd21 6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10 Reviewed-by: alanb ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java Changeset: 895a1211b2e1 Author: chegar Date: 2010-03-16 14:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/895a1211b2e1 6935199: java/net regression tests failing with Assertions Reviewed-by: michaelm ! test/ProblemList.txt ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/URLClassLoader/closetest/CloseTest.java Changeset: 0500f7306cbe Author: weijun Date: 2010-03-17 09:55 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0500f7306cbe 6868865: Test: sun/security/tools/jarsigner/oldsig.sh fails under all platforms Reviewed-by: wetmore ! test/sun/security/tools/jarsigner/oldsig.sh Changeset: 2796f839e337 Author: weijun Date: 2010-03-18 18:26 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2796f839e337 6829283: HTTP/Negotiate: Autheticator triggered again when user cancels the first one Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/spnego/NegotiateCallbackHandler.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java Changeset: c52f292a8f86 Author: valeriep Date: 2010-03-18 17:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c52f292a8f86 6695485: SignedObject constructor throws ProviderException if it's called using provider "SunPKCS11-Solaris" Summary: Added checking for RSA key lengths in initSign and initVerify Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Signature.java + test/sun/security/pkcs11/Signature/TestRSAKeyLength.java Changeset: df5714cbe76d Author: valeriep Date: 2010-03-18 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/df5714cbe76d 6591117: Poor preformance of PKCS#11 security provider compared to Sun default provider Summary: Added internal buffering to PKCS11 SecureRandom impl Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java Changeset: dc42c9d9ca16 Author: valeriep Date: 2010-03-18 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dc42c9d9ca16 6837847: PKCS#11 A SecureRandom and a serialization error following installation of 1.5.0_18 Summary: Added a custom readObject method to PKCS11 SecureRandom impl Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java + test/sun/security/pkcs11/SecureRandom/TestDeserialization.java Changeset: dff4f51b73d4 Author: lana Date: 2010-03-18 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dff4f51b73d4 Merge Changeset: 3bb93c410f41 Author: chegar Date: 2010-03-19 13:07 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3bb93c410f41 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java + test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh Changeset: c40572afb29e Author: chegar Date: 2010-03-22 11:55 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c40572afb29e 6632169: HttpClient and HttpsClient should not try to reverse lookup IP address of a proxy server Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java Changeset: 31dcf23042f9 Author: weijun Date: 2010-03-23 10:41 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/31dcf23042f9 6586707: NTLM authentication with proxy fails Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 8a9ebdc27045 Author: chegar Date: 2010-03-23 13:54 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8a9ebdc27045 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets 6771432: createSocket() - smpatch fails using 1.6.0_10 because of "Unconnected sockets not implemented" 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 Summary: All three bugs are interdependent Reviewed-by: xuelei ! src/share/classes/javax/net/SocketFactory.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java Changeset: f8c9a5e3f5db Author: dcubed Date: 2010-03-23 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f8c9a5e3f5db 6915365: 3/4 assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 Summary: Remove exception throw to decouple JDK and HotSpot additions of known types. Reviewed-by: mchung ! src/share/native/sun/management/Flag.c Changeset: 26477628f2d5 Author: weijun Date: 2010-03-25 12:07 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/26477628f2d5 6813340: X509Factory should not depend on is.available()==0 Reviewed-by: xuelei ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/tools/KeyTool.java + test/java/security/cert/CertificateFactory/ReturnStream.java + test/java/security/cert/CertificateFactory/SlowStream.java + test/java/security/cert/CertificateFactory/slowstream.sh Changeset: 6109b166bf68 Author: chegar Date: 2010-03-25 09:38 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6109b166bf68 6937703: java/net regression test issues with samevm Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/ProxySelector/B6737819.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java ! test/java/net/URL/TestIPv6Addresses.java ! test/java/net/URLClassLoader/HttpTest.java ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/contentHandler/UserContentHandler.java Changeset: 31517a0345d1 Author: xuelei Date: 2010-03-29 13:27 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/31517a0345d1 6693917: regression tests need to update for supporting ECC on solaris 11 Reviewed-by: weijun ! test/sun/security/ssl/etc/keystore ! test/sun/security/ssl/etc/truststore ! test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java Changeset: 3771ac2a8b3b Author: sherman Date: 2010-03-30 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3771ac2a8b3b 6902790: Converting/displaying HKSCs characters issue on Vista and Windows7 6911753: NSN wants to add Big5 HKSCS-2004 support Summary: support HKSCS2008 in Big5_HKSCS and MS950_HKSCS Reviewed-by: okutsu ! make/sun/nio/cs/FILES_java.gmk ! make/sun/nio/cs/Makefile + make/tools/CharsetMapping/Big5.c2b + make/tools/CharsetMapping/Big5.map + make/tools/CharsetMapping/Big5.nr + make/tools/CharsetMapping/HKSCS2001.c2b + make/tools/CharsetMapping/HKSCS2001.map + make/tools/CharsetMapping/HKSCS2008.c2b + make/tools/CharsetMapping/HKSCS2008.map + make/tools/CharsetMapping/HKSCS_XP.c2b + make/tools/CharsetMapping/HKSCS_XP.map ! make/tools/CharsetMapping/dbcs - make/tools/src/build/tools/charsetmapping/CharsetMapping.java + make/tools/src/build/tools/charsetmapping/DBCS.java + make/tools/src/build/tools/charsetmapping/EUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java + make/tools/src/build/tools/charsetmapping/HKSCS.java + make/tools/src/build/tools/charsetmapping/JIS0213.java ! make/tools/src/build/tools/charsetmapping/Main.java + make/tools/src/build/tools/charsetmapping/SBCS.java + make/tools/src/build/tools/charsetmapping/Utils.java ! src/share/classes/sun/awt/HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5.java ! src/share/classes/sun/io/ByteToCharBig5_HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java ! src/share/classes/sun/io/ByteToCharMS950_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5.java ! src/share/classes/sun/io/CharToByteBig5_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java ! src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/nio/cs/ext/Big5.java ! src/share/classes/sun/nio/cs/ext/Big5_HKSCS.java + src/share/classes/sun/nio/cs/ext/Big5_HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/Big5_Solaris.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/MS950_HKSCS.java + src/share/classes/sun/nio/cs/ext/MS950_HKSCS_XP.java ! src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.properties ! src/solaris/native/java/lang/java_props_md.c ! src/windows/classes/sun/awt/windows/fontconfig.properties ! src/windows/native/java/lang/java_props_md.c ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/java/nio/charset/Charset/RegisteredCharsets.java Changeset: 1105276dbd6a Author: sherman Date: 2010-04-03 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1105276dbd6a 4947220: (process)Runtime.exec() cannot invoke applications with unicode parameters(win) Summary: to use CreateProcessW on Windowns platform Reviewed-by: martin ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/solaris/native/java/lang/java_props_md.c ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/lang/java_props_md.c ! test/java/lang/ProcessBuilder/Basic.java Changeset: d3309aae68ef Author: dl Date: 2009-10-06 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d3309aae68ef 6888149: AtomicReferenceArray causes SIGSEGV -> SEGV_MAPERR error Summary: Avoid integer overflow by using long arithmetic Reviewed-by: martin, dholmes ! 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/AtomicReferenceArray.java Changeset: 08f57141c305 Author: asaha Date: 2009-11-20 14:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/08f57141c305 Merge - test/sun/tools/native2ascii/test2 Changeset: b1e8f41ed755 Author: chegar Date: 2009-11-23 12:40 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b1e8f41ed755 6639665: ThreadGroup finalizer allows creation of false root ThreadGroups Reviewed-by: alanb, hawtin ! src/share/classes/java/lang/ThreadGroup.java Changeset: e943f6b0b0e9 Author: alanb Date: 2009-11-25 10:02 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e943f6b0b0e9 6736390: File TOCTOU deserialization vulnerability Reviewed-by: hawtin ! src/share/classes/java/io/File.java Changeset: ff9c2f53594e Author: sherman Date: 2009-11-25 11:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ff9c2f53594e 6745393: Inflater/Deflater clone issue Summary: To use explicit lobk object. Reviewed-by: alanb ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c Changeset: d893f890b4dd Author: sherman Date: 2009-11-25 12:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d893f890b4dd 6904925: Changeset for 6745393 for jdk7 ssr forest was incomplete Summary: To add, commit and push back the ZStreamRef.java Reviewed-by: alanb + src/share/classes/java/util/zip/ZStreamRef.java Changeset: df3091222715 Author: mchung Date: 2009-11-25 09:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/df3091222715 6893947: Deserialization of RMIConnectionImpl objects should enforce stricter checks [ZDI-CAN-588] Summary: narrow the doPrivileged block to only set context ClassLoader Reviewed-by: hawtin, emcmanus ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: bc309e9233ce Author: mchung Date: 2009-11-25 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bc309e9233ce Merge Changeset: 621edf6b03fc Author: mchung Date: 2009-11-25 16:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/621edf6b03fc Merge Changeset: 338c8775f0a3 Author: asaha Date: 2009-11-26 07:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/338c8775f0a3 Merge Changeset: f0b63b6d9709 Author: asaha Date: 2009-12-01 08:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f0b63b6d9709 Merge - test/tools/launcher/SolarisDataModel.sh - test/tools/launcher/SolarisRunpath.sh - test/tools/launcher/libraryCaller.c - test/tools/launcher/libraryCaller.h - test/tools/launcher/libraryCaller.java Changeset: 121fa73c7185 Author: michaelm Date: 2009-12-02 12:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/121fa73c7185 6893954: Subclasses of InetAddress may incorrectly interpret network addresses Summary: runtime type checks and deserialization check Reviewed-by: chegar, alanb, jccollet ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/Socket.java ! src/share/classes/sun/nio/ch/Net.java Changeset: edaa7e2efd63 Author: asaha Date: 2009-12-04 10:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/edaa7e2efd63 Merge - make/tools/CharsetMapping/DoubleByte-X.java - make/tools/CharsetMapping/SingleByte-X.java - src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java - test/java/util/Formatter/Basic-X.java Changeset: 3598d6eb087c Author: xuelei Date: 2009-12-07 21:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3598d6eb087c 6898739: TLS renegotiation issue Summary: the interim fix disables TLS/SSL renegotiation Reviewed-by: mullan, chegar, wetmore ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java Changeset: 91a4840fa9b4 Author: mullan Date: 2009-12-08 15:58 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/91a4840fa9b4 6633872: Policy/PolicyFile leak dynamic ProtectionDomains. Reviewed-by: hawtin ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/ProtectionDomain.java + src/share/classes/sun/misc/JavaSecurityProtectionDomainAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/provider/PolicyFile.java Changeset: 7a60d100ffa5 Author: mullan Date: 2009-12-18 09:09 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7a60d100ffa5 6904162: Add new VeriSign root CA certificates to JRE and remove some old/unused ones Reviewed-by: asaha - test/lib/security/cacerts/VerifyCACerts.java Changeset: 3dabb7d5be98 Author: malenkov Date: 2009-12-22 17:56 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3dabb7d5be98 6904691: Java Applet Trusted Methods Chaining Privilege Escalation Vulnerability Reviewed-by: hawtin, peterz ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/Statement.java ! test/java/beans/EventHandler/Test6277246.java ! test/java/beans/EventHandler/Test6277266.java Changeset: c80b6350de63 Author: michaelm Date: 2010-01-12 12:13 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c80b6350de63 6910590: Application can modify command array, in ProcessBuilder Summary: clone array returned by List.toArray() Reviewed-by: chegar, alanb ! src/share/classes/java/lang/ProcessBuilder.java Changeset: 0667ab707c48 Author: bae Date: 2010-02-17 12:49 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0667ab707c48 6914866: Sun JRE ImagingLib arbitrary code execution vulnerability Reviewed-by: prr, hawtin ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! src/share/native/sun/awt/medialib/safe_alloc.h Changeset: 494aea51f26f Author: bae Date: 2010-02-17 13:10 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/494aea51f26f 6914823: Java AWT Library Invalid Index Vulnerability Reviewed-by: flar, hawtin ! src/share/classes/sun/awt/image/ImageRepresentation.java Changeset: 45ead4a2c48b Author: bae Date: 2010-02-17 13:32 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/45ead4a2c48b 6909597: Sun Java Runtime Environment JPEGImageReader stepX Integer Overflow Vulnerability Reviewed-by: igor ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: 1ff19af7b735 Author: bae Date: 2010-02-19 22:30 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1ff19af7b735 6899653: Sun Java Runtime CMM readMabCurveData Buffer Overflow Vulnerability Reviewed-by: prr, hawtin ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c Changeset: cda01c4b091c Author: ksrini Date: 2010-02-22 14:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cda01c4b091c 6902299: Java JAR "unpack200" must verify input parameters Summary: Added several checks for addition of values before memory allocation Reviewed-by: asaha ! src/share/native/com/sun/java/util/jar/pack/bytes.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: 7a6b3cc68e92 Author: denis Date: 2010-02-26 03:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7a6b3cc68e92 6887703: Unsigned applet can retrieve the dragged information before drop action occur Reviewed-by: uta ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: c5c6f8fa92ae Author: denis Date: 2010-03-06 03:37 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c5c6f8fa92ae 6932659: JTreg test files were missed in push of 6887703 Reviewed-by: uta ! test/java/awt/regtesthelpers/process/ProcessCommunicator.java Changeset: 2805db6e6ff6 Author: asaha Date: 2010-03-24 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2805db6e6ff6 Merge - make/java/redist/FILES.gmk - make/java/text/FILES_java.gmk - make/sun/nio/FILES_java.gmk ! src/share/classes/java/beans/Statement.java ! src/share/classes/java/util/zip/Deflater.java - src/share/classes/javax/swing/plaf/synth/DefaultMenuLayout.java - src/share/classes/sun/awt/ComponentAccessor.java - src/share/classes/sun/awt/WindowAccessor.java - src/share/classes/sun/dyn/util/BytecodeSignature.java - src/share/classes/sun/security/provider/IdentityDatabase.java ! src/share/classes/sun/security/provider/PolicyFile.java - src/share/classes/sun/security/provider/SystemIdentity.java - src/share/classes/sun/security/provider/SystemSigner.java - src/share/classes/sun/security/x509/X500Signer.java - src/share/classes/sun/security/x509/X509Cert.java - src/share/classes/sun/swing/plaf/synth/SynthUI.java - src/share/classes/sun/tools/jar/JarVerifierStream.java - src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java ! test/java/awt/regtesthelpers/process/ProcessCommunicator.java - test/java/net/Socket/FDClose.java Changeset: 1dccfa00dc64 Author: asaha Date: 2010-03-24 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1dccfa00dc64 Merge ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 6ec14b5ede77 Author: asaha Date: 2010-03-25 07:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6ec14b5ede77 Merge Changeset: 3ef9b3446677 Author: asaha Date: 2010-03-29 07:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3ef9b3446677 Merge Changeset: a9fdd143a58e Author: asaha Date: 2010-04-05 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a9fdd143a58e Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java Changeset: 69002275e0e2 Author: chegar Date: 2010-04-06 13:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/69002275e0e2 6648001: Cancelling HTTP authentication causes subsequent deadlocks Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/Authenticator/Deadlock.java Changeset: 495ba30cf02f Author: chegar Date: 2010-04-06 15:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/495ba30cf02f 6921111: NullPointerException in PlainDatagramSocketImpl.socketSetOption Reviewed-by: alanb ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c Changeset: 0b7f10901f30 Author: sherman Date: 2010-04-06 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0b7f10901f30 6717164: FilterInputStream.skip incorrectly inherits wording specifying how the InputStream.skip works Summary: restoring the javadoc Reviewed-by: alanb ! src/share/classes/java/io/FilterInputStream.java Changeset: fc7c38b2584c Author: martin Date: 2010-04-07 12:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fc7c38b2584c 6941130: Semaphore should throw if number of permits overflows or underflows Summary: Check if release could make number of permits negative Reviewed-by: dl, dholmes ! src/share/classes/java/util/concurrent/Semaphore.java + test/java/util/concurrent/Semaphore/PermitOverflow.java Changeset: 025f9e57566a Author: lana Date: 2010-04-08 15:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/025f9e57566a Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java ! src/share/classes/java/beans/Statement.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: 4a6abb7e224c Author: lana Date: 2010-04-13 16:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4a6abb7e224c Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: 7f90d0b9dbb7 Author: mikejwre Date: 2010-04-15 13:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7f90d0b9dbb7 Added tag jdk7-b89 for changeset 4a6abb7e224c ! .hgtags From john.coomes at oracle.com Fri Apr 16 13:22:18 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 20:22:18 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 10 new changesets Message-ID: <20100416202251.BC092445C0@hg.openjdk.java.net> Changeset: 9871ce4fd56f Author: jjg Date: 2010-03-10 16:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/9871ce4fd56f 6933914: fix missing newlines Reviewed-by: ohair ! test/tools/javac/OverrideChecks/6738538/T6738538a.java ! test/tools/javac/OverrideChecks/6738538/T6738538b.java ! test/tools/javac/api/6731573/Erroneous.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/cast/6548436/T6548436d.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6586091/T6586091.java ! test/tools/javac/enum/T6724345.java ! test/tools/javac/generics/T6557954.java ! test/tools/javac/generics/T6751514.java ! test/tools/javac/generics/T6869075.java ! test/tools/javac/generics/inference/6569789/T6569789.java ! test/tools/javac/generics/inference/6650759/T6650759a.java ! test/tools/javac/generics/wildcards/T6732484.java ! test/tools/javac/processing/model/util/elements/Foo.java ! test/tools/javac/varargs/T6746184.java - test/tools/javap/T6305779.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java Changeset: f856c0942c06 Author: jjg Date: 2010-03-12 12:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f856c0942c06 6934224: update langtools/test/Makefile Reviewed-by: ohair ! make/jprt.properties ! test/Makefile Changeset: 6fad35d25b1e Author: lana Date: 2010-03-18 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6fad35d25b1e Merge Changeset: dd30de080cb9 Author: jjg Date: 2010-03-23 18:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/dd30de080cb9 6937244: sqe ws7 tools javap/javap_t10a fail jdk7 b80 used output of javap is changed Reviewed-by: darcy ! src/share/classes/com/sun/tools/javap/ClassWriter.java + test/tools/javap/6937244/T6937244.java + test/tools/javap/6937244/T6937244A.java Changeset: 3058880c0b8d Author: jjg Date: 2010-03-24 12:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/3058880c0b8d 6937318: jdk7 b86: javah and javah -help is no output for these commands Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/JavahTask.java ! test/tools/javah/T6893943.java Changeset: 65e422bbb984 Author: darcy Date: 2010-03-24 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/65e422bbb984 6937417: javac -Xprint returns IndexOutOfBoundsException Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java + test/tools/javac/processing/model/util/elements/VacuousEnum.java Changeset: de6375751eb7 Author: ohair Date: 2010-03-26 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/de6375751eb7 6938326: Use of "ant -diagnostics" a problem with ant 1.8.0, exit code 1 now Reviewed-by: jjg ! make/Makefile Changeset: ad1bf317cc57 Author: lana Date: 2010-04-08 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ad1bf317cc57 Merge - test/tools/javap/T6305779.java Changeset: 6cea9a143208 Author: lana Date: 2010-04-13 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6cea9a143208 Merge - test/tools/javap/T6305779.java Changeset: 71c2c23a7c35 Author: mikejwre Date: 2010-04-15 13:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/71c2c23a7c35 Added tag jdk7-b89 for changeset 6cea9a143208 ! .hgtags From john.r.rose at oracle.com Fri Apr 16 14:48:56 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 16 Apr 2010 14:48:56 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1271421698.899.146.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> Message-ID: <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> I like it too; reviewed. The use of L0 is tricky. You call it L7 in one comment. Be sure that all of these uses of L0 are linked together by comments. The change touches one of my pet peeves: The SP adjustment tracking in the frame logic has always seemed awkward to me (not from your change). I don't see a clearer reformulation yet. (Chuck Rasbold made it better with the unextended_sp stuff.) One partial cleanup would lead to some simplifications. It would change the convention by which the interpreter pops its outgoing arguments. Currently it pretends to keep the arguments on stack throughout the call; it should release them to the callee before completing the control transfer to the callee. Currently, as a result, a return to the interpreter resets to a saved SP that points to the argument list base (lowest address, not highest), the address of an argument list that (at that point) is long gone. The interpreter must then perform extra calculations to re-adjust the SP by the size of the absent argument list, calculations which add no value. And when stack walking, we have to continually remember that the unextended SP might overlap with stack storage owned by the callee, which is counterintuitive and therefore bug-prone. -- John On Apr 16, 2010, at 5:41 AM, Christian Thalinger wrote: > On Thu, 2010-04-15 at 10:31 -0700, Tom Rodriguez wrote: >> Could the is_method_handle_invoke become part of CodeEmitInfo instead? >> That would make more sense to me. > > Right. This looks much better: > > http://cr.openjdk.java.net/~twisti/6930772/webrev.03/ > > -- Christian > From Ulf.Zibis at gmx.de Sat Apr 17 05:36:01 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 17 Apr 2010 14:36:01 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: Message-ID: <4BC9AB31.8040705@gmx.de> Hi Hiroshi, Chuck, Christian, can we additionally intrinsify: - Float.intBitsToFloat - Float.floatToRawIntBits - Double.longBitsToDouble - Double.doubleToRawLongBits They should result in a NOP, only type conversion. -Ulf Am 13.04.2010 21:11, schrieb Hiroshi Yamauchi: > Hi there, > > I'd like to contribute this patch that implements the intrinsics for > Short/Character.reverseBytes (in C2): > > http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ (Patch 1) > > (Thanks to Chuck for reviewing it and creating the webrev on my behalf.) > > This adds new siblings for the existing Integer/Long.reverseBytes > intrinsics. Note: I did my best for the sparc implementation > (sparc.ad) but haven't been able to build or test it (I don't have > access to a sparc machine.) > > An impact of this patch can be seen in the microbenchmark > jdk/test/java/nio/Buffer/SwapMicroBenchmark (which was written by > Martin) with an experimental patch that lets DirectByteBuffer use > those intrinsics (instead of simple Java implementations) on > non-native endian operations: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ > (Patch 2) > > This patch hasn't been checked in yet but is being worked on by Martin and Ulf. > > The numbers from my measurements on x86 32 bit follow. Note the > numbers for BIG_ENDIAN. > > ----------Unmodified---------- > Method Millis Ratio > swap char BIG_ENDIAN 64 1.000 > swap char LITTLE_ENDIAN 31 0.492 > swap short BIG_ENDIAN 75 1.176 > swap short LITTLE_ENDIAN 31 0.496 > swap int BIG_ENDIAN 45 0.711 > swap int LITTLE_ENDIAN 8 0.125 > swap long BIG_ENDIAN 72 1.131 > swap long LITTLE_ENDIAN 17 0.277 > > ----------Modified (with Patches 1 and 2)---------- > Method Millis Ratio > swap char BIG_ENDIAN 44 1.000 > swap char LITTLE_ENDIAN 31 0.709 > swap short BIG_ENDIAN 44 1.004 > swap short LITTLE_ENDIAN 31 0.708 > swap int BIG_ENDIAN 18 0.423 > swap int LITTLE_ENDIAN 8 0.180 > swap long BIG_ENDIAN 24 0.544 > swap long LITTLE_ENDIAN 17 0.400 > > The speedups are clearly non-trivial. The speedup for int/long is due > to the use of the existing Integer/Long.reverseBytes intrinsics in > DirectByteBuffer (Patch 2). The speedup for short/char is due to the > use of the new Character/Short.reverseBytes intrinsics in > DirectByteBuffer (Patch 1) and Patch 2. > > Anyone willing to review it (Patch 1)? > > Thanks, > Hiroshi > > > From Ulf.Zibis at gmx.de Sat Apr 17 05:47:38 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 17 Apr 2010 14:47:38 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <1271335516.2134.247.camel@macbook> References: <4BC4D91C.3000000@gmx.de> <1271335516.2134.247.camel@macbook> Message-ID: <4BC9ADEA.5010603@gmx.de> Am 15.04.2010 14:45, schrieb Christian Thalinger: > > I filed: > > 6944091: C2 should use movbe on x86 if available > Hi, can you please check: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939277 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6944091 They are still not publicly visible. Additionally since some weeks I get now response after filing RFE's against HotSpot C2 compiler, no Internal Review ID, no Bug ID, no email notification, no answer from Nelson Dcosta. Is there any other responsible for the bug database ??? Thanks, -Ulf From Christian.Thalinger at Sun.COM Mon Apr 19 00:15:06 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 19 Apr 2010 09:15:06 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <4BC9AB31.8040705@gmx.de> References: <4BC9AB31.8040705@gmx.de> Message-ID: <1271661306.899.151.camel@macbook> On Sat, 2010-04-17 at 14:36 +0200, Ulf Zibis wrote: > Hi Hiroshi, Chuck, Christian, > > can we additionally intrinsify: > - Float.intBitsToFloat > - Float.floatToRawIntBits > - Double.longBitsToDouble > - Double.doubleToRawLongBits We already do. -- Christian From Christian.Thalinger at Sun.COM Mon Apr 19 02:17:24 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 19 Apr 2010 11:17:24 +0200 Subject: Review Request: Improved Zero crash dump In-Reply-To: <20100415153359.GE3395@redhat.com> References: <20100414122728.GC3544@redhat.com> <1271329519.2134.206.camel@macbook> <20100415144609.GC3395@redhat.com> <1271343320.2134.353.camel@macbook> <20100415145947.GD3395@redhat.com> <1271343945.2134.354.camel@macbook> <20100415153359.GE3395@redhat.com> Message-ID: <1271668644.899.153.camel@macbook> On Thu, 2010-04-15 at 16:34 +0100, Gary Benson wrote: > Christian Thalinger wrote: > > On Thu, 2010-04-15 at 15:59 +0100, Gary Benson wrote: > > > Christian Thalinger wrote: > > > > On Thu, 2010-04-15 at 15:46 +0100, Gary Benson wrote: > > > > > Christian Thalinger wrote: > > > > > > On Wed, 2010-04-14 at 13:27 +0100, Gary Benson wrote: > > > > > > > While investigating a GC crash I noticed that the stack was > > > > > > > dumped differently to other crashes. This webrev fixes: > > > > > > > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump/ > > > > > > > > > > > > > > I don't have a bug id for this. > > > > > > > > > > > > FTR, as discussed on IRC we should factor the code into a method > > > > > > to avoid code duplication. > > > > > > > > > > How about this: > > > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump-2/ > > > > > > > > Looks good. What about the copyright? > > > > > > What should I do to it, update the Sun one, or add a Red Hat line? > > > > As you like. If you just want to update the Sun one I can do that for > > you when I commit it. > > Please. 6944503: Improved Zero crash dump It's submitted. -- Christian From gbenson at redhat.com Mon Apr 19 02:30:03 2010 From: gbenson at redhat.com (Gary Benson) Date: Mon, 19 Apr 2010 10:30:03 +0100 Subject: Review Request: Improved Zero crash dump In-Reply-To: <1271668644.899.153.camel@macbook> References: <20100414122728.GC3544@redhat.com> <1271329519.2134.206.camel@macbook> <20100415144609.GC3395@redhat.com> <1271343320.2134.353.camel@macbook> <20100415145947.GD3395@redhat.com> <1271343945.2134.354.camel@macbook> <20100415153359.GE3395@redhat.com> <1271668644.899.153.camel@macbook> Message-ID: <20100419093003.GA3687@redhat.com> Christian Thalinger wrote: > On Thu, 2010-04-15 at 16:34 +0100, Gary Benson wrote: > > Christian Thalinger wrote: > > > On Thu, 2010-04-15 at 15:59 +0100, Gary Benson wrote: > > > > Christian Thalinger wrote: > > > > > On Thu, 2010-04-15 at 15:46 +0100, Gary Benson wrote: > > > > > > Christian Thalinger wrote: > > > > > > > On Wed, 2010-04-14 at 13:27 +0100, Gary Benson wrote: > > > > > > > > While investigating a GC crash I noticed that the stack was > > > > > > > > dumped differently to other crashes. This webrev fixes: > > > > > > > > > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump/ > > > > > > > > > > > > > > > > I don't have a bug id for this. > > > > > > > > > > > > > > FTR, as discussed on IRC we should factor the code into a method > > > > > > > to avoid code duplication. > > > > > > > > > > > > How about this: > > > > > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-gc-crash-dump-2/ > > > > > > > > > > Looks good. What about the copyright? > > > > > > > > What should I do to it, update the Sun one, or add a Red Hat line? > > > > > > As you like. If you just want to update the Sun one I can do that for > > > you when I commit it. > > > > Please. > > 6944503: Improved Zero crash dump > > It's submitted. Cool, thanks. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Mon Apr 19 03:54:47 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 19 Apr 2010 12:54:47 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> Message-ID: <1271674487.917.4.camel@macbook> On Fri, 2010-04-16 at 14:48 -0700, John Rose wrote: > I like it too; reviewed. > > The use of L0 is tricky. You call it L7 in one comment. Be sure that > all of these uses of L0 are linked together by comments. L0? I think you mean L7. I only use L0 in unwind_exception to store a temporary result. > > The change touches one of my pet peeves: The SP adjustment tracking > in the frame logic has always seemed awkward to me (not from your > change). I don't see a clearer reformulation yet. (Chuck Rasbold > made it better with the unextended_sp stuff.) > > One partial cleanup would lead to some simplifications. It would > change the convention by which the interpreter pops its outgoing > arguments. Currently it pretends to keep the arguments on stack > throughout the call; it should release them to the callee before > completing the control transfer to the callee. Currently, as a > result, a return to the interpreter resets to a saved SP that points > to the argument list base (lowest address, not highest), the address > of an argument list that (at that point) is long gone. The > interpreter must then perform extra calculations to re-adjust the SP > by the size of the absent argument list, calculations which add no > value. And when stack walking, we have to continually remember that > the unextended SP might overlap with stack storage owned by the > callee, which is counterintuitive and therefore bug-prone. I see. Indeed this is a little odd. Do you already have code for that or is there just an idea? -- Christian From Christian.Thalinger at Sun.COM Mon Apr 19 05:50:03 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 19 Apr 2010 14:50:03 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <4BBF570A.5080903@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> Message-ID: <1271681403.2814.28.camel@macbook> On Fri, 2010-04-09 at 09:34 -0700, Vladimir Kozlov wrote: > On 4/9/10 8:13 AM, Christian Thalinger wrote: > >> > >> MethodHandles::generate_method_handle_interpreter_entry(): > >> > >> ! Register tem = G5_method; > >> ! for (jint* pchase = methodOopDesc::method_type_offsets_chain(); (*pchase) != -1; pchase++) { > >> ! __ ld_ptr(tem, *pchase, G5_method_type); > >> ! tem = G5_method_type; // yes, it's the same register... > >> ^ it is loop invariant, why you put it inside? > >> ! } > > > > I'm not sure I understand. G5_method_type is loaded in the ld-ptr > > instruction from Address(tem, *pchase). > > tem = G5_method_type is register renaming - it is not moving value, > so you don't need to do renaming inside loop. Ahh, got it. That is because of the porting from x86. I removed the code from the loop and added an assert. > >> > >> Also MacroAssembler::load_method_handle_vmslots() has next code which > >> looks similar to above but has the check "!= 0" > >> > >> ! if (java_dyn_MethodHandle::vmslots_offset_in_bytes() != 0) { > >> ! // hoist vmslots into every mh to avoid dependent load chain > >> ! ld( Address(mh_reg, delayed_value(java_dyn_MethodHandle::vmslots_offset_in_bytes, temp_reg)), vmslots_reg); > >> ! } else { > >> ! Register temp2_reg = vmslots_reg; > >> ! ld_ptr(Address(mh_reg, delayed_value(java_dyn_MethodHandle::type_offset_in_bytes, temp_reg)), temp2_reg); > >> ! ld_ptr(Address(temp2_reg, delayed_value(java_dyn_MethodType::form_offset_in_bytes, temp_reg)), temp2_reg); > >> ! ld( Address(temp2_reg, delayed_value(java_dyn_MethodTypeForm::vmslots_offset_in_bytes, temp_reg)), vmslots_reg); > >> ! } > > > > You want me to reuse that code? > > No. I was confused that in load_method_handle_vmslots() there is separate code when vmslots_offset_in_bytes() != 0 and > generate_method_handle_interpreter_entry() does not have such code. Hmm. I don't know the details here (John should) but maybe that's because we dig out the right MethodType and then retrieve the vmslots value from that MethodType and the short-cut is not valid at that point. But that's just a guess. Here is the updated webrev: http://cr.openjdk.java.net/~twisti/6829193/webrev.03/ -- Christian From Christian.Thalinger at Sun.COM Mon Apr 19 07:32:00 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 19 Apr 2010 14:32:00 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6944503: Improved Zero crash dump Message-ID: <20100419143204.8272D44607@hg.openjdk.java.net> Changeset: c544d979f886 Author: twisti Date: 2010-04-19 02:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c544d979f886 6944503: Improved Zero crash dump Summary: With Zero on a GC crash the stack was dumped differently to other crashes. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp From yamauchi at google.com Mon Apr 19 14:47:40 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Mon, 19 Apr 2010 14:47:40 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <4BC4D91C.3000000@gmx.de> References: <4BC4D91C.3000000@gmx.de> Message-ID: It's a good point. I'm just curious - is the movbe instruction supported on the Atom chip only or all Intel processors released around or after 2008? What about AMD? Hiroshi On Tue, Apr 13, 2010 at 1:50 PM, Ulf Zibis wrote: > +1 > I would like to see this enhancement. > > But we could do better on x86, as I guess those swap instructions would > likely come accompanied with a move: > ?0x00b95d79: bswap ?%ebx ? ? ? ? ? ? ? ;*invokevirtual putInt > ?... > ?0x00b95d8d: mov ? ?%ebx,(%eax,%ecx,1) ?;*invokevirtual putInt > > could be shorter: > ?... > ?0x00b95d8b: movbe ? ?%ebx,(%eax,%ecx,1) ?;*invokevirtual putInt > > On char/short there could be an additional win: > swap(x) { return (char)(Integer.reverseBytes(x) >>> 16); }: > ?0x00b8965d: bswap ?%edx > ?0x00b8965f: shr ? ?$0x10,%edx > ?... > ?0x00b8966c: mov ? ?%dx,(%eax) ? ? ? ? ;*invokevirtual putChar > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > java.nio.DirectByteBuffer::putChar at 30 (line 482) > > ... but best would be: > ?0x00b89667: movbe ? ?%dx,(%eax) ? ? ? ? ;*invokevirtual putChar > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > java.nio.DirectByteBuffer::putChar at 30 (line 482) > > Same thoughts on getInt, getChar/Short. > On SPARC I don't know. > > -Ulf > > > Am 13.04.2010 21:11, schrieb Hiroshi Yamauchi: >> >> Hi there, >> >> I'd like to contribute this patch that implements the intrinsics for >> Short/Character.reverseBytes (in C2): >> >> ? http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/ >> ?(Patch 1) >> >> (Thanks to Chuck for reviewing it and creating the webrev on my behalf.) >> >> This adds new siblings for the existing Integer/Long.reverseBytes >> intrinsics. Note: I did my best for the sparc implementation >> (sparc.ad) but haven't been able to build or test it (I don't have >> access to a sparc machine.) >> >> An impact of this patch can be seen in the microbenchmark >> jdk/test/java/nio/Buffer/SwapMicroBenchmark (which was written by >> Martin) with an experimental patch that lets DirectByteBuffer use >> those intrinsics (instead of simple Java implementations) on >> non-native endian operations: >> >> ? http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ >> ? ? ? (Patch 2) >> >> This patch hasn't been checked in yet but is being worked on by Martin and >> Ulf. >> >> The numbers from my measurements on x86 32 bit follow. Note the >> numbers for BIG_ENDIAN. >> >> ----------Unmodified---------- >> Method ? ? ? ? ? ? ? ? ? Millis Ratio >> swap char BIG_ENDIAN ? ? ? ? 64 1.000 >> swap char LITTLE_ENDIAN ? ? ?31 0.492 >> swap short BIG_ENDIAN ? ? ? ?75 1.176 >> swap short LITTLE_ENDIAN ? ? 31 0.496 >> swap int BIG_ENDIAN ? ? ? ? ?45 0.711 >> swap int LITTLE_ENDIAN ? ? ? ?8 0.125 >> swap long BIG_ENDIAN ? ? ? ? 72 1.131 >> swap long LITTLE_ENDIAN ? ? ?17 0.277 >> >> ----------Modified (with Patches 1 and 2)---------- >> Method ? ? ? ? ? ? ? ? ? Millis Ratio >> swap char BIG_ENDIAN ? ? ? ? 44 1.000 >> swap char LITTLE_ENDIAN ? ? ?31 0.709 >> swap short BIG_ENDIAN ? ? ? ?44 1.004 >> swap short LITTLE_ENDIAN ? ? 31 0.708 >> swap int BIG_ENDIAN ? ? ? ? ?18 0.423 >> swap int LITTLE_ENDIAN ? ? ? ?8 0.180 >> swap long BIG_ENDIAN ? ? ? ? 24 0.544 >> swap long LITTLE_ENDIAN ? ? ?17 0.400 >> >> The speedups are clearly non-trivial. The speedup for int/long is due >> to the use of the existing Integer/Long.reverseBytes intrinsics in >> DirectByteBuffer (Patch 2). The speedup for short/char is due to the >> use of the new Character/Short.reverseBytes intrinsics in >> DirectByteBuffer (Patch 1) and Patch 2. >> >> Anyone willing to review it (Patch 1)? >> >> Thanks, >> Hiroshi >> >> >> > > From gbenson at redhat.com Tue Apr 20 01:40:23 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 20 Apr 2010 09:40:23 +0100 Subject: Review Request: Zero JNI handles fix In-Reply-To: <20100330145920.GD3617@redhat.com> References: <20100329152453.GB3421@redhat.com> <1269942726.982.129.camel@macbook> <4BB202CA.9040202@oracle.com> <20100330145920.GD3617@redhat.com> Message-ID: <20100420084023.GB3510@redhat.com> Gary Benson wrote: > Keith McGuigan wrote: > > On 03/30/10 05:52, Christian Thalinger wrote: > > > On Mon, 2010-03-29 at 16:24 +0100, Gary Benson wrote: > > > > Zero will exit with an error when invoked with -Xcheck:jni. > > > > This webrev fixes: > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix/ > > > > > > > > Note that this is actually a pretty old issue, but the fix > > > > for it got lost from the IcedTea repositories. There's more > > > > information here: > > > > > > > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=323 > > > > > > > > I don't have a bug id for this. > > > > > > 6939182: Zero JNI handles fix > > > > > > I guess the changes are good since it uses an #ifdef. Maybe one > > > of the runtime guys could also comment on this one. > > > > It would be better to put this in zero-specific code somewhere > > instead of polluting common code with #ifdef, but if that's not > > possible... > > > > Also, instead of this point-fix in jniHandles, why not fix > > last_Java_sp() to return zero_stack()->sp() in the zero case? > > This is not the only place last_Java_sp() is called. Might > > want to fix it for last_Java_pc() (and related) too. > > The difficulty is that what last_Java_sp is returning in Zero is the > Zero frame pointer, which is not the highest thing on the stack. It > probably isn't the best thing to #ifdef this here though, I agree. > I'll have a think about it... I've reworked the fix: http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix-2/ last_Java_sp() now returns the actual Zero stack pointer. The frame anchor has a new last_Java_fp field that stores the value previously stored in last_Java_sp, in much the same way as the x86 port does. Note that the code in frame_zero.* already stored both these values, but with the names confusingly reversed. I have unreversed them in this webrev. I have also changed the type of the frame pointer be a ZeroFrame* -- leaving the stack pointer as an intptr_t* -- to help ensure that everything gets the arguments in the right order. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Tue Apr 20 02:16:43 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 20 Apr 2010 11:16:43 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <4BC9ADEA.5010603@gmx.de> References: <4BC4D91C.3000000@gmx.de> <1271335516.2134.247.camel@macbook> <4BC9ADEA.5010603@gmx.de> Message-ID: <1271755003.6002.8.camel@macbook> On Sat, 2010-04-17 at 14:47 +0200, Ulf Zibis wrote: > Am 15.04.2010 14:45, schrieb Christian Thalinger: > > > > I filed: > > > > 6944091: C2 should use movbe on x86 if available > > > > Hi, can you please check: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939277 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6944091 > > They are still not publicly visible. No sorry, I don't see any reason why these are not visible. Someone more familiar with Bugster should have a look. At least I added you to the interest list for 6944091. -- Christian From Christian.Thalinger at Sun.COM Tue Apr 20 02:22:12 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 20 Apr 2010 11:22:12 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <1271341529.2134.352.camel@macbook> Message-ID: <1271755332.6002.10.camel@macbook> On Thu, 2010-04-15 at 10:30 -0700, Tom Rodriguez wrote: > Can we use the macroassembler loads instead of emit_form on sparc? I was thinking the same but then I looked at emit_form3_mem_reg_asi and there is some other stuff happening there (SP/FP special case, disp != 0). -- Christian From Nelson.Dcosta at Sun.COM Tue Apr 20 03:06:05 2010 From: Nelson.Dcosta at Sun.COM (Nelson) Date: Tue, 20 Apr 2010 15:36:05 +0530 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <1271755003.6002.8.camel@macbook> References: <4BC4D91C.3000000@gmx.de> <1271335516.2134.247.camel@macbook> <4BC9ADEA.5010603@gmx.de> <1271755003.6002.8.camel@macbook> Message-ID: <4BCD7C8D.2060308@sun.com> Hi Ulf, There have been some hardware changes that are delaying the process of the bugs updating on bugs.sun.com. This should be rectified soon. I will keep you posted as soon as I hear this has been fixed. Regards, Nelson On 4/20/2010 2:46 PM, Christian Thalinger wrote: > On Sat, 2010-04-17 at 14:47 +0200, Ulf Zibis wrote: > >> Am 15.04.2010 14:45, schrieb Christian Thalinger: >> >>> I filed: >>> >>> 6944091: C2 should use movbe on x86 if available >>> >>> >> Hi, can you please check: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939277 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6944091 >> >> They are still not publicly visible. >> > No sorry, I don't see any reason why these are not visible. Someone > more familiar with Bugster should have a look. > > At least I added you to the interest list for 6944091. > > -- Christian > > From tom.rodriguez at oracle.com Tue Apr 20 10:47:53 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Apr 2010 10:47:53 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <1271755332.6002.10.camel@macbook> References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> Message-ID: <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> On Apr 20, 2010, at 2:22 AM, Christian Thalinger wrote: > On Thu, 2010-04-15 at 10:30 -0700, Tom Rodriguez wrote: >> Can we use the macroassembler loads instead of emit_form on sparc? > > I was thinking the same but then I looked at emit_form3_mem_reg_asi and > there is some other stuff happening there (SP/FP special case, disp != > 0). The special cases for FP/SP are needed for the stackSlotI variants but the memory variants can use the macroassembler versions if they are changed to be use iRegP instead of memory. This will force the matcher to compute the address into a register instead of attempting to use addressing modes which aren't supported by the ASI loads. The stackSlotI variants have to be handled by hand because the offsets aren't known until after register allocation. I just noticed that the original ReverseBytes routines also use the old ins_encode style, so maybe we should just keep the new ones like the old ones. The new ones should really be: opcode(Assembler::...); ins_encode( form3_mem_reg_little(src, dst) ); instead of the ins_encode %{ %} style since that is intended for the MacroAssembler style encodings. The opcodes in the webrev are wrong as well since they are the opcodes for the normal load not the ASI variant. The effect statements are also redundant and can be dropped. I think this all leads me to wish that all the reverse routines were written directly in terms of MacroAssembler with memory changed to iRegP and the stackSlotI variants handled by hand but in MacroAssembler as well. So the loads would look like this: // Load char reversed byte order instruct loadC_reversed(iRegI dst, iRegP src) %{ match(Set dst (ReverseBytesC (LoadUS src))); ins_cost(MEMORY_REF_COST); size(4); format %{ "LDUHA $src, $dst\t!asi=primary_little" %} ins_encode %{ __ lduha($src$$Register, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); %} ins_pipe(iload_mem); } and the stackSlotI variants would look like this: instruct bytes_reverse_char(iRegI dst, stackSlotI src) %{ match(Set dst (ReverseBytesC src)); effect(DEF dst, USE src); // Op cost is artificially doubled to make sure that load or store // instructions are preferred over this one which requires a spill // onto a stack slot. ins_cost(2*DEFAULT_COST + MEMORY_REF_COST); format %{ "LDUHA $src, $dst\t!asi=primary_little\n\t" %} ins_encode %{ int offset = $src$$disp + STACK_BIAS; __ add($src$$base$$Register, __ ensure_simm13_or_reg(offset, O7), O7); __ lduha(O7, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); %} ins_pipe( iload_mem ); %} > > -- Christian > From john.r.rose at oracle.com Tue Apr 20 14:25:54 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 20 Apr 2010 14:25:54 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1271681403.2814.28.camel@macbook> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> Message-ID: <1128F7D1-65C0-43B0-BE9A-C7631A8A5D7C@oracle.com> On Apr 19, 2010, at 5:50 AM, Christian Thalinger wrote: > Hmm. I don't know the details here (John should) but maybe that's > because we dig out the right MethodType and then retrieve the vmslots value from > that MethodType and the short-cut is not valid at that point. But > that's just a guess. That is correct. At some point we'll make a choice and delete one of the alternatives from the code. -- John From john.r.rose at oracle.com Tue Apr 20 14:49:33 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 20 Apr 2010 14:49:33 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1271674487.917.4.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> Message-ID: On Apr 19, 2010, at 3:54 AM, Christian Thalinger wrote: > L0? I think you mean L7. I only use L0 in unwind_exception to store a > temporary result. Yes, I meant L7. (I was looking at L0 used as a temp. nearby in c1_Runtime1_sparc.cpp.) The places where C1 uses L7 to correct the stack need to be clearly linked, perhaps by a shared symbolic constant. I see these places: - method_handle_invoke_SP_save_opr in c1_FrameMap_sparc.hpp - the tricky restore of L7 to SP in c1_Runtime1_sparc.cpp - the use of L7 to correct sp_adjustment_by_callee in frame_sparc.cpp The shared symbolic constant could be method_handle_invoke_SP_save_opr itself, if there's a way of digging L7 out of it. The basic rule here is the each type of frame that makes method handle invokes must preserve SP across those invokes. The interpreter already does so, stashing SP in the last_sp stack frame variable on all platforms. On Intel, both compilers (C1 and C2) stash SP in RBP. On SPARC they both use L7. When walking the stack, the preserved SP has to be taken into account. For the interpreter this is based on the last_sp variable, which is accessed via the frame pointer. For compiled code, which doesn't necessarily have frame pointers, the stack walker has to (a) determine if the call was a MH invoke, and (b) if so pull the corrected stack pointer out of a preserved register. Is that all correct? If so, the story (and what charming one it is :-) should be put into comments somewhere, perhaps near the shared symbolic constant for the preserved register. -- John From yamauchi at google.com Tue Apr 20 15:09:00 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 20 Apr 2010 15:09:00 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> Message-ID: Here's version 2: http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.02/ It's not up-to-date with the latest comments. But I send it here anyway. Re: movbe, I don't see string "movbe" in my /proc/cpuinfo output on my Linux machine. So, it probably does not have it. Is anyone working on a general movbe support in Hotspot? Hiroshi On Tue, Apr 20, 2010 at 10:47 AM, Tom Rodriguez wrote: > > On Apr 20, 2010, at 2:22 AM, Christian Thalinger wrote: > >> On Thu, 2010-04-15 at 10:30 -0700, Tom Rodriguez wrote: >>> Can we use the macroassembler loads instead of emit_form on sparc? >> >> I was thinking the same but then I looked at emit_form3_mem_reg_asi and >> there is some other stuff happening there (SP/FP special case, disp != >> 0). > > The special cases for FP/SP are needed for the stackSlotI variants but the memory variants can use the macroassembler versions if they are changed to be use iRegP instead of memory. ?This will force the matcher to compute the address into a register instead of attempting to use addressing modes which aren't supported by the ASI loads. ?The stackSlotI variants have to be handled by hand because the offsets aren't known until after register allocation. ?I just noticed that the original ReverseBytes routines also use the old ins_encode style, so maybe we should just keep the new ones like the old ones. ?The new ones should really be: > > ?opcode(Assembler::...); > ?ins_encode( form3_mem_reg_little(src, dst) ); > > instead of the ins_encode %{ %} style since that is intended for the MacroAssembler style encodings. ?The opcodes in the webrev are wrong as well since they are the opcodes for the normal load not the ASI variant. ?The effect statements are also redundant and can be dropped. > > I think this all leads me to wish that all the reverse routines were written directly in terms of MacroAssembler with memory changed to iRegP and the stackSlotI variants handled by hand but in MacroAssembler as well. ?So the loads would look like this: > > // Load char reversed byte order > instruct loadC_reversed(iRegI dst, iRegP src) %{ > ?match(Set dst (ReverseBytesC (LoadUS src))); > > ?ins_cost(MEMORY_REF_COST); > ?size(4); > ?format %{ "LDUHA ?$src, $dst\t!asi=primary_little" %} > > ?ins_encode %{ > ? ?__ lduha($src$$Register, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); > ?%} > ?ins_pipe(iload_mem); > } > > and the stackSlotI variants would look like this: > > instruct bytes_reverse_char(iRegI dst, stackSlotI src) %{ > ?match(Set dst (ReverseBytesC src)); > ?effect(DEF dst, USE src); > > ?// Op cost is artificially doubled to make sure that load or store > ?// instructions are preferred over this one which requires a spill > ?// onto a stack slot. > ?ins_cost(2*DEFAULT_COST + MEMORY_REF_COST); > ?format %{ "LDUHA ?$src, $dst\t!asi=primary_little\n\t" %} > ?ins_encode %{ > ? ?int offset = $src$$disp + STACK_BIAS; > ? ?__ add($src$$base$$Register, __ ensure_simm13_or_reg(offset, O7), O7); > ? ?__ lduha(O7, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); > ?%} > ?ins_pipe( iload_mem ); > %} > > >> >> -- Christian >> > > From tom.rodriguez at oracle.com Tue Apr 20 15:23:45 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Apr 2010 15:23:45 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> Message-ID: <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> We're not really targetting Atom so I wouldn't worry about it with your changes. I think there's a bug filed about it and we may get to it someday. You don't need ReverseBytesUS since there's no semantic difference with ReverseBytesS, so just drop it. As far as the sparc changes, don't worry about them, Christian or I will do something appropriate and send it our for review on top of your changes. tom On Apr 20, 2010, at 3:09 PM, Hiroshi Yamauchi wrote: > Here's version 2: > > http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.02/ > > It's not up-to-date with the latest comments. But I send it here anyway. > > Re: movbe, I don't see string "movbe" in my /proc/cpuinfo output on my > Linux machine. So, it probably does not have it. Is anyone working on > a general movbe support in Hotspot? > > Hiroshi > > > On Tue, Apr 20, 2010 at 10:47 AM, Tom Rodriguez > wrote: >> >> On Apr 20, 2010, at 2:22 AM, Christian Thalinger wrote: >> >>> On Thu, 2010-04-15 at 10:30 -0700, Tom Rodriguez wrote: >>>> Can we use the macroassembler loads instead of emit_form on sparc? >>> >>> I was thinking the same but then I looked at emit_form3_mem_reg_asi and >>> there is some other stuff happening there (SP/FP special case, disp != >>> 0). >> >> The special cases for FP/SP are needed for the stackSlotI variants but the memory variants can use the macroassembler versions if they are changed to be use iRegP instead of memory. This will force the matcher to compute the address into a register instead of attempting to use addressing modes which aren't supported by the ASI loads. The stackSlotI variants have to be handled by hand because the offsets aren't known until after register allocation. I just noticed that the original ReverseBytes routines also use the old ins_encode style, so maybe we should just keep the new ones like the old ones. The new ones should really be: >> >> opcode(Assembler::...); >> ins_encode( form3_mem_reg_little(src, dst) ); >> >> instead of the ins_encode %{ %} style since that is intended for the MacroAssembler style encodings. The opcodes in the webrev are wrong as well since they are the opcodes for the normal load not the ASI variant. The effect statements are also redundant and can be dropped. >> >> I think this all leads me to wish that all the reverse routines were written directly in terms of MacroAssembler with memory changed to iRegP and the stackSlotI variants handled by hand but in MacroAssembler as well. So the loads would look like this: >> >> // Load char reversed byte order >> instruct loadC_reversed(iRegI dst, iRegP src) %{ >> match(Set dst (ReverseBytesC (LoadUS src))); >> >> ins_cost(MEMORY_REF_COST); >> size(4); >> format %{ "LDUHA $src, $dst\t!asi=primary_little" %} >> >> ins_encode %{ >> __ lduha($src$$Register, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); >> %} >> ins_pipe(iload_mem); >> } >> >> and the stackSlotI variants would look like this: >> >> instruct bytes_reverse_char(iRegI dst, stackSlotI src) %{ >> match(Set dst (ReverseBytesC src)); >> effect(DEF dst, USE src); >> >> // Op cost is artificially doubled to make sure that load or store >> // instructions are preferred over this one which requires a spill >> // onto a stack slot. >> ins_cost(2*DEFAULT_COST + MEMORY_REF_COST); >> format %{ "LDUHA $src, $dst\t!asi=primary_little\n\t" %} >> ins_encode %{ >> int offset = $src$$disp + STACK_BIAS; >> __ add($src$$base$$Register, __ ensure_simm13_or_reg(offset, O7), O7); >> __ lduha(O7, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); >> %} >> ins_pipe( iload_mem ); >> %} >> >> >>> >>> -- Christian >>> >> >> From tom.rodriguez at oracle.com Tue Apr 20 15:39:54 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Apr 2010 15:39:54 -0700 Subject: review (S) for 6943485: JVMTI always on capabilities change code generation too much Message-ID: http://cr.openjdk.java.net/~never/6943485 6943485: JVMTI always on capabilities change code generation too much Reviewed-by: The set of always on JVMTI capabilities include thing which will cause changes in the code the compiler generates which interferes with using JVMTI to support profiling since you aren't profiling the same generated code that you would be executing. In particular the redefine and transform classes capabilities set the JvmtiExport::can_access_local_variables() flag which causes the compilers to keep all Java locals live even if they aren't needed for computation. Additionally we will currently turn of EA is this is set, which was done as the fix for 6895383. I've changed the setting of JvmtiExport::can_access_local_variables to only be driven by the two capabilities can_access_locals_variables and can_generate_breakpoints which should restrict these to be set when running under a debugger, since the original intent of keeping Java locals alive was to help simulate debugging while running under the interpreter where Java locals keep their values until they are overwritten. JvmtiExport::can_access_local_variables is only used by the compilers so this doesn't affect any other part of the system. I also moved some code which kept locals live in exception paths under the can_access_live_locals flag which made the flag can_examine_or_deopt_anywhere go dead. There were also some variables Compilation::_needs_debug_information and Compile::_deopt_happens which are always true and always must be true that I just deleted. Tested with runthese and all the NSK serviceability tests. Also compared the code we generate when running with and without an agent to make sure they were the same. From john.r.rose at oracle.com Tue Apr 20 16:05:26 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 20 Apr 2010 16:05:26 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <1128F7D1-65C0-43B0-BE9A-C7631A8A5D7C@oracle.com> Message-ID: <1F693765-041E-4501-94C7-9BE209C65E92@oracle.com> Review comments: In general, nice comments added in various places explaining what's going on. --- assembler_sparc In MacroAssembler::argument_offset I prefer the formulation with exact_log2, rather than introducing another constant (logStackElementSize). The slowness of exact_log2 doesn't matter, and the precise correspondence with its operand does matter. --- templateInterpreter_sparc (Note how much buggy garbage code goes away from generate_return_entry_for if callers pop arguments on call rather than on return.) --- templateTable_sparc + // XXX can I use G1 here Yes; you can just delete the query. 'G5_method': suggest using a locally named temp called 'G5_callsite'. --- methodHandles_x86, methodHandles The light changes to x86 code cry out for a refactor of sparc-specific code into methodHandles_sparc.hpp. We have this in the mlvm already, as part of meth-conv-6939861.patch. I guess we can wait for that change set to fix this, but it would have been nice to introduce the arch-specific header file with the second arch, rather than later. --- interp_masm_sparc, interpreter_sparc, stubGenerator_sparc, assembler_x86, methodHandles_x86 OK. --- methodHandles_sparc The biggie... The comments and variable names read well. It parallels the x86 code nicely. This is important, because the x86 code is changing. + // emit WrongMethodType path first, to enable jccb back-branch from main path Now we just have to notify the SPARC hardware designers that we are ready for the jccb instruction. :-) verify_argslot, etc.: Have you tested this code with the debug build? And also with -XX:+VerifyMethodHandles? STACK_BIAS: First, it is zero on ILP32, so it should be protected by LP64_ONLY. Second, you can't do this on LP64: add(SP, STACK_BIAS, SP); ...because if an interrupt comes in on that thread, the OS won't know how to walk the stack and find register windows, etc. Instead, correct 'offset' (maybe into a temp register), and then just add to SP. I think it's worth defining a MacroAssembler macro for correcting a RegisterorConstant value. Use regcon_sll_ptr_by_con as a model, and define regcon_align_ptr_by_con. In remove_arg_slots, you should increment SP. Use the the alignment macro, of course. In generate_method_handle_stub, I think the following comment is wrong: + // - O0: receiver method handle Should be G3_method_handle, right? ...To be continued... -- John From tom.rodriguez at oracle.com Tue Apr 20 16:22:31 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 20 Apr 2010 23:22:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6945219: minor SA fixes Message-ID: <20100420232250.0CCCA44630@hg.openjdk.java.net> Changeset: bc32f286fae0 Author: never Date: 2010-04-20 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bc32f286fae0 6945219: minor SA fixes Reviewed-by: twisti ! agent/src/os/linux/ps_core.c ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeDisassembler.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/SignatureIterator.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/FrameWrapper.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Assert.java From tom.rodriguez at oracle.com Tue Apr 20 16:38:33 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Apr 2010 16:38:33 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> Message-ID: <3559AA1D-8023-4567-AD16-3B40F1FA168F@oracle.com> On Apr 16, 2010, at 2:48 PM, John Rose wrote: > I like it too; reviewed. > > The use of L0 is tricky. You call it L7 in one comment. Be sure that all of these uses of L0 are linked together by comments. > > The change touches one of my pet peeves: The SP adjustment tracking in the frame logic has always seemed awkward to me (not from your change). I don't see a clearer reformulation yet. (Chuck Rasbold made it better with the unextended_sp stuff.) > > One partial cleanup would lead to some simplifications. It would change the convention by which the interpreter pops its outgoing arguments. Currently it pretends to keep the arguments on stack throughout the call; it should release them to the callee before completing the control transfer to the callee. I'm not sure how this can be changed. The outgoing expression stack forms the base of the locals in the callee frame. The SP of the frame also has to cover all live values in the frame throughout its lifetime, otherwise a signal handler frame can be pushed on top of the current SP and overwrite live values. It's also possible to stop at the call site and GC before entering the callee and the arguments have to be live somewhere when this occurs. Also on sparc Lesp and SP are different registers but on intel they are the same which can complicate any changes in this area. Am I misunderstanding what you are suggesting needs to be changed? > Currently, as a result, a return to the interpreter resets to a saved SP that points to the argument list base (lowest address, not highest), the address of an argument list that (at that point) is long gone. The interpreter must then perform extra calculations to re-adjust the SP by the size of the absent argument list, calculations which add no value. And when stack walking, we have to continually remember that the unextended SP might overlap with stack storage owned by the callee, which is counterintuitive and therefore bug-prone. That's new with method handles. Previously frames could only be enlarged as a result of SP adjustments by the callee but the new argument shuffling logic means they can be shrunk too. The shrinking could be avoided if we moved all the arguments when shrinking was required. Again I don't see how this can be avoided unless you disallow frame size adjustment which is pretty much impossible I think. tom > > -- John > > On Apr 16, 2010, at 5:41 AM, Christian Thalinger wrote: > >> On Thu, 2010-04-15 at 10:31 -0700, Tom Rodriguez wrote: >>> Could the is_method_handle_invoke become part of CodeEmitInfo instead? >>> That would make more sense to me. >> >> Right. This looks much better: >> >> http://cr.openjdk.java.net/~twisti/6930772/webrev.03/ >> >> -- Christian >> > From Ulf.Zibis at gmx.de Tue Apr 20 17:27:35 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 21 Apr 2010 02:27:35 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> Message-ID: <4BCE4677.2040501@gmx.de> Am 21.04.2010 00:23, schrieb Tom Rodriguez: > We're not really targetting Atom so I wouldn't worry about it with your changes. I think there's a bug filed about it and we may get to it someday. > Yes: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6944091 If only Atom can benefit from movbe, I too think, this could be done later. Cheers, -Ulf From yamauchi at google.com Tue Apr 20 17:45:49 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 20 Apr 2010 17:45:49 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> Message-ID: On Tue, Apr 20, 2010 at 3:23 PM, Tom Rodriguez wrote: > We're not really targetting Atom so I wouldn't worry about it with your changes. ?I think there's a bug filed about it and we may get to it someday. OK. > > You don't need ReverseBytesUS since there's no semantic difference with ReverseBytesS, so just drop it. I don't exactly get this. At least x86 they are different in that the former is compiled into "BSWAP; SHR 16" and the latter is compiled into "BSWAP; SAR 16". > > As far as the sparc changes, don't worry about them, Christian or I will do something appropriate and send it our for review on top of your changes. OK. > > tom > > On Apr 20, 2010, at 3:09 PM, Hiroshi Yamauchi wrote: > >> Here's version 2: >> >> http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.02/ >> >> It's not up-to-date with the latest comments. But I send it here anyway. >> >> Re: movbe, I don't see string "movbe" in my /proc/cpuinfo output on my >> Linux machine. So, it probably does not have it. Is anyone working on >> a general movbe support in Hotspot? >> >> Hiroshi >> >> >> On Tue, Apr 20, 2010 at 10:47 AM, Tom Rodriguez >> wrote: >>> >>> On Apr 20, 2010, at 2:22 AM, Christian Thalinger wrote: >>> >>>> On Thu, 2010-04-15 at 10:30 -0700, Tom Rodriguez wrote: >>>>> Can we use the macroassembler loads instead of emit_form on sparc? >>>> >>>> I was thinking the same but then I looked at emit_form3_mem_reg_asi and >>>> there is some other stuff happening there (SP/FP special case, disp != >>>> 0). >>> >>> The special cases for FP/SP are needed for the stackSlotI variants but the memory variants can use the macroassembler versions if they are changed to be use iRegP instead of memory. ?This will force the matcher to compute the address into a register instead of attempting to use addressing modes which aren't supported by the ASI loads. ?The stackSlotI variants have to be handled by hand because the offsets aren't known until after register allocation. ?I just noticed that the original ReverseBytes routines also use the old ins_encode style, so maybe we should just keep the new ones like the old ones. ?The new ones should really be: >>> >>> ?opcode(Assembler::...); >>> ?ins_encode( form3_mem_reg_little(src, dst) ); >>> >>> instead of the ins_encode %{ %} style since that is intended for the MacroAssembler style encodings. ?The opcodes in the webrev are wrong as well since they are the opcodes for the normal load not the ASI variant. ?The effect statements are also redundant and can be dropped. >>> >>> I think this all leads me to wish that all the reverse routines were written directly in terms of MacroAssembler with memory changed to iRegP and the stackSlotI variants handled by hand but in MacroAssembler as well. ?So the loads would look like this: >>> >>> // Load char reversed byte order >>> instruct loadC_reversed(iRegI dst, iRegP src) %{ >>> ?match(Set dst (ReverseBytesC (LoadUS src))); >>> >>> ?ins_cost(MEMORY_REF_COST); >>> ?size(4); >>> ?format %{ "LDUHA ?$src, $dst\t!asi=primary_little" %} >>> >>> ?ins_encode %{ >>> ? ?__ lduha($src$$Register, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); >>> ?%} >>> ?ins_pipe(iload_mem); >>> } >>> >>> and the stackSlotI variants would look like this: >>> >>> instruct bytes_reverse_char(iRegI dst, stackSlotI src) %{ >>> ?match(Set dst (ReverseBytesC src)); >>> ?effect(DEF dst, USE src); >>> >>> ?// Op cost is artificially doubled to make sure that load or store >>> ?// instructions are preferred over this one which requires a spill >>> ?// onto a stack slot. >>> ?ins_cost(2*DEFAULT_COST + MEMORY_REF_COST); >>> ?format %{ "LDUHA ?$src, $dst\t!asi=primary_little\n\t" %} >>> ?ins_encode %{ >>> ? ?int offset = $src$$disp + STACK_BIAS; >>> ? ?__ add($src$$base$$Register, __ ensure_simm13_or_reg(offset, O7), O7); >>> ? ?__ lduha(O7, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); >>> ?%} >>> ?ins_pipe( iload_mem ); >>> %} >>> >>> >>>> >>>> -- Christian >>>> >>> >>> > > From tom.rodriguez at oracle.com Tue Apr 20 18:36:14 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Apr 2010 18:36:14 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> Message-ID: On Apr 20, 2010, at 5:45 PM, Hiroshi Yamauchi wrote: > On Tue, Apr 20, 2010 at 3:23 PM, Tom Rodriguez wrote: >> We're not really targetting Atom so I wouldn't worry about it with your changes. I think there's a bug filed about it and we may get to it someday. > > OK. > >> >> You don't need ReverseBytesUS since there's no semantic difference with ReverseBytesS, so just drop it. > > I don't exactly get this. At least x86 they are different in that the > former is compiled into "BSWAP; SHR 16" and the latter is compiled > into "BSWAP; SAR 16". I wasn't looking closely enough and assumed that the result would always be unsigned, but that's not true. So ignore me. tom > >> >> As far as the sparc changes, don't worry about them, Christian or I will do something appropriate and send it our for review on top of your changes. > > OK. > >> >> tom >> >> On Apr 20, 2010, at 3:09 PM, Hiroshi Yamauchi wrote: >> >>> Here's version 2: >>> >>> http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.02/ >>> >>> It's not up-to-date with the latest comments. But I send it here anyway. >>> >>> Re: movbe, I don't see string "movbe" in my /proc/cpuinfo output on my >>> Linux machine. So, it probably does not have it. Is anyone working on >>> a general movbe support in Hotspot? >>> >>> Hiroshi >>> >>> >>> On Tue, Apr 20, 2010 at 10:47 AM, Tom Rodriguez >>> wrote: >>>> >>>> On Apr 20, 2010, at 2:22 AM, Christian Thalinger wrote: >>>> >>>>> On Thu, 2010-04-15 at 10:30 -0700, Tom Rodriguez wrote: >>>>>> Can we use the macroassembler loads instead of emit_form on sparc? >>>>> >>>>> I was thinking the same but then I looked at emit_form3_mem_reg_asi and >>>>> there is some other stuff happening there (SP/FP special case, disp != >>>>> 0). >>>> >>>> The special cases for FP/SP are needed for the stackSlotI variants but the memory variants can use the macroassembler versions if they are changed to be use iRegP instead of memory. This will force the matcher to compute the address into a register instead of attempting to use addressing modes which aren't supported by the ASI loads. The stackSlotI variants have to be handled by hand because the offsets aren't known until after register allocation. I just noticed that the original ReverseBytes routines also use the old ins_encode style, so maybe we should just keep the new ones like the old ones. The new ones should really be: >>>> >>>> opcode(Assembler::...); >>>> ins_encode( form3_mem_reg_little(src, dst) ); >>>> >>>> instead of the ins_encode %{ %} style since that is intended for the MacroAssembler style encodings. The opcodes in the webrev are wrong as well since they are the opcodes for the normal load not the ASI variant. The effect statements are also redundant and can be dropped. >>>> >>>> I think this all leads me to wish that all the reverse routines were written directly in terms of MacroAssembler with memory changed to iRegP and the stackSlotI variants handled by hand but in MacroAssembler as well. So the loads would look like this: >>>> >>>> // Load char reversed byte order >>>> instruct loadC_reversed(iRegI dst, iRegP src) %{ >>>> match(Set dst (ReverseBytesC (LoadUS src))); >>>> >>>> ins_cost(MEMORY_REF_COST); >>>> size(4); >>>> format %{ "LDUHA $src, $dst\t!asi=primary_little" %} >>>> >>>> ins_encode %{ >>>> __ lduha($src$$Register, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); >>>> %} >>>> ins_pipe(iload_mem); >>>> } >>>> >>>> and the stackSlotI variants would look like this: >>>> >>>> instruct bytes_reverse_char(iRegI dst, stackSlotI src) %{ >>>> match(Set dst (ReverseBytesC src)); >>>> effect(DEF dst, USE src); >>>> >>>> // Op cost is artificially doubled to make sure that load or store >>>> // instructions are preferred over this one which requires a spill >>>> // onto a stack slot. >>>> ins_cost(2*DEFAULT_COST + MEMORY_REF_COST); >>>> format %{ "LDUHA $src, $dst\t!asi=primary_little\n\t" %} >>>> ins_encode %{ >>>> int offset = $src$$disp + STACK_BIAS; >>>> __ add($src$$base$$Register, __ ensure_simm13_or_reg(offset, O7), O7); >>>> __ lduha(O7, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); >>>> %} >>>> ins_pipe( iload_mem ); >>>> %} >>>> >>>> >>>>> >>>>> -- Christian >>>>> >>>> >>>> >> >> From john.r.rose at oracle.com Tue Apr 20 18:43:10 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 20 Apr 2010 18:43:10 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <3559AA1D-8023-4567-AD16-3B40F1FA168F@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <3559AA1D-8023-4567-AD16-3B40F1FA168F@oracle.com> Message-ID: <86D4C23C-FD07-47BE-B72C-2AFC7DCCEF6E@oracle.com> On Apr 20, 2010, at 4:38 PM, Tom Rodriguez wrote: >> One partial cleanup would lead to some simplifications. It would change the convention by which the interpreter pops its outgoing arguments. Currently it pretends to keep the arguments on stack throughout the call; it should release them to the callee before completing the control transfer to the callee. > > I'm not sure how this can be changed. The outgoing expression stack forms the base of the locals in the callee frame. The SP of the frame also has to cover all live values in the frame throughout its lifetime, otherwise a signal handler frame can be pushed on top of the current SP and overwrite live values. For x86, on an outgoing call rsi and bp->last_sp would contain the popped sp value, but sp would continue to be the argument base. During the call [sp..rsi) would be the space holding the arguments being handed off from the caller to callee. Immediately out of the interpreter, the outgoing receiver argument would be reachable at [rsi-wordsize]; at present it's always awkward to calculate the receiver end of the argument list. For method handle adapters and maybe i2c adapters we'll want to use another register to remember the receiver end of the argument list, even after argument list reformatting. > It's also possible to stop at the call site and GC before entering the callee and the arguments have to be live somewhere when this occurs. A "resolve blob" like "handle_wrong_method" does that, because it sets the special 'caller_must_gc_arguments' bit. That's always handled as a special case, even today, so the special-case code would need to be adjusted to address the arguments using the different convention. (See 'map->include_argument_oops' in oops_interpreted_do, etc.) > Also on sparc Lesp and SP are different registers but on intel they are the same which can complicate any changes in this area. Am I misunderstanding what you are suggesting needs to be changed? For sparc, not much would change except the treatment of Lesp. SP(O6) and Gargs(G4) jointly serve to delimit the storage of outgoing arguments, and this wouldn't change (just as on x86 SP wouldn't be popped). The Lesp(L0) register would be cut back to mark the limit of the caller's stack, exclusive of arguments. The outgoing receiver would be reachable at [L0-wordSize] . >> Currently, as a result, a return to the interpreter resets to a saved SP that points to the argument list base (lowest address, not highest), the address of an argument list that (at that point) is long gone. The interpreter must then perform extra calculations to re-adjust the SP by the size of the absent argument list, calculations which add no value. And when stack walking, we have to continually remember that the unextended SP might overlap with stack storage owned by the callee, which is counterintuitive and therefore bug-prone. > > That's new with method handles. Previously frames could only be enlarged as a result of SP adjustments by the callee but the new argument shuffling logic means they can be shrunk too. The shrinking could be avoided if we moved all the arguments when shrinking was required. Again I don't see how this can be avoided unless you disallow frame size adjustment which is pretty much impossible I think. For an adapter method handle, there are four interesting addresses: The two ends of the scratch memory we can use, and the two ends of the argument list. This boils down to three values on Intel, since two of those 'ends' are pointed at by rsp. On sparc it's a little trickier. The current rsi value passed out of the interpreter doesn't help locate any of those values; if we pre-pop arguments, then rsi becomes the far end of the scratch memory, as well as the initial far end of the argument list. I haven't worked out the details on sparc, but I imagine they are similar, except for dealing with the duplicate stack pointers. -- John From Christian.Thalinger at Sun.COM Wed Apr 21 02:22:27 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 21 Apr 2010 11:22:27 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> Message-ID: <1271841747.15338.40.camel@macbook> On Tue, 2010-04-20 at 14:49 -0700, John Rose wrote: > On Apr 19, 2010, at 3:54 AM, Christian Thalinger wrote: > > > L0? I think you mean L7. I only use L0 in unwind_exception to store a > > temporary result. > > Yes, I meant L7. (I was looking at L0 used as a temp. nearby in > c1_Runtime1_sparc.cpp.) > > The places where C1 uses L7 to correct the stack need to be clearly > linked, perhaps by a shared symbolic constant. > > I see these places: > - method_handle_invoke_SP_save_opr in c1_FrameMap_sparc.hpp > - the tricky restore of L7 to SP in c1_Runtime1_sparc.cpp > - the use of L7 to correct sp_adjustment_by_callee in frame_sparc.cpp > > The shared symbolic constant could be method_handle_invoke_SP_save_opr > itself, if there's a way of digging L7 out of it. Maybe we should add a register definition like rbp_mh_SP_save and L7_mh_SP_save for x86 and SPARC respectively and use that one to have a common shared symbolic constant across all compilers. method_handle_invoke_SP_save_opr would be C1 only. Looking at the C2 changes this wouldn't cover all uses, e.g.: ! return L7_REGP_mask; + instruct CallStaticJavaHandle(method meth, l7RegP l7) %{ + effect(USE meth, KILL l7); At least the register definition could be used in the frame code and in the preserve_SP/restore_SP code. > > The basic rule here is the each type of frame that makes method handle > invokes must preserve SP across those invokes. > > The interpreter already does so, stashing SP in the last_sp stack > frame variable on all platforms. > > On Intel, both compilers (C1 and C2) stash SP in RBP. On SPARC they > both use L7. > > When walking the stack, the preserved SP has to be taken into account. > For the interpreter this is based on the last_sp variable, which is > accessed via the frame pointer. For compiled code, which doesn't > necessarily have frame pointers, the stack walker has to (a) determine > if the call was a MH invoke, and (b) if so pull the corrected stack > pointer out of a preserved register. > > Is that all correct? If so, the story (and what charming one it > is :-) should be put into comments somewhere, perhaps near the shared > symbolic constant for the preserved register. Yes that's all correct and a nice story indeed :-) -- Christian From Christian.Thalinger at Sun.COM Wed Apr 21 07:14:40 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 21 Apr 2010 16:14:40 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1F693765-041E-4501-94C7-9BE209C65E92@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <1128F7D1-65C0-43B0-BE9A-C7631A8A5D7C@oracle.com> <1F693765-041E-4501-94C7-9BE209C65E92@oracle.com> Message-ID: <1271859280.15338.565.camel@macbook> On Tue, 2010-04-20 at 16:05 -0700, John Rose wrote: > Review comments: > > In general, nice comments added in various places explaining what's > going on. > > --- assembler_sparc > In MacroAssembler::argument_offset I prefer the formulation with > exact_log2, rather than introducing another constant > (logStackElementSize). The slowness of exact_log2 doesn't matter, and > the precise correspondence with its operand does matter. Well, logStackElementSize already exists, so I thought using it is a good idea. Anyway, I change it back. > > --- templateInterpreter_sparc > (Note how much buggy garbage code goes away from > generate_return_entry_for if callers pop arguments on call rather than > on return.) > > --- templateTable_sparc > + // XXX can I use G1 here > Yes; you can just delete the query. > > 'G5_method': suggest using a locally named temp called 'G5_callsite'. Both done. > > --- methodHandles_x86, methodHandles > > The light changes to x86 code cry out for a refactor of sparc-specific > code into methodHandles_sparc.hpp. We have this in the mlvm already, > as part of meth-conv-6939861.patch. I guess we can wait for that > change set to fix this, but it would have been nice to introduce the > arch-specific header file with the second arch, rather than later. > > --- interp_masm_sparc, interpreter_sparc, stubGenerator_sparc, > assembler_x86, methodHandles_x86 > OK. > > --- methodHandles_sparc > The biggie... > > The comments and variable names read well. > > It parallels the x86 code nicely. This is important, because the x86 > code is changing. > > + // emit WrongMethodType path first, to enable jccb back-branch > from main path > Now we just have to notify the SPARC hardware designers that we are > ready for the jccb instruction. :-) Hehe. I fix the comment. > > verify_argslot, etc.: Have you tested this code with the debug build? > And also with -XX:+VerifyMethodHandles? debug build, yes. VerifyMethodHandles, no. Will do so right now... looks good. > > STACK_BIAS: First, it is zero on ILP32, so it should be protected by > LP64_ONLY. > Second, you can't do this on LP64: > add(SP, STACK_BIAS, SP); > ...because if an interrupt comes in on that thread, the OS won't know > how to walk the stack and find register windows, etc. > > Instead, correct 'offset' (maybe into a temp register), and then just > add to SP. I think it's worth defining a MacroAssembler macro for > correcting a RegisterorConstant value. Use regcon_sll_ptr_by_con as a > model, and define regcon_align_ptr_by_con. I tried different implementations but I think something like a regcon_add_align_sp would be best. I will post a webrev with this one. > > In remove_arg_slots, you should increment SP. Use the the alignment > macro, of course. Done. > > In generate_method_handle_stub, I think the following comment is > wrong: > + // - O0: receiver method handle > Should be G3_method_handle, right? Right. Fixed. -- Christian From tom.rodriguez at oracle.com Wed Apr 21 10:07:28 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 21 Apr 2010 10:07:28 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <86D4C23C-FD07-47BE-B72C-2AFC7DCCEF6E@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <3559AA1D-8023-4567-AD16-3B40F1FA168F@oracle.com> <86D4C23C-FD07-47BE-B72C-2AFC7DCCEF6E@oracle.com> Message-ID: <5AC00027-39E9-4BBF-82D3-370A328AA1F3@oracle.com> On Apr 20, 2010, at 6:43 PM, John Rose wrote: > On Apr 20, 2010, at 4:38 PM, Tom Rodriguez wrote: > >>> One partial cleanup would lead to some simplifications. It would change the convention by which the interpreter pops its outgoing arguments. Currently it pretends to keep the arguments on stack throughout the call; it should release them to the callee before completing the control transfer to the callee. >> >> I'm not sure how this can be changed. The outgoing expression stack forms the base of the locals in the callee frame. The SP of the frame also has to cover all live values in the frame throughout its lifetime, otherwise a signal handler frame can be pushed on top of the current SP and overwrite live values. > > For x86, on an outgoing call rsi and bp->last_sp would contain the popped sp value, but sp would continue to be the argument base. During the call [sp..rsi) would be the space holding the arguments being handed off from the caller to callee. Immediately out of the interpreter, the outgoing receiver argument would be reachable at [rsi-wordsize]; at present it's always awkward to calculate the receiver end of the argument list. For method handle adapters and maybe i2c adapters we'll want to use another register to remember the receiver end of the argument list, even after argument list reformatting. Ignoring the details of how, what you're really wanting is that the unextended sp is the value that sp would have after the caller popped the outgoing arguments? So the call bytecode itself would compute how many arguments are popped instead of being done in the return entry point. It seems like something like that could be worked out though I'm unconvinced that it does more than shuffle around some complex code. I assume the benefit would come from changes to rsi/Gargs. tom > >> It's also possible to stop at the call site and GC before entering the callee and the arguments have to be live somewhere when this occurs. > > A "resolve blob" like "handle_wrong_method" does that, because it sets the special 'caller_must_gc_arguments' bit. That's always handled as a special case, even today, so the special-case code would need to be adjusted to address the arguments using the different convention. (See 'map->include_argument_oops' in oops_interpreted_do, etc.) > >> Also on sparc Lesp and SP are different registers but on intel they are the same which can complicate any changes in this area. Am I misunderstanding what you are suggesting needs to be changed? > > For sparc, not much would change except the treatment of Lesp. SP(O6) and Gargs(G4) jointly serve to delimit the storage of outgoing arguments, and this wouldn't change (just as on x86 SP wouldn't be popped). The Lesp(L0) register would be cut back to mark the limit of the caller's stack, exclusive of arguments. The outgoing receiver would be reachable at [L0-wordSize] . > >>> Currently, as a result, a return to the interpreter resets to a saved SP that points to the argument list base (lowest address, not highest), the address of an argument list that (at that point) is long gone. The interpreter must then perform extra calculations to re-adjust the SP by the size of the absent argument list, calculations which add no value. And when stack walking, we have to continually remember that the unextended SP might overlap with stack storage owned by the callee, which is counterintuitive and therefore bug-prone. >> >> That's new with method handles. Previously frames could only be enlarged as a result of SP adjustments by the callee but the new argument shuffling logic means they can be shrunk too. The shrinking could be avoided if we moved all the arguments when shrinking was required. Again I don't see how this can be avoided unless you disallow frame size adjustment which is pretty much impossible I think. > > For an adapter method handle, there are four interesting addresses: The two ends of the scratch memory we can use, and the two ends of the argument list. This boils down to three values on Intel, since two of those 'ends' are pointed at by rsp. On sparc it's a little trickier. The current rsi value passed out of the interpreter doesn't help locate any of those values; if we pre-pop arguments, then rsi becomes the far end of the scratch memory, as well as the initial far end of the argument list. > > I haven't worked out the details on sparc, but I imagine they are similar, except for dealing with the duplicate stack pointers. > > -- John From tom.rodriguez at oracle.com Wed Apr 21 11:13:52 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 21 Apr 2010 11:13:52 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1271681403.2814.28.camel@macbook> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> Message-ID: <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> Resending to list because it bounced. This change: + void get_cache_entry_pointer_at_bcp(Register cache, Register tmp, int bcp_offset, bool giant_index = false); seems spurious. I think the return_entry_for changes aren't really in the spirit of the design of the template interpreter. If invokedynamic has it's own strategy for lookup in the constant pool then it probably needs it's own return entry point. The invokedynamic case would select a new table in prepare_invoke that was generated by a call to generate_return_entry_for with a new flag indicating that the bytecode being handled is invokedynamic so it could use the giant cp cache logic. What you've got is ok but it's not really the way the template interpreter works. regcon_sll_ptr_by_con sure is convenient but its implementation is totally surprising and the name is long and unclear particularly since it has the same signature as regcon_sll_ptr but does something different. It desperately needs a comment in the hpp explaining what it does. I don't think dst should ever be optional, otherwise why it at all. This use: + __ add(Gargs, __ regcon_sll_ptr_by_con(G5_stack_move, LogBytesPerWord, G5_stack_move), Gargs); should just be sll_ptr. Actually given all the magic that the existing regcon_sll_ptr does, couldn't you shoehorn the new behaviour into it? The by_con behaviour of returning the new regcon instead of the value return parameter seems better anyway. The switch in load_sized_value is too clever for my taste. How about just a switch on size_in_bytes with a test on is_signed where it's needed? I'll leave the big blobs of method handle code to John. tom On Apr 19, 2010, at 5:50 AM, Christian Thalinger wrote: > On Fri, 2010-04-09 at 09:34 -0700, Vladimir Kozlov wrote: >> On 4/9/10 8:13 AM, Christian Thalinger wrote: >>>> >>>> MethodHandles::generate_method_handle_interpreter_entry(): >>>> >>>> ! Register tem = G5_method; >>>> ! for (jint* pchase = methodOopDesc::method_type_offsets_chain(); (*pchase) != -1; pchase++) { >>>> ! __ ld_ptr(tem, *pchase, G5_method_type); >>>> ! tem = G5_method_type; // yes, it's the same register... >>>> ^ it is loop invariant, why you put it inside? >>>> ! } >>> >>> I'm not sure I understand. G5_method_type is loaded in the ld-ptr >>> instruction from Address(tem, *pchase). >> >> tem = G5_method_type is register renaming - it is not moving value, >> so you don't need to do renaming inside loop. > > Ahh, got it. That is because of the porting from x86. I removed the > code from the loop and added an assert. > >>>> >>>> Also MacroAssembler::load_method_handle_vmslots() has next code which >>>> looks similar to above but has the check "!= 0" >>>> >>>> ! if (java_dyn_MethodHandle::vmslots_offset_in_bytes() != 0) { >>>> ! // hoist vmslots into every mh to avoid dependent load chain >>>> ! ld( Address(mh_reg, delayed_value(java_dyn_MethodHandle::vmslots_offset_in_bytes, temp_reg)), vmslots_reg); >>>> ! } else { >>>> ! Register temp2_reg = vmslots_reg; >>>> ! ld_ptr(Address(mh_reg, delayed_value(java_dyn_MethodHandle::type_offset_in_bytes, temp_reg)), temp2_reg); >>>> ! ld_ptr(Address(temp2_reg, delayed_value(java_dyn_MethodType::form_offset_in_bytes, temp_reg)), temp2_reg); >>>> ! ld( Address(temp2_reg, delayed_value(java_dyn_MethodTypeForm::vmslots_offset_in_bytes, temp_reg)), vmslots_reg); >>>> ! } >>> >>> You want me to reuse that code? >> >> No. I was confused that in load_method_handle_vmslots() there is separate code when vmslots_offset_in_bytes() != 0 and >> generate_method_handle_interpreter_entry() does not have such code. > > Hmm. I don't know the details here (John should) but maybe that's > because we dig out the right MethodType and then retrieve the vmslots value from > that MethodType and the short-cut is not valid at that point. But > that's just a guess. > > Here is the updated webrev: > > http://cr.openjdk.java.net/~twisti/6829193/webrev.03/ > > -- Christian > From Christian.Thalinger at Sun.COM Wed Apr 21 11:46:02 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 21 Apr 2010 20:46:02 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <3132190F-8363-4F9A-899B-1B24D4537530@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <1128F7D1-65C0-43B0-BE9A-C7631A8A5D7C@oracle.com> <1F693765-041E-4501-94C7-9BE209C65E92@oracle.com> <3132190F-8363-4F9A-899B-1B24D4537530@oracle.com> Message-ID: <1271875562.15338.736.camel@macbook> On Wed, 2010-04-21 at 00:51 -0700, John Rose wrote: > Finishing up with methodHandles_sparc: > > case _raise_exception: I don't think you should change Lesp for this. > There's no way the GC can do anything with the new words pointed at by > Lesp, so it's risky. Is there some layer of software that wants Lesp > and Gargs to change in concert? Not that I know of. I remove the Lesp adjustment. > > case _bound_ref_mh: "FIXME Is this required on SPARC" > > Yes, longs and doubles have to be split across two stack slots in > ILP32. On sparc it's tricky because the stack slot pair is not > aligned enough for a plain STX/LDX. In LP64, the second stack slot is > pure garbage. So on ILP32, you have to shift the high 32 bits of > O1_scratch down, then store them where they belong (which is the > lower-addresses stack slot, IIRC). I suppose the st_long macro will > help with that. I think using st_long/st_ptr should do the trick. > > The "ld" operations should be explicitly marked as "ldsw" or "lduw", > especially for _adapter_opt_i2l. Done. Here is the new webrev: http://cr.openjdk.java.net/~twisti/6829193/webrev.04/ -- Christian From john.r.rose at oracle.com Wed Apr 21 12:12:58 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 21 Apr 2010 12:12:58 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1271841747.15338.40.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> <1271841747.15338.40.camel@macbook> Message-ID: <335E276C-C245-41E8-BD92-FC007B94867F@oracle.com> On Apr 21, 2010, at 2:22 AM, Christian Thalinger wrote: > Looking at the C2 changes this wouldn't cover all uses, e.g.: > > ! return L7_REGP_mask; In some cases an extra assert can apply the constant to the usage. At least a comment will give applicability to "grep". -- John From Christian.Thalinger at Sun.COM Wed Apr 21 12:16:39 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 21 Apr 2010 21:16:39 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <335E276C-C245-41E8-BD92-FC007B94867F@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> <1271841747.15338.40.camel@macbook> <335E276C-C245-41E8-BD92-FC007B94867F@oracle.com> Message-ID: <1271877399.15338.767.camel@macbook> On Wed, 2010-04-21 at 12:12 -0700, John Rose wrote: > On Apr 21, 2010, at 2:22 AM, Christian Thalinger wrote: > > > Looking at the C2 changes this wouldn't cover all uses, e.g.: > > > > ! return L7_REGP_mask; > > In some cases an extra assert can apply the constant to the usage. At > least a comment will give applicability to "grep". Right, I did that in the C1 FrameMap too. I'll post new C1 and C2 webrevs. -- Christian From Christian.Thalinger at Sun.COM Wed Apr 21 12:24:41 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 21 Apr 2010 21:24:41 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1271877399.15338.767.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> <1271841747.15338.40.camel@macbook> <335E276C-C245-41E8-BD92-FC007B94867F@oracle.com> <1271877399.15338.767.camel@macbook> Message-ID: <1271877881.15338.772.camel@macbook> On Wed, 2010-04-21 at 21:16 +0200, Christian Thalinger wrote: > On Wed, 2010-04-21 at 12:12 -0700, John Rose wrote: > > On Apr 21, 2010, at 2:22 AM, Christian Thalinger wrote: > > > > > Looking at the C2 changes this wouldn't cover all uses, e.g.: > > > > > > ! return L7_REGP_mask; > > > > In some cases an extra assert can apply the constant to the usage. At > > least a comment will give applicability to "grep". > > Right, I did that in the C1 FrameMap too. I'll post new C1 and C2 > webrevs. http://cr.openjdk.java.net/~twisti/6930772/webrev.04/ -- Christian From tom.rodriguez at oracle.com Wed Apr 21 12:31:02 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 21 Apr 2010 12:31:02 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1271877881.15338.772.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> <1271841747.15338.40.camel@macbook> <335E276C-C245-41E8-BD92-FC007B94867F@oracle.com> <1271877399.15338.767.camel@macbook> <1271877881.15338.772.camel@macbook> Message-ID: <5F680F20-9951-4F5E-86F6-FDD67A20B397@oracle.com> Why are you returning a LIR_Opr&? tom On Apr 21, 2010, at 12:24 PM, Christian Thalinger wrote: > On Wed, 2010-04-21 at 21:16 +0200, Christian Thalinger wrote: >> On Wed, 2010-04-21 at 12:12 -0700, John Rose wrote: >>> On Apr 21, 2010, at 2:22 AM, Christian Thalinger wrote: >>> >>>> Looking at the C2 changes this wouldn't cover all uses, e.g.: >>>> >>>> ! return L7_REGP_mask; >>> >>> In some cases an extra assert can apply the constant to the usage. At >>> least a comment will give applicability to "grep". >> >> Right, I did that in the C1 FrameMap too. I'll post new C1 and C2 >> webrevs. > > http://cr.openjdk.java.net/~twisti/6930772/webrev.04/ > > -- Christian > From john.r.rose at oracle.com Wed Apr 21 12:32:17 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 21 Apr 2010 12:32:17 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> Message-ID: <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> On Apr 21, 2010, at 11:13 AM, Tom Rodriguez wrote: > Resending to list because it bounced. > > This change: > > + void get_cache_entry_pointer_at_bcp(Register cache, Register tmp, int bcp_offset, bool giant_index = false); > > seems spurious. > > I think the return_entry_for changes aren't really in the spirit of the design of the template interpreter. If invokedynamic has it's own strategy for lookup in the constant pool then it probably needs it's own return entry point. Good point. And... note that the differences have to do with how the stack is popped. Nearly all of the complexity of return_entry goes away if the caller pre-pops the arguments. Before splitting return_entry, let's either do the pre-popping (making splitting moot) or decide that it's impractical. > regcon_sll_ptr_by_con sure is convenient but its implementation is totally surprising and the name is long and unclear particularly since it has the same signature as regcon_sll_ptr but does something different. It desperately needs a comment in the hpp explaining what it does. I don't think dst should ever be optional, otherwise why it at all. This use: > > + __ add(Gargs, __ regcon_sll_ptr_by_con(G5_stack_move, LogBytesPerWord, G5_stack_move), Gargs); > > should just be sll_ptr. Actually given all the magic that the existing regcon_sll_ptr does, couldn't you shoehorn the new behaviour into it? I would prefer that, but will defer to others on what is "too much magic". > The by_con behaviour of returning the new regcon instead of the value return parameter seems better anyway. > The switch in load_sized_value is too clever for my taste. How about just a switch on size_in_bytes with a test on is_signed where it's needed? My high school writing teacher used to direct us, if we thought we had written something especially clever, to be ready to strike it out. Christian, if you break up the Overly Clever Switch in the sensible way Tom suggests, please break up the parallel one in the x86 code too. -- John From yamauchi at google.com Wed Apr 21 12:40:12 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 21 Apr 2010 12:40:12 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> Message-ID: OK. Based on that, I think the last revision: http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.02/ is in good shape (aside from the movbe support and the sparc part.) Let me know if there are some comments. Thanks, Hiroshi On Tue, Apr 20, 2010 at 6:36 PM, Tom Rodriguez wrote: > > On Apr 20, 2010, at 5:45 PM, Hiroshi Yamauchi wrote: > >> On Tue, Apr 20, 2010 at 3:23 PM, Tom Rodriguez wrote: >>> We're not really targetting Atom so I wouldn't worry about it with your changes. ?I think there's a bug filed about it and we may get to it someday. >> >> OK. >> >>> >>> You don't need ReverseBytesUS since there's no semantic difference with ReverseBytesS, so just drop it. >> >> I don't exactly get this. At least x86 they are different in that the >> former is compiled into "BSWAP; SHR 16" and the latter is compiled >> into "BSWAP; SAR 16". > > I wasn't looking closely enough and assumed that the result would always be unsigned, but that's not true. ?So ignore me. > >> >>> >>> As far as the sparc changes, don't worry about them, Christian or I will do something appropriate and send it our for review on top of your changes. >> >> OK. >> >>> >>> tom >>> >>> On Apr 20, 2010, at 3:09 PM, Hiroshi Yamauchi wrote: >>> >>>> Here's version 2: >>>> >>>> http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.02/ >>>> >>>> It's not up-to-date with the latest comments. But I send it here anyway. >>>> >>>> Re: movbe, I don't see string "movbe" in my /proc/cpuinfo output on my >>>> Linux machine. So, it probably does not have it. Is anyone working on >>>> a general movbe support in Hotspot? >>>> >>>> Hiroshi >>>> >>>> >>>> On Tue, Apr 20, 2010 at 10:47 AM, Tom Rodriguez >>>> wrote: >>>>> >>>>> On Apr 20, 2010, at 2:22 AM, Christian Thalinger wrote: >>>>> >>>>>> On Thu, 2010-04-15 at 10:30 -0700, Tom Rodriguez wrote: >>>>>>> Can we use the macroassembler loads instead of emit_form on sparc? >>>>>> >>>>>> I was thinking the same but then I looked at emit_form3_mem_reg_asi and >>>>>> there is some other stuff happening there (SP/FP special case, disp != >>>>>> 0). >>>>> >>>>> The special cases for FP/SP are needed for the stackSlotI variants but the memory variants can use the macroassembler versions if they are changed to be use iRegP instead of memory. ?This will force the matcher to compute the address into a register instead of attempting to use addressing modes which aren't supported by the ASI loads. ?The stackSlotI variants have to be handled by hand because the offsets aren't known until after register allocation. ?I just noticed that the original ReverseBytes routines also use the old ins_encode style, so maybe we should just keep the new ones like the old ones. ?The new ones should really be: >>>>> >>>>> ?opcode(Assembler::...); >>>>> ?ins_encode( form3_mem_reg_little(src, dst) ); >>>>> >>>>> instead of the ins_encode %{ %} style since that is intended for the MacroAssembler style encodings. ?The opcodes in the webrev are wrong as well since they are the opcodes for the normal load not the ASI variant. ?The effect statements are also redundant and can be dropped. >>>>> >>>>> I think this all leads me to wish that all the reverse routines were written directly in terms of MacroAssembler with memory changed to iRegP and the stackSlotI variants handled by hand but in MacroAssembler as well. ?So the loads would look like this: >>>>> >>>>> // Load char reversed byte order >>>>> instruct loadC_reversed(iRegI dst, iRegP src) %{ >>>>> ?match(Set dst (ReverseBytesC (LoadUS src))); >>>>> >>>>> ?ins_cost(MEMORY_REF_COST); >>>>> ?size(4); >>>>> ?format %{ "LDUHA ?$src, $dst\t!asi=primary_little" %} >>>>> >>>>> ?ins_encode %{ >>>>> ? ?__ lduha($src$$Register, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); >>>>> ?%} >>>>> ?ins_pipe(iload_mem); >>>>> } >>>>> >>>>> and the stackSlotI variants would look like this: >>>>> >>>>> instruct bytes_reverse_char(iRegI dst, stackSlotI src) %{ >>>>> ?match(Set dst (ReverseBytesC src)); >>>>> ?effect(DEF dst, USE src); >>>>> >>>>> ?// Op cost is artificially doubled to make sure that load or store >>>>> ?// instructions are preferred over this one which requires a spill >>>>> ?// onto a stack slot. >>>>> ?ins_cost(2*DEFAULT_COST + MEMORY_REF_COST); >>>>> ?format %{ "LDUHA ?$src, $dst\t!asi=primary_little\n\t" %} >>>>> ?ins_encode %{ >>>>> ? ?int offset = $src$$disp + STACK_BIAS; >>>>> ? ?__ add($src$$base$$Register, __ ensure_simm13_or_reg(offset, O7), O7); >>>>> ? ?__ lduha(O7, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); >>>>> ?%} >>>>> ?ins_pipe( iload_mem ); >>>>> %} >>>>> >>>>> >>>>>> >>>>>> -- Christian >>>>>> >>>>> >>>>> >>> >>> > > From tom.rodriguez at oracle.com Wed Apr 21 12:48:02 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 21 Apr 2010 12:48:02 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> Message-ID: On Apr 21, 2010, at 12:32 PM, John Rose wrote: > On Apr 21, 2010, at 11:13 AM, Tom Rodriguez wrote: > >> Resending to list because it bounced. >> >> This change: >> >> + void get_cache_entry_pointer_at_bcp(Register cache, Register tmp, int bcp_offset, bool giant_index = false); >> >> seems spurious. >> >> I think the return_entry_for changes aren't really in the spirit of the design of the template interpreter. If invokedynamic has it's own strategy for lookup in the constant pool then it probably needs it's own return entry point. > > Good point. And... note that the differences have to do with how the stack is popped. Actually the existing differences are in how many bytes to advance the bci, since some calls are 3 long and others are 5. I just noticed that we generate return entry points for all steps from 0 to 7 but we only use 3 and 5. That seems like a waste. > Nearly all of the complexity of return_entry goes away if the caller pre-pops the arguments. Before splitting return_entry, let's either do the pre-popping (making splitting moot) or decide that it's impractical. I guess I'm leery of it since it's changing code that's working fine and isn't really that performance critical while we have lots of other things to do. I know the invokedynamic changes have had to dig around in the invoke paths a lot more so if it simplifies something there then fine. tom > >> regcon_sll_ptr_by_con sure is convenient but its implementation is totally surprising and the name is long and unclear particularly since it has the same signature as regcon_sll_ptr but does something different. It desperately needs a comment in the hpp explaining what it does. I don't think dst should ever be optional, otherwise why it at all. This use: >> >> + __ add(Gargs, __ regcon_sll_ptr_by_con(G5_stack_move, LogBytesPerWord, G5_stack_move), Gargs); >> >> should just be sll_ptr. Actually given all the magic that the existing regcon_sll_ptr does, couldn't you shoehorn the new behaviour into it? > > I would prefer that, but will defer to others on what is "too much magic". > >> The by_con behaviour of returning the new regcon instead of the value return parameter seems better anyway. > > >> The switch in load_sized_value is too clever for my taste. How about just a switch on size_in_bytes with a test on is_signed where it's needed? > > My high school writing teacher used to direct us, if we thought we had written something especially clever, to be ready to strike it out. Christian, if you break up the Overly Clever Switch in the sensible way Tom suggests, please break up the parallel one in the x86 code too. > > -- John From Ulf.Zibis at gmx.de Wed Apr 21 15:20:29 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 22 Apr 2010 00:20:29 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> Message-ID: <4BCF7A2D.4030805@gmx.de> Am 21.04.2010 21:40, schrieb Hiroshi Yamauchi: > OK. Based on that, I think the last revision: > > http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.02/ > > is in good shape (aside from the movbe support and the sparc part.) > Let me know if there are some comments. What about having intrinsics for byte swapping on float/double values? This could give a significant performance boost on direct nio buffers. -Ulf From john.r.rose at oracle.com Wed Apr 21 15:26:13 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 21 Apr 2010 15:26:13 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <4BCF7A2D.4030805@gmx.de> References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <4BCF7A2D.4030805@gmx.de> Message-ID: On Apr 21, 2010, at 3:20 PM, Ulf Zibis wrote: > What about having intrinsics for byte swapping on float/double values? > This could give a significant performance boost on direct nio buffers. The existing intrinsics for swapping and int/float raw conversion will do this, when combined in the obvious way. -- John From Ulf.Zibis at gmx.de Wed Apr 21 16:47:11 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 22 Apr 2010 01:47:11 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <4BCF7A2D.4030805@gmx.de> Message-ID: <4BCF8E7F.9080509@gmx.de> Am 22.04.2010 00:26, schrieb John Rose: > On Apr 21, 2010, at 3:20 PM, Ulf Zibis wrote: > > >> What about having intrinsics for byte swapping on float/double values? >> This could give a significant performance boost on direct nio buffers. >> > The existing intrinsics for swapping and int/float raw conversion will do this, when combined in the obvious way. -- John > > Thanks. Are there intrinsics for int/float raw conversion ? How are the macros called ? -Ulf From john.r.rose at oracle.com Wed Apr 21 17:30:22 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 21 Apr 2010 17:30:22 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <4BCF8E7F.9080509@gmx.de> References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <4BCF7A2D.4030805@gmx.de> <4BCF8E7F.9080509@gmx.de> Message-ID: <88A60EB1-AC45-4B32-8D5C-F9AB55D0FC14@oracle.com> On Apr 21, 2010, at 4:47 PM, Ulf Zibis wrote: > Are there intrinsics for int/float raw conversion ? > How are the macros called ? Google floatToRawIntBits and doubleToRawLongBits. Any optimizing dynamic compiler (like Hotspot's C2) will know these are simple bitwise representation casts. -- John From john.r.rose at oracle.com Wed Apr 21 18:14:02 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 21 Apr 2010 18:14:02 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> Message-ID: <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> On Apr 21, 2010, at 12:32 PM, John Rose wrote: >> regcon_sll_ptr_by_con sure is convenient but its implementation is totally surprising and the name is long and unclear particularly since it has the same signature as regcon_sll_ptr but does something different. It desperately needs a comment in the hpp explaining what it does. I don't think dst should ever be optional, otherwise why it at all. This use: >> >> + __ add(Gargs, __ regcon_sll_ptr_by_con(G5_stack_move, LogBytesPerWord, G5_stack_move), Gargs); >> >> should just be sll_ptr. Actually given all the magic that the existing regcon_sll_ptr does, couldn't you shoehorn the new behaviour into it? > > I would prefer that, but will defer to others on what is "too much magic". Looking in more detail, I think regcon_sll_ptr is already designed to do what regcon_sll_ptr_by_con is trying to do. So I think you should get rid of the longer-named thing. Here's an example of how to replace the longer function by the shorter, with code that is no more complicated and perhaps more readable: diff --git a/src/cpu/sparc/vm/methodHandles_sparc.cpp b/src/cpu/sparc/vm/methodHandles_sparc.cpp --- a/src/cpu/sparc/vm/methodHandles_sparc.cpp +++ b/src/cpu/sparc/vm/methodHandles_sparc.cpp @@ -171,7 +171,8 @@ // for (temp = sp + size; temp < argslot; temp++) // temp[-size] = temp[0] // argslot -= size; - RegisterOrConstant offset = __ regcon_sll_ptr_by_con(arg_slots, LogBytesPerWord, temp3_reg); + RegisterOrConstant offset = arg_slots; + __ regcon_sll_ptr(offset, LogBytesPerWord, temp3_reg); // Keep the stack pointer 2*wordSize aligned. const int TwoWordAlignmentMask = ((1 << LogBytesPerWord) * 2) - 1; if (offset.is_register()) { Although I like the way the code reads, the side-effect to &offset is a little unnerving when you look into the details. I could live with reformulating the regcon_foo_ptr macros to return the new RegisterOrConstant value as an explicit result, rather than patching it in-place as the dest argument. But I think regcon_sll_ptr_by_con should go. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100421/f89046e1/attachment.html From john.r.rose at oracle.com Wed Apr 21 23:03:09 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 21 Apr 2010 23:03:09 -0700 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: <1270646925.2639.213.camel@macbook> References: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> <1269942561.982.126.camel@macbook> <5166E91B-B858-404F-BAB5-D34E42B8C91C@oracle.com> <1270568501.2639.122.camel@macbook> <1270646925.2639.213.camel@macbook> Message-ID: As suggested, I moved the adapter_conversion_ops_supported_mask into methodHandles_.cpp. Christian, I have you down as a reviewer. Let me know if you want me to adjust it in any way to prepare for your changes. For example, I could split the methodHandles_.hpp files so you don't have to put sparc-specific stuff into methodHandles.hpp. And, if there are no more comments on this change, I'll push it. -- John On Apr 7, 2010, at 6:28 AM, Christian Thalinger wrote: > On Tue, 2010-04-06 at 11:16 -0700, John Rose wrote: >> On Apr 6, 2010, at 8:41 AM, Christian Thalinger wrote: >> >>> On Wed, 2010-03-31 at 12:46 -0700, John Rose wrote: >>>> Christian's comments, plus the move mentioned below, are incorporated in the updated webrev: >>>> http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.01 >>> >>> I guess we also need a SPARC version of >>> MethodHandles::adapter_conversion_ops_supported_mask. Should we add >>> that one here or with one of my SPARC changes? >> >> Whichever way makes sense to you is fine with me. I suggest you merge >> the SPARC support with my changes, and if there is something (like the >> mask) which belongs in my changes, send me a diff and I'll add it in. > > It seems only the following one is required. I pushed the SPARC C1 and > C2 patches to the MLVM repository today so you can also give it a try. > > diff --git a/src/cpu/sparc/vm/methodHandles_sparc.cpp b/src/cpu/sparc/vm/methodHandles_sparc.cpp > --- a/src/cpu/sparc/vm/methodHandles_sparc.cpp > +++ b/src/cpu/sparc/vm/methodHandles_sparc.cpp > @@ -289,6 +289,23 @@ > #endif // PRODUCT > > > +// which conversion op types are implemented here? > +int MethodHandles::adapter_conversion_ops_supported_mask() { > + return ((1< + |(1< + |(1< + |(1< + |(1< + |(1< + |(1< + |(1< + |(1< + //|(1< + ); > + // FIXME: MethodHandlesTest gets a crash if we enable OP_SPREAD_ARGS. > +} > + > + > //------------------------------------------------------------------------------ > // MethodHandles::generate_method_handle_stub > // > > From john.r.rose at oracle.com Thu Apr 22 00:08:35 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 22 Apr 2010 00:08:35 -0700 Subject: Request for reviews (L): 6939203: JSR 292 needs method handle constants In-Reply-To: References: <1270566425.2639.118.camel@macbook> Message-ID: <59C4FCAF-3A4F-43B3-BAE1-0BB2898293F9@oracle.com> On Apr 6, 2010, at 2:44 PM, John Rose wrote: > On Apr 6, 2010, at 8:07 AM, Christian Thalinger wrote: > >> On Tue, 2010-03-30 at 04:24 -0700, John Rose wrote: >>> 6939203: JSR 292 needs method handle constants >>> Summary: Add new CP types CONSTANT_MethodHandle, CONSTANT_MethodType; extend 'ldc' bytecode. >>> http://cr.openjdk.java.net/~jrose/6939203/hs-webrev.00 >> >> src/share/vm/interpreter/bytecode.hpp: >> >> 404 inline friend Bytecode_loadconstant* Bytecode_loadconstant_at(address bcp, methodHandle method); >> 405 inline friend Bytecode_loadconstant* Bytecode_loadconstant_at(methodHandle method, int bci); >> >> Why are the arguments swapped? int and address should be different >> types. > > The (bcp, optional method) pattern mimics Bytecodes::code_at. > The (method, bci) pattern mimics a methodOop accessor. > The patterns don't mix well. I'll try to boil this down to fewer overloadings. It boiled down nicely; I took out all but one overloading. The ones based on the "address bcp" parameter were not actually useful. I also added to interpreterRuntime.[ch]pp a bci(thread) accessor to use instead of the bcp(thread) accessor, and changed two unrelated places where bci(thread) was more obviously correct than bcp(thread). Please look over those diffs. >> src/share/vm/interpreter/rewriter.cpp: >> >> 142 Bytecodes::Code fastc = Bytecodes::_nop; >> 143 if (tag.is_method_handle() || tag.is_method_type()) { >> 144 fastc = (is_wide >> 145 ? Bytecodes::_fast_aldc_w >> 146 : Bytecodes::_fast_aldc); >> 147 } >> 148 if (fastc != Bytecodes::_nop) { >> >> Why do you have a second if here? > > No particular reason, other than leaving open an option to extend the aldc treatment to classes or other (future) constant types. I'll merge the two blocks. Fixed. The code is much simpler. Here's the final webrev (if you agree that I fixed the issues you raised): http://cr.openjdk.java.net/~jrose/6939203/hs-webrev.01 -- John From Christian.Thalinger at Sun.COM Thu Apr 22 00:22:34 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 22 Apr 2010 09:22:34 +0200 Subject: Request for reviews (L): 6939203: JSR 292 needs method handle constants In-Reply-To: <59C4FCAF-3A4F-43B3-BAE1-0BB2898293F9@oracle.com> References: <1270566425.2639.118.camel@macbook> <59C4FCAF-3A4F-43B3-BAE1-0BB2898293F9@oracle.com> Message-ID: <1271920954.15338.773.camel@macbook> On Thu, 2010-04-22 at 00:08 -0700, John Rose wrote: > Here's the final webrev (if you agree that I fixed the issues you raised): > http://cr.openjdk.java.net/~jrose/6939203/hs-webrev.01 Yes, that looks good. -- Christian From gbenson at redhat.com Thu Apr 22 04:14:47 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 22 Apr 2010 12:14:47 +0100 Subject: Review Request: Zero JNI handles fix In-Reply-To: <20100420084023.GB3510@redhat.com> References: <20100329152453.GB3421@redhat.com> <1269942726.982.129.camel@macbook> <4BB202CA.9040202@oracle.com> <20100330145920.GD3617@redhat.com> <20100420084023.GB3510@redhat.com> Message-ID: <20100422111447.GD4039@redhat.com> Gary Benson wrote: > Gary Benson wrote: > > Keith McGuigan wrote: > > > On 03/30/10 05:52, Christian Thalinger wrote: > > > > On Mon, 2010-03-29 at 16:24 +0100, Gary Benson wrote: > > > > > Zero will exit with an error when invoked with -Xcheck:jni. > > > > > This webrev fixes: > > > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix/ > > > > > > > > > > Note that this is actually a pretty old issue, but the fix > > > > > for it got lost from the IcedTea repositories. There's more > > > > > information here: > > > > > > > > > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=323 > > > > > > > > > > I don't have a bug id for this. > > > > > > > > 6939182: Zero JNI handles fix > > > > > > > > I guess the changes are good since it uses an #ifdef. Maybe one > > > > of the runtime guys could also comment on this one. > > > > > > It would be better to put this in zero-specific code somewhere > > > instead of polluting common code with #ifdef, but if that's not > > > possible... > > > > > > Also, instead of this point-fix in jniHandles, why not fix > > > last_Java_sp() to return zero_stack()->sp() in the zero case? > > > This is not the only place last_Java_sp() is called. Might > > > want to fix it for last_Java_pc() (and related) too. > > > > The difficulty is that what last_Java_sp is returning in Zero is the > > Zero frame pointer, which is not the highest thing on the stack. It > > probably isn't the best thing to #ifdef this here though, I agree. > > I'll have a think about it... > > I've reworked the fix: > > http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix-2/ > > last_Java_sp() now returns the actual Zero stack pointer. The frame > anchor has a new last_Java_fp field that stores the value previously > stored in last_Java_sp, in much the same way as the x86 port does. > > Note that the code in frame_zero.* already stored both these values, > but with the names confusingly reversed. I have unreversed them in > this webrev. I have also changed the type of the frame pointer be a > ZeroFrame* -- leaving the stack pointer as an intptr_t* -- to help > ensure that everything gets the arguments in the right order. A minor update: http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix-3/ Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Thu Apr 22 06:33:54 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 22 Apr 2010 15:33:54 +0200 Subject: review (S) for 6943485: JVMTI always on capabilities change code generation too much In-Reply-To: References: Message-ID: <1271943234.15338.799.camel@macbook> On Tue, 2010-04-20 at 15:39 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6943485 > > 6943485: JVMTI always on capabilities change code generation too much > Reviewed-by: > > The set of always on JVMTI capabilities include thing which will cause > changes in the code the compiler generates which interferes with using > JVMTI to support profiling since you aren't profiling the same > generated code that you would be executing. In particular the > redefine and transform classes capabilities set the > JvmtiExport::can_access_local_variables() flag which causes the > compilers to keep all Java locals live even if they aren't needed for > computation. Additionally we will currently turn of EA is this is > set, which was done as the fix for 6895383. I've changed the setting > of JvmtiExport::can_access_local_variables to only be driven by the > two capabilities can_access_locals_variables and > can_generate_breakpoints which should restrict these to be set when > running under a debugger, since the original intent of keeping Java > locals alive was to help simulate debugging while running under the > interpreter where Java locals keep their values until they are > overwritten. JvmtiExport::can_access_local_variables is only used by > the compilers so this doesn't affect any other part of the system. I > also moved some code which kept locals live in exception paths under > the can_access_live_locals flag which made the flag > can_examine_or_deopt_anywhere go dead. There were also some variables > Compilation::_needs_debug_information and Compile::_deopt_happens > which are always true and always must be true that I just deleted. > > Tested with runthese and all the NSK serviceability tests. Also > compared the code we generate when running with and without an agent > to make sure they were the same. The changes look good and I think the changes are OK. -- Christian From tom.rodriguez at oracle.com Thu Apr 22 14:03:16 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 22 Apr 2010 14:03:16 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> Message-ID: <9D317290-7994-43D6-8013-C41185EC9BA7@oracle.com> I took your changes and then made the sparc changes the way I think they should be. All the other changes are exactly as they were in your webrev though I added some minor makefile changes for adlc. http://cr.openjdk.java.net/~never/6946040 6946040: add intrinsic for short and char reverseBytes Reviewed-by: never, twisti Contributed-by: Hiroshi Yamauchi This is Hiroshi's patch for reverseShort and reverseChar intrinsics. I've redone the sparc implementation and fixed bugs in the original implementation as well. The existing versions were broken with implicit null checking since implicit null checks assume that the faulting load is the first instruction in the node but because of the way the memory was being handled it wasn't. The first instruction was actually an add so if an implicit null happened the JVM would die. The new code restricts these forms to use reg+reg addressing only so any address math is handled automatically. Tested with new test case and the original test case for the other intrinsics which I've moved from the closed repo to the open one. I also turned on the debug options in the adlc by default to make debugging adlc problems easier. tom On Apr 21, 2010, at 12:40 PM, Hiroshi Yamauchi wrote: > OK. Based on that, I think the last revision: > > http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.02/ > > is in good shape (aside from the movbe support and the sparc part.) > Let me know if there are some comments. > > Thanks, > Hiroshi > > On Tue, Apr 20, 2010 at 6:36 PM, Tom Rodriguez wrote: >> >> On Apr 20, 2010, at 5:45 PM, Hiroshi Yamauchi wrote: >> >>> On Tue, Apr 20, 2010 at 3:23 PM, Tom Rodriguez wrote: >>>> We're not really targetting Atom so I wouldn't worry about it with your changes. I think there's a bug filed about it and we may get to it someday. >>> >>> OK. >>> >>>> >>>> You don't need ReverseBytesUS since there's no semantic difference with ReverseBytesS, so just drop it. >>> >>> I don't exactly get this. At least x86 they are different in that the >>> former is compiled into "BSWAP; SHR 16" and the latter is compiled >>> into "BSWAP; SAR 16". >> >> I wasn't looking closely enough and assumed that the result would always be unsigned, but that's not true. So ignore me. >> >>> >>>> >>>> As far as the sparc changes, don't worry about them, Christian or I will do something appropriate and send it our for review on top of your changes. >>> >>> OK. >>> >>>> >>>> tom >>>> >>>> On Apr 20, 2010, at 3:09 PM, Hiroshi Yamauchi wrote: >>>> >>>>> Here's version 2: >>>>> >>>>> http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.02/ >>>>> >>>>> It's not up-to-date with the latest comments. But I send it here anyway. >>>>> >>>>> Re: movbe, I don't see string "movbe" in my /proc/cpuinfo output on my >>>>> Linux machine. So, it probably does not have it. Is anyone working on >>>>> a general movbe support in Hotspot? >>>>> >>>>> Hiroshi >>>>> >>>>> >>>>> On Tue, Apr 20, 2010 at 10:47 AM, Tom Rodriguez >>>>> wrote: >>>>>> >>>>>> On Apr 20, 2010, at 2:22 AM, Christian Thalinger wrote: >>>>>> >>>>>>> On Thu, 2010-04-15 at 10:30 -0700, Tom Rodriguez wrote: >>>>>>>> Can we use the macroassembler loads instead of emit_form on sparc? >>>>>>> >>>>>>> I was thinking the same but then I looked at emit_form3_mem_reg_asi and >>>>>>> there is some other stuff happening there (SP/FP special case, disp != >>>>>>> 0). >>>>>> >>>>>> The special cases for FP/SP are needed for the stackSlotI variants but the memory variants can use the macroassembler versions if they are changed to be use iRegP instead of memory. This will force the matcher to compute the address into a register instead of attempting to use addressing modes which aren't supported by the ASI loads. The stackSlotI variants have to be handled by hand because the offsets aren't known until after register allocation. I just noticed that the original ReverseBytes routines also use the old ins_encode style, so maybe we should just keep the new ones like the old ones. The new ones should really be: >>>>>> >>>>>> opcode(Assembler::...); >>>>>> ins_encode( form3_mem_reg_little(src, dst) ); >>>>>> >>>>>> instead of the ins_encode %{ %} style since that is intended for the MacroAssembler style encodings. The opcodes in the webrev are wrong as well since they are the opcodes for the normal load not the ASI variant. The effect statements are also redundant and can be dropped. >>>>>> >>>>>> I think this all leads me to wish that all the reverse routines were written directly in terms of MacroAssembler with memory changed to iRegP and the stackSlotI variants handled by hand but in MacroAssembler as well. So the loads would look like this: >>>>>> >>>>>> // Load char reversed byte order >>>>>> instruct loadC_reversed(iRegI dst, iRegP src) %{ >>>>>> match(Set dst (ReverseBytesC (LoadUS src))); >>>>>> >>>>>> ins_cost(MEMORY_REF_COST); >>>>>> size(4); >>>>>> format %{ "LDUHA $src, $dst\t!asi=primary_little" %} >>>>>> >>>>>> ins_encode %{ >>>>>> __ lduha($src$$Register, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); >>>>>> %} >>>>>> ins_pipe(iload_mem); >>>>>> } >>>>>> >>>>>> and the stackSlotI variants would look like this: >>>>>> >>>>>> instruct bytes_reverse_char(iRegI dst, stackSlotI src) %{ >>>>>> match(Set dst (ReverseBytesC src)); >>>>>> effect(DEF dst, USE src); >>>>>> >>>>>> // Op cost is artificially doubled to make sure that load or store >>>>>> // instructions are preferred over this one which requires a spill >>>>>> // onto a stack slot. >>>>>> ins_cost(2*DEFAULT_COST + MEMORY_REF_COST); >>>>>> format %{ "LDUHA $src, $dst\t!asi=primary_little\n\t" %} >>>>>> ins_encode %{ >>>>>> int offset = $src$$disp + STACK_BIAS; >>>>>> __ add($src$$base$$Register, __ ensure_simm13_or_reg(offset, O7), O7); >>>>>> __ lduha(O7, Assembler::ASI_PRIMARY_LITTLE, $dst$$Register); >>>>>> %} >>>>>> ins_pipe( iload_mem ); >>>>>> %} >>>>>> >>>>>> >>>>>>> >>>>>>> -- Christian >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> From daniel.daugherty at oracle.com Thu Apr 22 11:58:21 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 22 Apr 2010 12:58:21 -0600 Subject: review (S) for 6943485: JVMTI always on capabilities change code generation too much In-Reply-To: References: Message-ID: <4BD09C4D.5000407@oracle.com> On 4/20/2010 4:39 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6943485 > Summary: thumbs up I updated the bug comments with some code history stuff. src/share/vm/c1/c1_Compilation.cpp No comments. src/share/vm/c1/c1_Compilation.hpp No comments. src/share/vm/c1/c1_GraphBuilder.cpp No comments. src/share/vm/c1/c1_LinearScan.cpp No comments. src/share/vm/c1/c1_globals.hpp No comments. src/share/vm/ci/ciEnv.cpp No comments. src/share/vm/ci/ciEnv.hpp No comments. src/share/vm/opto/c2compiler.cpp So it's okay to EscapeAnalysis when redefining classes? src/share/vm/opto/compile.cpp No comments. src/share/vm/opto/compile.hpp No comments. src/share/vm/opto/graphKit.cpp No comments. src/share/vm/prims/jvmtiExport.cpp No comments. src/share/vm/prims/jvmtiExport.hpp No comments. src/share/vm/prims/jvmtiManageCapabilities.cpp In addition to can_generate_breakpoint_events, the can_generate_frame_pop_events should be queried also when setting can_access_local_variables. From Ulf.Zibis at gmx.de Thu Apr 22 14:54:02 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 22 Apr 2010 23:54:02 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <88A60EB1-AC45-4B32-8D5C-F9AB55D0FC14@oracle.com> References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <4BCF7A2D.4030805@gmx.de> <4BCF8E7F.9080509@gmx.de> <88A60EB1-AC45-4B32-8D5C-F9AB55D0FC14@oracle.com> Message-ID: <4BD0C57A.4040703@gmx.de> Am 22.04.2010 02:30, schrieb John Rose: > On Apr 21, 2010, at 4:47 PM, Ulf Zibis wrote: > > >> Are there intrinsics for int/float raw conversion ? >> How are the macros called ? >> > Google floatToRawIntBits and doubleToRawLongBits. Any optimizing dynamic compiler (like Hotspot's C2) will know these are simple bitwise representation casts. > After some search I found the macros and their implementation in the webrev. At this point I'm asking, why those and the reverseBytes methods are coded in java and later were intrinsified by the JIT. Couldn't they directly be implemented as native methods? This would give the developer a clear hint, that they are processed fast, and would reduce the optimization work by HotSpot. -Ulf From yamauchi at google.com Thu Apr 22 15:22:26 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Thu, 22 Apr 2010 15:22:26 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <9D317290-7994-43D6-8013-C41185EC9BA7@oracle.com> References: <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <9D317290-7994-43D6-8013-C41185EC9BA7@oracle.com> Message-ID: Thanks, Tom. It looks good to me. > This is Hiroshi's patch for reverseShort and reverseChar intrinsics. > I've redone the sparc implementation and fixed bugs in the original > implementation as well. ?The existing versions were broken with > implicit null checking since implicit null checks assume that the > faulting load is the first instruction in the node but because of the > way the memory was being handled it wasn't. ?The first instruction was > actually an add so if an implicit null happened the JVM would die. > The new code restricts these forms to use reg+reg addressing only so > any address math is handled automatically. ?Tested with new test case I must have overlooked the '+2' offset in the stackSlotI (in bytes_reverse_unsigned_short/bytes_reverse_short.) I'm just curious but I'm not sure who emits the add instruction. One instruction that can be emitted before the load instruction (and that I can see) is: 949 emit3_simm13( cbuf, Assembler::arith_op, index, Assembler::or_op3, 0, disp); emitted by the now-removed emit_form3_mem_reg_asi(). But it's an or, not an add. There may be some code emission that I don't see. Hiroshi From tom.rodriguez at oracle.com Thu Apr 22 15:43:35 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 22 Apr 2010 15:43:35 -0700 Subject: review (S) for 6943485: JVMTI always on capabilities change code generation too much In-Reply-To: <4BD09C4D.5000407@oracle.com> References: <4BD09C4D.5000407@oracle.com> Message-ID: <42ECCE6F-7E8E-4E8C-8182-7B6E000D3CEF@oracle.com> On Apr 22, 2010, at 11:58 AM, daniel.daugherty at oracle.com wrote: > On 4/20/2010 4:39 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6943485 >> > > Summary: thumbs up > > I updated the bug comments with some code history stuff. Thanks. > src/share/vm/opto/c2compiler.cpp > So it's okay to EscapeAnalysis when redefining classes? I believe so. If the methods are redefined then the code should be invalidated and recompiled. There might be one place where we need an evol dependency but I need to check into that. We had previously been running all the JVMTI tests with EA enabled at various points and hadn't seen any issues. > > src/share/vm/opto/compile.cpp > No comments. > > src/share/vm/opto/compile.hpp > No comments. > > src/share/vm/opto/graphKit.cpp > No comments. > > src/share/vm/prims/jvmtiExport.cpp > No comments. > > src/share/vm/prims/jvmtiExport.hpp > No comments. > > src/share/vm/prims/jvmtiManageCapabilities.cpp > In addition to can_generate_breakpoint_events, the > can_generate_frame_pop_events should be queried also when > setting can_access_local_variables. Why? tom From tom.rodriguez at oracle.com Thu Apr 22 16:15:43 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 22 Apr 2010 16:15:43 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <9D317290-7994-43D6-8013-C41185EC9BA7@oracle.com> Message-ID: <7F29BAF0-D6B3-460E-9DFB-A10C02DCE56F@oracle.com> Resending because of bounce. On Apr 22, 2010, at 3:22 PM, Hiroshi Yamauchi wrote: > Thanks, Tom. It looks good to me. Thanks. > >> This is Hiroshi's patch for reverseShort and reverseChar intrinsics. >> I've redone the sparc implementation and fixed bugs in the original >> implementation as well. The existing versions were broken with >> implicit null checking since implicit null checks assume that the >> faulting load is the first instruction in the node but because of the >> way the memory was being handled it wasn't. The first instruction was >> actually an add so if an implicit null happened the JVM would die. >> The new code restricts these forms to use reg+reg addressing only so >> any address math is handled automatically. Tested with new test case > > I must have overlooked the '+2' offset in the stackSlotI (in > bytes_reverse_unsigned_short/bytes_reverse_short.) It showed up in testing of course. I didn't notice it before that. > I'm just curious but I'm not sure who emits the add instruction. One > instruction that can be emitted before the load instruction (and that > I can see) is: > > 949 emit3_simm13( cbuf, Assembler::arith_op, index, > Assembler::or_op3, 0, disp); > > emitted by the now-removed emit_form3_mem_reg_asi(). But it's an or, > not an add. There may be some code emission that I don't see. That code was doing or g0, simm13, o7. On sparc both add and or can be used for the constant formation idiom though you decompose the constant differently when sethi is involved since it does 22 bits and the others do 13 so they overlap. sethi hi22, r or r, simm13, r always works but an add has to operate on the low 10 bits. tom > > Hiroshi From yamauchi at google.com Thu Apr 22 17:03:04 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Thu, 22 Apr 2010 17:03:04 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <9D317290-7994-43D6-8013-C41185EC9BA7@oracle.com> Message-ID: On Thu, Apr 22, 2010 at 3:56 PM, Tom Rodriguez wrote: > > On Apr 22, 2010, at 3:22 PM, Hiroshi Yamauchi wrote: > >> Thanks, Tom. It looks good to me. > > Thanks. > >> >>> This is Hiroshi's patch for reverseShort and reverseChar intrinsics. >>> I've redone the sparc implementation and fixed bugs in the original >>> implementation as well. ?The existing versions were broken with >>> implicit null checking since implicit null checks assume that the >>> faulting load is the first instruction in the node but because of the >>> way the memory was being handled it wasn't. ?The first instruction was >>> actually an add so if an implicit null happened the JVM would die. >>> The new code restricts these forms to use reg+reg addressing only so >>> any address math is handled automatically. ?Tested with new test case >> >> I must have overlooked the '+2' offset in the stackSlotI (in >> bytes_reverse_unsigned_short/bytes_reverse_short.) > > It showed up in testing of course. ?I didn't notice it before that. > >> I'm just curious but I'm not sure who emits the add instruction. One >> instruction that can be emitted before the load instruction (and that >> I can see) is: >> >> 949 ? ? emit3_simm13( cbuf, Assembler::arith_op, index, >> Assembler::or_op3, 0, disp); >> >> emitted by the now-removed emit_form3_mem_reg_asi(). But it's an or, >> not an add. There may be some code emission that I don't see. > > That code was doing or g0, simm13, o7. ?On sparc both add and or can be used for the constant formation idiom though you decompose the constant differently when sethi is involved since it does 22 bits and the others do 13 so they overlap. ?sethi hi22, r or r, simm13, r always works but an add has to operate on the low 10 bits. That makes sense. Thanks. > > tom > >> >> Hiroshi > > From daniel.daugherty at oracle.com Thu Apr 22 16:20:56 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 22 Apr 2010 17:20:56 -0600 Subject: review (S) for 6943485: JVMTI always on capabilities change code generation too much In-Reply-To: <42ECCE6F-7E8E-4E8C-8182-7B6E000D3CEF@oracle.com> References: <4BD09C4D.5000407@oracle.com> <42ECCE6F-7E8E-4E8C-8182-7B6E000D3CEF@oracle.com> Message-ID: <4BD0D9D8.5030200@oracle.com> On 4/22/2010 4:43 PM, Tom Rodriguez wrote: > On Apr 22, 2010, at 11:58 AM, daniel.daugherty at oracle.com wrote: > > >> On 4/20/2010 4:39 PM, Tom Rodriguez wrote: >> >>> http://cr.openjdk.java.net/~never/6943485 >>> >>> >> Summary: thumbs up >> >> I updated the bug comments with some code history stuff. >> > > Thanks. > > >> src/share/vm/opto/c2compiler.cpp >> So it's okay to EscapeAnalysis when redefining classes? >> > > I believe so. If the methods are redefined then the code should be invalidated and recompiled. There might be one place where we need an evol dependency but I need to check into that. We had previously been running all the JVMTI tests with EA enabled at various points and hadn't seen any issues. > That's good to know! >> src/share/vm/prims/jvmtiManageCapabilities.cpp >> In addition to can_generate_breakpoint_events, the >> can_generate_frame_pop_events should be queried also when >> setting can_access_local_variables. >> > > Why? > When the can_generate_frame_pop_events capability is enabled, you can call NotifyFramePop() on a thread that is suspended or on your own thread. You also specify a depth value that ids the frame in which you are interested. You either resume the target thread or continue execution in your own thread. When the target frame is popped from the stack, a FramePop event is generated. From the FramePop event handler, you can access local variables and get the bci and... However, you have to use the GetLocal APIs which already require can_access_local_variables... It looks like a similar argument can be made for not needing can_generate_breakpoint_events... The Breakpoint event handler gets similar parameters to the FramePop event handler so why did you add can_generate_breakpoint_events? What about GetFrameLocation()? Do you need access to locals in order to get the current execution location (bci)? That API doesn't require a capability so I'm guessing that it doesn't need locals access to do its work... Dan From john.r.rose at oracle.com Thu Apr 22 18:15:12 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 22 Apr 2010 18:15:12 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <4BD0C57A.4040703@gmx.de> References: <1271341529.2134.352.camel@macbook> <1271755332.6002.10.camel@macbook> <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <4BCF7A2D.4030805@gmx.de> <4BCF8E7F.9080509@gmx.de> <88A60EB1-AC45-4B32-8D5C-F9AB55D0FC14@oracle.com> <4BD0C57A.4040703@gmx.de> Message-ID: On Apr 22, 2010, at 2:54 PM, Ulf Zibis wrote: > Couldn't they directly be implemented as native methods? This would give the developer a clear hint, that they are processed fast, and would reduce the optimization work by HotSpot. That's odd. To me, seeing a native method is a clear hint that it is processed exceedingly slowly. -- John From David.Holmes at oracle.com Thu Apr 22 18:27:22 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 23 Apr 2010 11:27:22 +1000 Subject: How to compare thecaller thread object and callee's holder? In-Reply-To: References: <4BCFA257.4020609@oracle.com> Message-ID: <4BD0F77A.4030804@oracle.com> Tony Guan said the following on 04/23/10 08:50: > Thanks you for the reply. By "holder" of a method, I mean the object > whose class owns the method interested. Ok. I didn't understand how the "thread" was related to the holder. > Given that from the dtrace functionality, I already know the current > thread, and the methodOoopDesc* of the called method, I need to > identify the caller object and the callee object from the two > parameters passed to the dtrace_method_entry: > > JRT_LEAF(int, SharedRuntime::dtrace_method_entry( JavaThread* thread, > methodOopDesc* method)) in shareRuntime.cpp > Ah that's a much more specific question :) But I'm afraid I can't answer it with certainty (I don't think you can get either easily) but the compiler folk (cc'ed) will have a much better idea. David ----- > for a callee method, we may refer it as receiver. > and for a caller, let's just name it as a caller object, sorry for the > vague term I borrowed from the source code of hotspot. The following > code shows more accurately what I want: > > class B{ > methodB(){ > ... > } > } > > class A{ > > void methodA() > { > B objectB=new B(); > objectB.methodB(); //*****here is what I am at > > } > static public main(args) > { > A objectA=new A(); > A.methodA(); > } > > } > > Now, as we are calling objectB.methodB() from A.methodA(), all I need > is to find out objectA and objectB from within the JVM. > > Given that from the dtrace functionality, I already know the current > thread, and the methodOoopDesc* of the called method, I need to > identify the caller object and the callee object from the two > parameters passed to the dtrace_method_entry: > > JRT_LEAF(int, SharedRuntime::dtrace_method_entry( JavaThread* thread, > methodOopDesc* method)) in shareRuntime.cpp > > Thanks! > > Tony (Xiaohua Guan) > > > > On Wed, Apr 21, 2010 at 8:11 PM, David Holmes wrote: >> Tony, >> >> Tony Guan said the following on 04/22/10 00:06: >>> a quick question: given a caller thread object( JavaThread* thread) >>> and the method to be called by the thread (methodOopDesc* method), how >>> do I know that the holder of the "method" is from the same caller >>> object or not? >> I don't understand what you mean here by "holder"? >> >>> The reason why I am asking is: >>> in >>> JRT_LEAF(int, SharedRuntime::dtrace_method_entry( JavaThread* >>> thread, methodOopDesc* method)) in shareRuntime.cpp >>> >>> I want to check if the method called will start another thread or not, >>> so I need to compare the holders of the caller and callee. >> Again I don't know what the "holder" is here. If a method starts a thread >> then that new thread doesn't necessarily have any connection back to the >> method from which it was started. >> >>> So one more question: is there any other way to achieve this? >> I think you would have to add code in the thread start routine (of the JVM) >> and have the before/after method hooks to do this eg: >> >> before-method: set flag showing current thread is interested in thread >> start >> start-thread: check if current thread interested in thread start and if so >> bump a counter >> after-method: check counter and clear flag >> >> David Holmes >> From tom.rodriguez at oracle.com Thu Apr 22 19:13:01 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 22 Apr 2010 19:13:01 -0700 Subject: How to compare thecaller thread object and callee's holder? In-Reply-To: <4BD0F77A.4030804@oracle.com> References: <4BCFA257.4020609@oracle.com> <4BD0F77A.4030804@oracle.com> Message-ID: On Apr 22, 2010, at 6:27 PM, David Holmes wrote: > Tony Guan said the following on 04/23/10 08:50: >> Thanks you for the reply. By "holder" of a method, I mean the object >> whose class owns the method interested. Normally hotspot uses the term holder for the class that owns a method and receiver as the object being invoked. > > Ok. I didn't understand how the "thread" was related to the holder. > >> Given that from the dtrace functionality, I already know the current >> thread, and the methodOoopDesc* of the called method, I need to >> identify the caller object and the callee object from the two >> parameters passed to the dtrace_method_entry: >> JRT_LEAF(int, SharedRuntime::dtrace_method_entry( JavaThread* thread, >> methodOopDesc* method)) in shareRuntime.cpp > > Ah that's a much more specific question :) But I'm afraid I can't answer it with certainty (I don't think you can get either easily) but the compiler folk (cc'ed) will have a much better idea. You can't recover the caller from just those two values. If you tracked method enter/exit on a per thread stack you could track it yourself. You might also be able to use the jstack action to grab the current stack trace. tom > > David > ----- > > >> for a callee method, we may refer it as receiver. >> and for a caller, let's just name it as a caller object, sorry for the >> vague term I borrowed from the source code of hotspot. The following >> code shows more accurately what I want: >> class B{ >> methodB(){ >> ... >> } >> } >> class A{ >> void methodA() >> { >> B objectB=new B(); >> objectB.methodB(); //*****here is what I am at >> } >> static public main(args) >> { >> A objectA=new A(); >> A.methodA(); >> } >> } >> Now, as we are calling objectB.methodB() from A.methodA(), all I need >> is to find out objectA and objectB from within the JVM. >> Given that from the dtrace functionality, I already know the current >> thread, and the methodOoopDesc* of the called method, I need to >> identify the caller object and the callee object from the two >> parameters passed to the dtrace_method_entry: >> JRT_LEAF(int, SharedRuntime::dtrace_method_entry( JavaThread* thread, >> methodOopDesc* method)) in shareRuntime.cpp >> Thanks! >> Tony (Xiaohua Guan) >> On Wed, Apr 21, 2010 at 8:11 PM, David Holmes wrote: >>> Tony, >>> >>> Tony Guan said the following on 04/22/10 00:06: >>>> a quick question: given a caller thread object( JavaThread* thread) >>>> and the method to be called by the thread (methodOopDesc* method), how >>>> do I know that the holder of the "method" is from the same caller >>>> object or not? >>> I don't understand what you mean here by "holder"? >>> >>>> The reason why I am asking is: >>>> in >>>> JRT_LEAF(int, SharedRuntime::dtrace_method_entry( JavaThread* >>>> thread, methodOopDesc* method)) in shareRuntime.cpp >>>> >>>> I want to check if the method called will start another thread or not, >>>> so I need to compare the holders of the caller and callee. >>> Again I don't know what the "holder" is here. If a method starts a thread >>> then that new thread doesn't necessarily have any connection back to the >>> method from which it was started. >>> >>>> So one more question: is there any other way to achieve this? >>> I think you would have to add code in the thread start routine (of the JVM) >>> and have the before/after method hooks to do this eg: >>> >>> before-method: set flag showing current thread is interested in thread >>> start >>> start-thread: check if current thread interested in thread start and if so >>> bump a counter >>> after-method: check counter and clear flag >>> >>> David Holmes >>> From tom.rodriguez at oracle.com Thu Apr 22 19:33:49 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 22 Apr 2010 19:33:49 -0700 Subject: review (S) for 6943485: JVMTI always on capabilities change code generation too much In-Reply-To: <4BD0D9D8.5030200@oracle.com> References: <4BD09C4D.5000407@oracle.com> <42ECCE6F-7E8E-4E8C-8182-7B6E000D3CEF@oracle.com> <4BD0D9D8.5030200@oracle.com> Message-ID: <3673AA52-2F1F-411F-8AA0-C6A81ABB44CF@oracle.com> On Apr 22, 2010, at 4:20 PM, daniel.daugherty at oracle.com wrote: > On 4/22/2010 4:43 PM, Tom Rodriguez wrote: >> On Apr 22, 2010, at 11:58 AM, daniel.daugherty at oracle.com wrote: >> >> >>> On 4/20/2010 4:39 PM, Tom Rodriguez wrote: >>> >>>> http://cr.openjdk.java.net/~never/6943485 >>>> >>> Summary: thumbs up >>> >>> I updated the bug comments with some code history stuff. >>> >> >> Thanks. >> >> >>> src/share/vm/opto/c2compiler.cpp >>> So it's okay to EscapeAnalysis when redefining classes? >>> >> >> I believe so. If the methods are redefined then the code should be invalidated and recompiled. There might be one place where we need an evol dependency but I need to check into that. We had previously been running all the JVMTI tests with EA enabled at various points and hadn't seen any issues. >> > > That's good to know! I added some changes in bcEscapeAnalyzer to make sure that evol dependencies are added when it's used. Thanks for asking that question. > > >>> src/share/vm/prims/jvmtiManageCapabilities.cpp >>> In addition to can_generate_breakpoint_events, the >>> can_generate_frame_pop_events should be queried also when >>> setting can_access_local_variables. >>> >> >> Why? > > When the can_generate_frame_pop_events capability is enabled, > you can call NotifyFramePop() on a thread that is suspended or > on your own thread. You also specify a depth value that ids the > frame in which you are interested. > > You either resume the target thread or continue execution in > your own thread. When the target frame is popped from the stack, > a FramePop event is generated. From the FramePop event handler, > you can access local variables and get the bci and... > > However, you have to use the GetLocal APIs which already require > can_access_local_variables... > > It looks like a similar argument can be made for not needing > can_generate_breakpoint_events... The Breakpoint event handler > gets similar parameters to the FramePop event handler so why > did you add can_generate_breakpoint_events? It's mainly because keeping extra locals live is really targetted at a true debugger used by an end user which I figured would be marked by the use of breakpoints. You can always access locals in Java frames even without can_access_local_variables it's just that if they weren't live anymore they will have their default Java value instead of whatever value was actually computed. I've added can_generate_frame_pop_events to the set as you suggested since it seems reasonable. > > What about GetFrameLocation()? Do you need access to locals in > order to get the current execution location (bci)? That API > doesn't require a capability so I'm guessing that it doesn't > need locals access to do its work... No. We always have that information around. tom > > Dan > From Christian.Thalinger at Sun.COM Fri Apr 23 06:45:42 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Apr 2010 15:45:42 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <5F680F20-9951-4F5E-86F6-FDD67A20B397@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> <1271841747.15338.40.camel@macbook> <335E276C-C245-41E8-BD92-FC007B94867F@oracle.com> <1271877399.15338.767.camel@macbook> <1271877881.15338.772.camel@macbook> <5F680F20-9951-4F5E-86F6-FDD67A20B397@oracle.com> Message-ID: <1272030342.15338.940.camel@macbook> On Wed, 2010-04-21 at 12:31 -0700, Tom Rodriguez wrote: > Why are you returning a LIR_Opr&? Because the do_temp call in LIR_OpVisitState::visit requires it. -- Christian From Christian.Thalinger at Sun.COM Fri Apr 23 07:11:03 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Apr 2010 16:11:03 +0200 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: References: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> <1269942561.982.126.camel@macbook> <5166E91B-B858-404F-BAB5-D34E42B8C91C@oracle.com> <1270568501.2639.122.camel@macbook> <1270646925.2639.213.camel@macbook> Message-ID: <1272031863.15338.961.camel@macbook> On Wed, 2010-04-21 at 23:03 -0700, John Rose wrote: > As suggested, I moved the adapter_conversion_ops_supported_mask into > methodHandles_.cpp. > > Christian, I have you down as a reviewer. Let me know if you want me > to adjust it in any way to prepare for your changes. For example, I > could split the methodHandles_.hpp files so you don't have to > put sparc-specific stuff into methodHandles.hpp. We definitely should do that. I will not do that in one of my current changes as it would get too much and confusing. I can also open a new CR for that and push it on its own. > And, if there are no more comments on this change, I'll push it. Please. -- Christian From Christian.Thalinger at Sun.COM Fri Apr 23 07:06:34 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Apr 2010 16:06:34 +0200 Subject: Request for reviews (L): 6939207: refactor constant pool index processing In-Reply-To: <2C343FD4-0DDD-4E23-8D36-BC0822237586@oracle.com> References: <1270631795.2639.207.camel@macbook> <2C343FD4-0DDD-4E23-8D36-BC0822237586@oracle.com> Message-ID: <1272031594.15338.957.camel@macbook> On Thu, 2010-04-22 at 00:49 -0700, John Rose wrote: > > src/share/vm/ci/ciStreams.hpp: > > > > int get_index_giant() const { > > - assert_index_size(4); > > + assert_index_size(4); assert_native_index(); > > return Bytes::get_native_u4(_bc_start+1); > > } > > > > Should we assert on has_giant_index in this one? > > That's what assert_index_size(4) does, right? Indeed. I didn't look what assert_index_size is actually doing, sorry. > > > src/share/vm/interpreter/templateTable.hpp: > > > > + size_t index_size); // one of 1,2,4 > > > > What do you think about using enum values instead of sizeof(u?) in the > > code? > > That would provide slightly stronger type checking for those > parameters. (Size_t is a nondescript type.) But we use tiny ints for > mode flags in so many other places... I thought about putting this in > some place like bytes.hpp or globalDefinitions: > > enum UFieldSize { u1Size = 1, u2Size = 2, u4Size = 4 }; > > Then the "size_t index_size" parameters would change "UFieldSize > index_size". But it occurred to me that this will look inconsistent > with the more generic definitions of wordSize, etc. Is there a > particular benefit that would come from doing it "extra specially > right" just at this point? I'm inclined not to do it. Besides that you cannot pass a wrong size? No. Keep it as it is. > In the meantime, I pushed the refactoring further towards consistent naming. Tell me what you think of this version: > http://cr.openjdk.java.net/~jrose/6939207/webrev.02 I have to say I was a little confused about the get_index1, get_index2, ... naming as it looks like you were running out of method names and just append 1, 2, ... ;-) The change is very big. I take a look at it again later. -- Christian From Christian.Thalinger at Sun.COM Fri Apr 23 05:16:24 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Apr 2010 14:16:24 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> Message-ID: <1272024984.15338.898.camel@macbook> On Wed, 2010-04-21 at 18:14 -0700, John Rose wrote: > Although I like the way the code reads, the side-effect to &offset is > a little unnerving when you look into the details. I could live with > reformulating the regcon_foo_ptr macros to return the new > RegisterOrConstant value as an explicit result, rather than patching > it in-place as the dest argument. I changed that. But it still feels a little odd and sometimes difficult that the macro works as: RegisterOrConstant regcon_sll_ptr(RegisterOrConstant dest, RegisterOrConstant src, Register temp = noreg); I'd actually like it more this way: void regcon_sll_ptr(RegisterOrConstant s1, RegisterOrConstant s2, RegisterOrConstant d); > > > But I think regcon_sll_ptr_by_con should go. It's gone. -- Christian From Christian.Thalinger at Sun.COM Fri Apr 23 05:11:29 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Apr 2010 14:11:29 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> Message-ID: <1272024689.15338.893.camel@macbook> On Wed, 2010-04-21 at 11:13 -0700, Tom Rodriguez wrote: > Resending to list because it bounced. > > This change: > > + void get_cache_entry_pointer_at_bcp(Register cache, Register tmp, int bcp_offset, bool giant_index = false); > > seems spurious. I think John has a patch out that changes that. > > I think the return_entry_for changes aren't really in the spirit of > the design of the template interpreter. If invokedynamic has it's own > strategy for lookup in the constant pool then it probably needs it's > own return entry point. The invokedynamic case would select a new > table in prepare_invoke that was generated by a call to > generate_return_entry_for with a new flag indicating that the bytecode > being handled is invokedynamic so it could use the giant cp cache > logic. What you've got is ok but it's not really the way the template > interpreter works. > > regcon_sll_ptr_by_con sure is convenient but its implementation is > totally surprising and the name is long and unclear particularly since > it has the same signature as regcon_sll_ptr but does something > different. It desperately needs a comment in the hpp explaining what > it does. I don't think dst should ever be optional, otherwise why it > at all. This use: > > + __ add(Gargs, __ regcon_sll_ptr_by_con(G5_stack_move, LogBytesPerWord, G5_stack_move), Gargs); > > should just be sll_ptr. I changed that. > Actually given all the magic that the existing regcon_sll_ptr does, > couldn't you shoehorn the new behaviour into it? The by_con behaviour > of returning the new regcon instead of the value return parameter > seems better anyway. Working on that. -- Christian From Christian.Thalinger at Sun.COM Fri Apr 23 03:50:29 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Apr 2010 12:50:29 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> Message-ID: <1272019829.15338.811.camel@macbook> On Wed, 2010-04-21 at 12:32 -0700, John Rose wrote: > > The switch in load_sized_value is too clever for my taste. How > about just a switch on size_in_bytes with a test on is_signed where > it's needed? > > My high school writing teacher used to direct us, if we thought we had > written something especially clever, to be ready to strike it out. > Christian, if you break up the Overly Clever Switch in the sensible > way Tom suggests, please break up the parallel one in the x86 code > too. I changed in both places. -- Christian From tom.rodriguez at oracle.com Fri Apr 23 10:23:08 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 23 Apr 2010 10:23:08 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1272030342.15338.940.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> <1271841747.15338.40.camel@macbook> <335E276C-C245-41E8-BD92-FC007B94867F@oracle.com> <1271877399.15338.767.camel@macbook> <1271877881.15338.772.camel@macbook> <5F680F20-9951-4F5E-86F6-FDD67A20B397@oracle.com> <1272030342.15338.940.camel@macbook> Message-ID: <69F4C70A-D624-496C-9189-F5AE6CF07121@oracle.com> On Apr 23, 2010, at 6:45 AM, Christian Thalinger wrote: > On Wed, 2010-04-21 at 12:31 -0700, Tom Rodriguez wrote: >> Why are you returning a LIR_Opr&? > > Because the do_temp call in LIR_OpVisitState::visit requires it. You should paper over that locally with a temp instead of polluting FrameMap with that constraint. tom > > -- Christian > From tom.rodriguez at oracle.com Fri Apr 23 10:22:08 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 23 Apr 2010 10:22:08 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1272024984.15338.898.camel@macbook> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> <1272024984.15338.898.camel@macbook> Message-ID: On Apr 23, 2010, at 5:16 AM, Christian Thalinger wrote: > On Wed, 2010-04-21 at 18:14 -0700, John Rose wrote: >> Although I like the way the code reads, the side-effect to &offset is >> a little unnerving when you look into the details. I could live with >> reformulating the regcon_foo_ptr macros to return the new >> RegisterOrConstant value as an explicit result, rather than patching >> it in-place as the dest argument. > > I changed that. But it still feels a little odd and sometimes difficult > that the macro works as: > > RegisterOrConstant regcon_sll_ptr(RegisterOrConstant dest, RegisterOrConstant src, Register temp = noreg); > > I'd actually like it more this way: > > void regcon_sll_ptr(RegisterOrConstant s1, RegisterOrConstant s2, RegisterOrConstant d); I'd be ok with that for sparc, though I think you still need the temp if dest and src were both constants that were larger than a simm13. tom > >> >> >> But I think regcon_sll_ptr_by_con should go. > > It's gone. > > -- Christian > From john.r.rose at oracle.com Fri Apr 23 15:46:48 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 23 Apr 2010 15:46:48 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> <1272024984.15338.898.camel@macbook> Message-ID: On Apr 23, 2010, at 10:22 AM, Tom Rodriguez wrote: >> >> void regcon_sll_ptr(RegisterOrConstant s1, RegisterOrConstant s2, RegisterOrConstant d); > > I'd be ok with that for sparc, though I think you still need the temp if dest and src were both constants that were larger than a simm13. *And* the destination value has to be passed by-reference, because if the temp is used for materialization, the updated destination will have to be passed back out to the caller. -- JOhn From john.r.rose at oracle.com Fri Apr 23 15:52:59 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 23 Apr 2010 15:52:59 -0700 Subject: Request for reviews (L): 6939207: refactor constant pool index processing In-Reply-To: <1272031594.15338.957.camel@macbook> References: <1270631795.2639.207.camel@macbook> <2C343FD4-0DDD-4E23-8D36-BC0822237586@oracle.com> <1272031594.15338.957.camel@macbook> Message-ID: <347FD1C4-6BED-42E6-A3C0-7C9FD1EE8AD5@oracle.com> On Apr 23, 2010, at 7:06 AM, Christian Thalinger wrote: > I have to say I was a little confused about the get_index1, > get_index2, ... naming as it looks like you were running out of method > names and just append 1, 2, ... ;-) You are right, it could look that way at first. Can you suggest some comments that would short-circuit that impression quickly? > The change is very big. I take a look at it again later. That will be just fine. -- John From igor.veresov at oracle.com Fri Apr 23 21:13:50 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 23 Apr 2010 21:13:50 -0700 Subject: Request for review(XXS): 6946892 c1 shouldn't sign-extend to upper 32bits on x64 Message-ID: <4BD26FFE.5070601@oracle.com> C1 does sign-extension when it loads ints and shorts from memory to 64-bit registers. This causes problems for C2 because it relies on the fact the int passed in a 64-bit register is zero-extended. Webrev: http://cr.openjdk.java.net/~iveresov/6946892/webrev.00/ Thanks, igor From Christian.Thalinger at Sun.COM Mon Apr 26 03:27:28 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 26 Apr 2010 12:27:28 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <69F4C70A-D624-496C-9189-F5AE6CF07121@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> <1271841747.15338.40.camel@macbook> <335E276C-C245-41E8-BD92-FC007B94867F@oracle.com> <1271877399.15338.767.camel@macbook> <1271877881.15338.772.camel@macbook> <5F680F20-9951-4F5E-86F6-FDD67A20B397@oracle.com> <1272030342.15338.940.camel@macbook> <69F4C70A-D624-496C-9189-F5AE6CF07121@oracle.com> Message-ID: <1272277648.1069.4.camel@macbook> On Fri, 2010-04-23 at 10:23 -0700, Tom Rodriguez wrote: > On Apr 23, 2010, at 6:45 AM, Christian Thalinger wrote: > > > On Wed, 2010-04-21 at 12:31 -0700, Tom Rodriguez wrote: > >> Why are you returning a LIR_Opr&? > > > > Because the do_temp call in LIR_OpVisitState::visit requires it. > > You should paper over that locally with a temp instead of polluting > FrameMap with that constraint. OK. http://cr.openjdk.java.net/~twisti/6930772/webrev.05/ -- Christian From Christian.Thalinger at Sun.COM Mon Apr 26 05:30:42 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 26 Apr 2010 14:30:42 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1272277648.1069.4.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> <1271841747.15338.40.camel@macbook> <335E276C-C245-41E8-BD92-FC007B94867F@oracle.com> <1271877399.15338.767.camel@macbook> <1271877881.15338.772.camel@macbook> <5F680F20-9951-4F5E-86F6-FDD67A20B397@oracle.com> <1272030342.15338.940.camel@macbook> <69F4C70A-D624-496C-9189-F5AE6CF07121@oracle.com> <1272277648.1069.4.camel@macbook> Message-ID: <1272285043.1069.135.camel@macbook> On Mon, 2010-04-26 at 12:27 +0200, Christian Thalinger wrote: > On Fri, 2010-04-23 at 10:23 -0700, Tom Rodriguez wrote: > > On Apr 23, 2010, at 6:45 AM, Christian Thalinger wrote: > > > > > On Wed, 2010-04-21 at 12:31 -0700, Tom Rodriguez wrote: > > >> Why are you returning a LIR_Opr&? > > > > > > Because the do_temp call in LIR_OpVisitState::visit requires it. > > > > You should paper over that locally with a temp instead of polluting > > FrameMap with that constraint. > > OK. > > http://cr.openjdk.java.net/~twisti/6930772/webrev.05/ That doesn't work, it hits an assert. It seems the problem happens because the local temporary reference goes dead and then an assert is hit somewhere in the register allocator. The only way I can see to make this work is to put the temporary into LIR_OpJavaCall. -- Christian From Christian.Thalinger at Sun.COM Mon Apr 26 07:49:42 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 26 Apr 2010 16:49:42 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> <1272024984.15338.898.camel@macbook> Message-ID: <1272293382.1069.139.camel@macbook> On Fri, 2010-04-23 at 15:46 -0700, John Rose wrote: > On Apr 23, 2010, at 10:22 AM, Tom Rodriguez wrote: > > >> > >> void regcon_sll_ptr(RegisterOrConstant s1, RegisterOrConstant s2, RegisterOrConstant d); > > > > I'd be ok with that for sparc, though I think you still need the > temp if dest and src were both constants that were larger than a > simm13. Yes, a temp is required. I missed that above. > > *And* the destination value has to be passed by-reference, because if > the temp is used for materialization, the updated destination will > have to be passed back out to the caller. Right. Here is the change: http://cr.openjdk.java.net/~twisti/6829193/webrev.05/ I like that much more. -- Christian From tom.rodriguez at oracle.com Mon Apr 26 10:32:22 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 26 Apr 2010 10:32:22 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1272285043.1069.135.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <4FFA9696-52AB-478F-9816-2FF2F25B40B3@oracle.com> <1271421698.899.146.camel@macbook> <8CA79149-FA00-4D13-84AE-530FD9FD10E2@oracle.com> <1271674487.917.4.camel@macbook> <1271841747.15338.40.camel@macbook> <335E276C-C245-41E8-BD92-FC007B94867F@oracle.com> <1271877399.15338.767.camel@macbook> <1271877881.15338.772.camel@macbook> <5F680F20-9951-4F5E-86F6-FDD67A20B397@oracle.com> <1272030342.15338.940.camel@macbook> <69F4C70A-D624-496C-9189-F5AE6CF07121@oracle.com> <1272277648.1069.4.camel@macbook> <1272285043.1069.135.camel@macbook> Message-ID: <6AFBE4F7-BF5B-40E0-8B76-6328D068BBB6@oracle.com> >> >> http://cr.openjdk.java.net/~twisti/6930772/webrev.05/ > > That doesn't work, it hits an assert. It seems the problem happens > because the local temporary reference goes dead and then an assert is > hit somewhere in the register allocator. Oh right, it hangs onto the reference. > > The only way I can see to make this work is to put the temporary into > LIR_OpJavaCall. It's either in there or adding some special handling support in LIR_OpVisitState but adding it in the call seems more reasonable. tom > > -- Christian > From tom.rodriguez at oracle.com Mon Apr 26 12:04:01 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 26 Apr 2010 12:04:01 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1272293382.1069.139.camel@macbook> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> <1272024984.15338.898.camel@macbook> <1272293382.1069.139.camel@macbook> Message-ID: <0B27A023-227D-455F-9E44-BDC5516C317D@oracle.com> On Apr 26, 2010, at 7:49 AM, Christian Thalinger wrote: > On Fri, 2010-04-23 at 15:46 -0700, John Rose wrote: >> On Apr 23, 2010, at 10:22 AM, Tom Rodriguez wrote: >> >>>> >>>> void regcon_sll_ptr(RegisterOrConstant s1, RegisterOrConstant s2, RegisterOrConstant d); >>> >>> I'd be ok with that for sparc, though I think you still need the >> temp if dest and src were both constants that were larger than a >> simm13. > > Yes, a temp is required. I missed that above. > >> >> *And* the destination value has to be passed by-reference, because if >> the temp is used for materialization, the updated destination will >> have to be passed back out to the caller. > > Right. Here is the change: > > http://cr.openjdk.java.net/~twisti/6829193/webrev.05/ > > I like that much more. It's better but I still don't like the value return parameter. Almost every path through there changes the value of dest and that seems like something that should be directly returned. If it always produced its result in a register then I think it should follow the pattern of sll_ptr but since it doesn't I think it should follow a different pattern. tom > > -- Christian > From tom.rodriguez at oracle.com Mon Apr 26 12:16:27 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 26 Apr 2010 12:16:27 -0700 Subject: Request for review(XXS): 6946892 c1 shouldn't sign-extend to upper 32bits on x64 In-Reply-To: <4BD26FFE.5070601@oracle.com> References: <4BD26FFE.5070601@oracle.com> Message-ID: <02F67A13-9AF6-4233-8896-B83DCF30F9F9@oracle.com> This looks good. Have you tested the 64 bit client much after this change? The sign extension here could be hiding some missing sign extension at the LIR level. tom On Apr 23, 2010, at 9:13 PM, Igor Veresov wrote: > C1 does sign-extension when it loads ints and shorts from memory to 64-bit registers. This causes problems for C2 because it relies on the fact the int passed in a 64-bit register is zero-extended. > > Webrev: http://cr.openjdk.java.net/~iveresov/6946892/webrev.00/ > > Thanks, > igor From tom.rodriguez at oracle.com Mon Apr 26 15:35:19 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Mon, 26 Apr 2010 22:35:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6946040: add intrinsic for short and char reverseBytes Message-ID: <20100426223521.A3C0344194@hg.openjdk.java.net> Changeset: d7f654633cfe Author: never Date: 2010-04-26 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d7f654633cfe 6946040: add intrinsic for short and char reverseBytes Reviewed-by: never, twisti Contributed-by: Hiroshi Yamauchi ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.hpp + test/compiler/6431242/Test.java + test/compiler/6946040/TestCharShortByteSwap.java From tom.rodriguez at oracle.com Tue Apr 27 02:00:31 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 27 Apr 2010 09:00:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6943485: JVMTI always on capabilities change code generation too much Message-ID: <20100427090033.90911441AE@hg.openjdk.java.net> Changeset: b4776199210f Author: never Date: 2010-04-26 23:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b4776199210f 6943485: JVMTI always on capabilities change code generation too much Reviewed-by: twisti, dcubed ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiManageCapabilities.cpp From Christian.Thalinger at Sun.COM Tue Apr 27 04:47:40 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 27 Apr 2010 13:47:40 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <0B27A023-227D-455F-9E44-BDC5516C317D@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> <1272024984.15338.898.camel@macbook> <1272293382.1069.139.camel@macbook> <0B27A023-227D-455F-9E44-BDC5516C317D@oracle.com> Message-ID: <1272368860.19839.69.camel@macbook> On Mon, 2010-04-26 at 12:04 -0700, Tom Rodriguez wrote: > On Apr 26, 2010, at 7:49 AM, Christian Thalinger wrote: > > > On Fri, 2010-04-23 at 15:46 -0700, John Rose wrote: > >> On Apr 23, 2010, at 10:22 AM, Tom Rodriguez wrote: > >> > >>>> > >>>> void regcon_sll_ptr(RegisterOrConstant s1, RegisterOrConstant s2, RegisterOrConstant d); > >>> > >>> I'd be ok with that for sparc, though I think you still need the > >> temp if dest and src were both constants that were larger than a > >> simm13. > > > > Yes, a temp is required. I missed that above. > > > >> > >> *And* the destination value has to be passed by-reference, because if > >> the temp is used for materialization, the updated destination will > >> have to be passed back out to the caller. > > > > Right. Here is the change: > > > > http://cr.openjdk.java.net/~twisti/6829193/webrev.05/ > > > > I like that much more. > > It's better but I still don't like the value return parameter. Almost > every path through there changes the value of dest and that seems like > something that should be directly returned. If it always produced its > result in a register then I think it should follow the pattern of > sll_ptr but since it doesn't I think it should follow a different > pattern. Last try :-) http://cr.openjdk.java.net/~twisti/6829193/webrev.06/ -- Christian From Christian.Thalinger at Sun.COM Tue Apr 27 07:37:50 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 27 Apr 2010 16:37:50 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> Message-ID: <1272379070.19839.74.camel@macbook> On Thu, 2010-04-15 at 10:18 -0700, John Rose wrote: > On Apr 15, 2010, at 4:25 AM, Christian Thalinger wrote: > > > Additionally I changed ciMethod::is_method_handle_invoke to use the > > holder and method name to be able to call it on unloaded methods. John > > hasn't replied yet on my email if that's OK but my extensive testings > > show that it should be OK. > > Yes, that's fine. -- John It seems there is a mismatch somewhere. When running JRuby tests with C2 I get asserts like: Internal Error at ciMethod.cpp:705, pid=6123, tid=7 Error: assert(flag == flag3,"consistent") The method is a MH invoke but the flags say it's not: (dbx) p get_methodOop()->print() {method} - klass: {other class} - method holder: 'java/dyn/InvokeDynamic' - constants: 0xfec17ce9constant pool [10] for 'java/dyn/InvokeDynamic' - access: 0x19 public static final - name: 'invoke' - signature: '(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/String;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject;' - max stack: 6 - max locals: 5 - size of params: 5 - method size: 20 - vtable index: -3 - i2i entry: 0xfaa0b900 - adapter: 0x0815b510 - compiled entry 0xfaab319f - code size: 15 - code start: 0xf76e5ab0 - code end (excl): 0xf76e5abf - checked ex length: 0 - localvar length: 0 (dbx) p flags() flags() = { _flags = 25 } -- Christian From igor.veresov at oracle.com Tue Apr 27 08:46:57 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 27 Apr 2010 08:46:57 -0700 Subject: Request for review(XXS): 6946892 c1 shouldn't sign-extend to upper 32bits on x64 In-Reply-To: <02F67A13-9AF6-4233-8896-B83DCF30F9F9@oracle.com> References: <4BD26FFE.5070601@oracle.com> <02F67A13-9AF6-4233-8896-B83DCF30F9F9@oracle.com> Message-ID: <4BD706F1.9010309@oracle.com> Thank you, Tom! I've tested with SPECjvm98 and SPECjvm2008, they work ok. I'll keep an eye on related things that may bubble up. igor On 4/26/10 12:16 PM, Tom Rodriguez wrote: > This looks good. Have you tested the 64 bit client much after this change? The sign extension here could be hiding some missing sign extension at the LIR level. > > tom > > On Apr 23, 2010, at 9:13 PM, Igor Veresov wrote: > >> C1 does sign-extension when it loads ints and shorts from memory to 64-bit registers. This causes problems for C2 because it relies on the fact the int passed in a 64-bit register is zero-extended. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6946892/webrev.00/ >> >> Thanks, >> igor > From Christian.Thalinger at Sun.COM Tue Apr 27 10:25:35 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 27 Apr 2010 19:25:35 +0200 Subject: Request for reviews (S): 6934104: JSR 292 needs to support SPARC C2 In-Reply-To: References: <1270725916.2639.269.camel@macbook> Message-ID: <1272389135.19839.144.camel@macbook> On Thu, 2010-04-08 at 11:38 -0700, Tom Rodriguez wrote: > Looks good. Here is an updated version which uses the new register definitions added with the C1 changes: http://cr.openjdk.java.net/~twisti/6934104/webrev.02/ -- Christian From john.r.rose at oracle.com Tue Apr 27 10:27:40 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 27 Apr 2010 10:27:40 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1272379070.19839.74.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> Message-ID: <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> On Apr 27, 2010, at 7:37 AM, Christian Thalinger wrote: > It seems there is a mismatch somewhere. When running JRuby tests with > C2 I get asserts like: The mismatch is that the method triggering the assert is a member of InvokeDynamic, not MethodHandle. This means somebody reasonably thinks it's not really a method handle invoke. In fact, it is a generated adapter for a compiled dynamic call site, isn't it? And if we ever allow reflection to reify InvokeDynamic methods somehow, there will be regular methods that are members of InvokeDynamic, some of whom might be named 'invoke'. So, there's a terminology problem here. I think is_method_handle_invoke should be true only for the signature-polymorphic members of java.dyn.MethodHandle (invoke, eventually invokeGeneric/invokeExact). We should have a different predicate (if we need it) for adapters. -- John From yamauchi at google.com Tue Apr 27 10:29:28 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 27 Apr 2010 10:29:28 -0700 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <7F29BAF0-D6B3-460E-9DFB-A10C02DCE56F@oracle.com> References: <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <9D317290-7994-43D6-8013-C41185EC9BA7@oracle.com> <7F29BAF0-D6B3-460E-9DFB-A10C02DCE56F@oracle.com> Message-ID: Tom, Thanks. It looks like it's been checked in. http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d7f654633cfe Now, Martin and Ulf, the following patch is up to you: http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ Hiroshi On Thu, Apr 22, 2010 at 4:15 PM, Tom Rodriguez wrote: > Resending because of bounce. > > On Apr 22, 2010, at 3:22 PM, Hiroshi Yamauchi wrote: > >> Thanks, Tom. It looks good to me. > > Thanks. > >> >>> This is Hiroshi's patch for reverseShort and reverseChar intrinsics. >>> I've redone the sparc implementation and fixed bugs in the original >>> implementation as well. ?The existing versions were broken with >>> implicit null checking since implicit null checks assume that the >>> faulting load is the first instruction in the node but because of the >>> way the memory was being handled it wasn't. ?The first instruction was >>> actually an add so if an implicit null happened the JVM would die. >>> The new code restricts these forms to use reg+reg addressing only so >>> any address math is handled automatically. ?Tested with new test case >> >> I must have overlooked the '+2' offset in the stackSlotI (in >> bytes_reverse_unsigned_short/bytes_reverse_short.) > > It showed up in testing of course. ?I didn't notice it before that. > >> I'm just curious but I'm not sure who emits the add instruction. One >> instruction that can be emitted before the load instruction (and that >> I can see) is: >> >> 949 ? ? emit3_simm13( cbuf, Assembler::arith_op, index, >> Assembler::or_op3, 0, disp); >> >> emitted by the now-removed emit_form3_mem_reg_asi(). But it's an or, >> not an add. There may be some code emission that I don't see. > > That code was doing or g0, simm13, o7. ?On sparc both add and or can be used for the constant formation idiom though you decompose the constant differently when sethi is involved since it does 22 bits and the others do 13 so they overlap. ?sethi hi22, r or r, simm13, r always works but an add has to operate on the low 10 bits. > > tom > >> >> Hiroshi > > From tom.rodriguez at oracle.com Tue Apr 27 11:01:26 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 27 Apr 2010 11:01:26 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1272368860.19839.69.camel@macbook> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> <1272024984.15338.898.camel@macbook> <1272293382.1069.139.camel@macbook> <0B27A023-227D-455F-9E44-BDC5516C317D@oracle.com> <1272368860.19839.69.camel@macbook> Message-ID: <57ACBF03-DDCB-4944-BFE4-69A45BD1716B@oracle.com> >> >> It's better but I still don't like the value return parameter. Almost >> every path through there changes the value of dest and that seems like >> something that should be directly returned. If it always produced its >> result in a register then I think it should follow the pattern of >> sll_ptr but since it doesn't I think it should follow a different >> pattern. > > Last try :-) > > http://cr.openjdk.java.net/~twisti/6829193/webrev.06/ That looks good. tom > > -- Christian > From tom.rodriguez at oracle.com Tue Apr 27 11:04:46 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 27 Apr 2010 11:04:46 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1272368860.19839.69.camel@macbook> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> <1272024984.15338.898.camel@macbook> <1272293382.1069.139.camel@macbook> <0B27A023-227D-455F-9E44-BDC5516C317D@oracle.com> <1272368860.19839.69.camel@macbook> Message-ID: <83F0295F-FECC-4CEB-9E22-01A701220AD4@oracle.com> By the way, I noticed that you had an assert !UseCompressedOops in some of the code. You should be able to support it appropriately by simply using load_heap_oop instead of ld_ptr. The basic rule is use load_heap_oop if the field is a compressed oop, which applies to all normal Java fields, and use ld_ptr if the field is actually declared in C++, like the special oop fields in Thread. There are some corner cases but that gets you through most of them. tom On Apr 27, 2010, at 4:47 AM, Christian Thalinger wrote: > On Mon, 2010-04-26 at 12:04 -0700, Tom Rodriguez wrote: >> On Apr 26, 2010, at 7:49 AM, Christian Thalinger wrote: >> >>> On Fri, 2010-04-23 at 15:46 -0700, John Rose wrote: >>>> On Apr 23, 2010, at 10:22 AM, Tom Rodriguez wrote: >>>> >>>>>> >>>>>> void regcon_sll_ptr(RegisterOrConstant s1, RegisterOrConstant s2, RegisterOrConstant d); >>>>> >>>>> I'd be ok with that for sparc, though I think you still need the >>>> temp if dest and src were both constants that were larger than a >>>> simm13. >>> >>> Yes, a temp is required. I missed that above. >>> >>>> >>>> *And* the destination value has to be passed by-reference, because if >>>> the temp is used for materialization, the updated destination will >>>> have to be passed back out to the caller. >>> >>> Right. Here is the change: >>> >>> http://cr.openjdk.java.net/~twisti/6829193/webrev.05/ >>> >>> I like that much more. >> >> It's better but I still don't like the value return parameter. Almost >> every path through there changes the value of dest and that seems like >> something that should be directly returned. If it always produced its >> result in a register then I think it should follow the pattern of >> sll_ptr but since it doesn't I think it should follow a different >> pattern. > > Last try :-) > > http://cr.openjdk.java.net/~twisti/6829193/webrev.06/ > > -- Christian > From tom.rodriguez at oracle.com Tue Apr 27 11:05:55 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 27 Apr 2010 11:05:55 -0700 Subject: Request for reviews (S): 6934104: JSR 292 needs to support SPARC C2 In-Reply-To: <1272389135.19839.144.camel@macbook> References: <1270725916.2639.269.camel@macbook> <1272389135.19839.144.camel@macbook> Message-ID: <4769DD28-399E-40EF-AD7D-4C5DD5321E75@oracle.com> Looks good. tom On Apr 27, 2010, at 10:25 AM, Christian Thalinger wrote: > On Thu, 2010-04-08 at 11:38 -0700, Tom Rodriguez wrote: >> Looks good. > > Here is an updated version which uses the new register definitions added > with the C1 changes: > > http://cr.openjdk.java.net/~twisti/6934104/webrev.02/ > > -- Christian > From igor.veresov at oracle.com Tue Apr 27 13:34:40 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 27 Apr 2010 20:34:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6946892: c1 shouldn't sign-extend to upper 32bits on x64 Message-ID: <20100427203442.D7B5C441C9@hg.openjdk.java.net> Changeset: 314e17ca2c23 Author: iveresov Date: 2010-04-27 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/314e17ca2c23 6946892: c1 shouldn't sign-extend to upper 32bits on x64 Summary: c1 does sign-extension when it loads ints and shorts from memory to 64-bit registers. This causes problems for c2 because it relies on the fact the int passed in a 64-bit register is zero-extended. Reviewed-by: never ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp From Ulf.Zibis at gmx.de Tue Apr 27 15:07:38 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 28 Apr 2010 00:07:38 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: References: <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <9D317290-7994-43D6-8013-C41185EC9BA7@oracle.com> <7F29BAF0-D6B3-460E-9DFB-A10C02DCE56F@oracle.com> Message-ID: <4BD7602A.4090304@gmx.de> Am 27.04.2010 19:29, schrieb Hiroshi Yamauchi: > Tom, > > Thanks. It looks like it's been checked in. > > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d7f654633cfe > > Now, Martin and Ulf, the following patch is up to you: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ > Looks perfect to me. Maybe you like to rename char variables to c, integers to i etc., just for sugar. I'm not sure, if starting at offset 7/3/1 and then decrementing down to 0 is the fastest way to step through the multi-byte values in makeType and get/putTypeL/B methods. They are anyway intrinsified little later. My guess is, we could save byte code and JIT optimization load by defining those methods as native calls, and user will not be confused, if those methods will perform slow on assembling the multi-byte values from single bytes. -Ulf From Christian.Thalinger at Sun.COM Wed Apr 28 02:23:58 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 28 Apr 2010 11:23:58 +0200 Subject: Request for reviews (L): 6939207: refactor constant pool index processing In-Reply-To: <347FD1C4-6BED-42E6-A3C0-7C9FD1EE8AD5@oracle.com> References: <1270631795.2639.207.camel@macbook> <2C343FD4-0DDD-4E23-8D36-BC0822237586@oracle.com> <1272031594.15338.957.camel@macbook> <347FD1C4-6BED-42E6-A3C0-7C9FD1EE8AD5@oracle.com> Message-ID: <1272446638.19839.330.camel@macbook> On Fri, 2010-04-23 at 15:52 -0700, John Rose wrote: > On Apr 23, 2010, at 7:06 AM, Christian Thalinger wrote: > > > I have to say I was a little confused about the get_index1, > > get_index2, ... naming as it looks like you were running out of method > > names and just append 1, 2, ... ;-) > > You are right, it could look that way at first. Can you suggest some > comments that would short-circuit that impression quickly? Well, you could rename it to get_index_u{1,2,4} which would correspond to the other Bytes::get* functions. If you want to keep them maybe add a simple comment like: // get_{index,offset,constant}{1,2,4} methods return an // index/offset/constant of the size of the appended number in bytes //(1, 2, or 4 bytes). You may rephrase for better English. I just see that ciStreams.hpp has comments on most of these methods. > > > The change is very big. I take a look at it again later. > > That will be just fine. src/share/vm/prims/jvmtiClassFileReconstituter.cpp: Copyright year update missing. src/share/vm/prims/methodComparator.cpp: - if (_s_old->get_index_big() != _s_new->get_index_big()) + if (Bytes::get_Java_u2(_s_old->bcp() + 1) != Bytes::get_Java_u2(_s_new->bcp() + 1)) Why can't you use get_index2() here? What is the difference to: case Bytecodes::_sipush : - if (_s_old->get_index_big() != _s_new->get_index_big()) + if (_s_old->get_index2() != _s_new->get_index2()) Otherwise looks good. -- Christian From Christian.Thalinger at Sun.COM Wed Apr 28 02:46:08 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 28 Apr 2010 11:46:08 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <83F0295F-FECC-4CEB-9E22-01A701220AD4@oracle.com> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> <1272024984.15338.898.camel@macbook> <1272293382.1069.139.camel@macbook> <0B27A023-227D-455F-9E44-BDC5516C317D@oracle.com> <1272368860.19839.69.camel@macbook> <83F0295F-FECC-4CEB-9E22-01A701220AD4@oracle.com> Message-ID: <1272447968.19839.366.camel@macbook> On Tue, 2010-04-27 at 11:04 -0700, Tom Rodriguez wrote: > By the way, I noticed that you had an assert !UseCompressedOops in > some of the code. You should be able to support it appropriately by > simply using load_heap_oop instead of ld_ptr. The basic rule is use > load_heap_oop if the field is a compressed oop, which applies to all > normal Java fields, and use ld_ptr if the field is actually declared > in C++, like the special oop fields in Thread. There are some corner > cases but that gets you through most of them. Right, we also still miss compressed oops support on x86. John has already filed a CR: 6829194: JSR 292 needs to support compressed oops Should I take care of that? -- Christian From Ulf.Zibis at gmx.de Wed Apr 28 03:34:53 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 28 Apr 2010 12:34:53 +0200 Subject: Short/Character.reverseBytes intrinsics In-Reply-To: <4BD7602A.4090304@gmx.de> References: <244511AF-3523-4D86-8E6F-CB1C18DE9F20@oracle.com> <17AE5DF9-415B-480D-90C0-29236F6D7E92@oracle.com> <9D317290-7994-43D6-8013-C41185EC9BA7@oracle.com> <7F29BAF0-D6B3-460E-9DFB-A10C02DCE56F@oracle.com> <4BD7602A.4090304@gmx.de> Message-ID: <4BD80F4D.5070808@gmx.de> Alternatively I think, it would be more consequent to collect all bit mechanics in Bits.java. Following this, Type.reverseBytes should call Bits.swap(type) instead contrariwise. Additionally this would allow to place swap(float) and swap(double) in Bits.java. May be the from/to raw bits mechanics code should too be better placed in Bits.java. Another point: Wouldn't the " -- Processor and memory-system properties -- " section better fit to Unsafe.java class ? Anyway, the switch block in the static initializer should be proper indented. -Ulf Am 28.04.2010 00:07, schrieb Ulf Zibis: > Am 27.04.2010 19:29, schrieb Hiroshi Yamauchi: >> Tom, >> >> Thanks. It looks like it's been checked in. >> >> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d7f654633cfe >> >> Now, Martin and Ulf, the following patch is up to you: >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/nioBits.java/ > > Looks perfect to me. > > Maybe you like to rename char variables to c, integers to i etc., just > for sugar. > > I'm not sure, if starting at offset 7/3/1 and then decrementing down > to 0 is the fastest way to step through the multi-byte values in > makeType and get/putTypeL/B methods. They are anyway intrinsified > little later. My guess is, we could save byte code and JIT > optimization load by defining those methods as native calls, and user > will not be confused, if those methods will perform slow on assembling > the multi-byte values from single bytes. > > -Ulf > > > From Christian.Thalinger at Sun.COM Wed Apr 28 04:22:33 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 28 Apr 2010 13:22:33 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> Message-ID: <1272453753.19839.472.camel@macbook> On Tue, 2010-04-27 at 10:27 -0700, John Rose wrote: > On Apr 27, 2010, at 7:37 AM, Christian Thalinger wrote: > > > It seems there is a mismatch somewhere. When running JRuby tests with > > C2 I get asserts like: > > The mismatch is that the method triggering the assert is a member of > InvokeDynamic, not MethodHandle. > > This means somebody reasonably thinks it's not really a method handle > invoke. In fact, it is a generated adapter for a compiled dynamic > call site, isn't it? Yes, this is an adapter for an invokedynamic call site. > And if we ever allow reflection to reify InvokeDynamic methods > somehow, there will be regular methods that are members of > InvokeDynamic, some of whom might be named 'invoke'. > > So, there's a terminology problem here. > > I think is_method_handle_invoke should be true only for the > signature-polymorphic members of java.dyn.MethodHandle (invoke, > eventually invokeGeneric/invokeExact). We should have a different > predicate (if we need it) for adapters. Well, I think we need it, otherwise we don't inline them (from InlineTree::shouldNotInline): // Always inline MethodHandle methods. if (callee_method->is_method_handle_invoke()) return NULL; Wait! We have methodOopDesc::is_method_handle_adapter. I think we should add a check for that in the above statement and only return true in ciMethod::is_method_handle_invoke as you suggested above. -- Christian From Christian.Thalinger at Sun.COM Wed Apr 28 05:35:55 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 28 Apr 2010 14:35:55 +0200 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1272453753.19839.472.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> Message-ID: <1272458155.19839.474.camel@macbook> On Wed, 2010-04-28 at 13:22 +0200, Christian Thalinger wrote: > > I think is_method_handle_invoke should be true only for the > > signature-polymorphic members of java.dyn.MethodHandle (invoke, > > eventually invokeGeneric/invokeExact). We should have a different > > predicate (if we need it) for adapters. > > Well, I think we need it, otherwise we don't inline them (from > InlineTree::shouldNotInline): > > // Always inline MethodHandle methods. > if (callee_method->is_method_handle_invoke()) > return NULL; > > Wait! We have methodOopDesc::is_method_handle_adapter. I think we > should add a check for that in the above statement and only return true > in ciMethod::is_method_handle_invoke as you suggested above. That doesn't work. I forgot that generated adapters for MH call sites are called java.dyn.MethodHandle::invoke and that fits the pattern of ciMethod::is_method_handle_invoke. We need something else... -- Christian From Christian.Thalinger at Sun.COM Wed Apr 28 07:23:41 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 28 Apr 2010 16:23:41 +0200 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1272368860.19839.69.camel@macbook> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> <1272024984.15338.898.camel@macbook> <1272293382.1069.139.camel@macbook> <0B27A023-227D-455F-9E44-BDC5516C317D@oracle.com> <1272368860.19839.69.camel@macbook> Message-ID: <1272464621.19839.476.camel@macbook> On Tue, 2010-04-27 at 13:47 +0200, Christian Thalinger wrote: > On Mon, 2010-04-26 at 12:04 -0700, Tom Rodriguez wrote: > > On Apr 26, 2010, at 7:49 AM, Christian Thalinger wrote: > > > > > On Fri, 2010-04-23 at 15:46 -0700, John Rose wrote: > > >> On Apr 23, 2010, at 10:22 AM, Tom Rodriguez wrote: > > >> > > >>>> > > >>>> void regcon_sll_ptr(RegisterOrConstant s1, RegisterOrConstant s2, RegisterOrConstant d); > > >>> > > >>> I'd be ok with that for sparc, though I think you still need the > > >> temp if dest and src were both constants that were larger than a > > >> simm13. > > > > > > Yes, a temp is required. I missed that above. > > > > > >> > > >> *And* the destination value has to be passed by-reference, because if > > >> the temp is used for materialization, the updated destination will > > >> have to be passed back out to the caller. > > > > > > Right. Here is the change: > > > > > > http://cr.openjdk.java.net/~twisti/6829193/webrev.05/ > > > > > > I like that much more. > > > > It's better but I still don't like the value return parameter. Almost > > every path through there changes the value of dest and that seems like > > something that should be directly returned. If it always produced its > > result in a register then I think it should follow the pattern of > > sll_ptr but since it doesn't I think it should follow a different > > pattern. > > Last try :-) > > http://cr.openjdk.java.net/~twisti/6829193/webrev.06/ Here is (hopefully) the final version: http://cr.openjdk.java.net/~twisti/6829193/webrev.07/ I tested this on all architectures (except Windows) and it looks good. If there are no objections I will commit it tomorrow. -- Christian From tom.rodriguez at oracle.com Wed Apr 28 11:35:42 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 28 Apr 2010 11:35:42 -0700 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC In-Reply-To: <1272447968.19839.366.camel@macbook> References: <1269027319.2224.10.camel@macbook> <1270725898.2639.267.camel@macbook> <4BBE5DB9.8090203@oracle.com> <1270826004.1510.263.camel@macbook> <4BBF570A.5080903@oracle.com> <1271681403.2814.28.camel@macbook> <3A34DB51-D59F-40E3-BD32-690C0BEFCA3B@oracle.com> <836CE2D2-74E1-44F6-9B8D-38B146498A71@oracle.com> <07BB258B-A2D4-4011-8091-7541E13637D8@oracle.com> <1272024984.15338.898.camel@macbook> <1272293382.1069.139.camel@macbook> <0B27A023-227D-455F-9E44-BDC5516C317D@oracle.com> <1272368860.19839.69.camel@macbook> <83F0295F-FECC-4CEB-9E22-01A701220AD4@oracle.com> <1272447968.19839.366.camel@macbook> Message-ID: <48D73E23-E767-4765-AE4E-4AB367D881B8@oracle.com> On Apr 28, 2010, at 2:46 AM, Christian Thalinger wrote: > On Tue, 2010-04-27 at 11:04 -0700, Tom Rodriguez wrote: >> By the way, I noticed that you had an assert !UseCompressedOops in >> some of the code. You should be able to support it appropriately by >> simply using load_heap_oop instead of ld_ptr. The basic rule is use >> load_heap_oop if the field is a compressed oop, which applies to all >> normal Java fields, and use ld_ptr if the field is actually declared >> in C++, like the special oop fields in Thread. There are some corner >> cases but that gets you through most of them. > > Right, we also still miss compressed oops support on x86. John has > already filed a CR: > > 6829194: JSR 292 needs to support compressed oops > > Should I take care of that? Mostly it's just picking between ld_ptr and load_heap_oop and deciding that when you're writing the code seems easier than going back and trying to find all the places that need to be corrected. It's fine if it's all going to be put off into another bug. A lot of this could have been automatic if we revamped ld_ptr and stopped using raw offsets. We'd bandied around the idea of wrapping the offsets with objects like ByteSize and WordSize do so that we could get type checking and overloading on offset tyeps to help with selecting the right instruction for loading fields from assembly. This was prior to compressed oops but I think it would have made compressed oops simpler in many ways. Oh well. tom > > -- Christian > From john.r.rose at oracle.com Wed Apr 28 12:23:31 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 28 Apr 2010 12:23:31 -0700 Subject: Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1 In-Reply-To: <1272458155.19839.474.camel@macbook> References: <1270725914.2639.268.camel@macbook> <84E09CA6-A381-4ED9-984B-69E0088CE81D@oracle.com> <1270801366.1510.6.camel@macbook> <641FFC3E-A700-4EEA-9B45-D56C0F285CA8@oracle.com> <1271330753.2134.210.camel@macbook> <1272379070.19839.74.camel@macbook> <3DE38E56-4CE9-40F5-929B-EE929C040A1F@oracle.com> <1272453753.19839.472.camel@macbook> <1272458155.19839.474.camel@macbook> Message-ID: <687EC090-C84C-440F-A8D0-EF60B653BF3F@oracle.com> Suggestion: Grep for is_method_handle_adapter in this file, and adapt any relevant changes: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-ing-6939134.patch (My bad that it's not pushed yet.) -- John On Apr 28, 2010, at 5:35 AM, Christian Thalinger wrote: > On Wed, 2010-04-28 at 13:22 +0200, Christian Thalinger wrote: >>> I think is_method_handle_invoke should be true only for the >>> signature-polymorphic members of java.dyn.MethodHandle (invoke, >>> eventually invokeGeneric/invokeExact). We should have a different >>> predicate (if we need it) for adapters. >> >> Well, I think we need it, otherwise we don't inline them (from >> InlineTree::shouldNotInline): >> >> // Always inline MethodHandle methods. >> if (callee_method->is_method_handle_invoke()) >> return NULL; >> >> Wait! We have methodOopDesc::is_method_handle_adapter. I think we >> should add a check for that in the above statement and only return true >> in ciMethod::is_method_handle_invoke as you suggested above. > > That doesn't work. I forgot that generated adapters for MH call sites > are called java.dyn.MethodHandle::invoke and that fits the pattern of > ciMethod::is_method_handle_invoke. We need something else... > > -- Christian > From john.r.rose at oracle.com Thu Apr 29 03:49:29 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 29 Apr 2010 10:49:29 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 19 new changesets Message-ID: <20100429105009.2E505442E5@hg.openjdk.java.net> Changeset: 3f12a94552cc Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3f12a94552cc Added tag jdk7-b88 for changeset 4b60f23c4223 ! .hgtags Changeset: 5b29c2368d93 Author: lana Date: 2010-04-08 15:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5b29c2368d93 Merge ! src/share/vm/opto/type.cpp Changeset: 15836273ac24 Author: lana Date: 2010-04-13 16:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/15836273ac24 Merge Changeset: 4c78b7c16824 Author: trims Date: 2010-04-15 19:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4c78b7c16824 6944398: Bump the HS18 build number to 03 Summary: Update the HS18 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e16cca0aa5e1 Author: trims Date: 2010-04-15 19:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e16cca0aa5e1 Merge Changeset: 25f53b53aaa3 Author: trims Date: 2010-04-15 19:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/25f53b53aaa3 Added tag hs18-b02 for changeset 4b60f23c4223 ! .hgtags Changeset: 765578777b6e Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/765578777b6e Added tag jdk7-b89 for changeset 15836273ac24 ! .hgtags Changeset: 605c9707a766 Author: trims Date: 2010-04-20 21:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/605c9707a766 Merge ! .hgtags Changeset: ba07d5be2d51 Author: jrose Date: 2010-04-21 01:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ba07d5be2d51 Merge Changeset: 0bfd3fb24150 Author: jmasa Date: 2010-04-13 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0bfd3fb24150 6858496: Clear all SoftReferences before an out-of-memory due to GC overhead limit. Summary: Ensure a full GC that clears SoftReferences before throwing an out-of-memory Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_serial ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: 7666957bc44d Author: tonyp Date: 2010-03-30 15:43 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7666957bc44d 6937142: G1: improvements to debugging output (S-M) Summary: Various fixes to the G1 debugging output. Reviewed-by: johnc, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 5dbd9300cf9c Author: johnc Date: 2010-04-15 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5dbd9300cf9c 6943926: G1: Integer overflow during heap region verification Summary: The expression that calculates the live bytes for a heap region can overflow for a suitably large humongous region/object. Cache the object size in a suitably sized local variable so that the expression is converted to a wider type. Reviewed-by: tonyp, jmasa, iveresov, apetrusenko ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: f9ec1e4bbb44 Author: tonyp Date: 2010-04-15 18:45 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f9ec1e4bbb44 6939027: G1: assertion failure during the concurrent phase of cleanup Summary: The outgoing region map is not maintained properly and it's causing an assert failure. Given that we don't actually use it, I'm removing it. I'm piggy-backing a small change on this which removes a message that it's printed before a Full GC when DisableExplicitGC is set. Reviewed-by: apetrusenko, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: 79e419e5ea3b Author: apetrusenko Date: 2010-04-16 08:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/79e419e5ea3b 6942253: G1: replace G1ParallelGCAllocBufferSize with YoungPLABSize and OldPLABSize Summary: Replaces the G1-specific parameter with the existing ones that are used by the other GCs (YoungPLABSize and OldPLABSize) Reviewed-by: tonyp, johnc ! 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/g1_globals.hpp Changeset: bdb5361c461c Author: kevinw Date: 2010-04-16 17:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bdb5361c461c 6897143: Stress test crashes during HeapInspection using ParallelGC. Summary: ensure_parsability() must be called even if GC_locker prevents GC. Reviewed-by: ysr, chrisphi ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: 6ecb6e6de3d6 Author: kevinw Date: 2010-04-19 05:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6ecb6e6de3d6 Merge Changeset: 1316cec51b4d Author: johnc Date: 2010-04-22 10:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1316cec51b4d 6819061: G1: eliminate serial Other times that are proportional to the collection set length 6871109: G1: remove the concept of the scan only prefix Summary: Removed scan only regions and associated code. The young portion of the collection set is now constructed incrementally - when a young region is retired as the current allocation region it is added to the collection set. Reviewed-by: apetrusenko, iveresov, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/services/g1MemoryPool.cpp Changeset: 454ff03c0daf Author: tonyp Date: 2010-04-26 18:01 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/454ff03c0daf Merge Changeset: 90acda19b80f Author: jrose Date: 2010-04-29 00:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/90acda19b80f Merge From Christian.Thalinger at Sun.COM Thu Apr 29 11:06:57 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 29 Apr 2010 18:06:57 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6829193: JSR 292 needs to support SPARC Message-ID: <20100429180701.1F99944342@hg.openjdk.java.net> Changeset: c640000b7cc1 Author: twisti Date: 2010-04-29 06:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c640000b7cc1 6829193: JSR 292 needs to support SPARC Summary: There are unimplemented portions of the hotspot code for method handles and invokedynamic specific to SPARC. Reviewed-by: kvn, never, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandles.hpp From igor.veresov at oracle.com Thu Apr 29 17:19:00 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 29 Apr 2010 17:19:00 -0700 Subject: Request for review (XXS): 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed Message-ID: <4BDA21F4.90701@oracle.com> This is for both hs17 and hs18. Webrev: http://cr.openjdk.java.net/~iveresov/6948602/webrev.00/ Thanks, igor From tom.rodriguez at oracle.com Thu Apr 29 17:21:58 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 29 Apr 2010 17:21:58 -0700 Subject: Request for review (XXS): 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed In-Reply-To: <4BDA21F4.90701@oracle.com> References: <4BDA21F4.90701@oracle.com> Message-ID: <9C3714A6-0DF7-44B0-BBAB-0622DB0AD4C8@oracle.com> Looks good. tom On Apr 29, 2010, at 5:19 PM, Igor Veresov wrote: > This is for both hs17 and hs18. > > Webrev: http://cr.openjdk.java.net/~iveresov/6948602/webrev.00/ > > Thanks, > igor From igor.veresov at oracle.com Thu Apr 29 17:27:40 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 29 Apr 2010 17:27:40 -0700 Subject: Request for review (XXS): 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed In-Reply-To: <9C3714A6-0DF7-44B0-BBAB-0622DB0AD4C8@oracle.com> References: <4BDA21F4.90701@oracle.com> <9C3714A6-0DF7-44B0-BBAB-0622DB0AD4C8@oracle.com> Message-ID: <4BDA23FC.3030709@oracle.com> Thanks, Tom! On 4/29/10 5:21 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Apr 29, 2010, at 5:19 PM, Igor Veresov wrote: > >> This is for both hs17 and hs18. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6948602/webrev.00/ >> >> Thanks, >> igor > From vladimir.kozlov at oracle.com Fri Apr 30 09:36:33 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Apr 2010 09:36:33 -0700 Subject: Request for review (XXS): 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed In-Reply-To: <4BDA21F4.90701@oracle.com> References: <4BDA21F4.90701@oracle.com> Message-ID: <4BDB0711.8010402@oracle.com> Looks good. Could you add reference to 6942326 in the comment and in the 6948602 bug report? Thanks, Vladimir Igor Veresov wrote: > This is for both hs17 and hs18. > > Webrev: http://cr.openjdk.java.net/~iveresov/6948602/webrev.00/ > > Thanks, > igor From igor.veresov at oracle.com Thu Apr 29 17:43:58 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 29 Apr 2010 17:43:58 -0700 Subject: Request for review (XXS): 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed In-Reply-To: <4BDB0711.8010402@oracle.com> References: <4BDA21F4.90701@oracle.com> <4BDB0711.8010402@oracle.com> Message-ID: <4BDA27CE.6030600@oracle.com> On 4/30/10 9:36 AM, Vladimir Kozlov wrote: > Looks good. > Thanks! > Could you add reference to 6942326 in the comment Yeah, it's actually in the bug name also. > and in the 6948602 bug report? Sure. igor > > Thanks, > Vladimir > > Igor Veresov wrote: >> This is for both hs17 and hs18. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6948602/webrev.00/ >> >> Thanks, >> igor From igor.veresov at oracle.com Thu Apr 29 19:55:02 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 30 Apr 2010 02:55:02 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed Message-ID: <20100430025504.B7819443C4@hg.openjdk.java.net> Changeset: ae8f909e5fc7 Author: iveresov Date: 2010-04-29 17:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ae8f909e5fc7 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed Summary: Disable the use of pcmpestri until it can be guaranteed that the load doesn't cross in to the uncommited space. See 6942326. Reviewed-by: never, kvn ! src/share/vm/opto/library_call.cpp From john.coomes at oracle.com Thu Apr 29 21:00:53 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:00:53 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b90 for changeset 425ba3efabbf Message-ID: <20100430040053.15FC4443DC@hg.openjdk.java.net> Changeset: 97d8b6c659c2 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/97d8b6c659c2 Added tag jdk7-b90 for changeset 425ba3efabbf ! .hgtags From john.coomes at oracle.com Thu Apr 29 21:00:55 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:00:55 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b90 for changeset 56ce07b0eb47 Message-ID: <20100430040058.74B30443DD@hg.openjdk.java.net> Changeset: bcd2fc089227 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/bcd2fc089227 Added tag jdk7-b90 for changeset 56ce07b0eb47 ! .hgtags From john.coomes at oracle.com Thu Apr 29 21:05:25 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:05:25 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b90 for changeset c5d932ee326d Message-ID: <20100430040525.554A2443DE@hg.openjdk.java.net> Changeset: b89b2c3044a2 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/b89b2c3044a2 Added tag jdk7-b90 for changeset c5d932ee326d ! .hgtags From john.coomes at oracle.com Thu Apr 29 21:05:28 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:05:28 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b90 for changeset ead7c4566a00 Message-ID: <20100430040528.6B478443DF@hg.openjdk.java.net> Changeset: cf4686bf35ab Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/cf4686bf35ab Added tag jdk7-b90 for changeset ead7c4566a00 ! .hgtags From john.coomes at oracle.com Thu Apr 29 21:07:33 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:07:33 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 37 new changesets Message-ID: <20100430041540.D11A7443E0@hg.openjdk.java.net> Changeset: 471c3c1f18d1 Author: bae Date: 2010-04-20 11:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/471c3c1f18d1 6936389: FontManager.fileCloser may cause memory leak in applets Reviewed-by: igor, prr, ant ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java + test/sun/awt/font/ClassLoaderLeakTest.java Changeset: bd5d1afc00ab Author: lana Date: 2010-04-20 16:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bd5d1afc00ab Merge Changeset: 43b8a8bc8208 Author: uta Date: 2010-04-14 15:28 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/43b8a8bc8208 6920842: Wheel events do not bubbling to the browser if they was not treated in applet. Reviewed-by: art, anthony, peterz ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java Changeset: ba8ecdbf0b88 Author: lana Date: 2010-04-15 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ba8ecdbf0b88 Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: f51dc9fc72d3 Author: lana Date: 2010-04-20 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f51dc9fc72d3 Merge Changeset: b48c141258e1 Author: peytoia Date: 2010-04-13 13:47 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b48c141258e1 6709938: RFE: Support more scripts in JDK logical fonts using new fonts in Windows XP and later. Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 98359a01cbe0 Author: okutsu Date: 2010-04-14 13:53 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/98359a01cbe0 6941948: NumaricShaper.shape() doesn't work with NumericShaper.Range.EASTERN_ARABIC Reviewed-by: peytoia ! src/share/classes/java/awt/font/NumericShaper.java + test/java/awt/font/NumericShaper/EasternArabicTest.java Changeset: 4d8b1b04544c Author: lana Date: 2010-04-15 11:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4d8b1b04544c Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java ! src/windows/classes/sun/awt/windows/fontconfig.properties - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: 17d17234a1d9 Author: okutsu Date: 2010-04-16 15:53 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/17d17234a1d9 6609675: [Fmt-Da] DateFormat.parse() on a timezone changes its calendar's timezone Reviewed-by: peytoia ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/SimpleDateFormat.java Changeset: f75f5e2274d5 Author: rupashka Date: 2010-04-16 13:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f75f5e2274d5 6922179: SynthTextPaneUI.installUI() doesn't set component to opaque as specified Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java Changeset: 584dcb7ecaf9 Author: naoto Date: 2010-04-19 14:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/584dcb7ecaf9 6943941: Rebranding issues with some tests in jdk/test/java/util Reviewed-by: ohair ! test/java/util/Locale/Bug4175998Test.java ! test/java/util/ResourceBundle/Bug4083270Test.java ! test/java/util/ResourceBundle/Bug4165815Test.java ! test/java/util/ResourceBundle/Bug4168625Class.java ! test/java/util/ResourceBundle/Bug4168625Getter.java ! test/java/util/ResourceBundle/Bug4168625Resource.java ! test/java/util/ResourceBundle/Bug4168625Resource2.java ! test/java/util/ResourceBundle/Bug4168625Resource2_en_US.java ! test/java/util/ResourceBundle/Bug4168625Resource3.java ! test/java/util/ResourceBundle/Bug4168625Resource3_en.java ! test/java/util/ResourceBundle/Bug4168625Resource3_en_CA.java ! test/java/util/ResourceBundle/Bug4168625Resource3_en_IE.java ! test/java/util/ResourceBundle/Bug4168625Resource3_en_US.java ! test/java/util/ResourceBundle/Bug4177489Test.java ! test/java/util/ResourceBundle/Bug4177489_Resource.java ! test/java/util/ResourceBundle/Bug4177489_Resource_jf.java Changeset: 2571720800a6 Author: peytoia Date: 2010-04-20 15:01 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2571720800a6 6945238: (tz) Support tzdata2010i Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/southamerica Changeset: 0d9662f62d0d Author: lana Date: 2010-04-20 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0d9662f62d0d Merge Changeset: 710c4493902f Author: mullan Date: 2010-04-09 07:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/710c4493902f 6909281: 6u19 b99(pit):Error loading first applet in browser session( both FF && IE, windows ): NPE is thrown Summary: Fix for 6633872 causes NPE due to uninitialised ProtectionDomain class Reviewed-by: andrew ! src/share/classes/sun/misc/SharedSecrets.java Changeset: 89f4ec9e4b33 Author: xuelei Date: 2010-04-10 09:13 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/89f4ec9e4b33 6941936: Broken pipe error of test case DNSIdentities.java Reviewed-by: chegar ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java Changeset: 507cd94489e7 Author: sherman Date: 2010-04-12 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/507cd94489e7 6942707: nwe Big5.map for HKSCS2008 missed 5 codepoints Summary: updated the Big5.map table to add 5 entries Reviewed-by: okutsu - make/tools/CharsetMapping/Big5.c2b ! make/tools/CharsetMapping/Big5.map Changeset: 6b641c576e77 Author: valeriep Date: 2010-04-07 17:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6b641c576e77 6918573: sun.security.pkcs11.P11RSACipher.finalize() is a scalability blocker Summary: Removed the finalize() methods and use PhantomReference in Session to do auto clean up. Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/Session.java ! src/share/classes/sun/security/pkcs11/SessionManager.java Changeset: a45217204978 Author: valeriep Date: 2010-04-12 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a45217204978 Merge - make/tools/CharsetMapping/Big5.c2b Changeset: 1672f0212f02 Author: chegar Date: 2010-04-13 12:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1672f0212f02 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String Reviewed-by: alanb, michaelm, andrew ! src/share/classes/java/net/NetworkInterface.java Changeset: ed61accf772e Author: chegar Date: 2010-04-15 16:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ed61accf772e 6943219: test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java fail in linux Reviewed-by: andrew ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java Changeset: c70d4266d474 Author: sherman Date: 2010-04-15 17:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c70d4266d474 6931676: TEST_BUG: wrong value for bugid in comments Summary: update to the correct bugid Reviewed-by: martin ! test/java/util/regex/RegExTest.java Changeset: db4fd2fdf196 Author: weijun Date: 2010-04-16 10:06 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/db4fd2fdf196 6937978: let keytool -gencert generate the chain Reviewed-by: mullan ! src/share/classes/sun/security/tools/KeyTool.java ! test/sun/security/tools/keytool/selfissued.sh Changeset: 0d989dc383d3 Author: weijun Date: 2010-04-16 10:13 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0d989dc383d3 6939248: Jarsigner can't extract Extended Key Usage from Timestamp Reply correctly Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/tools/TimestampedSigner.java + test/sun/security/tools/jarsigner/TimestampCheck.java + test/sun/security/tools/jarsigner/ts.sh Changeset: c444651077d2 Author: andrew Date: 2010-04-16 09:54 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c444651077d2 6944361: Missing CKR_ values in PKCS11Exception Summary: Allow native NSS errors to be observed and correctly reported Reviewed-by: wetmore, valeriep ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java ! src/share/classes/sun/security/x509/X509Key.java Changeset: 7ecc023957d8 Author: lana Date: 2010-04-17 08:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7ecc023957d8 Merge Changeset: 97fb6f6d230a Author: weijun Date: 2010-04-20 19:30 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/97fb6f6d230a 6944847: native gss lib names on linux Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java + test/sun/security/krb5/Krb5NameEquals.java + test/sun/security/krb5/runNameEquals.sh Changeset: d8ad2da3ecf3 Author: wetmore Date: 2010-04-20 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d8ad2da3ecf3 6945604: wrong error message in CardImpl.java Reviewed-by: mullan ! src/share/classes/sun/security/smartcardio/CardImpl.java Changeset: 884df20e9cce Author: lana Date: 2010-04-20 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/884df20e9cce Merge - make/tools/CharsetMapping/Big5.c2b Changeset: 9bf334e32d35 Author: yhuang Date: 2010-01-21 22:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9bf334e32d35 6916787: Ukrainian currency name needs to be fixed Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 00890dd53f45 Author: yhuang Date: 2010-01-27 23:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/00890dd53f45 6919624: minimalDaysInFirstWeek ressource for hungarian is wrong Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/CalendarData_hu.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 0173ef08dcc8 Author: yhuang Date: 2010-02-11 20:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0173ef08dcc8 6776102: sun/util/resources/TimeZone/Bug6317929.java test failed against 6u12b01 and passed against 6u11b03 Reviewed-by: yhuang, peytoia ! test/sun/util/resources/TimeZone/Bug6317929.java Changeset: b2485d8eba40 Author: yhuang Date: 2010-04-11 21:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b2485d8eba40 Merge - make/java/redist/FILES.gmk - make/java/text/FILES_java.gmk - make/sun/nio/FILES_java.gmk - src/share/classes/sun/dyn/util/BytecodeSignature.java - src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java Changeset: babd3f260d32 Author: yhuang Date: 2010-04-11 23:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/babd3f260d32 6875904: Java 7 message synchronization 1 Reviewed-by: ogino, faryad ! make/sun/launcher/Makefile ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties + src/share/classes/sun/launcher/resources/launcher_de.properties + src/share/classes/sun/launcher/resources/launcher_es.properties + src/share/classes/sun/launcher/resources/launcher_fr.properties + src/share/classes/sun/launcher/resources/launcher_it.properties + src/share/classes/sun/launcher/resources/launcher_ja.properties + src/share/classes/sun/launcher/resources/launcher_ko.properties + src/share/classes/sun/launcher/resources/launcher_sv.properties + src/share/classes/sun/launcher/resources/launcher_zh_CN.properties + src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_de.java ! src/share/classes/sun/security/util/AuthResources_es.java ! src/share/classes/sun/security/util/AuthResources_fr.java ! src/share/classes/sun/security/util/AuthResources_it.java ! src/share/classes/sun/security/util/AuthResources_ja.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/security/util/AuthResources_sv.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java Changeset: 7794a4a38e99 Author: yhuang Date: 2010-04-20 01:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7794a4a38e99 Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: b5ae88dd3dbd Author: mikejwre Date: 2010-04-28 20:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b5ae88dd3dbd Merge Changeset: ab117ded3e3f Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ab117ded3e3f Added tag jdk7-b90 for changeset 7f90d0b9dbb7 ! .hgtags Changeset: 08a31cab971f Author: mikejwre Date: 2010-04-29 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/08a31cab971f Merge - make/tools/CharsetMapping/Big5.c2b From john.coomes at oracle.com Thu Apr 29 21:27:06 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:27:06 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 9 new changesets Message-ID: <20100430042725.D2468443E2@hg.openjdk.java.net> Changeset: 96072ad00783 Author: jjg Date: 2010-04-09 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/96072ad00783 6942649: add hidden option to identify location and version of javac classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javac/T6942649.java Changeset: 396b117c1743 Author: mcimadamore Date: 2010-04-14 12:23 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/396b117c1743 6939618: Revert 'simple' diamond implementation Summary: backout changeset for 6840638 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.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/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java - test/tools/javac/generics/diamond/neg/Neg01.java - test/tools/javac/generics/diamond/neg/Neg01.out - test/tools/javac/generics/diamond/neg/Neg02.java - test/tools/javac/generics/diamond/neg/Neg02.out - test/tools/javac/generics/diamond/neg/Neg03.java - test/tools/javac/generics/diamond/neg/Neg03.out - test/tools/javac/generics/diamond/neg/Neg04.java - test/tools/javac/generics/diamond/neg/Neg04.out - test/tools/javac/generics/diamond/neg/Neg05.java - test/tools/javac/generics/diamond/neg/Neg05.out - test/tools/javac/generics/diamond/pos/Pos01.java - test/tools/javac/generics/diamond/pos/Pos02.java - test/tools/javac/generics/diamond/pos/Pos03.java - test/tools/javac/generics/diamond/pos/Pos04.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java Changeset: 9d9d08922405 Author: mcimadamore Date: 2010-04-14 12:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/9d9d08922405 6939620: Switch to 'complex' diamond inference scheme Summary: Implement new inference scheme for diamond operator that takes into account type of actual arguments supplied to constructor Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.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/Resolve.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/6840059/T6840059.out + test/tools/javac/generics/diamond/neg/Neg01.java + test/tools/javac/generics/diamond/neg/Neg01.out + test/tools/javac/generics/diamond/neg/Neg02.java + test/tools/javac/generics/diamond/neg/Neg02.out + test/tools/javac/generics/diamond/neg/Neg03.java + test/tools/javac/generics/diamond/neg/Neg03.out + test/tools/javac/generics/diamond/neg/Neg04.java + test/tools/javac/generics/diamond/neg/Neg04.out + test/tools/javac/generics/diamond/neg/Neg05.java + test/tools/javac/generics/diamond/neg/Neg05.out + test/tools/javac/generics/diamond/neg/Neg06.java + test/tools/javac/generics/diamond/neg/Neg06.out + test/tools/javac/generics/diamond/neg/Neg07.java + test/tools/javac/generics/diamond/neg/Neg07.out + test/tools/javac/generics/diamond/neg/Neg08.java + test/tools/javac/generics/diamond/neg/Neg08.out + test/tools/javac/generics/diamond/neg/Neg09.java + test/tools/javac/generics/diamond/neg/Neg09.out + test/tools/javac/generics/diamond/neg/Neg10.java + test/tools/javac/generics/diamond/neg/Neg10.out + test/tools/javac/generics/diamond/neg/Neg11.java + test/tools/javac/generics/diamond/neg/Neg11.out + test/tools/javac/generics/diamond/pos/Pos01.java + test/tools/javac/generics/diamond/pos/Pos02.java + test/tools/javac/generics/diamond/pos/Pos03.java + test/tools/javac/generics/diamond/pos/Pos04.java + test/tools/javac/generics/diamond/pos/Pos05.java Changeset: 37fa8cd046ab Author: lana Date: 2010-04-17 08:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/37fa8cd046ab Merge Changeset: 06e06ec0d6f2 Author: yhuang Date: 2010-04-11 23:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/06e06ec0d6f2 6875904: Java 7 message synchronization 1 Reviewed-by: ogino, faryad ! src/share/classes/com/sun/tools/apt/resources/apt_ja.properties ! src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties Changeset: 053bf290d575 Author: yhuang Date: 2010-04-20 01:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/053bf290d575 Merge - test/tools/javap/T6305779.java Changeset: b68de5eee27b Author: mikejwre Date: 2010-04-28 20:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b68de5eee27b Merge Changeset: ebf79cbf5711 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ebf79cbf5711 Added tag jdk7-b90 for changeset 71c2c23a7c35 ! .hgtags Changeset: 97b6fa97b8dd Author: mikejwre Date: 2010-04-29 14:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/97b6fa97b8dd Merge ! test/tools/javac/generics/diamond/neg/Neg01.java ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.java ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.java ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.java ! test/tools/javac/generics/diamond/neg/Neg04.out ! test/tools/javac/generics/diamond/neg/Neg05.java ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/pos/Pos01.java ! test/tools/javac/generics/diamond/pos/Pos02.java ! test/tools/javac/generics/diamond/pos/Pos03.java ! test/tools/javac/generics/diamond/pos/Pos04.java From john.coomes at oracle.com Fri Apr 30 01:58:37 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 08:58:37 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b91 for changeset 97d8b6c659c2 Message-ID: <20100430085837.2F53044467@hg.openjdk.java.net> Changeset: 5f5c33d417f3 Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/5f5c33d417f3 Added tag jdk7-b91 for changeset 97d8b6c659c2 ! .hgtags From john.coomes at oracle.com Fri Apr 30 01:58:40 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 08:58:40 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b91 for changeset bcd2fc089227 Message-ID: <20100430085841.4DE5944468@hg.openjdk.java.net> Changeset: 930582f667a1 Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/930582f667a1 Added tag jdk7-b91 for changeset bcd2fc089227 ! .hgtags From john.coomes at oracle.com Fri Apr 30 02:01:33 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 09:01:33 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b91 for changeset b89b2c3044a2 Message-ID: <20100430090133.ADEAE44469@hg.openjdk.java.net> Changeset: e6a40e4bb104 Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/e6a40e4bb104 Added tag jdk7-b91 for changeset b89b2c3044a2 ! .hgtags From john.coomes at oracle.com Fri Apr 30 02:01:36 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 09:01:36 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b91 for changeset cf4686bf35ab Message-ID: <20100430090136.948964446A@hg.openjdk.java.net> Changeset: df7c033f6a11 Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/df7c033f6a11 Added tag jdk7-b91 for changeset cf4686bf35ab ! .hgtags From john.coomes at oracle.com Fri Apr 30 02:01:41 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 09:01:41 +0000 Subject: hg: jdk7/hotspot-comp/jdk: Added tag jdk7-b91 for changeset 08a31cab971f Message-ID: <20100430090200.1FB204446B@hg.openjdk.java.net> Changeset: f2dce7210cc0 Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f2dce7210cc0 Added tag jdk7-b91 for changeset 08a31cab971f ! .hgtags From john.coomes at oracle.com Fri Apr 30 02:04:52 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 09:04:52 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b91 for changeset 97b6fa97b8dd Message-ID: <20100430090455.AD8EA4446C@hg.openjdk.java.net> Changeset: 98cba5876cb5 Author: mikejwre Date: 2010-04-29 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/98cba5876cb5 Added tag jdk7-b91 for changeset 97b6fa97b8dd ! .hgtags From Christian.Thalinger at Sun.COM Fri Apr 30 04:28:49 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 30 Apr 2010 13:28:49 +0200 Subject: Review Request: Zero JNI handles fix In-Reply-To: <20100422111447.GD4039@redhat.com> References: <20100329152453.GB3421@redhat.com> <1269942726.982.129.camel@macbook> <4BB202CA.9040202@oracle.com> <20100330145920.GD3617@redhat.com> <20100420084023.GB3510@redhat.com> <20100422111447.GD4039@redhat.com> Message-ID: <1272626929.920.13.camel@macbook> On Thu, 2010-04-22 at 12:14 +0100, Gary Benson wrote: > > I've reworked the fix: > > > > http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix-2/ > > > > last_Java_sp() now returns the actual Zero stack pointer. The frame > > anchor has a new last_Java_fp field that stores the value previously > > stored in last_Java_sp, in much the same way as the x86 port does. > > > > Note that the code in frame_zero.* already stored both these values, > > but with the names confusingly reversed. I have unreversed them in > > this webrev. I have also changed the type of the frame pointer be a > > ZeroFrame* -- leaving the stack pointer as an intptr_t* -- to help > > ensure that everything gets the arguments in the right order. > > A minor update: > > http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix-3/ I assume the changes work as you have (hopefully) tested them. Since it only touches Zero files, I'd say the changes are OK. I will push it. I also add Keith as reviewer. -- Christian From Christian.Thalinger at Sun.COM Fri Apr 30 06:31:19 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 30 Apr 2010 13:31:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6939182: Zero JNI handles fix Message-ID: <20100430133123.4E77C444D3@hg.openjdk.java.net> Changeset: 0c5b3cf3c1f5 Author: twisti Date: 2010-04-30 04:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0c5b3cf3c1f5 6939182: Zero JNI handles fix Summary: Zero will exit with an error when invoked with -Xcheck:jni. Reviewed-by: twisti, kamg Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/javaFrameAnchor_zero.hpp ! src/cpu/zero/vm/stack_zero.cpp ! src/cpu/zero/vm/stack_zero.hpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp From Christian.Thalinger at Sun.COM Fri Apr 30 10:38:55 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 30 Apr 2010 17:38:55 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6943304: remove tagged stack interpreter Message-ID: <20100430173857.3B36E4452F@hg.openjdk.java.net> Changeset: 2338d41fbd81 Author: twisti Date: 2010-04-30 08:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2338d41fbd81 6943304: remove tagged stack interpreter Reviewed-by: coleenp, never, gbenson ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/methodHandles_x86.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/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/interpreter_zero.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp