From aleksey.shipilev at oracle.com Mon Dec 3 14:20:32 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 04 Dec 2012 02:20:32 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics Message-ID: <50BD25B0.2060501@oracle.com> (submitting this on behalf of Doug Lea) Hi, Please see the preliminary webrev for changes associated with JEP 171 aka Fences [1]. The webrev is here: http://shipilev.net/pub/jdk/hotspot/fences/webrev-1/ Testing: - built and tested on Linux x86_64 - java-concurrency-torture [2] fences tests [3] passes on Linux x86_64 - looking through generated assembly for torture tests Please review the code changes while this thing flies through JPRT and JEP is being "funded". Thanks, Aleksey. [1] http://openjdk.java.net/jeps/171 [2] https://github.com/shipilev/java-concurrency-torture [3] java -jar concurrency-torture.jar -t ".*fences.*" From aleksey.shipilev at oracle.com Mon Dec 3 14:36:34 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 04 Dec 2012 02:36:34 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family Message-ID: <50BD2972.4090603@oracle.com> (again, submitting on behalf of Doug Lea) Hi, This simple change is missing from recently committed CR 7023898. While the VM support is there in Hotspot, no methods are exposed in Unsafe to actually make use of those intrinsics. This is the webrev fixing that: http://shipilev.net/pub/jdk/hotspot/unsafe-getandadd/webrev-1/ Testing: - Built and tested in Linux x86_64 - Doug had provided the AtomicIntegerV8 [1] version making use of this new code, extensively tested on his platforms - java-concurrency-torture [2] atomicity tests [3] are passed for AtomicIntegerV8 on my and Doug's platforms - no other testing is expected for this trivial change. I would need a sponsor to push this change. Thanks, Aleksey. [1] https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/java/util/concurrent/atomic/AtomicIntegerV8.java [2] https://github.com/shipilev/java-concurrency-torture/ [3] https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java From vitalyd at gmail.com Mon Dec 3 14:40:32 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 3 Dec 2012 17:40:32 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BD25B0.2060501@oracle.com> References: <50BD25B0.2060501@oracle.com> Message-ID: Hi Aleksey, Why not have a bit more fine grained methods? OrderAccess in the VM has operations matching JMM wording: loadload, storestore, loadstore, storeload. So maybe have those + the ones you already put. Since this is an "experts only" API I think giving access to all combos would be good. Sent from my phone On Dec 3, 2012 5:21 PM, "Aleksey Shipilev" wrote: > (submitting this on behalf of Doug Lea) > > Hi, > > Please see the preliminary webrev for changes associated with JEP 171 > aka Fences [1]. The webrev is here: > http://shipilev.net/pub/jdk/hotspot/fences/webrev-1/ > > Testing: > - built and tested on Linux x86_64 > - java-concurrency-torture [2] fences tests [3] passes on Linux x86_64 > - looking through generated assembly for torture tests > > Please review the code changes while this thing flies through JPRT and > JEP is being "funded". > > Thanks, > Aleksey. > > [1] http://openjdk.java.net/jeps/171 > [2] https://github.com/shipilev/java-concurrency-torture > [3] java -jar concurrency-torture.jar -t ".*fences.*" > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121203/faab3a64/attachment.html From aleksey.shipilev at oracle.com Mon Dec 3 14:42:03 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 04 Dec 2012 02:42:03 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50BD2972.4090603@oracle.com> References: <50BD2972.4090603@oracle.com> Message-ID: <50BD2ABB.30703@oracle.com> (I should have CC'ed Doug on this, doing now). -Aleksey. On 12/04/2012 02:36 AM, Aleksey Shipilev wrote: > (again, submitting on behalf of Doug Lea) > > Hi, > > This simple change is missing from recently committed CR 7023898. While > the VM support is there in Hotspot, no methods are exposed in Unsafe to > actually make use of those intrinsics. This is the webrev fixing that: > http://shipilev.net/pub/jdk/hotspot/unsafe-getandadd/webrev-1/ > > Testing: > - Built and tested in Linux x86_64 > - Doug had provided the AtomicIntegerV8 [1] version making use of this > new code, extensively tested on his platforms > - java-concurrency-torture [2] atomicity tests [3] are passed for > AtomicIntegerV8 on my and Doug's platforms > - no other testing is expected for this trivial change. > > I would need a sponsor to push this change. > > Thanks, > Aleksey. > > [1] > https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/java/util/concurrent/atomic/AtomicIntegerV8.java > [2] https://github.com/shipilev/java-concurrency-torture/ > [3] > https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java > From christian.thalinger at oracle.com Mon Dec 3 14:49:54 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 3 Dec 2012 14:49:54 -0800 Subject: RFR (XXS): 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 Message-ID: <2E38B5E9-40EB-4142-9FF5-66F71F476964@oracle.com> http://cr.openjdk.java.net/~twisti/8004319 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 Reviewed-by: The problem are root compiles which need to be intrinsified. Currently there is only one method that has this property: java.lang.ref.Reference.get() The fix is to detect root compiles in LibraryCallKit::LibraryCallKit and set _reexecute_sp to sp(). src/share/vm/opto/library_call.cpp From Vladimir.Kozlov at oracle.com Mon Dec 3 15:05:42 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 03 Dec 2012 15:05:42 -0800 Subject: RFR (XXS): 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 In-Reply-To: <2E38B5E9-40EB-4142-9FF5-66F71F476964@oracle.com> References: <2E38B5E9-40EB-4142-9FF5-66F71F476964@oracle.com> Message-ID: <50BD3046.9090302@oracle.com> Good. Vladimir On 12/03/12 14:49, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8004319 > > 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 > Reviewed-by: > > The problem are root compiles which need to be intrinsified. > Currently there is only one method that has this property: > java.lang.ref.Reference.get() > > The fix is to detect root compiles in LibraryCallKit::LibraryCallKit > and set _reexecute_sp to sp(). > > src/share/vm/opto/library_call.cpp > From christian.thalinger at oracle.com Mon Dec 3 15:10:15 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 3 Dec 2012 15:10:15 -0800 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BD25B0.2060501@oracle.com> References: <50BD25B0.2060501@oracle.com> Message-ID: <7617DBAF-43DC-4574-9AFC-EB2D9AE6E1BD@oracle.com> On Dec 3, 2012, at 2:20 PM, Aleksey Shipilev wrote: > (submitting this on behalf of Doug Lea) > > Hi, > > Please see the preliminary webrev for changes associated with JEP 171 > aka Fences [1]. The webrev is here: > http://shipilev.net/pub/jdk/hotspot/fences/webrev-1/ src/share/vm/opto/library_call.cpp: You should pass the intrinsic_id down to inline_unsafe_fence like we do for inline_fp_conversions. All these boolean arguments are only confusing. -- Chris > > Testing: > - built and tested on Linux x86_64 > - java-concurrency-torture [2] fences tests [3] passes on Linux x86_64 > - looking through generated assembly for torture tests > > Please review the code changes while this thing flies through JPRT and > JEP is being "funded". > > Thanks, > Aleksey. > > [1] http://openjdk.java.net/jeps/171 > [2] https://github.com/shipilev/java-concurrency-torture > [3] java -jar concurrency-torture.jar -t ".*fences.*" From aleksey.shipilev at oracle.com Mon Dec 3 15:12:46 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 04 Dec 2012 03:12:46 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <7617DBAF-43DC-4574-9AFC-EB2D9AE6E1BD@oracle.com> References: <50BD25B0.2060501@oracle.com> <7617DBAF-43DC-4574-9AFC-EB2D9AE6E1BD@oracle.com> Message-ID: <50BD31EE.3050405@oracle.com> On 12/04/2012 03:10 AM, Christian Thalinger wrote: >> Please see the preliminary webrev for changes associated with JEP >> 171 aka Fences [1]. The webrev is here: >> http://shipilev.net/pub/jdk/hotspot/fences/webrev-1/ > > src/share/vm/opto/library_call.cpp: > > You should pass the intrinsic_id down to inline_unsafe_fence like we > do for inline_fp_conversions. All these boolean arguments are only > confusing. Fair enough. Thanks for the review! I will wait for more reviews and update the webrev. -Aleksey. From christian.thalinger at oracle.com Mon Dec 3 15:27:04 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 3 Dec 2012 15:27:04 -0800 Subject: RFR (XXS): 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 In-Reply-To: <50BD3046.9090302@oracle.com> References: <2E38B5E9-40EB-4142-9FF5-66F71F476964@oracle.com> <50BD3046.9090302@oracle.com> Message-ID: Thank you, Vladimir. -- Chris On Dec 3, 2012, at 3:05 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 12/03/12 14:49, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8004319 >> >> 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 >> Reviewed-by: >> >> The problem are root compiles which need to be intrinsified. >> Currently there is only one method that has this property: >> java.lang.ref.Reference.get() >> >> The fix is to detect root compiles in LibraryCallKit::LibraryCallKit >> and set _reexecute_sp to sp(). >> >> src/share/vm/opto/library_call.cpp >> From dl at cs.oswego.edu Mon Dec 3 15:57:10 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 03 Dec 2012 18:57:10 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> Message-ID: <50BD3C56.6070200@cs.oswego.edu> On 12/03/12 17:40, Vitaly Davidovich wrote: > Hi Aleksey, > > Why not have a bit more fine grained methods? OrderAccess in the VM has > operations matching JMM wording: loadload, storestore, loadstore, storeload. By convention these days, in sparc-ese, "loadFence" => LOAD_LOAD|LOAD_STORE "storeFence" => STORE_STORE|LOAD_STORE "fullFence" => STORE_LOAD|LOAD_LOAD|STORE_STORE|LOAD_STORE Which maps exactly to internals in hotspot, and other VMs, and most processors(*) and to the non-exotic C11/C++11 modes. So there's nothing else you'd be tempted to support. (*) except, famously, POWER and pre-ARMV8/ARM64 ARM, which are always a bit of an adventure to map. Luckily, upcoming ARMV8 is a breeze though. -Doug From dl at cs.oswego.edu Mon Dec 3 16:00:10 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 03 Dec 2012 19:00:10 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BD31EE.3050405@oracle.com> References: <50BD25B0.2060501@oracle.com> <7617DBAF-43DC-4574-9AFC-EB2D9AE6E1BD@oracle.com> <50BD31EE.3050405@oracle.com> Message-ID: <50BD3D0A.4090206@cs.oswego.edu> On 12/03/12 18:12, Aleksey Shipilev wrote: > On 12/04/2012 03:10 AM, Christian Thalinger wrote: >>> Please see the preliminary webrev for changes associated with JEP >>> 171 aka Fences [1]. The webrev is here: >>> http://shipilev.net/pub/jdk/hotspot/fences/webrev-1/ >> >> src/share/vm/opto/library_call.cpp: >> >> You should pass the intrinsic_id down to inline_unsafe_fence like we >> do for inline_fp_conversions. All these boolean arguments are only >> confusing. > > Fair enough. Thanks for the review! I will wait for more reviews and > update the webrev. > Yes, thanks Christian. The use of ids simplifies this simple set of patches a little bit more. -Doug From vitalyd at gmail.com Mon Dec 3 16:45:41 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 3 Dec 2012 19:45:41 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BD3C56.6070200@cs.oswego.edu> References: <50BD25B0.2060501@oracle.com> <50BD3C56.6070200@cs.oswego.edu> Message-ID: Hi Doug, I was primarily thinking of storestore - on archs where stores and loads can be ordered orthogonally (and can be reordered architecturally), the additional loadstore in storeFence would be unnecessary (I.e. caller only wants storestore), no? If you think load, store, and full fence is all that's required, then OK. Thanks Sent from my phone On Dec 3, 2012 6:57 PM, "Doug Lea"
wrote: > On 12/03/12 17:40, Vitaly Davidovich wrote: > >> Hi Aleksey, >> >> Why not have a bit more fine grained methods? OrderAccess in the VM has >> operations matching JMM wording: loadload, storestore, loadstore, >> storeload. >> > > By convention these days, in sparc-ese, > "loadFence" => LOAD_LOAD|LOAD_STORE > "storeFence" => STORE_STORE|LOAD_STORE > "fullFence" => STORE_LOAD|LOAD_LOAD|STORE_**STORE|LOAD_STORE > > Which maps exactly to internals in hotspot, and other VMs, > and most processors(*) and to the non-exotic C11/C++11 modes. > So there's nothing else you'd be tempted to support. > > (*) except, famously, POWER and pre-ARMV8/ARM64 ARM, which > are always a bit of an adventure to map. Luckily, upcoming > ARMV8 is a breeze though. > > -Doug > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121203/283afe40/attachment.html From dl at cs.oswego.edu Mon Dec 3 16:57:48 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 03 Dec 2012 19:57:48 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <50BD3C56.6070200@cs.oswego.edu> Message-ID: <50BD4A8C.9030608@cs.oswego.edu> On 12/03/12 19:45, Vitaly Davidovich wrote: > Hi Doug, > > I was primarily thinking of storestore - on archs where stores and loads can be > ordered orthogonally (and can be reordered architecturally), the additional > loadstore in storeFence would be unnecessary (I.e. caller only wants > storestore), no? Yes. But by combining the boring essentially-free LOAD_STORE with STORE_STORE, you avoid some anomalies when it does arise, with no interesting effect in the normal use cases. (Hans Boehm once had a couple of examples of why you want this at http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/ but I don't seem them there at the moment.) One could argue to call these "acquireFence, "releaseFence" and "volatileFence", just like hotspot does internally. But experiences in several of the periodic discussions about introducing Java-level versions (poke around http://cs.oswego.edu/pipermail/concurrency-interest/) led me to believe that more neutral names are less prone to misunderstanding. -Doug > > If you think load, store, and full fence is all that's required, then OK. > > Thanks > > Sent from my phone > > On Dec 3, 2012 6:57 PM, "Doug Lea"
> > wrote: > > On 12/03/12 17:40, Vitaly Davidovich wrote: > > Hi Aleksey, > > Why not have a bit more fine grained methods? OrderAccess in the VM has > operations matching JMM wording: loadload, storestore, loadstore, storeload. > > > By convention these days, in sparc-ese, > "loadFence" => LOAD_LOAD|LOAD_STORE > "storeFence" => STORE_STORE|LOAD_STORE > "fullFence" => STORE_LOAD|LOAD_LOAD|STORE___STORE|LOAD_STORE > > Which maps exactly to internals in hotspot, and other VMs, > and most processors(*) and to the non-exotic C11/C++11 modes. > So there's nothing else you'd be tempted to support. > > (*) except, famously, POWER and pre-ARMV8/ARM64 ARM, which > are always a bit of an adventure to map. Luckily, upcoming > ARMV8 is a breeze though. > > -Doug > > > From christian.thalinger at oracle.com Mon Dec 3 18:01:08 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 04 Dec 2012 02:01:08 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 Message-ID: <20121204020113.6117C47D09@hg.openjdk.java.net> Changeset: dd38cfd12c3a Author: twisti Date: 2012-12-03 15:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dd38cfd12c3a 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 Reviewed-by: kvn, johnc ! src/share/vm/opto/library_call.cpp From nils.eliasson at oracle.com Tue Dec 4 03:06:54 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 04 Dec 2012 12:06:54 +0100 Subject: RFR(S): 8003983 Fix of broken logcompilation tool In-Reply-To: <50B3C33A.8090109@oracle.com> References: <50B384EB.4030207@oracle.com> <50B3C33A.8090109@oracle.com> Message-ID: <50BDD94E.8020900@oracle.com> Thanks Vladimir! I think I need a second review. Anyone? //Nils Vladimir Kozlov skrev 2012-11-26 20:30: > Looks good. > > Thanks, > Vladimir > > On 11/26/12 07:04, Nils Eliasson wrote: >> Fixing LogCompilation tool so that I can do my own additions later. >> >> Includes fixes for: >> c1 missing parse tag that is required to surround method tag >> c1 call tag requires count attribute >> c1 phase tag requires nodes (set to zero since there is no nodes concept >> in c1) >> Method tag must handle missing bytes, iicount and flags attributes when >> unloading=1 is set >> Wrong description in help for '-n'. >> >> http://cr.openjdk.java.net/~neliasso/8003983/webrev.01/ >> >> Tested with running HelloDate on tiered with -Xcomp. Will add this as >> jtreg test separately. >> >> Thanks, >> Nils Eliasson From dl at cs.oswego.edu Tue Dec 4 04:35:44 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 04 Dec 2012 07:35:44 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BD31EE.3050405@oracle.com> References: <50BD25B0.2060501@oracle.com> <7617DBAF-43DC-4574-9AFC-EB2D9AE6E1BD@oracle.com> <50BD31EE.3050405@oracle.com> Message-ID: <50BDEE20.8010900@cs.oswego.edu> Footnote: A minor difference between the implementation and the sketch I wrote up in JEP171 is that, while writing JEP171, I hadn't completely checked whether just MemBarVolatile without a MemBarAcquire suffices for c2 internals dealing with loads. But I now, have, and it does. For the only interesting case, see Block::schedule_local (in lcm.cpp)] that does the right thing here by checking for either kind of fence. So inline_unsafe_fence need not generate MemBarAcquire for fullFence. -Doug From aleksey.shipilev at oracle.com Tue Dec 4 07:24:13 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 04 Dec 2012 19:24:13 +0400 Subject: RFR (S) #2: CR 8004318/JEP 171: Fences intrinsics Message-ID: <50BE159D.30306@oracle.com> Hi, This is the updated webrev for Fences intrinsics [1]: http://shipilev.net/pub/jdk/hotspot/fences/webrev-2/ It includes the review fixes from Christian. Testing: - built and tested in Linux x86_64 - java-concurrency-torture [2] Fences tests [3] are passing - JPRT passes on all platforms, with no regressions [*] I think this patch is ready for the inclusion, and we need a sponsor for it. Original JEP still needs to be pushed to "Funded" state in order to get clearance for push though. -Aleksey. [1] http://openjdk.java.net/jeps/171 [2] https://github.com/shipilev/java-concurrency-torture [3] java -jar concurrency-torture.jar -t ".*fences.*" [*] There is a single unrelated failure, which is reproduced on clean hotspot-comp build as well (langtools/DefaultMethodRegressionTests) From bharadwaj.yadavalli at oracle.com Tue Dec 4 08:10:45 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Tue, 04 Dec 2012 11:10:45 -0500 Subject: RFR(S): 8003983 Fix of broken logcompilation tool In-Reply-To: <50BDD94E.8020900@oracle.com> References: <50B384EB.4030207@oracle.com> <50B3C33A.8090109@oracle.com> <50BDD94E.8020900@oracle.com> Message-ID: <50BE2085.1040006@oracle.com> Not sure if my review counts (I am an "author" buy not a "committer"), but the changes look good to me as well. Bharadwaj On 12/4/2012 6:06 AM, Nils Eliasson wrote: > Thanks Vladimir! > > I think I need a second review. Anyone? > > //Nils > > Vladimir Kozlov skrev 2012-11-26 20:30: >> Looks good. >> >> Thanks, >> Vladimir >> >> On 11/26/12 07:04, Nils Eliasson wrote: >>> Fixing LogCompilation tool so that I can do my own additions later. >>> >>> Includes fixes for: >>> c1 missing parse tag that is required to surround method tag >>> c1 call tag requires count attribute >>> c1 phase tag requires nodes (set to zero since there is no nodes >>> concept >>> in c1) >>> Method tag must handle missing bytes, iicount and flags attributes when >>> unloading=1 is set >>> Wrong description in help for '-n'. >>> >>> http://cr.openjdk.java.net/~neliasso/8003983/webrev.01/ >>> >>> Tested with running HelloDate on tiered with -Xcomp. Will add this as >>> jtreg test separately. >>> >>> Thanks, >>> Nils Eliasson > From volker.simonis at gmail.com Tue Dec 4 08:33:36 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 4 Dec 2012 17:33:36 +0100 Subject: RFR(S): 7147740: add assertions to check stack alignment on VM entry from generated code (x64) In-Reply-To: <5FB37493-DB72-474A-9F84-0278D1D1BD00@oracle.com> References: <18C467C6-5E3B-45D3-9D32-A05FFCEEEC81@oracle.com> <4F453F90.6050500@oracle.com> <4F4663A2.8020609@oracle.com> <4F467389.3010605@oracle.com> <4F467A29.5000900@oracle.com> <5FB37493-DB72-474A-9F84-0278D1D1BD00@oracle.com> Message-ID: Hi, sorry for reopening this thread after so long time but I've just realized that this check is very weak. It currently only works because we build with '-fno-omit-frame-pointer'. The problem is the following: - GCC 'usually' ensures that stack frames (and thus the SP) are 16-byte aligned. - however for framless leaf methods GCC doesn't care a lot about the SP alignment (because nothing has to read/written to/from stack) - 'os::current_stack_pointer()' is such a frameless leaf method. Its code looks as follows (if compiled with '-fomit-frame-pointer') 0000000000000000 : 0: 48 89 e0 mov %rsp,%rax 3: c3 retq - so if current_stack_pointer() will be called from a method with a 16-byte aligned SP it will always return a 8-byte aligned only SP, because the call to current_stack_pointer() will push the return address onto the stack and decrement it by 8 bytes. - if we build with '-fno-omit-frame-pointer', the code for current_stack_pointer() looks as follows: 0000000000000000 : 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 89 e0 mov %rsp,%rax 7: 5d pop %rbp 8: c3 retq - the pushing of the FP will decrease the SP by 8 more bytes and we 'magically' have a 16-byte aligned SP again. The general problem with the approach of calling a helper like os::verify_stack_alignment() to verify the stack alignment of a method is that the helper will NOT verify the SP of the current caller (i.e. what we really want), but the stack alignment of the second calle (i.e. os::current_stack_pointer() in this case. The only solution I'm currently seeing is to either make sure that os::verify_stack_alignment() as well as os::current_stack_pointer() get inlined into the caller or to pack them both into a macro which will be expanded into every user. But I'm neither sure if the inlining solution is feasible (I think we can not 'enforce' inlining) nor whether the macro solution will always work (packing inline assembly into macros doesn't seem to be the most elegant and secure approach). Any comments? Regards, Volker PS: by the way, I discovered this problem while I was trying to compile the HotSpot with Clang where os::verify_stack_alignment() always asserted "incorrect stack alignment", but not because the stack was badly aligned in the caller of os::verify_stack_alignment(). It was just badly aligned in os::current_stack_pointer(). You can reproduce the same problem if you compile HotSpot with '-fomit-frame-pointer'. On Fri, Feb 24, 2012 at 9:44 AM, Roland Westrelin wrote: >> OK. It makes sense. I looked and all related bugs we had are for 64bit VM. > > Thanks for the review, Vladimir. > > Roland. From roland.westrelin at oracle.com Tue Dec 4 08:42:04 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 4 Dec 2012 17:42:04 +0100 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50B57BE4.9070709@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> <50ABDC69.8050604@oracle.com> <50ACCE8F.1080701@oracle.com> <50AD6E25.3080100@oracle.com> <50AF85F0.3020103@oracle.com> <50B5552A.3050009@oracle.com> <50B56557.4010506@oracle.com> <50B57BE4.9070709@oracle.com> Message-ID: Bharadwaj, I Know this is pushed already but I notice one thing that confuses me in this change that I haven't seen discussed before: Compile::check_node_count() now checks live_nodes() against MaxNodeLimit but check_node_count() is used during parsing and at this point live_nodes() is not correct (it's C->unique(), right?). So depending on the compilation phase we either check the number of uniquely created nodes or the number of live nodes against MaxNodeLimit. To me that makes MaxNodeLimit mostly irrelevant. Roland. From kirk at kodewerk.com Tue Dec 4 09:23:31 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 4 Dec 2012 18:23:31 +0100 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BD25B0.2060501@oracle.com> References: <50BD25B0.2060501@oracle.com> Message-ID: <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> I just have one question, what is a fence? Regards, Kirk On 2012-12-03, at 11:20 PM, Aleksey Shipilev wrote: > (submitting this on behalf of Doug Lea) > > Hi, > > Please see the preliminary webrev for changes associated with JEP 171 > aka Fences [1]. The webrev is here: > http://shipilev.net/pub/jdk/hotspot/fences/webrev-1/ > > Testing: > - built and tested on Linux x86_64 > - java-concurrency-torture [2] fences tests [3] passes on Linux x86_64 > - looking through generated assembly for torture tests > > Please review the code changes while this thing flies through JPRT and > JEP is being "funded". > > Thanks, > Aleksey. > > [1] http://openjdk.java.net/jeps/171 > [2] https://github.com/shipilev/java-concurrency-torture > [3] java -jar concurrency-torture.jar -t ".*fences.*" From aleksey.shipilev at oracle.com Tue Dec 4 09:34:04 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 04 Dec 2012 21:34:04 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> Message-ID: <50BE340C.9000108@oracle.com> http://en.wikipedia.org/wiki/Fence_instruction -Aleksey. On 12/04/2012 09:23 PM, Kirk Pepperdine wrote: > I just have one question, what is a fence? > > Regards, > Kirk > > On 2012-12-03, at 11:20 PM, Aleksey Shipilev wrote: > >> (submitting this on behalf of Doug Lea) >> >> Hi, >> >> Please see the preliminary webrev for changes associated with JEP 171 >> aka Fences [1]. The webrev is here: >> http://shipilev.net/pub/jdk/hotspot/fences/webrev-1/ >> >> Testing: >> - built and tested on Linux x86_64 >> - java-concurrency-torture [2] fences tests [3] passes on Linux x86_64 >> - looking through generated assembly for torture tests >> >> Please review the code changes while this thing flies through JPRT and >> JEP is being "funded". >> >> Thanks, >> Aleksey. >> >> [1] http://openjdk.java.net/jeps/171 >> [2] https://github.com/shipilev/java-concurrency-torture >> [3] java -jar concurrency-torture.jar -t ".*fences.*" > From Vladimir.Kozlov at oracle.com Tue Dec 4 11:05:39 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 04 Dec 2012 11:05:39 -0800 Subject: RFR(S): 8003983 Fix of broken logcompilation tool In-Reply-To: <50BE2085.1040006@oracle.com> References: <50B384EB.4030207@oracle.com> <50B3C33A.8090109@oracle.com> <50BDD94E.8020900@oracle.com> <50BE2085.1040006@oracle.com> Message-ID: <50BE4983.5060505@oracle.com> On 12/04/12 08:10, Bharadwaj Yadavalli wrote: > Not sure if my review counts (I am an "author" buy not a "committer"), > but the changes look good to me as well. It is always encouraging for everyone in the group to do reviews and send comments/questions regardless his status. Unfortunately for changesets we have to specify official reviewers (you become one after pushing 32 changesets). Vladimir > > Bharadwaj > > On 12/4/2012 6:06 AM, Nils Eliasson wrote: >> Thanks Vladimir! >> >> I think I need a second review. Anyone? >> >> //Nils >> >> Vladimir Kozlov skrev 2012-11-26 20:30: >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/26/12 07:04, Nils Eliasson wrote: >>>> Fixing LogCompilation tool so that I can do my own additions later. >>>> >>>> Includes fixes for: >>>> c1 missing parse tag that is required to surround method tag >>>> c1 call tag requires count attribute >>>> c1 phase tag requires nodes (set to zero since there is no nodes >>>> concept >>>> in c1) >>>> Method tag must handle missing bytes, iicount and flags attributes when >>>> unloading=1 is set >>>> Wrong description in help for '-n'. >>>> >>>> http://cr.openjdk.java.net/~neliasso/8003983/webrev.01/ >>>> >>>> Tested with running HelloDate on tiered with -Xcomp. Will add this as >>>> jtreg test separately. >>>> >>>> Thanks, >>>> Nils Eliasson >> From Vladimir.Kozlov at oracle.com Tue Dec 4 11:47:35 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 04 Dec 2012 11:47:35 -0800 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BD25B0.2060501@oracle.com> References: <50BD25B0.2060501@oracle.com> Message-ID: <50BE5357.60601@oracle.com> Aleksey, Add cases into the switch in "if (!InlineNatives)" since this should not be controlled by -XX:-InlineNatives flag. There is separate flag for unsafe methods: -XX:-InlineUnsafeOps. You don't need next code since you don't need to check for available mach instructions: 440 case vmIntrinsics::_loadFence: 441 case vmIntrinsics::_storeFence: 442 case vmIntrinsics::_fullFence: 443 break; 444 Thanks, Vladimir On 12/03/12 14:20, Aleksey Shipilev wrote: > (submitting this on behalf of Doug Lea) > > Hi, > > Please see the preliminary webrev for changes associated with JEP 171 > aka Fences [1]. The webrev is here: > http://shipilev.net/pub/jdk/hotspot/fences/webrev-1/ > > Testing: > - built and tested on Linux x86_64 > - java-concurrency-torture [2] fences tests [3] passes on Linux x86_64 > - looking through generated assembly for torture tests > > Please review the code changes while this thing flies through JPRT and > JEP is being "funded". > > Thanks, > Aleksey. > > [1] http://openjdk.java.net/jeps/171 > [2] https://github.com/shipilev/java-concurrency-torture > [3] java -jar concurrency-torture.jar -t ".*fences.*" From aleksey.shipilev at oracle.com Tue Dec 4 12:17:17 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Dec 2012 00:17:17 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BE5357.60601@oracle.com> References: <50BD25B0.2060501@oracle.com> <50BE5357.60601@oracle.com> Message-ID: <50BE5A4D.2010400@oracle.com> On 12/04/2012 11:47 PM, Vladimir Kozlov wrote: > Add cases into the switch in "if (!InlineNatives)" since this should not > be controlled by -XX:-InlineNatives flag. There is separate flag for > unsafe methods: -XX:-InlineUnsafeOps. Thanks for the hint, Vladimir! This one is better? http://shipilev.net/pub/jdk/hotspot/fences/webrev-3/ -Aleksey. From john.r.rose at oracle.com Tue Dec 4 12:37:14 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 4 Dec 2012 12:37:14 -0800 Subject: RFR(S): 8003983 Fix of broken logcompilation tool In-Reply-To: <50B384EB.4030207@oracle.com> References: <50B384EB.4030207@oracle.com> Message-ID: <6126A3BD-B044-4998-99FC-4D5A8023CEE4@oracle.com> On Nov 26, 2012, at 7:04 AM, Nils Eliasson wrote: > Fixing LogCompilation tool so that I can do my own additions later. > > Includes fixes for: > c1 missing parse tag that is required to surround method tag > c1 call tag requires count attribute > c1 phase tag requires nodes (set to zero since there is no nodes concept in c1) > Method tag must handle missing bytes, iicount and flags attributes when unloading=1 is set > Wrong description in help for '-n'. > > http://cr.openjdk.java.net/~neliasso/8003983/webrev.01/ > > Tested with running HelloDate on tiered with -Xcomp. Will add this as jtreg test separately. > > Thanks, > Nils Eliasson Generally speaking, if an attribute in the LogCompilation XML has a default value, it can be omitted from the log file. At least, that's how I think about the XML schema (or lack thereof). Therefore, I think the XML reader needs to be robust if attributes are missing. You are adding these explicit attributes to some parts of the XML output: phase ... nodes='0' parse_done ... nodes='0' call ... count='0' This is OK, but would it be possible to default them in the reader instead? That way of doing things may lead to a more robust system. Something like this: - site.setCount(Integer.parseInt(search(atts, "count"))); + site.setCount(Integer.parseInt(search(atts, "count", "0"))); (etc.) In the present case, either way is fine with me. You can cite me as a reviewer. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121204/c80129e8/attachment.html From vladimir.kozlov at oracle.com Tue Dec 4 12:39:20 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 04 Dec 2012 12:39:20 -0800 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BE5A4D.2010400@oracle.com> References: <50BD25B0.2060501@oracle.com> <50BE5357.60601@oracle.com> <50BE5A4D.2010400@oracle.com> Message-ID: <50BE5F78.6030608@oracle.com> Yes, this is good. We will select a sponsor for you to push this. Thanks, Vladimir On 12/4/12 12:17 PM, Aleksey Shipilev wrote: > On 12/04/2012 11:47 PM, Vladimir Kozlov wrote: >> Add cases into the switch in "if (!InlineNatives)" since this should not >> be controlled by -XX:-InlineNatives flag. There is separate flag for >> unsafe methods: -XX:-InlineUnsafeOps. > > Thanks for the hint, Vladimir! > > This one is better? > http://shipilev.net/pub/jdk/hotspot/fences/webrev-3/ > > -Aleksey. > From dl at cs.oswego.edu Tue Dec 4 12:51:03 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 04 Dec 2012 15:51:03 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BE5F78.6030608@oracle.com> References: <50BD25B0.2060501@oracle.com> <50BE5357.60601@oracle.com> <50BE5A4D.2010400@oracle.com> <50BE5F78.6030608@oracle.com> Message-ID: <50BE6237.80100@cs.oswego.edu> On 12/04/12 15:39, Vladimir Kozlov wrote: > Yes, this is good. We will select a sponsor for you to push this. Great; thanks! This will help tremendously in our effort to hold the record for the fastest JEP turnaround ever. (Although we are already past one day, so there will be room for someone else to beat us :-) -Doug > > Thanks, > Vladimir > > On 12/4/12 12:17 PM, Aleksey Shipilev wrote: >> On 12/04/2012 11:47 PM, Vladimir Kozlov wrote: >>> Add cases into the switch in "if (!InlineNatives)" since this should not >>> be controlled by -XX:-InlineNatives flag. There is separate flag for >>> unsafe methods: -XX:-InlineUnsafeOps. >> >> Thanks for the hint, Vladimir! >> >> This one is better? >> http://shipilev.net/pub/jdk/hotspot/fences/webrev-3/ >> >> -Aleksey. >> > From christian.thalinger at oracle.com Tue Dec 4 13:12:33 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 4 Dec 2012 13:12:33 -0800 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BE6237.80100@cs.oswego.edu> References: <50BD25B0.2060501@oracle.com> <50BE5357.60601@oracle.com> <50BE5A4D.2010400@oracle.com> <50BE5F78.6030608@oracle.com> <50BE6237.80100@cs.oswego.edu> Message-ID: <74CE271C-D05F-4DFF-BD97-0C0E8B4A3C57@oracle.com> On Dec 4, 2012, at 12:51 PM, Doug Lea
wrote: > On 12/04/12 15:39, Vladimir Kozlov wrote: >> Yes, this is good. We will select a sponsor for you to push this. > > Great; thanks! This will help tremendously in our effort to > hold the record for the fastest JEP turnaround ever. (Although we > are already past one day, so there will be room for someone else > to beat us :-) Well, it's still in the Posted state ;-) -- Chris > > -Doug > > >> >> Thanks, >> Vladimir >> >> On 12/4/12 12:17 PM, Aleksey Shipilev wrote: >>> On 12/04/2012 11:47 PM, Vladimir Kozlov wrote: >>>> Add cases into the switch in "if (!InlineNatives)" since this should not >>>> be controlled by -XX:-InlineNatives flag. There is separate flag for >>>> unsafe methods: -XX:-InlineUnsafeOps. >>> >>> Thanks for the hint, Vladimir! >>> >>> This one is better? >>> http://shipilev.net/pub/jdk/hotspot/fences/webrev-3/ >>> >>> -Aleksey. >>> >> > From john.r.rose at oracle.com Tue Dec 4 13:21:11 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 4 Dec 2012 13:21:11 -0800 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> Message-ID: On Dec 4, 2012, at 9:23 AM, Kirk Pepperdine wrote: > I just have one question, what is a fence? Oh, I've been waiting a long time for this one! Actually, a fence is a subject of many posts: http://www.langsyne.net/images/fent.jpg Cheers, ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121204/d2ddeee5/attachment.html From kirk at kodewerk.com Tue Dec 4 15:13:08 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 5 Dec 2012 00:13:08 +0100 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BE340C.9000108@oracle.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> Message-ID: Hi Aleksey, I didn't think you'd take this to be an straight-forward question. This was more an expression of concern about the C++ification of the platform. I'm not so convinced we should be introducing these annotations until we have explored other options that maybe more suitable for Java. Right now I fear that the JEP process is being abused. Instead of opening a discussion it's seems to being used to drive singular points of view into the JVM instead of an honest discussion about alternatives. This runs counter to the openness that OpenJDK is suppose to be promoting. I am not the only one that has expressed concerns about the direction theee @Contended and this JEP is taking us and those that have spoken out are not novices.... I believe you know very well that we understand false sharing, false synchronization and the importance of fences We also agree that the JMM is in need of some work because it reflects what we knew to be true when authored... but that understanding has advanced and as such so should the JMM. These JEP's are IMHO, (dirty) bandaids being used to cover over the real problem. Has anyone taken a deeper look into the impact of these JEP... because we all know that once they are in the distribution, they're not coming out. Regards, Kirk On 2012-12-04, at 6:34 PM, Aleksey Shipilev wrote: > http://en.wikipedia.org/wiki/Fence_instruction > > -Aleksey. > > On 12/04/2012 09:23 PM, Kirk Pepperdine wrote: >> I just have one question, what is a fence? >> >> Regards, >> Kirk >> >> On 2012-12-03, at 11:20 PM, Aleksey Shipilev wrote: >> >>> (submitting this on behalf of Doug Lea) >>> >>> Hi, >>> >>> Please see the preliminary webrev for changes associated with JEP 171 >>> aka Fences [1]. The webrev is here: >>> http://shipilev.net/pub/jdk/hotspot/fences/webrev-1/ >>> >>> Testing: >>> - built and tested on Linux x86_64 >>> - java-concurrency-torture [2] fences tests [3] passes on Linux x86_64 >>> - looking through generated assembly for torture tests >>> >>> Please review the code changes while this thing flies through JPRT and >>> JEP is being "funded". >>> >>> Thanks, >>> Aleksey. >>> >>> [1] http://openjdk.java.net/jeps/171 >>> [2] https://github.com/shipilev/java-concurrency-torture >>> [3] java -jar concurrency-torture.jar -t ".*fences.*" >> > From aleksey.shipilev at oracle.com Wed Dec 5 00:02:52 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Dec 2012 12:02:52 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> Message-ID: <50BEFFAC.1010807@oracle.com> On 12/05/2012 03:13 AM, Kirk Pepperdine wrote: > I didn't think you'd take this to be an straight-forward question. libpsychic.so.1: not found. > This was more an expression of concern about the C++ification of the > platform. I'm not so convinced we should be introducing these > annotations until we have explored other options that maybe more > suitable for Java. Fences are the members of Unsafe, which is known to hold the out-of-band methods, suitable for programming in JVMese, not exactly in Java. The libraries and on-JVM-runtimes are here to bridge the gap between JVMese and languages, and by that extension, with users. Should JMM refresh happen any time in the future, at that point we can talk whether fences are eligible for promotion to first-class Java language constructs; before that happens, fences are there among Unsafe methods, eligible to use in libraries and runtimes if that allows to gain substantial performance benefits while still maintaining the illusion of safe memory model. Bottom-line: it's very easy to confuse the exposure of JVM internals with the endorsement of new Java construct. You might as well start the rally against Unsafe.allocateMemory because it conflicts with safe "garbage-collected" Java. -Aleksey. From aleksey.shipilev at oracle.com Wed Dec 5 03:34:28 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Dec 2012 15:34:28 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50BD2ABB.30703@oracle.com> References: <50BD2972.4090603@oracle.com> <50BD2ABB.30703@oracle.com> Message-ID: <50BF3144.4070404@oracle.com> Friendly reminder to check this didn't fall into the trenches. -Aleksey. On 12/04/2012 02:42 AM, Aleksey Shipilev wrote: > (I should have CC'ed Doug on this, doing now). > > -Aleksey. > > On 12/04/2012 02:36 AM, Aleksey Shipilev wrote: >> (again, submitting on behalf of Doug Lea) >> >> Hi, >> >> This simple change is missing from recently committed CR 7023898. While >> the VM support is there in Hotspot, no methods are exposed in Unsafe to >> actually make use of those intrinsics. This is the webrev fixing that: >> http://shipilev.net/pub/jdk/hotspot/unsafe-getandadd/webrev-1/ >> >> Testing: >> - Built and tested in Linux x86_64 >> - Doug had provided the AtomicIntegerV8 [1] version making use of this >> new code, extensively tested on his platforms >> - java-concurrency-torture [2] atomicity tests [3] are passed for >> AtomicIntegerV8 on my and Doug's platforms >> - no other testing is expected for this trivial change. >> >> I would need a sponsor to push this change. >> >> Thanks, >> Aleksey. >> >> [1] >> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/java/util/concurrent/atomic/AtomicIntegerV8.java >> [2] https://github.com/shipilev/java-concurrency-torture/ >> [3] >> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java >> > From nils.eliasson at oracle.com Wed Dec 5 04:13:07 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 05 Dec 2012 13:13:07 +0100 Subject: RFR(S): 8003983 Fix of broken logcompilation tool In-Reply-To: <6126A3BD-B044-4998-99FC-4D5A8023CEE4@oracle.com> References: <50B384EB.4030207@oracle.com> <6126A3BD-B044-4998-99FC-4D5A8023CEE4@oracle.com> Message-ID: <50BF3A53.1000705@oracle.com> Yes, putting the defaults in the LogParser makes a lot of sense. Updated webrev: http://cr.openjdk.java.net/~neliasso/8003983/webrev.02/ //Nils John Rose skrev 2012-12-04 21:37: > > Generally speaking, if an attribute in the LogCompilation XML has a > default value, it can be omitted from the log file. At least, that's > how I think about the XML schema (or lack thereof). > > Therefore, I think the XML reader needs to be robust if attributes are > missing. > > You are adding these explicit attributes to some parts of the XML output: > phase ... nodes='0' > parse_done ... nodes='0' > call ... count='0' > > This is OK, but would it be possible to default them in the reader > instead? That way of doing things may lead to a more robust system. > Something like this: > - site.setCount(Integer.parseInt(search(atts, "count"))); > + site.setCount(Integer.parseInt(search(atts, "count", "0"))); > (etc.) > > In the present case, either way is fine with me. You can cite me as a > reviewer. > > ? John From david.r.chase at oracle.com Wed Dec 5 05:20:04 2012 From: david.r.chase at oracle.com (David Chase) Date: Wed, 5 Dec 2012 08:20:04 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BEFFAC.1010807@oracle.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> Message-ID: On 2012-12-05, at 3:02 AM, Aleksey Shipilev wrote: > Bottom-line: it's very easy to confuse the exposure of JVM internals > with the endorsement of new Java construct. You might as well start the > rally against Unsafe.allocateMemory because it conflicts with safe > "garbage-collected" Java. Aleksey, two things -- #1, the implementation technique used here (unsafe extensions to safe language, with an enforced boundary between them) is not as well known as it ought to be -- it's easy for Kirk to misread this, he's not psychic either. The C# approach of (last I checked) allowing the sprinkling of "unmanaged" blocks into ordinary code does not help, since it often gives the impression that "unmanaged" is for anyone to use, if their style-checker is not currently forbidding it, and wouldn't you like your Very Important Loop to run a little faster? #2, a restatement of a previous complaint (that I will let slide for now, but will bring up in the future again when we have time for cleanup and reorg) is that we need to be quite careful about the distinction between the various sorts of Unsafe. It is not unlikely the (flawed) original Unix approach to security, where a single flag controlled access to everything, and there are no shades of gray. Careful organization helps us avod accidental incorrect use of truly Unsafe features. For example, there is Unsafe-can-bork-the-VM ("poke"), Unsafe-can-subvert-security ("peek"), and Unsafe-can-see-implementation-quirks ("rawbits"). Some unsafe operations can result in denial-of-service if used inappropriately (infinite loops with no safepoints, for example). Another variant might be not truly unsafe, but only "work" for a difficult-to-document set of inputs. Both the fences and contended fall into another category, where the user cannot do any semantically bad things, but might create difficult-to-understand performance problems that we really don't want to bother with explaining to most users (@inline is another example). There's a natural tendency to say "we're on the implementation side, we know what we're doing, this organizational stuff is not a good use of our time, we have deadlines to meet" -- and I hope your response is the eye-rolling "yeah, right". I've seen some Unsafe howlers committed by "experts" over the years in other programming languages. Because this is open source, we have some external self-appointed experts who are using Unsafe stuff already when they think it is important to their application. If nothing else, profligate use of "Unsafe" increases the amount of code that must be reviewed with a microscope, when only a magnifying glass is necessary. David From aleksey.shipilev at oracle.com Wed Dec 5 05:56:02 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Dec 2012 17:56:02 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> Message-ID: <50BF5272.9030100@oracle.com> On 12/05/2012 05:20 PM, David Chase wrote: > #2, a restatement of a previous complaint (that I will let slide for > now, but will bring up in the future again when we have time for > cleanup and reorg) is that we need to be quite careful about the > distinction between the various sorts of Unsafe. Totally agree. Now to constructive side: are you up to actually clean up Unsafe? *This* makes a perfect JEP to have the open discussion about. > There's a natural tendency to say "we're on the implementation side, > we know what we're doing, this organizational stuff is not a good > use of our time, we have deadlines to meet" -- and I hope your > response is the eye-rolling "yeah, right". I understand this concern, but this might as well serve as the excuse of not doing anything at all, and only "exploring alternatives" for years, while key developers are fleeing away from the platform (I've almost used word "vibrant" here!). In fact, for fences, it was on the table for at least 3 years, and no better+practical approach emerged. That is why I get sincerely amused when somebody wants to have the discussion about fences again, and get double amused when exposing the intrinsics to out-of-band internal API somehow promotes to "omg, that breaks Java" stunts. > If nothing else, profligate use of "Unsafe" increases the amount of > code that must be reviewed with a microscope, when only a magnifying > glass is necessary. Totally agree x2. Again, do we want to push away fences from Unsafe to make the room for cleaning up Unsafe? If so, would be it better to move fences to, say, sun.misc.Fences? Seems to fit the bill for what you are suggesting of splitting up the Unsafe? -Aleksey. From david.r.chase at oracle.com Wed Dec 5 06:36:15 2012 From: david.r.chase at oracle.com (David Chase) Date: Wed, 5 Dec 2012 09:36:15 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BF5272.9030100@oracle.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> Message-ID: <50792326-8F10-4B91-9E77-F59BA8F3BBA0@oracle.com> On 2012-12-05, at 8:56 AM, Aleksey Shipilev wrote: > Totally agree. Now to constructive side: are you up to actually clean up > Unsafe? *This* makes a perfect JEP to have the open discussion about. In theory, yes, in practice, I have to be sure that I won't be told this is not what I should be spending time on, and I am also sufficiently new to Openjdk that I am almost completely ignorant of process and even acronyms. I'm still working towards getting committer rights. But "Unsafe" as an implementation layer for safe languages, that I have decades of experience with. >> If nothing else, profligate use of "Unsafe" increases the amount of >> code that must be reviewed with a microscope, when only a magnifying >> glass is necessary. > > Totally agree x2. Again, do we want to push away fences from Unsafe to > make the room for cleaning up Unsafe? If so, would be it better to move > fences to, say, sun.misc.Fences? Seems to fit the bill for what you are > suggesting of splitting up the Unsafe? I'm on the (ahem) fence here. I don't feel like ticking off Doug, deadlines are approaching, and I don't think this is the only wart in the Unsafe layer. On the other hand, how hard could it be to stuff it all in some other class of sun.misc? It doesn't actually need access protection, because (straining my pathological imagination here to think of an example, finding none) it's not a security hole. David From aleksey.shipilev at oracle.com Wed Dec 5 06:58:10 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Dec 2012 18:58:10 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50792326-8F10-4B91-9E77-F59BA8F3BBA0@oracle.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> <50792326-8F10-4B91-9E77-F59BA8F3BBA0@oracle.com> Message-ID: <50BF6102.8060301@oracle.com> On 12/05/2012 06:36 PM, David Chase wrote: > On 2012-12-05, at 8:56 AM, Aleksey Shipilev > wrote: > >> Totally agree. Now to constructive side: are you up to actually >> clean up Unsafe? *This* makes a perfect JEP to have the open >> discussion about. > > In theory, yes, in practice, I have to be sure that I won't be told > this is not what I should be spending time on, and I am also > sufficiently new to Openjdk that I am almost completely ignorant of > process and even acronyms. I'm still working towards getting > committer rights. But "Unsafe" as an implementation layer for safe > languages, that I have decades of experience with. Yes, sorry, under "you" I've meant the abstract reader who has the same thoughts about Unsafe. This this what open source is all about, right? You go ahead and suggest the improvements :) Basically, here: http://openjdk.java.net/jeps/1 >> Totally agree x2. Again, do we want to push away fences from Unsafe >> to make the room for cleaning up Unsafe? If so, would be it better >> to move fences to, say, sun.misc.Fences? Seems to fit the bill for >> what you are suggesting of splitting up the Unsafe? > > I'm on the (ahem) fence here. I don't feel like ticking off Doug, > deadlines are approaching, and I don't think this is the only wart in > the Unsafe layer. On the other hand, how hard could it be to stuff > it all in some other class of sun.misc? As for the Fences, the effort is pretty minimal to move once we figure out where to move. Less than one hour of work do to, mostly automatic. -Aleksey. From dl at cs.oswego.edu Wed Dec 5 07:32:13 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 05 Dec 2012 10:32:13 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BEFFAC.1010807@oracle.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> Message-ID: <50BF68FD.50809@cs.oswego.edu> [I should have actually subscribed to this list too, so as to not lose out when people dropped CC. I am now. Too many lists!] But ... David Chase wrote: > I'm on the (ahem) fence here. I don't feel like ticking off Doug, deadlines > are approaching, and I don't think this is the only wart in the Unsafe layer. > On the other hand, how hard could it be to stuff it all in some other class > of sun.misc? FWIW, my "what's best for openjdk" judgement is that it is best to keep the pressure on for a total overhaul effort for JDK9: For example, a package jvm.* developed with consensus with others VM folks, a JMM-like full spec effort for memory model related stuff. A indy/mh-based solution to the awfulness of using offset args. And so on. So the little bandaid of moving these three methods could be counter-productive -- allowing more muddling along for more releases. But really, at this point, I'd take anything. -Doug From kirk at kodewerk.com Wed Dec 5 07:50:09 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 5 Dec 2012 16:50:09 +0100 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BF5272.9030100@oracle.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> Message-ID: Hi Aleksey, On 2012-12-05, at 2:56 PM, Aleksey Shipilev wrote: > On 12/05/2012 05:20 PM, David Chase wrote: >> #2, a restatement of a previous complaint (that I will let slide for >> now, but will bring up in the future again when we have time for >> cleanup and reorg) is that we need to be quite careful about the >> distinction between the various sorts of Unsafe. > > Totally agree. Now to constructive side: are you up to actually clean up > Unsafe? *This* makes a perfect JEP to have the open discussion about. To my knowledge, n the history of the JDK.. no public exposed API has ever been cleaned up. Once exposed it will be used and once used it will be impossible to back off of it. Thus prudence needs to be preferred over expedience. What makes you believe that you will be able to clean Unsafe in the future? > >> There's a natural tendency to say "we're on the implementation side, >> we know what we're doing, this organizational stuff is not a good >> use of our time, we have deadlines to meet" -- and I hope your >> response is the eye-rolling "yeah, right". > > I understand this concern, but this might as well serve as the excuse of > not doing anything at all, and only "exploring alternatives" for years, > while key developers are fleeing away from the platform (I've almost > used word "vibrant" here!). Do you have numbers to support this assumption that developers are fleeing. The way I see it, more and more people are understanding the advantages of the platform and are moving to adopt it. I'm seeing more and more code ported from C++ to Java for reasons of maintainability etc.... This is not an excuse to not do anything but to properly resource and look into a safe solution to a known deficiency. I would like these things to be solved but I also believe there is a way to solve them in the context of how Java functions. The VM has proven time and time again that being adaptive to the run time has provided many many benefits that are not reachable by average developers. > > In fact, for fences, it was on the table for at least 3 years, and no > better+practical approach emerged. That is why I get sincerely amused > when somebody wants to have the discussion about fences again, and get > double amused when exposing the intrinsics to out-of-band internal API > somehow promotes to "omg, that breaks Java" stunts. Sorry to say this but I find this attitude both offensive and counter productive to community building. I will be giving a talk on concurrency at the Munich JUG in a few hours. We will talk about fences and I will show them how to do pointer manipulation in Java.. and how it can be used to implement wait-free, non-blocking algorithms.. I will show them how to get measurements to understand when their applications are fighting with the hardware... That said, I really wished that we had a better... safer way to achieve the same effect than exposing people to unsafe. Kind regards, Kirk Pepperdine From david.r.chase at oracle.com Wed Dec 5 08:07:45 2012 From: david.r.chase at oracle.com (David Chase) Date: Wed, 5 Dec 2012 11:07:45 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> Message-ID: <85CDE13C-18DD-4CF2-A213-C57EEFE772F4@oracle.com> On 2012-12-05, at 10:50 AM, Kirk Pepperdine wrote: > I will be giving a talk on concurrency at the Munich JUG in a few hours. We will talk about fences and I will show them how to do pointer manipulation in Java.. and how it can be used to implement wait-free, non-blocking algorithms.. I will show them how to get measurements to understand when their applications are fighting with the hardware... That said, I really wished that we had a better... safer way to achieve the same effect than exposing people to unsafe. If you have a pointer to the talk itself, or related materials, I would love to see it. How much do you know about the crazy world of GC implementation? GC surprises are the root cause of most of the Unsafe-induced bugs I've seen. David From forax at univ-mlv.fr Wed Dec 5 08:09:27 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 05 Dec 2012 17:09:27 +0100 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> Message-ID: <50BF71B7.6050001@univ-mlv.fr> On 12/05/2012 04:50 PM, Kirk Pepperdine wrote: > Hi Aleksey, > > > On 2012-12-05, at 2:56 PM, Aleksey Shipilev wrote: > >> On 12/05/2012 05:20 PM, David Chase wrote: >>> #2, a restatement of a previous complaint (that I will let slide for >>> now, but will bring up in the future again when we have time for >>> cleanup and reorg) is that we need to be quite careful about the >>> distinction between the various sorts of Unsafe. >> Totally agree. Now to constructive side: are you up to actually clean up >> Unsafe? *This* makes a perfect JEP to have the open discussion about. > To my knowledge, n the history of the JDK.. no public exposed API has ever been cleaned up. Once exposed it will be used and once used it will be impossible to back off of it. Thus prudence needs to be preferred over expedience. What makes you believe that you will be able to clean Unsafe in the future? yes, but things change ... take a look to: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6455182d2797 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b265ead7f331 you can't modularize the API without cleaning some interfaces, how to clean sun.misc is still an open question. R?mi From vitalyd at gmail.com Wed Dec 5 08:12:54 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 5 Dec 2012 11:12:54 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> Message-ID: Hi Kirk, Your comments seem to be one of the more loudly opposed ones. So we know what problems @Contended and Fences are trying to fix. Do you have any actionable alternatives to suggest? I'm sure everyone would agree that if these things could somehow fit into java better, then we'd all prefer that over JVMese approach. But nothing has been put forth by the folks opposing this. Simply wishing for something or saying "let's think about it" won't help - who is going to think about it and then do something? At the end of the day, there will probably always be some things that can be expressed better by peeling away the layers of abstraction from Java proper. I think it's unreasonable and unrealistic to think that java will provide access to low-level details of the underlying hardware - this is at odds with the design of the language. However, the JVM is fast enough that a lot of people are using it to build high performance software. In that space, it's always nice to eek out that extra level of perf, even if you're now stepping out of the "safe" zone. I personally don't see anything wrong with letting people make the decision to go there - it's not an accidental venture, and they make the leap with all the warning labels in their face. What I don't think java should solve is a people problem - if developers plunge into this space without thinking it through and doing analysis, that's their problem, frankly; nobody forced their hand. If the philosophy is to dumb down the platform to prevent people shooting themselves, then we should also get rid of a bunch of existing constructs/knobs in the JVM. There are plenty of Hotspot cmdline flags that can be considered low-level and could be played around with by people not understanding them that can have worse problems than @Contended. It's also interesting that in the C# space, which has had unsafe options almost from the get go, I have never heard anyone complain about it. In fact, Mono even went further with providing SIMD intrinsics in their library and that's only been praised (from what I've seen). Cheers Sent from my phone On Dec 5, 2012 10:51 AM, "Kirk Pepperdine" wrote: > Hi Aleksey, > > > On 2012-12-05, at 2:56 PM, Aleksey Shipilev > wrote: > > > On 12/05/2012 05:20 PM, David Chase wrote: > >> #2, a restatement of a previous complaint (that I will let slide for > >> now, but will bring up in the future again when we have time for > >> cleanup and reorg) is that we need to be quite careful about the > >> distinction between the various sorts of Unsafe. > > > > Totally agree. Now to constructive side: are you up to actually clean up > > Unsafe? *This* makes a perfect JEP to have the open discussion about. > > To my knowledge, n the history of the JDK.. no public exposed API has ever > been cleaned up. Once exposed it will be used and once used it will be > impossible to back off of it. Thus prudence needs to be preferred over > expedience. What makes you believe that you will be able to clean Unsafe in > the future? > > > > >> There's a natural tendency to say "we're on the implementation side, > >> we know what we're doing, this organizational stuff is not a good > >> use of our time, we have deadlines to meet" -- and I hope your > >> response is the eye-rolling "yeah, right". > > > > I understand this concern, but this might as well serve as the excuse of > > not doing anything at all, and only "exploring alternatives" for years, > > while key developers are fleeing away from the platform (I've almost > > used word "vibrant" here!). > > Do you have numbers to support this assumption that developers are > fleeing. The way I see it, more and more people are understanding the > advantages of the platform and are moving to adopt it. I'm seeing more and > more code ported from C++ to Java for reasons of maintainability etc.... > This is not an excuse to not do anything but to properly resource and look > into a safe solution to a known deficiency. I would like these things to be > solved but I also believe there is a way to solve them in the context of > how Java functions. The VM has proven time and time again that being > adaptive to the run time has provided many many benefits that are not > reachable by average developers. > > > > > In fact, for fences, it was on the table for at least 3 years, and no > > better+practical approach emerged. That is why I get sincerely amused > > when somebody wants to have the discussion about fences again, and get > > double amused when exposing the intrinsics to out-of-band internal API > > somehow promotes to "omg, that breaks Java" stunts. > > Sorry to say this but I find this attitude both offensive and counter > productive to community building. > > I will be giving a talk on concurrency at the Munich JUG in a few hours. > We will talk about fences and I will show them how to do pointer > manipulation in Java.. and how it can be used to implement wait-free, > non-blocking algorithms.. I will show them how to get measurements to > understand when their applications are fighting with the hardware... That > said, I really wished that we had a better... safer way to achieve the same > effect than exposing people to unsafe. > > Kind regards, > Kirk Pepperdine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121205/59f4782f/attachment.html From dl at cs.oswego.edu Wed Dec 5 08:14:29 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 05 Dec 2012 11:14:29 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> Message-ID: <50BF72E5.7010000@cs.oswego.edu> On 12/05/12 10:50, Kirk Pepperdine wrote: > their applications are fighting with the hardware... That said, I really > wished that we had a better... safer way to achieve the same effect than > exposing people to unsafe. > Of course, we all do. Mere wishing has had the effect of not exposing these obviously-needed intrinsics for 11 years now. (I regret letting people talk me out of exposing them back when I was first involved in the discussions of the semantics of c2 acquire/release/volatile membars.) And the past decade's worth of discussion, periodically re-raised on concurrency-interest list (http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest) usually boil down to: (1) We cannot expose these methods because we cannot spec them without overhauling the JMM, and (2) We don't like it that some people will misuse them. I'm sure that if you had a better solution for a better outcome, you would have posted it there :-) So, the current @Contended and Fences proposals concede these arguments. They do not provide support in Java(tm) the language or platform, but are available via an unstandardized API on openJDK and any other JVM that wants to offer this functionality. My intent was that these concessions should then allow this support to at least be in place for use now inside core libraries, and so that when the more controversial aspects are resolved, we don't stall yet again on the implementation side. -Doug From kirk at kodewerk.com Wed Dec 5 08:17:19 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 5 Dec 2012 17:17:19 +0100 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <85CDE13C-18DD-4CF2-A213-C57EEFE772F4@oracle.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> <85CDE13C-18DD-4CF2-A213-C57EEFE772F4@oracle.com> Message-ID: Hi David, This is sort of an off-topic list but I've been looking at GC implementations for quite some time. In March I tuned an application that was GC induced lock bound in a very interesting way. More recently I've been more interested in AdaptiveSizing as there are other metrics that need to be considered when deciding on how to resize. Right now we have to advise some clients to abandon adaptive sizing because it tends to undersize survivor spaces thus inducing far too frequent Full GCs. I'd happily contribute to a way to rid the need for @Contented but I fear that GC is consuming all of my time. Regards, Kirk On 2012-12-05, at 5:07 PM, David Chase wrote: > > On 2012-12-05, at 10:50 AM, Kirk Pepperdine wrote: >> I will be giving a talk on concurrency at the Munich JUG in a few hours. We will talk about fences and I will show them how to do pointer manipulation in Java.. and how it can be used to implement wait-free, non-blocking algorithms.. I will show them how to get measurements to understand when their applications are fighting with the hardware... That said, I really wished that we had a better... safer way to achieve the same effect than exposing people to unsafe. > > If you have a pointer to the talk itself, or related materials, I would love to see it. How much do you know about the crazy world of GC implementation? GC surprises are the root cause of most of the Unsafe-induced bugs I've seen. > > David > From kirk at kodewerk.com Wed Dec 5 08:55:14 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 5 Dec 2012 17:55:14 +0100 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BF72E5.7010000@cs.oswego.edu> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> <50BF72E5.7010000@cs.oswego.edu> Message-ID: <04A9AB93-FCDB-4A21-A6B3-CE417D32C1F4@kodewerk.com> Hi Doug, Thank you for engaging in an honest dialog. I have, in a previous email, posted an outline for and @Contented alternative. I cannot say that it paints a complete picture but then I've not really started thinking about this until recently and as I've mentioned to David, I'm really buried in the GC world at the moment (with adaptive sizing). I will repost a terse version. 1) we need to be able to detect the problem. I mentioned that we can do that with an MSR. IMHO, it would be better to focus some efforts on putting MSR access into the serviceability APIs. Thus we could detect (for almost free) when this types of problems arise. Not just cache miss/hit ratios due to some pathological variable layout but for other things such as TLAB hit/miss ratios which in a self tuning JVM world (something Oracle is putting on the boards for a possible Java 9 delivery) result in an adjustment to use large pages. Without this type of measurement, introduction of this annotation is a purely speculative measure. 2) We need to determine the code which is responsible for the problem. Again, this information is buried in the JVM.. we just need to get to it. 3) We need to make the appropriate adjustment to the code (arrange to have the values end up in different cache lines). Again, the JVM may need some rework to get this done but it's in the best position to make this adjustment. In fact some of Aleksey's code would/could be helpful in making this happen. I have Java code that runs in Linux that programs the MSRs. Unfortunately it's in a form that I cannot release here in this forum. If I could, I would. That said, I would be happy to work up a fragment that I could release. Unfortunately I'm not in a position to do this.. this week or next. If it's not too late, paying job will allow me to post code but only after Dec 15th. I'll happily post code then (or sooner if I can squeeze it in). WIth all due respect to those like yourself that have done so much to further the platform, i would say that this can be done without the need to overhaul the JMM. Some people will mis-use what ever you give them so I don't really go for the mothering attitude either. However, I do think that delegating the decision to a time when better information is available has been a brilliant success. In other words, from a performance perspective, it is the run time that has the highest quality information to understand if an optimization or adjustment to the code is going to make a difference (or not). And in the case of @Contented I would argue that it is the once again the run time that will have the highest quality information needed to understand if variables should be pushed away from each other or if this is simply un-needed overhead that is simply reducing the effectiveness of the CPU caches. Kind regards, Kirk PS, as for the JEP process it's self.. it's not a very well known process. I come in contact with dozens of developers in the course of my performance workshops and tuning engagements and I would say that very very few of them have ever heard of a JEP. In fact I would go further to say that IME, very few people of what one might consider to be luminaries in the industry are aware of the JEP process. So, my earlier comment was more to the point that while things may have been collecting dust for a while... I and many others didn't know about it.. but now that I do, I'm paying attention.. (can't speak for the others). On 2012-12-05, at 5:14 PM, Doug Lea
wrote: > On 12/05/12 10:50, Kirk Pepperdine wrote: > >> their applications are fighting with the hardware... That said, I really >> wished that we had a better... safer way to achieve the same effect than >> exposing people to unsafe. >> > > Of course, we all do. Mere wishing has had the effect of not > exposing these obviously-needed intrinsics for 11 years now. > (I regret letting people talk me out of exposing them > back when I was first involved in the discussions of the > semantics of c2 acquire/release/volatile membars.) And the past > decade's worth of discussion, periodically re-raised > on concurrency-interest list (http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest) usually boil down to: (1) We > cannot expose these methods because we cannot spec them > without overhauling the JMM, and (2) We don't like it > that some people will misuse them. I'm sure that > if you had a better solution for a better outcome, you > would have posted it there :-) > > So, the current @Contended and Fences proposals concede > these arguments. They do not provide support in Java(tm) the > language or platform, but are available via an > unstandardized API on openJDK and any other JVM > that wants to offer this functionality. My intent > was that these concessions should then allow this > support to at least be in place for use now > inside core libraries, and so that when the more > controversial aspects are resolved, we don't > stall yet again on the implementation side. > > -Doug > From dl at cs.oswego.edu Wed Dec 5 09:08:42 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 05 Dec 2012 12:08:42 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BF72E5.7010000@cs.oswego.edu> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> <50BF72E5.7010000@cs.oswego.edu> Message-ID: <50BF7F9A.6080806@cs.oswego.edu> On 12/05/12 11:14, Doug Lea wrote: > Of course, we all do. Mere wishing has had the effect of not > exposing these obviously-needed intrinsics for 11 years now. Oh, one more FAQ that is a little obscure in the JEP: If I've been living without these for 11 years, what's wrong with delaying this for another release or two? I have so far been able to twist designs/code to use volatiles and/or fenced access intrinsics to combine fences with access. But JDK8 is the first release where the specs of at least one component (StampedLock) relies on a lack of reordering that is allowed by the JMM for volatiles. As it turns out, this reordering does not occur when you use getLongVolatile in hotpot instead of a plain volatile read, but this is just an accidental fact that is not mentioned anywhere. I really do not want to depend on this in released code that will run on multiple JVMs, relying on varying interpretation of the non-existent getLongVolatile spec. Using a plain Unsafe.loadFence here will clearly suffice: Even if the fence intrinsics remain as-yet unformalized, the intent is clear. So this was a good enough reason to masochistically go through this process :-) -Doug From aleksey.shipilev at oracle.com Wed Dec 5 09:51:09 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Dec 2012 21:51:09 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> Message-ID: <50BF898D.5020401@oracle.com> On 12/05/2012 07:50 PM, Kirk Pepperdine wrote: > To my knowledge, n the history of the JDK.. no public exposed API > has ever been cleaned up. Once exposed it will be used and once used > it will be impossible to back off of it. Thus prudence needs to be > preferred over expedience. What makes you believe that you will be > able to clean Unsafe in the future? The definition of "publicly exposed API" is very blunt when it comes to Unsafe. Unsafe is internal, and as such is deliberately unsupported. Otherwise, you end up cornering yourself into "you can't really add this internal thingy, because that becomes the part of exposed APIs" extending to each and any class in JDK internals, which pretty much seals off JDK libraries from *any* internal change. > The VM has proven time and time again that being adaptive to the run > time has provided many many benefits that are not reachable by > average developers. Noble goal. Now, can we do something about it in realistic timeframe? "Average users" don't actually care about all this fences stuff, but the do care about the performance of library classes about to rely on fences to ensure correctness (e.g. JDK8-ish SequenceLock). >> In fact, for fences, it was on the table for at least 3 years, and >> no better+practical approach emerged. That is why I get sincerely >> amused when somebody wants to have the discussion about fences >> again, and get double amused when exposing the intrinsics to >> out-of-band internal API somehow promotes to "omg, that breaks >> Java" stunts. > > Sorry to say this but I find this attitude both offensive and > counter productive to community building. Sorry to hear my directness and leaking discomfort having this discussion is again looked offensive. Switching back to nice guy mode... :I I find the discussion about exposing intrinsics to out-of-band class unnecessarily extended to the discussion on the Java language. While the goal to accommodate fences into Java language is worth discussing, it is not the part of this JEP. This JEP is about exposing these primitives to library developers who sorely need these intrinsics now, without making any promises for the general crowd. These intrinsics are unarguably unsafe, and that is why these are not even conceived to be used in "safe" Java land. > That said, I really wished that we had a better... safer way to > achieve the same effect than exposing people to unsafe. Everyone does. In fact, it had popped out countless times, so that I'm getting mad every time I hear it anew (I wonder how Doug even keeps his sanity, must be some interesting contract sealed with blood). You can emulate fences by reading/writing from/to static volatile field, and make your VM intrinsify the methods doing the read/writes, and remove the memory opts, leaving only the barriers. This would be approachable for the general public, because it has the clear semantics in terms of existing JMM ("the memory effects as if reading/writing global volatile field"). This will eventually sinkhole to "no can do: users will misuse these", and we will get back to square one to Unsafe proposal. -Aleksey. From aleksey.shipilev at oracle.com Wed Dec 5 09:56:27 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Dec 2012 21:56:27 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50BF898D.5020401@oracle.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> <50BF898D.5020401@oracle.com> Message-ID: <50BF8ACB.6050807@oracle.com> On 12/05/2012 09:51 PM, Aleksey Shipilev wrote: > These intrinsics are unarguably unsafe, and that is why these are not > even conceived to be used in "safe" Java land. Err... Should have said "constitute the moral hazard" rather that claiming the barriers are unsafe. -Aleksey. From dl at cs.oswego.edu Wed Dec 5 10:43:51 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 05 Dec 2012 13:43:51 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <04A9AB93-FCDB-4A21-A6B3-CE417D32C1F4@kodewerk.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> <50BF72E5.7010000@cs.oswego.edu> <04A9AB93-FCDB-4A21-A6B3-CE417D32C1F4@kodewerk.com> Message-ID: <50BF95E7.5060408@cs.oswego.edu> On 12/05/12 11:55, Kirk Pepperdine wrote: > ... Just one followup to again emphasize the main thrust of the proposals: Like for example, invokeDynamic, these proposals target the JVM, not Java. And like "asm" escapes in C, they are accessible by mixing some JVMese with your Java code. By all means, let's do better for Java programmers (and Scala and Clojure and Ruby programmers too). But for now it would be great to get some of the capabilities in place so we have a basis for doing so. > PS, as for the JEP process it's self.. it's not a very well known process. Give it time. Developments that interestingly impact the platform will increasingly involve JEPs. Also, please send feedback (I think the gb-discuss list would be a good place) about any meta issues about JEP process. -Doug From john.r.rose at oracle.com Wed Dec 5 12:24:39 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 5 Dec 2012 12:24:39 -0800 Subject: RFR(S): 8003983 Fix of broken logcompilation tool In-Reply-To: <50BF3A53.1000705@oracle.com> References: <50B384EB.4030207@oracle.com> <6126A3BD-B044-4998-99FC-4D5A8023CEE4@oracle.com> <50BF3A53.1000705@oracle.com> Message-ID: <48EF430C-A942-4BB5-92B2-DBCB7CBCDE5D@oracle.com> Thanks. Ship it! ? John On Dec 5, 2012, at 4:13 AM, Nils Eliasson wrote: > Yes, putting the defaults in the LogParser makes a lot of sense. > > Updated webrev: > > http://cr.openjdk.java.net/~neliasso/8003983/webrev.02/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121205/1175c74f/attachment.html From christian.thalinger at oracle.com Wed Dec 5 16:22:53 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 5 Dec 2012 16:22:53 -0800 Subject: RFR (XXL): 8003250: SPARC: move MacroAssembler into separate file Message-ID: [Prologue: As for 8003240 this patch is XXL but it's mostly verbatim copying. I say mostly because this time I had to move some methods from Assembler to MacroAssembler to get it working. Some methods were removed (e.g. test_v9, test_v8_onlys) because they were not used at all.] http://cr.openjdk.java.net/~twisti/8003250 8003250: SPARC: move MacroAssembler into separate file Reviewed-by: The assembler_.{cpp,hpp} files are already very big and we should split them into two files: assembler_.{cpp,hpp} macroAssembler_.{cpp,hpp} This is for SPARC. src/cpu/sparc/vm/assembler_sparc.cpp src/cpu/sparc/vm/macroAssembler_sparc.cpp src/cpu/sparc/vm/assembler_sparc.hpp src/cpu/sparc/vm/macroAssembler_sparc.hpp src/cpu/sparc/vm/assembler_sparc.inline.hpp src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp src/cpu/sparc/vm/frame_sparc.inline.hpp src/cpu/sparc/vm/icache_sparc.cpp src/cpu/sparc/vm/icBuffer_sparc.cpp src/cpu/sparc/vm/interp_masm_sparc.hpp src/cpu/sparc/vm/interpreter_sparc.cpp src/cpu/sparc/vm/jniFastGetField_sparc.cpp src/cpu/sparc/vm/metaspaceShared_sparc.cpp src/cpu/sparc/vm/methodHandles_sparc.cpp src/cpu/sparc/vm/nativeInst_sparc.cpp src/cpu/sparc/vm/nativeInst_sparc.hpp src/cpu/sparc/vm/relocInfo_sparc.cpp src/cpu/sparc/vm/runtime_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/vm_version_sparc.cpp src/cpu/sparc/vm/vmreg_sparc.cpp src/cpu/sparc/vm/vtableStubs_sparc.cpp src/cpu/x86/vm/assembler_x86.hpp src/cpu/x86/vm/macroAssembler_x86.cpp src/cpu/zero/vm/assembler_zero.cpp src/cpu/zero/vm/assembler_zero.hpp src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp src/share/vm/adlc/main.cpp src/share/vm/asm/assembler.hpp src/share/vm/asm/macroAssembler.hpp src/share/vm/asm/macroAssembler.inline.hpp src/share/vm/asm/register.hpp src/share/vm/code/vmreg.hpp From john.r.rose at oracle.com Wed Dec 5 17:22:13 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 5 Dec 2012 17:22:13 -0800 Subject: RFR (XXL): 8003250: SPARC: move MacroAssembler into separate file In-Reply-To: References: Message-ID: On Dec 5, 2012, at 4:22 PM, Christian Thalinger wrote: > [Prologue: As for 8003240 this patch is XXL but it's mostly verbatim copying. I say mostly because this time I had to move some methods from Assembler to MacroAssembler to get it working. Some methods were removed (e.g. test_v9, test_v8_onlys) because they were not used at all.] I did not verify the verbatim copying, but assuming that there are no extra changes hiding in the moved lines, it is good. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121205/44463841/attachment.html From christian.thalinger at oracle.com Wed Dec 5 19:17:19 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 5 Dec 2012 19:17:19 -0800 Subject: RFR (XXL): 8003250: SPARC: move MacroAssembler into separate file In-Reply-To: References: Message-ID: <884F9A0D-7D20-4E6A-90AB-2B20E8751784@oracle.com> On Dec 5, 2012, at 5:22 PM, John Rose wrote: > On Dec 5, 2012, at 4:22 PM, Christian Thalinger wrote: > >> [Prologue: As for 8003240 this patch is XXL but it's mostly verbatim copying. I say mostly because this time I had to move some methods from Assembler to MacroAssembler to get it working. Some methods were removed (e.g. test_v9, test_v8_onlys) because they were not used at all.] > > I did not verify the verbatim copying, but assuming that there are no extra changes hiding in the moved lines, it is good. Thank you, John. By Vladimir's request I removed macroAssembler.hpp includes where we include macroAssembler.inline.hpp and added the include to macroAssembler.inline.hpp: http://cr.openjdk.java.net/~twisti/8003250/src/share/vm/asm/macroAssembler.inline.hpp.udiff.html -- Chris > > ? John From Vladimir.Kozlov at oracle.com Wed Dec 5 19:34:36 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 05 Dec 2012 19:34:36 -0800 Subject: RFR (XXL): 8003250: SPARC: move MacroAssembler into separate file In-Reply-To: <884F9A0D-7D20-4E6A-90AB-2B20E8751784@oracle.com> References: <884F9A0D-7D20-4E6A-90AB-2B20E8751784@oracle.com> Message-ID: <50C0124C.3080004@oracle.com> Good. Vladimir On 12/05/12 19:17, Christian Thalinger wrote: > > On Dec 5, 2012, at 5:22 PM, John Rose wrote: > >> On Dec 5, 2012, at 4:22 PM, Christian Thalinger wrote: >> >>> [Prologue: As for 8003240 this patch is XXL but it's mostly verbatim copying. I say mostly because this time I had to move some methods from Assembler to MacroAssembler to get it working. Some methods were removed (e.g. test_v9, test_v8_onlys) because they were not used at all.] >> >> I did not verify the verbatim copying, but assuming that there are no extra changes hiding in the moved lines, it is good. > > Thank you, John. > > By Vladimir's request I removed macroAssembler.hpp includes where we include macroAssembler.inline.hpp and added the include to macroAssembler.inline.hpp: > > http://cr.openjdk.java.net/~twisti/8003250/src/share/vm/asm/macroAssembler.inline.hpp.udiff.html > > -- Chris > >> >> ? John > From nils.eliasson at oracle.com Thu Dec 6 05:29:34 2012 From: nils.eliasson at oracle.com (nils.eliasson at oracle.com) Date: Thu, 06 Dec 2012 13:29:34 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8003983: LogCompilation tool is broken since c1 support Message-ID: <20121206132946.2912747F13@hg.openjdk.java.net> Changeset: c5d414e98fd4 Author: neliasso Date: 2012-11-26 15:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c5d414e98fd4 8003983: LogCompilation tool is broken since c1 support Summary: Fixed emitting and parsing Reviewed-by: jrose, kvn ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/vm/c1/c1_Compilation.cpp From christian.thalinger at oracle.com Thu Dec 6 09:57:39 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 6 Dec 2012 09:57:39 -0800 Subject: RFR (XXL): 8003250: SPARC: move MacroAssembler into separate file In-Reply-To: <50C0124C.3080004@oracle.com> References: <884F9A0D-7D20-4E6A-90AB-2B20E8751784@oracle.com> <50C0124C.3080004@oracle.com> Message-ID: Thank you, Vladimir. -- Chris On Dec 5, 2012, at 7:34 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 12/05/12 19:17, Christian Thalinger wrote: >> >> On Dec 5, 2012, at 5:22 PM, John Rose wrote: >> >>> On Dec 5, 2012, at 4:22 PM, Christian Thalinger wrote: >>> >>>> [Prologue: As for 8003240 this patch is XXL but it's mostly verbatim copying. I say mostly because this time I had to move some methods from Assembler to MacroAssembler to get it working. Some methods were removed (e.g. test_v9, test_v8_onlys) because they were not used at all.] >>> >>> I did not verify the verbatim copying, but assuming that there are no extra changes hiding in the moved lines, it is good. >> >> Thank you, John. >> >> By Vladimir's request I removed macroAssembler.hpp includes where we include macroAssembler.inline.hpp and added the include to macroAssembler.inline.hpp: >> >> http://cr.openjdk.java.net/~twisti/8003250/src/share/vm/asm/macroAssembler.inline.hpp.udiff.html >> >> -- Chris >> >>> >>> ? John >> From bharadwaj.yadavalli at oracle.com Thu Dec 6 10:36:18 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 06 Dec 2012 13:36:18 -0500 Subject: RFR (XXS): Fix build failure for Zero target Message-ID: <50C0E5A2.50000@oracle.com> Please review a very small change needed to address a build failure for Zero target. http://cr.openjdk.java.net/~bharadwaj/shark/webrev/ Thanks, Bharadwaj From nils.eliasson at oracle.com Thu Dec 6 11:02:11 2012 From: nils.eliasson at oracle.com (nils.eliasson at oracle.com) Date: Thu, 06 Dec 2012 19:02:11 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20121206190217.A903A47F48@hg.openjdk.java.net> Changeset: b7ff5879152e Author: neliasso Date: 2012-12-06 09:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b7ff5879152e 8003934: Fix generation of malformed options to Projectcreator Summary: Makefile produces unmatched quotes due to nmake bug Reviewed-by: jwilhelm, brutisso ! make/windows/projectfiles/common/Makefile Changeset: 228a94f37a67 Author: neliasso Date: 2012-12-06 14:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/228a94f37a67 Merge From christian.thalinger at oracle.com Thu Dec 6 11:42:47 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 6 Dec 2012 11:42:47 -0800 Subject: RFR (XXS): Fix build failure for Zero target In-Reply-To: <50C0E5A2.50000@oracle.com> References: <50C0E5A2.50000@oracle.com> Message-ID: <53DCF3F8-D801-4495-B6D2-88FB73E83F5A@oracle.com> On Dec 6, 2012, at 10:36 AM, Bharadwaj Yadavalli wrote: > Please review a very small change needed to address a build failure for Zero target. > > http://cr.openjdk.java.net/~bharadwaj/shark/webrev/ Looks good. What's the bug number? -- Chris > > Thanks, > > Bharadwaj > From Vladimir.Kozlov at oracle.com Thu Dec 6 11:43:46 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 06 Dec 2012 11:43:46 -0800 Subject: RFR (XXS): Fix build failure for Zero target In-Reply-To: <50C0E5A2.50000@oracle.com> References: <50C0E5A2.50000@oracle.com> Message-ID: <50C0F572.1000509@oracle.com> Good. Thanks, Vladimir On 12/06/12 10:36, Bharadwaj Yadavalli wrote: > Please review a very small change needed to address a build failure for > Zero target. > > http://cr.openjdk.java.net/~bharadwaj/shark/webrev/ > > Thanks, > > Bharadwaj > From bharadwaj.yadavalli at oracle.com Thu Dec 6 11:49:51 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 06 Dec 2012 14:49:51 -0500 Subject: RFR (XXS): Fix build failure for Zero target In-Reply-To: <53DCF3F8-D801-4495-B6D2-88FB73E83F5A@oracle.com> References: <50C0E5A2.50000@oracle.com> <53DCF3F8-D801-4495-B6D2-88FB73E83F5A@oracle.com> Message-ID: <50C0F6DF.8050502@oracle.com> On 12/6/2012 2:42 PM, Christian Thalinger wrote: > Looks good. What's the bug number? Thanks. JDK-8004668 (https://jbs.oracle.com/bugs/browse/JDK-8004668) Bharadwaj From rkennke at redhat.com Thu Dec 6 11:52:20 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 06 Dec 2012 20:52:20 +0100 Subject: RFR (XXS): Fix build failure for Zero target In-Reply-To: <50C0E5A2.50000@oracle.com> References: <50C0E5A2.50000@oracle.com> Message-ID: <1354823540.1747.12.camel@mercury> Am Donnerstag, den 06.12.2012, 13:36 -0500 schrieb Bharadwaj Yadavalli: > Please review a very small change needed to address a build failure for > Zero target. > > http://cr.openjdk.java.net/~bharadwaj/shark/webrev/ I am not an official reviewer, but thought I'd throw in that I tested this with Zero and Shark and it works fine. Thanks, Roman From bharadwaj.yadavalli at oracle.com Thu Dec 6 12:03:03 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 06 Dec 2012 15:03:03 -0500 Subject: RFR (XXS): Fix build failure for Zero target In-Reply-To: <1354823540.1747.12.camel@mercury> References: <50C0E5A2.50000@oracle.com> <1354823540.1747.12.camel@mercury> Message-ID: <50C0F9F7.70307@oracle.com> On 12/6/2012 2:52 PM, Roman Kennke wrote: > Am Donnerstag, den 06.12.2012, 13:36 -0500 schrieb Bharadwaj Yadavalli: >> Please review a very small change needed to address a build failure for >> Zero target. >> >> http://cr.openjdk.java.net/~bharadwaj/shark/webrev/ > I am not an official reviewer, but thought I'd throw in that I tested > this with Zero and Shark and it works fine. Great! Thanks for you testing it and letting me know, Roman. Bharadwaj From rkennke at redhat.com Thu Dec 6 12:30:49 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 06 Dec 2012 21:30:49 +0100 Subject: RFR: Fix OSR in Shark for non-empty incoming stack Message-ID: <1354825849.1747.28.camel@mercury> This patch disables on-stack-replacement in Shark when the incoming stack-depth is > 0. (This caused a segmentation fault when running SpecJVM.) http://cr.openjdk.java.net/~rkennke/shark-osr/webrev.00/ I tried to figure out what to do in that case for a while, until I looked at opto which simply bails out, so I decided to do the same. Is there anything better that could be done without huge efforts (it seems to happen very rarely after all)? Ok to go in? (I have a bunch of patches coming up for Shark, I was undecided if I should post them as one big or several smaller patches, and then found that having several unrelated things interleaved in one patch makes it really difficult to understand what it does.) Regards, Roman From rkennke at redhat.com Thu Dec 6 12:43:18 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 06 Dec 2012 21:43:18 +0100 Subject: RFR: Implement deoptimization support in Shark Message-ID: <1354826598.1747.36.camel@mercury> This change implements support for method deoptimization in Shark, and thus (re-) enables an optimization for potentially inlining virtual methods. http://cr.openjdk.java.net/~rkennke/shark-deopt/webrev.01/ This optimization has been enabled before, a while ago, but has been disabled because it leads to segmentation faults: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=481 I used the testcase in the above bugreport (one of the jtreg tests in jdk) to verify that the change does indeed deoptimize (and re-compile) methods correctly. Besides that, no regressions could be found in hotspot/test/compiler (and a bunch of other tests and programs I've been running, including SpecJVM, Eclipse, etc). Ok to go in? Cheers, Roman From rkennke at redhat.com Thu Dec 6 12:48:01 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 06 Dec 2012 21:48:01 +0100 Subject: RFR: Fix volatile float field access in Shark Message-ID: <1354826881.1747.39.camel@mercury> One of the jtreg tests (test/compiler/6796786/Test6796786.java) was failing with Shark because LLVM could not compile atomic load/store for float (and double). This change inserts a bitcast to the int type with same width. http://cr.openjdk.java.net/~rkennke/shark-atomic/webrev/ Ok to go in? Roman From rkennke at redhat.com Thu Dec 6 13:02:08 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 06 Dec 2012 22:02:08 +0100 Subject: Enable JSR292 support in Shark Message-ID: <1354827728.1747.50.camel@mercury> This patch enables JSR292 support in Shark. It's cheating though: for everything related to JSR292 it basically reverts to the interpreter (Zero.. which does implement JSR292). http://cr.openjdk.java.net/~rkennke/shark-jsr292/webrev.00/ More specifically, it refuses to compile all methods that have an or invokedynamic, invokehandle instruction or which do call out to one of the 4 MH/varargs intrinsics or which are themselves a compiled lambda-form. It also does not compile a native wrapper for those intrinsics, because we need to call the interpreter entry points. Native wrappers would throw UnsatisfiedLinkError because there is no corresponding native method available. There's one little change in AbstractCompiler: I added a method can_compile_method() in order to give me a way to intercept compilation for the intrinsics (which are native methods and can not be trapped like Java methods). If you know of a better way to achieve this (ideally without touching non-Shark code) please let me know. There's another odd thing that I noticed: ciField->is_constant() doesn't (at least not always?) also mean that the field is static. Is this correct? The docs for is_constant() seem to imply otherwise. (Infact, I noticed this oddity when attempting to compile the lambda forms. I believe I have seen other odd things like calling a non-static method with an invokestatic instruction, which tripped an assert. Is it possible that those compiled lambda forms do odd (invalid?) stuff like that and only get away with it because of some sort of non-strictness in the intepreters/compilers? Maybe I did not look close enough though, because I then decided to simply not compile those lambda forms at all.. ;-) I guess I will get back to that later when I implement this stuff in Shark for real.) Some opinions on the above would be greatly appreciated. (That's the last patch in this series for now.) Best regards, Roman From christian.thalinger at oracle.com Thu Dec 6 13:05:51 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 06 Dec 2012 21:05:51 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20121206210555.A1DAB47F57@hg.openjdk.java.net> Changeset: f0c2369fda5a Author: twisti Date: 2012-12-06 09:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f0c2369fda5a 8003250: SPARC: move MacroAssembler into separate file Reviewed-by: jrose, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/icBuffer_sparc.cpp ! src/cpu/sparc/vm/icache_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp + src/cpu/sparc/vm/macroAssembler_sparc.cpp + src/cpu/sparc/vm/macroAssembler_sparc.hpp + src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/sparc/vm/metaspaceShared_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/runtime_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/vm_version_sparc.cpp ! src/cpu/sparc/vm/vmreg_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/code/vmreg.hpp Changeset: 522662fa9c16 Author: twisti Date: 2012-12-06 11:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/522662fa9c16 Merge From david.r.chase at oracle.com Thu Dec 6 14:03:03 2012 From: david.r.chase at oracle.com (David Chase) Date: Thu, 6 Dec 2012 17:03:03 -0500 Subject: RFR: Fix OSR in Shark for non-empty incoming stack In-Reply-To: <1354825849.1747.28.camel@mercury> References: <1354825849.1747.28.camel@mercury> Message-ID: <9977897D-B686-492D-A8DC-0CB050B07127@oracle.com> Minor glitch in a comment in SharkInvariants: ---- // Accessing this directly is kind of ugly, so it's private. Add // new accessors below if you need something from it. ! protected: ---- It's not private anymore. David From john.r.rose at oracle.com Thu Dec 6 14:08:50 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 6 Dec 2012 14:08:50 -0800 Subject: Enable JSR292 support in Shark In-Reply-To: <1354827728.1747.50.camel@mercury> References: <1354827728.1747.50.camel@mercury> Message-ID: On Dec 6, 2012, at 1:02 PM, Roman Kennke wrote: > There's one little change in AbstractCompiler: I added a method > can_compile_method() in order to give me a way to intercept compilation > for the intrinsics (which are native methods and can not be trapped like > Java methods). If you know of a better way to achieve this (ideally > without touching non-Shark code) please let me know. That seems reasonable, for now, as long as you never call those intrinsics from compiled code, ever. The new intrinsics are tricky, because they are not allowed to fall back to the normal c2i/i2c adapter paths. The reason for this is they are sensitive to details of argument packing and ordering, which c2i/i2c transitions disrupt. Therefore, if one of those intrinsics is ever called from compiled code, it must not go through a c2i transition, but must be handled by a bespoke compiled adapter. Apparently your change respects this invariant, by refusing to compile the affected call sites. See: https://wikis.oracle.com/display/HotSpotInternals/Linker+methods+for+direct+method+handles (BTW, I think the community would be grateful if you would add to these pages or adjust them as you "discover" poorly documented parts of the system. Say the word and I'll give you edit access to the wiki.) > There's another odd thing that I noticed: ciField->is_constant() doesn't > (at least not always?) also mean that the field is static. Is this > correct? The docs for is_constant() seem to imply otherwise. We are interpreting ciField.is_constant to mean "this field, viewed as a variable, does not change in the future". In other words, it behaves like we expect a final field to behave, with no allowance for trickery from java.lang.reflect.Field.set. It does not mean "this field represents a value which is syntactically a constant as defined by the JLS" or "...which has a ConstantValue attribute." We plan to update this documentation in this patch: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/anno-stable-8001107.patch > (Infact, I noticed this oddity when attempting to compile the lambda > forms. I believe I have seen other odd things like calling a non-static > method with an invokestatic instruction, which tripped an assert. That should not happen. > Is it > possible that those compiled lambda forms do odd (invalid?) stuff like > that and only get away with it because of some sort of non-strictness in > the intepreters/compilers? There is non-strictness in the binding of invokedynamic or invokehandle to target methods. Specifically, the method bound to an invokedynamic, or the method entered (via a MH) from an invokehandle, can be either static or non-static, as long as its basic type signature matches the call site. (And by "basic", I mean that references are detuned to Object and subwords like boolean are detuned to int.) If the method is non-static, it is treated (for such calls) exactly as if it were a static method with a prepended receiver argument. Also, if the call site features an "appendix" argument, it is treated as if it accepted a trailing reference parameter. For more details see: https://wikis.oracle.com/display/HotSpotInternals/Method+handles+and+invokedynamic > Maybe I did not look close enough though, > because I then decided to simply not compile those lambda forms at > all.. ;-) I guess I will get back to that later when I implement this > stuff in Shark for real.) That's reasonable, I think, since those guys call the linker intrinsics which will give you problems (with c2i/i2c as noted above). > Some opinions on the above would be greatly appreciated. HTH. And, seriously, consider being a HSI wiki contributor. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121206/579fe9d5/attachment-0001.html From rkennke at redhat.com Thu Dec 6 15:08:30 2012 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 07 Dec 2012 00:08:30 +0100 Subject: Enable JSR292 support in Shark In-Reply-To: References: <1354827728.1747.50.camel@mercury> Message-ID: <1354835310.1747.64.camel@mercury> Hi John, > > There's one little change in AbstractCompiler: I added a method > > can_compile_method() in order to give me a way to intercept > > compilation > > for the intrinsics (which are native methods and can not be trapped > > like > > Java methods). If you know of a better way to achieve this (ideally > > without touching non-Shark code) please let me know. > > > That seems reasonable, for now, as long as you never call those > intrinsics from compiled code, ever. > > > The new intrinsics are tricky, because they are not allowed to fall > back to the normal c2i/i2c adapter paths. The reason for this is they > are sensitive to details of argument packing and ordering, which > c2i/i2c transitions disrupt. Therefore, if one of those intrinsics is > ever called from compiled code, it must not go through a c2i > transition, but must be handled by a bespoke compiled adapter. > Apparently your change respects this invariant, by refusing to > compile the affected call sites. > I see. I sortof learned that. The hard way ;-) > See: > https://wikis.oracle.com/display/HotSpotInternals/Linker+methods+for > +direct+method+handles > > > (BTW, I think the community would be grateful if you would add to > these pages or adjust them as you "discover" poorly documented parts > of the system. Say the word and I'll give you edit access to the > wiki.) Cool, somehow I managed to not find these docs when I implemented the interpreter part of this a while back and figured out everything by taking apart the assembly stuff in the template interpreter. (I believe, the Zero impl does make for nice documentation now though, the code came out surprisingly straightforward. If you're interested, it's all in methodHandles_zero.cpp). > > There's another odd thing that I noticed: ciField->is_constant() > > doesn't > > (at least not always?) also mean that the field is static. Is this > > correct? The docs for is_constant() seem to imply otherwise. > > > We are interpreting ciField.is_constant to mean "this field, viewed as > a variable, does not change in the future". In other words, it > behaves like we expect a final field to behave, with no allowance for > trickery from java.lang.reflect.Field.set. It does not mean "this > field represents a value which is syntactically a constant as defined > by the JLS" or "...which has a ConstantValue attribute." Uhh, ok, so I need to change some more code (mainly asserts) to is_final() && is_static() or such ;-) > We plan to update this documentation in this patch: > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/anno-stable-8001107.patch > > > > (Infact, I noticed this oddity when attempting to compile the lambda > > forms. I believe I have seen other odd things like calling a > > non-static > > method with an invokestatic instruction, which tripped an assert. > > > That should not happen. I will look at it again, and see what exactly happened. > > Is it > > possible that those compiled lambda forms do odd (invalid?) stuff > > like > > that and only get away with it because of some sort of > > non-strictness in > > the intepreters/compilers? > > > There is non-strictness in the binding of invokedynamic or > invokehandle to target methods. Specifically, the method bound to an > invokedynamic, or the method entered (via a MH) from an invokehandle, > can be either static or non-static, as long as its basic type > signature matches the call site. (And by "basic", I mean that > references are detuned to Object and subwords like boolean are detuned > to int.) If the method is non-static, it is treated (for such calls) > exactly as if it were a static method with a prepended receiver > argument. Also, if the call site features an "appendix" argument, it > is treated as if it accepted a trailing reference parameter. Ok this makes sense. > For more details see: > https://wikis.oracle.com/display/HotSpotInternals/Method+handles+and > +invokedynamic > > > Maybe I did not look close enough though, > > because I then decided to simply not compile those lambda forms at > > all.. ;-) I guess I will get back to that later when I implement > > this > > stuff in Shark for real.) > > > That's reasonable, I think, since those guys call the linker > intrinsics which will give you problems (with c2i/i2c as noted above). > > > Some opinions on the above would be greatly appreciated. > > HTH. And, seriously, consider being a HSI wiki contributor. Thanks a lot for your explanations, it's really helpful. I would like to (potentially) contribute to the HSI wiki, if you want to give me access :-) Cheers, Roman From bharadwaj.yadavalli at oracle.com Thu Dec 6 15:20:12 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 06 Dec 2012 18:20:12 -0500 Subject: Remove AbstractAssembler::print(Label& L) Message-ID: <50C1282C.50000@oracle.com> We wish to get rid of AbstractAssembler::print(Label& L) as it is not called in the Hotspot code anywhere. However, before doing so, I would like to know if there is someone that might be using it for debugging purposes such as calling in the debugger. Thanks, Bharadwaj From john.coomes at oracle.com Thu Dec 6 20:38:19 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:38:19 +0000 Subject: hg: hsx/hotspot-comp: 6 new changesets Message-ID: <20121207043820.308E647F8E@hg.openjdk.java.net> Changeset: 98a7af257bee Author: erikj Date: 2012-12-03 10:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/98a7af257bee 8003819: build-infra: backslashes at end of LIB and INCLUDE in spec.gmk Summary: Removing trailing backslash from LIB and INCLUDE. Reviewed-by: ohrstrom, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 754f91d22e1c Author: erikj Date: 2012-12-05 09:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/754f91d22e1c 8001541: Cannot build on Solaris using softlinks Summary: Fixed softlink resolver macro in configure. Reviewed-by: tbell, ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: ec187d02c95e Author: erikj Date: 2012-12-05 10:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ec187d02c95e 8004281: build-infra: Move all jar creation to images target and put jars in images/lib Summary: Fixed bug in setting up make dependencies in SetupArchive. Reviewed-by: ohair, tbell, dholmes ! common/makefiles/JavaCompilation.gmk Changeset: bd32ef0789ca Author: erikj Date: 2012-12-05 16:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/bd32ef0789ca 8003414: build-infra: fails on on windows Summary: Added extra check that windows sdk is valid. Reviewed-by: tbell, ohrstrom, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 9a6ec97ec45c Author: katleman Date: 2012-12-05 12:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/9a6ec97ec45c Merge Changeset: c91c581321ce Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/c91c581321ce Added tag jdk8-b67 for changeset 9a6ec97ec45c ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:38:24 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:38:24 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b67 for changeset 394515ad2a55 Message-ID: <20121207043826.E5BA247F8F@hg.openjdk.java.net> Changeset: 82000531feaa Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/82000531feaa Added tag jdk8-b67 for changeset 394515ad2a55 ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:38:31 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:38:31 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b67 for changeset 83df3493ca3c Message-ID: <20121207043838.D32D247F90@hg.openjdk.java.net> Changeset: b854e7008421 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/b854e7008421 Added tag jdk8-b67 for changeset 83df3493ca3c ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:38:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:38:43 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b67 for changeset eb06aa51dfc2 Message-ID: <20121207043848.14EED47F91@hg.openjdk.java.net> Changeset: d3fe408f3a9a Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/d3fe408f3a9a Added tag jdk8-b67 for changeset eb06aa51dfc2 ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:38:56 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:38:56 +0000 Subject: hg: hsx/hotspot-comp/jdk: 4 new changesets Message-ID: <20121207044018.0449247F92@hg.openjdk.java.net> Changeset: b0f008ab45d7 Author: twisti Date: 2012-11-30 11:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b0f008ab45d7 8001885: JSR 292 classes should use jdk.internal.org.objectweb.asm Reviewed-by: kvn, jrose, twisti Contributed-by: David Chase ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 0fda013e4638 Author: erikj Date: 2012-12-05 10:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0fda013e4638 8004281: build-infra: Move all jar creation to images target and put jars in images/lib Reviewed-by: ohair, tbell, dholmes ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk Changeset: ce9b02a3a17e Author: katleman Date: 2012-12-05 12:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ce9b02a3a17e Merge Changeset: ea0d3a9d0d01 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ea0d3a9d0d01 Added tag jdk8-b67 for changeset ce9b02a3a17e ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:41:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:41:27 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b67 for changeset 303b09787a69 Message-ID: <20121207044135.6A88547F93@hg.openjdk.java.net> Changeset: e9a13a6c9d5d Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e9a13a6c9d5d Added tag jdk8-b67 for changeset 303b09787a69 ! .hgtags From xerox.time.tech at gmail.com Fri Dec 7 13:52:03 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Fri, 7 Dec 2012 16:52:03 -0500 Subject: hash value in java objects Message-ID: I am wondering when the hash values in the java objects are materialized. are they materialized when the object is created ? or when hashCode on the object is called. what about modifications to the object ? Xin From alejandro.murillo at oracle.com Fri Dec 7 14:16:09 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 07 Dec 2012 22:16:09 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 34 new changesets Message-ID: <20121207221723.0606547FC8@hg.openjdk.java.net> Changeset: 2f6dc76eb8e5 Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2f6dc76eb8e5 Added tag jdk8-b66 for changeset 01684f7fee1b ! .hgtags Changeset: 49cbd3e25ba9 Author: zgu Date: 2012-11-16 09:05 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/49cbd3e25ba9 8003487: NMT: incorrect assertion in VMMemPointerIterator::remove_released_region method (memSnapshot.cpp) Summary: The assertion is applied to only the region to be released, also performs region integrity checking Reviewed-by: acorn, coleenp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp Changeset: 3ed6de6e139b Author: coleenp Date: 2012-11-20 20:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3ed6de6e139b Merge Changeset: 73e64867adb7 Author: mikael Date: 2012-11-21 09:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/73e64867adb7 8003690: Example code in JVMTI GetStackTrace documentation is broken Summary: Fixed to minor errors in example code Reviewed-by: sspitsyn, dholmes ! src/share/vm/prims/jvmti.xml Changeset: 6b881a6b0665 Author: dholmes Date: 2012-11-21 20:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6b881a6b0665 8003591: Abstract_VM_Version::internal_vm_info_string needs to stringify FLOAT_ARCH for ease of use Reviewed-by: coleenp, kvn ! src/share/vm/runtime/vm_version.cpp Changeset: ca1be5fbe6ff Author: dholmes Date: 2012-11-21 21:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ca1be5fbe6ff Merge Changeset: 7c15faa95ce7 Author: mikael Date: 2012-11-27 07:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7c15faa95ce7 8003879: Duplicate definitions in vmStructs Summary: Removed duplicate entries Reviewed-by: dholmes, sspitsyn ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp Changeset: bbc14465e7db Author: zgu Date: 2012-11-28 09:19 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bbc14465e7db 8003689: MemTracker::init_tracking_options() reads outside array if commandline argument is empty Summary: Fixed potential buffer overrun when giving empty option to NativeMemoryTracking commandline option Reviewed-by: ctornqvi, hseigel, kvn ! src/share/vm/services/memTracker.cpp Changeset: 5de2a5bd519e Author: zgu Date: 2012-11-28 06:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5de2a5bd519e Merge Changeset: fe81517cfb77 Author: hseigel Date: 2012-11-28 08:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fe81517cfb77 6924920: Class Data Sharing limit on the java version string can create failures Summary: Truncate the java version string and add a hash value if it is too long. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/filemap.cpp Changeset: b51dc8df86e5 Author: coleenp Date: 2012-11-28 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b51dc8df86e5 Merge Changeset: 59c790074993 Author: coleenp Date: 2012-11-28 17:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/59c790074993 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call Summary: Make metaspace::contains be lock free and used to see if something is in metaspace, also compare Method* with vtbl pointer. Reviewed-by: dholmes, sspitsyn, dcubed, jmasa ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 53715fb1597d Author: brutisso Date: 2012-11-20 11:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/53715fb1597d 7198334: UseNUMA modifies system parameters on non-NUMA system Summary: The flags MinHeapDeltaBytes and UseNUMAInterleaving must be adjusted after the OS have adjusted the UseNUMA flag in the method os::init_2. Reviewed-by: dholmes, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp Changeset: 19c1bd641922 Author: coleenp Date: 2012-11-26 12:31 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/19c1bd641922 8003722: More gcc 4.7 compilation errors Summary: Add a few more this->qualifications. Reviewed-by: coleenp, dholmes Contributed-by: duboscq at ssw.jku.at ! src/share/vm/memory/binaryTreeDictionary.cpp Changeset: d0aa87f04bd5 Author: stefank Date: 2012-11-27 10:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d0aa87f04bd5 8003720: NPG: Method in interpreter stack frame can be deallocated Summary: Pass down a closure during root scanning to keep the class of the method alive. Reviewed-by: coleenp, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp + test/runtime/8003720/Asmator.java + test/runtime/8003720/Test8003720.java + test/runtime/8003720/Victim.java + test/runtime/8003720/VictimClassLoader.java Changeset: f34d701e952e Author: stefank Date: 2012-11-27 14:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f34d701e952e 8003935: Simplify the needed includes for using Thread::current() Reviewed-by: dholmes, rbackman, coleenp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/os/bsd/vm/mutex_bsd.cpp ! src/os/bsd/vm/mutex_bsd.inline.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/threadCritical_bsd.cpp ! src/os/bsd/vm/thread_bsd.inline.hpp ! src/os/linux/vm/mutex_linux.cpp ! src/os/linux/vm/mutex_linux.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/threadCritical_linux.cpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/os/solaris/vm/mutex_solaris.cpp ! src/os/solaris/vm/mutex_solaris.inline.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/os/windows/vm/mutex_windows.cpp ! src/os/windows/vm/mutex_windows.inline.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/threadCritical_windows.cpp ! src/os/windows/vm/thread_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/threadLS_linux_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/threadLS_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/threadLS_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/threadLS_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp + src/share/vm/runtime/thread.inline.hpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 2fc0334f613a Author: johnc Date: 2012-11-27 14:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2fc0334f613a 7194633: G1: Assertion and guarantee failures in block offset table Summary: Add detailed error messages to assertions and guarantees in G1's block offset table. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/memory/space.cpp Changeset: c24f778e9401 Author: johnc Date: 2012-11-29 11:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c24f778e9401 Merge ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b2dbd323c668 Author: jiangli Date: 2012-11-27 17:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b2dbd323c668 8003848: Make ConstMethod::generic_signature_index optional and move Method::_max_stack to ConstMethod. Summary: Make ConstMethod::generic_signature_index optional and move Method::_max_stack to ConstMethod. Reviewed-by: bdelsart, sspitsyn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5505fbbae3d3 Author: cjplummer Date: 2012-11-29 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5505fbbae3d3 Merge ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 90273fc0a981 Author: coleenp Date: 2012-11-29 16:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/90273fc0a981 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap Summary: Add ClassLoaderData object for each anonymous class with metaspaces to allocate in. Reviewed-by: twisti, jrose, stefank ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/ci/ciReplay.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/prims/unsafe.cpp Changeset: dad48145e775 Author: stefank Date: 2012-11-29 23:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dad48145e775 8004199: Change the ASM package for Test8003720 Reviewed-by: kvn, jrose ! test/runtime/8003720/Asmator.java ! test/runtime/8003720/Test8003720.java Changeset: 5fafdef522c6 Author: johnc Date: 2012-11-30 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5fafdef522c6 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: b61d9c88b759 Author: amurillo Date: 2012-11-30 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b61d9c88b759 Merge Changeset: 25bdce771bb3 Author: amurillo Date: 2012-11-30 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/25bdce771bb3 Added tag hs25-b11 for changeset b61d9c88b759 ! .hgtags Changeset: 10587a580c51 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/10587a580c51 Added tag jdk8-b67 for changeset 25bdce771bb3 ! .hgtags Changeset: 816b7e5bf2ed Author: amurillo Date: 2012-11-30 17:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/816b7e5bf2ed 8004248: new hotspot build - hs25-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d2f8c38e543d Author: roland Date: 2012-12-07 01:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d2f8c38e543d Merge ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp Changeset: 0f80645e9c26 Author: johnc Date: 2012-11-30 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0f80645e9c26 8004170: G1: Verbose GC output is not getting flushed to log file using JDK 8 Summary: Add flushes to G1CollectedHeap::log_gc_footer() and TraceCPUTime destructor. Reviewed-by: jwilhelm, azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/timer.cpp Changeset: eade6b2e4782 Author: jmasa Date: 2012-11-29 10:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eade6b2e4782 8003554: NPG: move Metablock and Metachunk code out of metaspace.cpp Reviewed-by: coleenp + src/share/vm/memory/metablock.cpp + src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metaspace.cpp Changeset: cbe736bc70fa Author: jwilhelm Date: 2012-12-07 07:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cbe736bc70fa Merge Changeset: a35a72dd2e12 Author: amurillo Date: 2012-12-07 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a35a72dd2e12 Merge Changeset: 121aa71316af Author: amurillo Date: 2012-12-07 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/121aa71316af Added tag hs25-b12 for changeset a35a72dd2e12 ! .hgtags Changeset: 4a2ed49abd51 Author: amurillo Date: 2012-12-07 10:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4a2ed49abd51 8004724: new hotspot build - hs25-b13 Reviewed-by: jcoomes ! make/hotspot_version From vitalyd at gmail.com Fri Dec 7 14:31:26 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 7 Dec 2012 17:31:26 -0500 Subject: hash value in java objects In-Reply-To: References: Message-ID: Hash is encoded in the mark word, so I think the answer to your question is it's created when object is allocated (and thus gets a markOop). The actual hash value is decoded from the mark word at call time, but it's just a shift and mask at that point. Someone can correct me if this is wrong. Thanks Sent from my phone On Dec 7, 2012 4:52 PM, "Xin Tong" wrote: > I am wondering when the hash values in the java objects are > materialized. are they materialized when the object is created ? or > when hashCode on the object is called. what about modifications to > the object ? > > Xin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121207/4337297f/attachment.html From john.r.rose at oracle.com Fri Dec 7 16:06:36 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 7 Dec 2012 16:06:36 -0800 Subject: Enable JSR292 support in Shark In-Reply-To: <1354835310.1747.64.camel@mercury> References: <1354827728.1747.50.camel@mercury> <1354835310.1747.64.camel@mercury> Message-ID: On Dec 6, 2012, at 3:08 PM, Roman Kennke wrote: > Thanks a lot for your explanations, it's really helpful. I would like to > (potentially) contribute to the HSI wiki, if you want to give me > access :-) Good! Is rkennke at gmail.com your Oracle SSO login? If so I'll add you to the wiki editors. If not, let me know the login you'll be using with the wiki. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121207/4fb6e8da/attachment-0001.html From vladimir.kozlov at oracle.com Fri Dec 7 16:42:12 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 07 Dec 2012 16:42:12 -0800 Subject: Request for reviews (XS): 8004741: Missing compiled exception handle table entry for multidimensional array allocation In-Reply-To: <4FA969C9.4090003@oracle.com> References: <4FA969C9.4090003@oracle.com> Message-ID: <50C28CE4.6010404@oracle.com> http://cr.openjdk.java.net/~kvn/8004741/webrev Added missing exception path for multidimensional array allocation runtime calls. It cased "missing exception handler" error during an exception processing on the return from such runtime call. It is very rare case because usually the compiled frame is deoptimized (go back to Interpreter) to process an exception. Thanks, Vladimir From christian.thalinger at oracle.com Fri Dec 7 17:32:28 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 7 Dec 2012 17:32:28 -0800 Subject: Request for reviews (XS): 8004741: Missing compiled exception handle table entry for multidimensional array allocation In-Reply-To: <50C28CE4.6010404@oracle.com> References: <4FA969C9.4090003@oracle.com> <50C28CE4.6010404@oracle.com> Message-ID: <9F818F6A-D60C-413E-B291-B256183E1F59@oracle.com> Looks good. -- Chris On Dec 7, 2012, at 4:42 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8004741/webrev > > Added missing exception path for multidimensional array allocation runtime calls. It cased "missing exception handler" error during an exception processing on the return from such runtime call. It is very rare case because usually the compiled frame is deoptimized (go back to Interpreter) to process an exception. > > Thanks, > Vladimir > > From Vladimir.Kozlov at oracle.com Fri Dec 7 18:11:13 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 07 Dec 2012 18:11:13 -0800 Subject: Request for reviews (XS): 8004741: Missing compiled exception handle table entry for multidimensional array allocation In-Reply-To: <9F818F6A-D60C-413E-B291-B256183E1F59@oracle.com> References: <4FA969C9.4090003@oracle.com> <50C28CE4.6010404@oracle.com> <9F818F6A-D60C-413E-B291-B256183E1F59@oracle.com> Message-ID: <50C2A1C1.1050802@oracle.com> Thank you, Christian As you asked I modified code in JavaThread::send_thread_stop() to skip deoptimization and immediately hit the failure without fix. Thanks, Vladimir On 12/07/12 17:32, Christian Thalinger wrote: > Looks good. -- Chris > > On Dec 7, 2012, at 4:42 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8004741/webrev >> >> Added missing exception path for multidimensional array allocation runtime calls. It cased "missing exception handler" error during an exception processing on the return from such runtime call. It is very rare case because usually the compiled frame is deoptimized (go back to Interpreter) to process an exception. >> >> Thanks, >> Vladimir >> >> > From vladimir.kozlov at oracle.com Fri Dec 7 20:27:05 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 08 Dec 2012 04:27:05 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004668: Build failure for Zero target Message-ID: <20121208042707.9B7C947FD4@hg.openjdk.java.net> Changeset: 0c535211ef13 Author: bharadwaj Date: 2012-12-07 18:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0c535211ef13 8004668: Build failure for Zero target Summary: fixed build failure for Zero target Reviewed-by: twisti, kvn ! src/cpu/zero/vm/assembler_zero.cpp From rednaxelafx at gmail.com Fri Dec 7 20:38:46 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 8 Dec 2012 12:38:46 +0800 Subject: hash value in java objects In-Reply-To: References: Message-ID: Short answer is the identity hash code is calculated when: 1. the hashCode() method is called the first time for this object, if the type of this object doesn't override Object.hashCode(); 2. System.identityHashCode() is called the first time for this object. A "0" value encoded as the hash in the mark word indicates that the identity hash code hasn't been calculated yet (which is the initial state after an object is created). If the type of an object overrides Object.hashCode(), then calling it doesn't have anything to do with the identity hash code. The identity hash code of a Java object is stored in the mark word of the object header if it has been calculated and the object is unlocked. Otherwise it may be stored in the displaced mark word or in the inflated lock. - Kris On Sat, Dec 8, 2012 at 6:31 AM, Vitaly Davidovich wrote: > Hash is encoded in the mark word, so I think the answer to your question is > it's created when object is allocated (and thus gets a markOop). The actual > hash value is decoded from the mark word at call time, but it's just a shift > and mask at that point. Someone can correct me if this is wrong. > > Thanks > > Sent from my phone > > On Dec 7, 2012 4:52 PM, "Xin Tong" wrote: >> >> I am wondering when the hash values in the java objects are >> materialized. are they materialized when the object is created ? or >> when hashCode on the object is called. what about modifications to >> the object ? >> >> Xin From xerox.time.tech at gmail.com Fri Dec 7 21:39:21 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Sat, 8 Dec 2012 00:39:21 -0500 Subject: hash value in java objects In-Reply-To: References: Message-ID: On Fri, Dec 7, 2012 at 11:38 PM, Krystal Mok wrote: > Short answer is the identity hash code is calculated when: > 1. the hashCode() method is called the first time for this object, if > the type of this object doesn't override Object.hashCode(); > 2. System.identityHashCode() is called the first time for this object. > would not materialize the hashcode takes much code. why not materialize lazily ? Xin > A "0" value encoded as the hash in the mark word indicates that the > identity hash code hasn't been calculated yet (which is the initial > state after an object is created). > > If the type of an object overrides Object.hashCode(), then calling it > doesn't have anything to do with the identity hash code. > > The identity hash code of a Java object is stored in the mark word of > the object header if it has been calculated and the object is > unlocked. Otherwise it may be stored in the displaced mark word or in > the inflated lock. > > - Kris > > On Sat, Dec 8, 2012 at 6:31 AM, Vitaly Davidovich wrote: >> Hash is encoded in the mark word, so I think the answer to your question is >> it's created when object is allocated (and thus gets a markOop). The actual >> hash value is decoded from the mark word at call time, but it's just a shift >> and mask at that point. Someone can correct me if this is wrong. >> >> Thanks >> >> Sent from my phone >> >> On Dec 7, 2012 4:52 PM, "Xin Tong" wrote: >>> >>> I am wondering when the hash values in the java objects are >>> materialized. are they materialized when the object is created ? or >>> when hashCode on the object is called. what about modifications to >>> the object ? >>> >>> Xin From john.r.rose at oracle.com Fri Dec 7 23:19:57 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 7 Dec 2012 23:19:57 -0800 Subject: hKash value in java objects In-Reply-To: References: Message-ID: <512093B7-854B-4B51-A1DA-79E51FFA9795@oracle.com> On Dec 7, 2012, at 9:39 PM, Xin Tong wrote: > On Fri, Dec 7, 2012 at 11:38 PM, Krystal Mok wrote: >> Short answer is the identity hash code is calculated when: >> 1. the hashCode() method is called the first time for this object, if >> the type of this object doesn't override Object.hashCode(); >> 2. System.identityHashCode() is called the first time for this object. >> > would not materialize the hashcode takes much code. why not materialize lazily ? That's what Kris means, I think. You can check the code; it's ObjectSynchronizer::FastHashCode in this file: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/runtime/synchronizer.cpp Enjoy, ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121207/518c7c1a/attachment.html From rednaxelafx at gmail.com Sat Dec 8 07:50:17 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 8 Dec 2012 23:50:17 +0800 Subject: hash value in java objects In-Reply-To: References: Message-ID: The identity hash code for Java objects are calculated lazily because most Java objects don't need it. Usually objects are only hashed when used as key for hash-based containers, such as HashMap; the objects used as keys this way are usually a little fraction of all objects. Of those used as keys, many may have provided its own implementation of hashCode(), which wouldn't need the identity hash code. It takes space to store the hash code. In HotSpot VM, the mark word is multiplexed to store a few kinds of metadata, but of course it can't store all of them when they're all present. It'd be wasting space to store data that may never be used, that's the original idea for calculating the identity hash code lazily. The problem of wasting space is especially bad for objects that have only a couple of fields. The same goes for monitors. There has been quite a few schemes for populating the identity hash code and the monitor info lazily. e.g. Monty VM (or better known as the CLDC HotSpot Implementation, or CLDC-HI) uses another scheme that used "prototypical near class". You could read section 3.1.1.3 of [1] if you're interested. By the way, there could also be some obscure cons of using the identity hash code unnecessarily in HotSpot. See Topic2 of [2] for example. That blog is in Japanese, but I'm sure you can get the idea of it just by reading the code examples. In short, it was trying to show how unnecessary use of identity hash code could cause excessive use of memory during GC. - Kris [1]: http://verdich.dk/kasper/RES.pdf [2]: http://www.nminoru.jp/~nminoru/diary/2012/02.html#20120218p1 On Sat, Dec 8, 2012 at 1:39 PM, Xin Tong wrote: > On Fri, Dec 7, 2012 at 11:38 PM, Krystal Mok wrote: >> Short answer is the identity hash code is calculated when: >> 1. the hashCode() method is called the first time for this object, if >> the type of this object doesn't override Object.hashCode(); >> 2. System.identityHashCode() is called the first time for this object. >> > would not materialize the hashcode takes much code. why not materialize lazily ? > > Xin >> A "0" value encoded as the hash in the mark word indicates that the >> identity hash code hasn't been calculated yet (which is the initial >> state after an object is created). >> >> If the type of an object overrides Object.hashCode(), then calling it >> doesn't have anything to do with the identity hash code. >> >> The identity hash code of a Java object is stored in the mark word of >> the object header if it has been calculated and the object is >> unlocked. Otherwise it may be stored in the displaced mark word or in >> the inflated lock. >> >> - Kris >> >> On Sat, Dec 8, 2012 at 6:31 AM, Vitaly Davidovich wrote: >>> Hash is encoded in the mark word, so I think the answer to your question is >>> it's created when object is allocated (and thus gets a markOop). The actual >>> hash value is decoded from the mark word at call time, but it's just a shift >>> and mask at that point. Someone can correct me if this is wrong. >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Dec 7, 2012 4:52 PM, "Xin Tong" wrote: >>>> >>>> I am wondering when the hash values in the java objects are >>>> materialized. are they materialized when the object is created ? or >>>> when hashCode on the object is called. what about modifications to >>>> the object ? >>>> >>>> Xin From xerox.time.tech at gmail.com Sun Dec 9 12:58:48 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Sun, 9 Dec 2012 15:58:48 -0500 Subject: compaction on Nursery Collection Message-ID: I am wondering why compaction is only run on full collection. but not Nursery Collection in parallel throughput GC in hotspot ? Xin From xerox.time.tech at gmail.com Sun Dec 9 19:55:03 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Sun, 9 Dec 2012 22:55:03 -0500 Subject: Put an extra byte in every object header Message-ID: what is a way to put an extra byte into every object header in hotspot. I tried putting it into class markOop and class Oop. none worked. the runtime crashed when running java programs. Is there anything i need to change ? Xin From suenaga.yasumasa at lab.ntt.co.jp Sun Dec 9 20:10:54 2012 From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga) Date: Mon, 10 Dec 2012 13:10:54 +0900 Subject: Build error after CR#7172640 with GCC4.7.2 Message-ID: <50C560CE.3000402@lab.ntt.co.jp> Hi, When I build hsx/hotspot-comp with GCC 4.7.2 on Fedora17, it fails with message as following: ---------- /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp: In member function 'CallGenerator* Compile::make_vm_intrinsic(ciMethod*, bool)': /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:415:67: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:418:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:421:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:424:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] cc1plus: all warnings being treated as errors make[6]: *** [library_call.o] Error 1 ---------- Cause of this problem is that Compile::make_vm_intrinsic() should return pointer type (CallGenerator*), however patch of CR#7172640 returns boolean value. I posted this problem on BugDatabase as a new bug (Internal review ID is 2396515). However, it does not seem to public yet. I've made a patch which attached in this email, and it works fine in my environment. I would like to contribute this patch, and I hope to merge this patch into mainline. Please cooperate. Best regards, Yasumasa -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: builderr-gcc47.patch Url: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121210/d8610449/builderr-gcc47.patch From bharadwaj.yadavalli at oracle.com Mon Dec 10 08:30:24 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 10 Dec 2012 11:30:24 -0500 Subject: RFR(S) - 8004548 : remove unused AbstractAssembler::print(Label&) Message-ID: <50C60E20.2050006@oracle.com> Please review the requested cleanup done in the changes at http://cr.openjdk.java.net/~bharadwaj/8004548/webrev/ Thanks, Bharadwaj From Vladimir.Kozlov at oracle.com Mon Dec 10 09:40:45 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Dec 2012 09:40:45 -0800 Subject: RFR(S) - 8004548 : remove unused AbstractAssembler::print(Label&) In-Reply-To: <50C60E20.2050006@oracle.com> References: <50C60E20.2050006@oracle.com> Message-ID: <50C61E9D.4080208@oracle.com> Good. Vladimir On 12/10/12 08:30, Bharadwaj Yadavalli wrote: > Please review the requested cleanup done in the changes at > http://cr.openjdk.java.net/~bharadwaj/8004548/webrev/ > > Thanks, > > Bharadwaj > From rkennke at redhat.com Mon Dec 10 12:00:05 2012 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 10 Dec 2012 21:00:05 +0100 Subject: Enable JSR292 support in Shark In-Reply-To: References: <1354827728.1747.50.camel@mercury> <1354835310.1747.64.camel@mercury> Message-ID: <1355169605.1747.117.camel@mercury> Am Freitag, den 07.12.2012, 16:06 -0800 schrieb John Rose: > On Dec 6, 2012, at 3:08 PM, Roman Kennke wrote: > > > Thanks a lot for your explanations, it's really helpful. I would > > like to > > (potentially) contribute to the HSI wiki, if you want to give me > > access :-) > > Good! Is rkennke at gmail.com your Oracle SSO login? If so I'll add you > to the wiki editors. If not, let me know the login you'll be using > with the wiki. ? John My Oracle login is roman at kennke.org . Thanks for adding me! About the patches, do I need to do anything? Should I enter them in OpenJDK bugzilla or how can I move them forward? Roman From christian.thalinger at oracle.com Mon Dec 10 14:41:43 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 10 Dec 2012 14:41:43 -0800 Subject: RFR(S) - 8004548 : remove unused AbstractAssembler::print(Label&) In-Reply-To: <50C60E20.2050006@oracle.com> References: <50C60E20.2050006@oracle.com> Message-ID: <2F7CF88C-CA04-4925-B89D-16F5F3405272@oracle.com> On Dec 10, 2012, at 8:30 AM, Bharadwaj Yadavalli wrote: > Please review the requested cleanup done in the changes at http://cr.openjdk.java.net/~bharadwaj/8004548/webrev/ src/cpu/sparc/vm/assembler_sparc.inline.hpp: Also remove now unused print_instruction (that's the method I started looking from to find that all this is old and unused). -- Chris > > Thanks, > > Bharadwaj > From vladimir.kozlov at oracle.com Mon Dec 10 14:50:57 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Dec 2012 14:50:57 -0800 Subject: Request for reviews (XS): 8004741: Missing compiled exception handle table entry for multidimensional array allocation In-Reply-To: <50C2A1C1.1050802@oracle.com> References: <4FA969C9.4090003@oracle.com> <50C28CE4.6010404@oracle.com> <9F818F6A-D60C-413E-B291-B256183E1F59@oracle.com> <50C2A1C1.1050802@oracle.com> Message-ID: <50C66751.8050403@oracle.com> Updated webrev: http://cr.openjdk.java.net/~kvn/8004741/webrev.01 I ran compiler regression tests with disable dioptimization for exceptions processing. And 2 tests failed because thrown exception (NegativeArraySizeException) during runtime call was not caught by catch block. The problem was C2 expected only OutOfMemoryError (which is not Exception) from slow allocation runtime calls. I replaced it with Throwable which C2 uses for other calls. Thanks, Vladimir On 12/7/12 6:11 PM, Vladimir Kozlov wrote: > Thank you, Christian > > As you asked I modified code in JavaThread::send_thread_stop() to skip > deoptimization and immediately hit the failure without fix. > > Thanks, > Vladimir > > On 12/07/12 17:32, Christian Thalinger wrote: >> Looks good. -- Chris >> >> On Dec 7, 2012, at 4:42 PM, Vladimir >> Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/8004741/webrev >>> >>> Added missing exception path for multidimensional array allocation >>> runtime calls. It cased "missing exception handler" error during an >>> exception processing on the return from such runtime call. It is very >>> rare case because usually the compiled frame is deoptimized (go back >>> to Interpreter) to process an exception. >>> >>> Thanks, >>> Vladimir >>> >>> >> From christian.thalinger at oracle.com Mon Dec 10 15:00:00 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 10 Dec 2012 15:00:00 -0800 Subject: Request for reviews (XS): 8004741: Missing compiled exception handle table entry for multidimensional array allocation In-Reply-To: <50C66751.8050403@oracle.com> References: <4FA969C9.4090003@oracle.com> <50C28CE4.6010404@oracle.com> <9F818F6A-D60C-413E-B291-B256183E1F59@oracle.com> <50C2A1C1.1050802@oracle.com> <50C66751.8050403@oracle.com> Message-ID: On Dec 10, 2012, at 2:50 PM, Vladimir Kozlov wrote: > Updated webrev: > > http://cr.openjdk.java.net/~kvn/8004741/webrev.01 > > I ran compiler regression tests with disable dioptimization for exceptions processing. And 2 tests failed because thrown exception (NegativeArraySizeException) during runtime call was not caught by catch block. The problem was C2 expected only OutOfMemoryError (which is not Exception) from slow allocation runtime calls. I replaced it with Throwable which C2 uses for other calls. This looks right to me. -- Chris > > Thanks, > Vladimir > > On 12/7/12 6:11 PM, Vladimir Kozlov wrote: >> Thank you, Christian >> >> As you asked I modified code in JavaThread::send_thread_stop() to skip >> deoptimization and immediately hit the failure without fix. >> >> Thanks, >> Vladimir >> >> On 12/07/12 17:32, Christian Thalinger wrote: >>> Looks good. -- Chris >>> >>> On Dec 7, 2012, at 4:42 PM, Vladimir >>> Kozlov wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/8004741/webrev >>>> >>>> Added missing exception path for multidimensional array allocation >>>> runtime calls. It cased "missing exception handler" error during an >>>> exception processing on the return from such runtime call. It is very >>>> rare case because usually the compiled frame is deoptimized (go back >>>> to Interpreter) to process an exception. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>> From vladimir.kozlov at oracle.com Mon Dec 10 15:07:12 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Dec 2012 15:07:12 -0800 Subject: Request for reviews (XS): 8004741: Missing compiled exception handle table entry for multidimensional array allocation In-Reply-To: References: <4FA969C9.4090003@oracle.com> <50C28CE4.6010404@oracle.com> <9F818F6A-D60C-413E-B291-B256183E1F59@oracle.com> <50C2A1C1.1050802@oracle.com> <50C66751.8050403@oracle.com> Message-ID: <50C66B20.7010100@oracle.com> Thanks, Christian Vladimir On 12/10/12 3:00 PM, Christian Thalinger wrote: > > On Dec 10, 2012, at 2:50 PM, Vladimir Kozlov wrote: > >> Updated webrev: >> >> http://cr.openjdk.java.net/~kvn/8004741/webrev.01 >> >> I ran compiler regression tests with disable dioptimization for exceptions processing. And 2 tests failed because thrown exception (NegativeArraySizeException) during runtime call was not caught by catch block. The problem was C2 expected only OutOfMemoryError (which is not Exception) from slow allocation runtime calls. I replaced it with Throwable which C2 uses for other calls. > > This looks right to me. > > -- Chris > >> >> Thanks, >> Vladimir >> >> On 12/7/12 6:11 PM, Vladimir Kozlov wrote: >>> Thank you, Christian >>> >>> As you asked I modified code in JavaThread::send_thread_stop() to skip >>> deoptimization and immediately hit the failure without fix. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/07/12 17:32, Christian Thalinger wrote: >>>> Looks good. -- Chris >>>> >>>> On Dec 7, 2012, at 4:42 PM, Vladimir >>>> Kozlov wrote: >>>> >>>>> http://cr.openjdk.java.net/~kvn/8004741/webrev >>>>> >>>>> Added missing exception path for multidimensional array allocation >>>>> runtime calls. It cased "missing exception handler" error during an >>>>> exception processing on the return from such runtime call. It is very >>>>> rare case because usually the compiled frame is deoptimized (go back >>>>> to Interpreter) to process an exception. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>> > From nils.eliasson at oracle.com Tue Dec 11 06:01:30 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 11 Dec 2012 15:01:30 +0100 Subject: methodHandles, MethodOops and Method* Message-ID: <50C73CBA.2080706@oracle.com> Looking at the compiler code I see two patterns, which one is correct? Which one should we use? When we access things in a Method* from CompilerOracle we transition to native and use methodHandles. check_is_loaded(); // check that ciMethod is loaded VM_ENTRY_MARK; // Transition to VM from Native methodHandle mh(THREAD, get_Method()); // create a handle to a Method* (methodOop with permgen) But in other places I see a shorter form: bool force_inline() { return get_Method()->force_inline(); } Pre-permgen-removal - I belive the first example was the correct way to do things. We need to transition to VM-running, and to do that we need a methodHandle to the MethodOop to keep it from being reclaimed while we are looking at it. But how are things supposed to work post-permgen? Do we still need the methodHandle or is it direct access allowed like in the 2nd example? //Nils E From christian.thalinger at oracle.com Tue Dec 11 15:47:25 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Dec 2012 15:47:25 -0800 Subject: RFR (XXS): 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java Message-ID: http://cr.openjdk.java.net/~twisti/8003238 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java Reviewed-by: The VM code for setTarget takes the Compile_lock and flushes all dependent methods. After that we leave the lock and set the new target in the CallSite object. The problem here is that after we left the lock an already compiled method could be installed with dependencies that are still correct because the CallSite.target hasn't been updated yet. The fix is to move the set_target calls inside the Compile_lock. src/share/vm/prims/methodHandles.cpp From christian.thalinger at oracle.com Tue Dec 11 15:58:40 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Dec 2012 15:58:40 -0800 Subject: Build error after CR#7172640 with GCC4.7.2 In-Reply-To: <50C560CE.3000402@lab.ntt.co.jp> References: <50C560CE.3000402@lab.ntt.co.jp> Message-ID: On Dec 9, 2012, at 8:10 PM, Yasumasa Suenaga wrote: > Hi, > > When I build hsx/hotspot-comp with GCC 4.7.2 on Fedora17, it fails with message as following: > > ---------- > /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp: In member function 'CallGenerator* Compile::make_vm_intrinsic(ciMethod*, bool)': > /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:415:67: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] > /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:418:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] > /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:421:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] > /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:424:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] > cc1plus: all warnings being treated as errors > make[6]: *** [library_call.o] Error 1 > ---------- > > Cause of this problem is that Compile::make_vm_intrinsic() should return pointer type > (CallGenerator*), however patch of CR#7172640 returns boolean value. Good catch. I messed that up. > > > I posted this problem on BugDatabase as a new bug (Internal review ID is 2396515). > However, it does not seem to public yet. > > I've made a patch which attached in this email, and it works fine in my environment. > I would like to contribute this patch, and I hope to merge this patch into mainline. Did you or your company sign the OCA? If yes, I'd happily add you as a contributor to this changeset. If not, I will just fix it myself and push it (since it's a trivial change). I filed: 8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 -- Chris > > Please cooperate. > > > Best regards, > Yasumasa > > From christian.thalinger at oracle.com Tue Dec 11 16:10:36 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Dec 2012 16:10:36 -0800 Subject: Put an extra byte in every object header In-Reply-To: References: Message-ID: <51347EC7-A048-40BB-B0D3-859670F33624@oracle.com> On Dec 9, 2012, at 7:55 PM, Xin Tong wrote: > what is a way to put an extra byte into every object header in > hotspot. I tried putting it into class markOop and class Oop. none > worked. the runtime crashed when running java programs. > Is there anything i need to change ? There was a discussing about this very recently. I just can't find the post right now. You might use a search engine yourself. -- Chris > > Xin From vladimir.kozlov at oracle.com Tue Dec 11 16:09:16 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Dec 2012 16:09:16 -0800 Subject: RFR (XXS): 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java In-Reply-To: References: Message-ID: <50C7CB2C.4040107@oracle.com> Looks good. Vladimir On 12/11/12 3:47 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8003238 > > 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java > Reviewed-by: > > The VM code for setTarget takes the Compile_lock and flushes all > dependent methods. After that we leave the lock and set the new > target in the CallSite object. > > The problem here is that after we left the lock an already compiled > method could be installed with dependencies that are still correct > because the CallSite.target hasn't been updated yet. > > The fix is to move the set_target calls inside the Compile_lock. > > src/share/vm/prims/methodHandles.cpp > From suenaga.yasumasa at lab.ntt.co.jp Tue Dec 11 16:31:48 2012 From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga) Date: Wed, 12 Dec 2012 09:31:48 +0900 Subject: Build error after CR#7172640 with GCC4.7.2 In-Reply-To: References: <50C560CE.3000402@lab.ntt.co.jp> Message-ID: <50C7D074.1040608@lab.ntt.co.jp> Hi Chris, > Did you or your company sign the OCA? If yes, I'd happily add you as a contributor to this changeset. If not, I will just fix it myself and push it (since it's a trivial change). I've not yet signed the OCA. We (my company) are currently considering who should sign the OCA. So I don't care even without my name in the changeset. Thanks, Yasumasa On 2012/12/12 8:58, Christian Thalinger wrote: > > On Dec 9, 2012, at 8:10 PM, Yasumasa Suenaga wrote: > >> Hi, >> >> When I build hsx/hotspot-comp with GCC 4.7.2 on Fedora17, it fails with message as following: >> >> ---------- >> /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp: In member function 'CallGenerator* Compile::make_vm_intrinsic(ciMethod*, bool)': >> /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:415:67: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] >> /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:418:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] >> /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:421:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] >> /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:424:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] >> cc1plus: all warnings being treated as errors >> make[6]: *** [library_call.o] Error 1 >> ---------- >> >> Cause of this problem is that Compile::make_vm_intrinsic() should return pointer type >> (CallGenerator*), however patch of CR#7172640 returns boolean value. > > Good catch. I messed that up. > >> >> >> I posted this problem on BugDatabase as a new bug (Internal review ID is 2396515). >> However, it does not seem to public yet. >> >> I've made a patch which attached in this email, and it works fine in my environment. >> I would like to contribute this patch, and I hope to merge this patch into mainline. > > Did you or your company sign the OCA? If yes, I'd happily add you as a contributor to this changeset. If not, I will just fix it myself and push it (since it's a trivial change). > > I filed: > > 8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 > > -- Chris > >> >> Please cooperate. >> >> >> Best regards, >> Yasumasa >> >> > From john.r.rose at oracle.com Tue Dec 11 16:36:02 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 11 Dec 2012 16:36:02 -0800 Subject: RFR (XXS): 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java In-Reply-To: References: Message-ID: Good! ? John On Dec 11, 2012, at 3:47 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8003238 > > 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java > Reviewed-by: > > The VM code for setTarget takes the Compile_lock and flushes all > dependent methods. After that we leave the lock and set the new > target in the CallSite object. > > The problem here is that after we left the lock an already compiled > method could be installed with dependencies that are still correct > because the CallSite.target hasn't been updated yet. > > The fix is to move the set_target calls inside the Compile_lock. > > src/share/vm/prims/methodHandles.cpp > From christian.thalinger at oracle.com Tue Dec 11 16:53:08 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Dec 2012 16:53:08 -0800 Subject: RFR (XXS): 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java In-Reply-To: References: Message-ID: <7FC618CE-0EAC-4099-B2D5-5912D7EFEA43@oracle.com> Thank you, John and Vladimir. -- Chris On Dec 11, 2012, at 4:36 PM, John Rose wrote: > Good! ? John > > On Dec 11, 2012, at 3:47 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/8003238 >> >> 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java >> Reviewed-by: >> >> The VM code for setTarget takes the Compile_lock and flushes all >> dependent methods. After that we leave the lock and set the new >> target in the CallSite object. >> >> The problem here is that after we left the lock an already compiled >> method could be installed with dependencies that are still correct >> because the CallSite.target hasn't been updated yet. >> >> The fix is to move the set_target calls inside the Compile_lock. >> >> src/share/vm/prims/methodHandles.cpp >> > From christian.thalinger at oracle.com Tue Dec 11 16:54:27 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Dec 2012 16:54:27 -0800 Subject: 8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 [Was: Re: Build error after CR#7172640 with GCC4.7.2] In-Reply-To: <50C7D074.1040608@lab.ntt.co.jp> References: <50C560CE.3000402@lab.ntt.co.jp> <50C7D074.1040608@lab.ntt.co.jp> Message-ID: <586A909B-BBE9-4AB0-9CB8-BD8B05470776@oracle.com> On Dec 11, 2012, at 4:31 PM, Yasumasa Suenaga wrote: > Hi Chris, > >> Did you or your company sign the OCA? If yes, I'd happily add you as a contributor to this changeset. If not, I will just fix it myself and push it (since it's a trivial change). > > I've not yet signed the OCA. > We (my company) are currently considering who should sign the OCA. > > So I don't care even without my name in the changeset. Okay. I will go ahead and push the fix. Thanks again. -- Chris > > > Thanks, > > Yasumasa > > > On 2012/12/12 8:58, Christian Thalinger wrote: >> >> On Dec 9, 2012, at 8:10 PM, Yasumasa Suenaga wrote: >> >>> Hi, >>> >>> When I build hsx/hotspot-comp with GCC 4.7.2 on Fedora17, it fails with message as following: >>> >>> ---------- >>> /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp: In member function 'CallGenerator* Compile::make_vm_intrinsic(ciMethod*, bool)': >>> /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:415:67: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] >>> /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:418:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] >>> /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:421:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] >>> /usr/src/OpenJDK/hsx/fail/hotspot-comp/hotspot/src/share/vm/opto/library_call.cpp:424:66: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] >>> cc1plus: all warnings being treated as errors >>> make[6]: *** [library_call.o] Error 1 >>> ---------- >>> >>> Cause of this problem is that Compile::make_vm_intrinsic() should return pointer type >>> (CallGenerator*), however patch of CR#7172640 returns boolean value. >> >> Good catch. I messed that up. >> >>> >>> >>> I posted this problem on BugDatabase as a new bug (Internal review ID is 2396515). >>> However, it does not seem to public yet. >>> >>> I've made a patch which attached in this email, and it works fine in my environment. >>> I would like to contribute this patch, and I hope to merge this patch into mainline. >> >> Did you or your company sign the OCA? If yes, I'd happily add you as a contributor to this changeset. If not, I will just fix it myself and push it (since it's a trivial change). >> >> I filed: >> >> 8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 >> >> -- Chris >> >>> >>> Please cooperate. >>> >>> >>> Best regards, >>> Yasumasa >>> >>> >> From christian.thalinger at oracle.com Tue Dec 11 16:09:52 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Dec 2012 16:09:52 -0800 Subject: compaction on Nursery Collection In-Reply-To: References: Message-ID: On Dec 9, 2012, at 12:58 PM, Xin Tong wrote: > I am wondering why compaction is only run on full collection. but not > Nursery Collection in parallel throughput GC in hotspot ? This question should go to hotspot-gc-dev. BCC'ing hotspot-compiler-dev. -- Chris > > Xin From rednaxelafx at gmail.com Tue Dec 11 20:47:22 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 12 Dec 2012 12:47:22 +0800 Subject: Put an extra byte in every object header In-Reply-To: <51347EC7-A048-40BB-B0D3-859670F33624@oracle.com> References: <51347EC7-A048-40BB-B0D3-859670F33624@oracle.com> Message-ID: This is the thread Chris was talking about: http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-June/005994.html HTH, Kris On Wed, Dec 12, 2012 at 8:10 AM, Christian Thalinger wrote: > > On Dec 9, 2012, at 7:55 PM, Xin Tong wrote: > >> what is a way to put an extra byte into every object header in >> hotspot. I tried putting it into class markOop and class Oop. none >> worked. the runtime crashed when running java programs. >> Is there anything i need to change ? > > There was a discussing about this very recently. I just can't find the post right now. You might use a search engine yourself. > > -- Chris > >> >> Xin > From xerox.time.tech at gmail.com Wed Dec 12 14:57:24 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Wed, 12 Dec 2012 17:57:24 -0500 Subject: Put an extra byte in every object header In-Reply-To: References: <51347EC7-A048-40BB-B0D3-859670F33624@oracle.com> Message-ID: On Tue, Dec 11, 2012 at 11:47 PM, Krystal Mok wrote: > This is the thread Chris was talking about: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-June/005994.html > I put the option in the . but my VM still crashes at test_gamma. The crash report and changes are as shown below. class oopDesc { friend class VMStructs; private: volatile markOop _mark; union _metadata { wideKlassOop _klass; narrowOop _compressed_klass; } _metadata; int magic; // Fast access to barrier set. Must be initialized. static BarrierSet* _bs; public: enum ConcSafeType { IsUnsafeConc = false, IsSafeConc = true }; oopDesc() {magic = 0xAABBCCDD; } ... } make[6]: Leaving directory `/home/xtong/openjdk/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product' All done. make[5]: Leaving directory `/home/xtong/openjdk/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product' cd linux_amd64_compiler2/product && ./test_gamma Picked up _JAVA_OPTIONS: -XX:-UseCompressedOops Using java runtime at: /usr/lib/jvm/java-6-openjdk-amd64/jre Picked up _JAVA_OPTIONS: -XX:-UseCompressedOops # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00002b7ced68d797, pid=13715, tid=47815576852224 # # JRE version: 6.0_24-b24 # Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64 ) # Problematic frame: # V [libjvm.so+0x7c3797] Symbol::as_C_string() const+0x7 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/xtong/openjdk/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product/hs_err_pid13715.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Aborted (core dumped) make[4]: *** [product] Error 134 make[4]: Leaving directory `/home/xtong/openjdk/build/linux-amd64/hotspot/outputdir' make[3]: *** [generic_build2] Error 2 make[3]: Leaving directory `/home/xtong/openjdk/hotspot/make' make[2]: *** [product] Error 2 make[2]: Leaving directory `/home/xtong/openjdk/hotspot/make' make[1]: *** [hotspot-build] Error 2 make[1]: Leaving directory `/home/xtong/openjdk' make: *** [build_product_image] Error 2 Xin > HTH, > Kris > > On Wed, Dec 12, 2012 at 8:10 AM, Christian Thalinger > wrote: >> >> On Dec 9, 2012, at 7:55 PM, Xin Tong wrote: >> >>> what is a way to put an extra byte into every object header in >>> hotspot. I tried putting it into class markOop and class Oop. none >>> worked. the runtime crashed when running java programs. >>> Is there anything i need to change ? >> >> There was a discussing about this very recently. I just can't find the post right now. You might use a search engine yourself. >> >> -- Chris >> >>> >>> Xin >> From xerox.time.tech at gmail.com Wed Dec 12 14:59:09 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Wed, 12 Dec 2012 17:59:09 -0500 Subject: Put an extra byte in every object header In-Reply-To: References: <51347EC7-A048-40BB-B0D3-859670F33624@oracle.com> Message-ID: On Wed, Dec 12, 2012 at 5:57 PM, Xin Tong wrote: > On Tue, Dec 11, 2012 at 11:47 PM, Krystal Mok wrote: >> This is the thread Chris was talking about: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-June/005994.html >> > I put the option in the . but my VM still crashes at test_gamma. The > crash report and changes are as shown below. > Sorry the is -UseCompressedOops place in the _JAVA_OPTIONS. xtong at socrates:~/openjdk$ export _JAVA_OPTIONS='-XX:-UseCompressedOops' Xin > class oopDesc { > friend class VMStructs; > private: > volatile markOop _mark; > union _metadata { > wideKlassOop _klass; > narrowOop _compressed_klass; > } _metadata; > > int magic; > > // Fast access to barrier set. Must be initialized. > static BarrierSet* _bs; > > public: > enum ConcSafeType { > IsUnsafeConc = false, > IsSafeConc = true > }; > > oopDesc() {magic = 0xAABBCCDD; } > ... > } > > make[6]: Leaving directory > `/home/xtong/openjdk/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product' > All done. > make[5]: Leaving directory > `/home/xtong/openjdk/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product' > cd linux_amd64_compiler2/product && ./test_gamma > Picked up _JAVA_OPTIONS: -XX:-UseCompressedOops > Using java runtime at: /usr/lib/jvm/java-6-openjdk-amd64/jre > Picked up _JAVA_OPTIONS: -XX:-UseCompressedOops > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00002b7ced68d797, pid=13715, tid=47815576852224 > # > # JRE version: 6.0_24-b24 > # Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64 ) > # Problematic frame: > # V [libjvm.so+0x7c3797] Symbol::as_C_string() const+0x7 > # > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /home/xtong/openjdk/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product/hs_err_pid13715.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > Aborted (core dumped) > make[4]: *** [product] Error 134 > make[4]: Leaving directory > `/home/xtong/openjdk/build/linux-amd64/hotspot/outputdir' > make[3]: *** [generic_build2] Error 2 > make[3]: Leaving directory `/home/xtong/openjdk/hotspot/make' > make[2]: *** [product] Error 2 > make[2]: Leaving directory `/home/xtong/openjdk/hotspot/make' > make[1]: *** [hotspot-build] Error 2 > make[1]: Leaving directory `/home/xtong/openjdk' > make: *** [build_product_image] Error 2 > > Xin > >> HTH, >> Kris >> >> On Wed, Dec 12, 2012 at 8:10 AM, Christian Thalinger >> wrote: >>> >>> On Dec 9, 2012, at 7:55 PM, Xin Tong wrote: >>> >>>> what is a way to put an extra byte into every object header in >>>> hotspot. I tried putting it into class markOop and class Oop. none >>>> worked. the runtime crashed when running java programs. >>>> Is there anything i need to change ? >>> >>> There was a discussing about this very recently. I just can't find the post right now. You might use a search engine yourself. >>> >>> -- Chris >>> >>>> >>>> Xin >>> From rednaxelafx at gmail.com Wed Dec 12 15:55:26 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 13 Dec 2012 07:55:26 +0800 Subject: Put an extra byte in every object header In-Reply-To: References: <51347EC7-A048-40BB-B0D3-859670F33624@oracle.com> Message-ID: You should read the whole thread. There's more discussion after my suggestion of specifying -UseCompressedOops (which wasn't a cure to the root problem). - Kris On Thu, Dec 13, 2012 at 6:59 AM, Xin Tong wrote: > On Wed, Dec 12, 2012 at 5:57 PM, Xin Tong wrote: >> On Tue, Dec 11, 2012 at 11:47 PM, Krystal Mok wrote: >>> This is the thread Chris was talking about: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-June/005994.html >>> >> I put the option in the . but my VM still crashes at test_gamma. The >> crash report and changes are as shown below. >> > Sorry the is -UseCompressedOops place in the _JAVA_OPTIONS. > > xtong at socrates:~/openjdk$ export _JAVA_OPTIONS='-XX:-UseCompressedOops' > > Xin > >> class oopDesc { >> friend class VMStructs; >> private: >> volatile markOop _mark; >> union _metadata { >> wideKlassOop _klass; >> narrowOop _compressed_klass; >> } _metadata; >> >> int magic; >> >> // Fast access to barrier set. Must be initialized. >> static BarrierSet* _bs; >> >> public: >> enum ConcSafeType { >> IsUnsafeConc = false, >> IsSafeConc = true >> }; >> >> oopDesc() {magic = 0xAABBCCDD; } >> ... >> } >> >> make[6]: Leaving directory >> `/home/xtong/openjdk/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product' >> All done. >> make[5]: Leaving directory >> `/home/xtong/openjdk/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product' >> cd linux_amd64_compiler2/product && ./test_gamma >> Picked up _JAVA_OPTIONS: -XX:-UseCompressedOops >> Using java runtime at: /usr/lib/jvm/java-6-openjdk-amd64/jre >> Picked up _JAVA_OPTIONS: -XX:-UseCompressedOops >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00002b7ced68d797, pid=13715, tid=47815576852224 >> # >> # JRE version: 6.0_24-b24 >> # Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64 ) >> # Problematic frame: >> # V [libjvm.so+0x7c3797] Symbol::as_C_string() const+0x7 >> # >> # Failed to write core dump. Core dumps have been disabled. To enable >> core dumping, try "ulimit -c unlimited" before starting Java again >> # >> # An error report file with more information is saved as: >> # /home/xtong/openjdk/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product/hs_err_pid13715.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> Aborted (core dumped) >> make[4]: *** [product] Error 134 >> make[4]: Leaving directory >> `/home/xtong/openjdk/build/linux-amd64/hotspot/outputdir' >> make[3]: *** [generic_build2] Error 2 >> make[3]: Leaving directory `/home/xtong/openjdk/hotspot/make' >> make[2]: *** [product] Error 2 >> make[2]: Leaving directory `/home/xtong/openjdk/hotspot/make' >> make[1]: *** [hotspot-build] Error 2 >> make[1]: Leaving directory `/home/xtong/openjdk' >> make: *** [build_product_image] Error 2 >> >> Xin >> >>> HTH, >>> Kris >>> >>> On Wed, Dec 12, 2012 at 8:10 AM, Christian Thalinger >>> wrote: >>>> >>>> On Dec 9, 2012, at 7:55 PM, Xin Tong wrote: >>>> >>>>> what is a way to put an extra byte into every object header in >>>>> hotspot. I tried putting it into class markOop and class Oop. none >>>>> worked. the runtime crashed when running java programs. >>>>> Is there anything i need to change ? >>>> >>>> There was a discussing about this very recently. I just can't find the post right now. You might use a search engine yourself. >>>> >>>> -- Chris >>>> >>>>> >>>>> Xin >>>> From goetz.lindenmaier at sap.com Thu Dec 13 02:49:31 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Dec 2012 11:49:31 +0100 Subject: RFR(M): pass outputStream to more opto debug routines Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF73EB5AD@DEWDFECCR03.wdf.sap.corp> Hi, We pass the outputStream to much more debug routines than openJDK does, as we write a lot more information to files e.g., in case of a crash. I would like to contribute the changes that allow to pass the output stream to node->dump() and everything reachable from there. This also fixes the usage of output stream in print_register_type() in oopMap.cpp and in MachNullCheckNode::format(), where a single print command still used tty. Further we initialize _node_regs_max_index so that node_regs_max_index() == 0 indicates that registers of a node can be accessed. This is also useful in debug output. http://cr.openjdk.java.net/~goetz/webrevs/webrev-os_in_nodeDump/ Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121213/ab9c6d3b/attachment.html From richard.reingruber at sap.com Thu Dec 13 09:09:06 2012 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 13 Dec 2012 18:09:06 +0100 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 Message-ID: Hi, I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). I have prepared a small webrev with the suggested fix and a regression test: http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ Could you please review the patch and create a bug id? Thanks! Cheers, Richard. BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) From roland.westrelin at oracle.com Thu Dec 13 10:32:16 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 13 Dec 2012 19:32:16 +0100 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support Message-ID: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> http://cr.openjdk.java.net/~roland/8005031/webrev.00/ A collection of small changes that were found to be required for the upcoming incremental inlining support and that we intend to push first so that they be tested in isolation. With incremental inlining, inlining doesn't happen in parse order anymore so the output of PrintInlining can get confusing. There's some support in this change to keep the PrintInlining output in order. Regarding add_node.cpp, I noticed some nodes wouldn't be found as dead by the igvn. I assume it is a bug. Roland. From christian.thalinger at oracle.com Thu Dec 13 10:46:04 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 13 Dec 2012 10:46:04 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: References: Message-ID: On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: > Hi, > > I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. > > On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). > > I have prepared a small webrev with the suggested fix and a regression test: > > http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ > > Could you please review the patch and create a bug id? Thanks! Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: 8005033: clear high word for integer pop count on SPARC It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? -- Chris > > Cheers, > Richard. > > BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) > From dean.long at oracle.com Thu Dec 13 10:44:23 2012 From: dean.long at oracle.com (Dean Long) Date: Thu, 13 Dec 2012 10:44:23 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: References: Message-ID: <50CA2207.2070102@oracle.com> convI2L_reg_zex doesn't use the mask, so would shrI_reg_imm5(dst, src, 0) or shrI_reg_reg(dst, src, R_G0) work just as well? dl On 12/13/2012 9:09 AM, Reingruber, Richard wrote: > Hi, > > I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. > > On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). > > I have prepared a small webrev with the suggested fix and a regression test: > > http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ > > Could you please review the patch and create a bug id? Thanks! > > Cheers, > Richard. > > BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) > From forax at univ-mlv.fr Thu Dec 13 11:20:46 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 13 Dec 2012 20:20:46 +0100 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> Message-ID: <50CA2A8E.40002@univ-mlv.fr> On 12/13/2012 07:32 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8005031/webrev.00/ > > A collection of small changes that were found to be required for the upcoming incremental inlining support and that we intend to push first so that they be tested in isolation. > > With incremental inlining, inlining doesn't happen in parse order anymore so the output of PrintInlining can get confusing. There's some support in this change to keep the PrintInlining output in order. > > Regarding add_node.cpp, I noticed some nodes wouldn't be found as dead by the igvn. I assume it is a bug. > > Roland. Incremental inlining in hotspot, wow, it's Christmas before Christmas ? R?mi From vladimir.kozlov at oracle.com Thu Dec 13 11:48:27 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Dec 2012 11:48:27 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: References: Message-ID: <50CA310B.4030701@oracle.com> We should use macroassembler instructions and we have special instruction to clear upper half: ins_encode %{ __ clruwu($src$$Register); __ popc($src$$Register, $dst$$Register); %} Vladimir On 12/13/12 10:46 AM, Christian Thalinger wrote: > > On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: > >> Hi, >> >> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >> >> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >> >> I have prepared a small webrev with the suggested fix and a regression test: >> >> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >> >> Could you please review the patch and create a bug id? Thanks! > > Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: > > 8005033: clear high word for integer pop count on SPARC > > It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? > > -- Chris > >> >> Cheers, >> Richard. >> >> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >> > From vladimir.kozlov at oracle.com Thu Dec 13 12:36:49 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Dec 2012 12:36:49 -0800 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> Message-ID: <50CA3C61.5090902@oracle.com> On 12/13/12 10:32 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8005031/webrev.00/ > > A collection of small changes that were found to be required for the upcoming incremental inlining support and that we intend to push first so that they be tested in isolation. Why you removed asserts in callnode.cpp? > > With incremental inlining, inlining doesn't happen in parse order anymore so the output of PrintInlining can get confusing. There's some support in this change to keep the PrintInlining output in order. I think "chunk" word is not appropriate for this. Maybe "Event" or something: PrintInliningChunk --> PrintInliningEvent _print_inlining_chunks --> _print_inlining_list Allocate the list in comp arena for use in later inlining: new(comp_arena()) LogCompilation output will be also affected. I remember fixing the tool for StringOpts. Could you verify that it works and fix it if it does not? > > Regarding add_node.cpp, I noticed some nodes wouldn't be found as dead by the igvn. I assume it is a bug. I think you should put it on igvn._worklist because PhaseIterGVN::optimize() does removal of nodes with outcount() == 0. I don't think it is safe to do it inside Ideal() call. Also, file RFE (starter_task) to find all similar cases (may be add the check for input nodes in transform_old()). Thanks, Vladimir > > Roland. > From vladimir.x.ivanov at oracle.com Thu Dec 13 15:02:40 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Dec 2012 02:02:40 +0300 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop Message-ID: <50CA5E90.7080708@oracle.com> http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 31 lines changed: 16 ins; 6 del; 9 mod In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's possible to hoist the load of _interrupted flag out of the loop. The fix is to add a barrier to forbid such optimization. Proposed fix is cleaner that [1] (no explicit memory state management). The place for the barrier is deliberately chosen earlier than necessary and it blocks hoisting of some loop invariants when Thread.isInterrupted() is called in a loop. But I think it's a fair price since I don't think that Thread.isInterrupted(Z)Z performance in tight loops is critical. If you prefer [1] let me know. Also, cleaned up the code around a little. Testing: failing test, manual (verified generated code), JPRT (in progress) Thanks! Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 From john.r.rose at oracle.com Thu Dec 13 14:31:31 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Dec 2012 14:31:31 -0800 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <50CA5E90.7080708@oracle.com> References: <50CA5E90.7080708@oracle.com> Message-ID: <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> On Dec 13, 2012, at 3:02 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 > 31 lines changed: 16 ins; 6 del; 9 mod > > In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's possible to hoist the load of _interrupted flag out of the loop. The fix is to add a barrier to forbid such optimization. > > Proposed fix is cleaner that [1] (no explicit memory state management). > The place for the barrier is deliberately chosen earlier than necessary and it blocks hoisting of some loop invariants when Thread.isInterrupted() is called in a loop. But I think it's a fair price since I don't think that Thread.isInterrupted(Z)Z performance in tight loops is critical. I don't see any new barrier in the simple fix. Where is it? It looks like the load of thr._interrupted can be hoisted under the same circumstances as before. If the slow path is somehow turned into a loop exit (via uncommon trap, maybe), then the memory state will fold up and the bit load can be hoisted. It seems like your "fast" fix is more robust, for this reason. Also, it's not your bug, but I'm not convinced that "slow_val = intcon(1)" is correct. I think another thread could come in and clear the interrupted bit, and this call to the native function could return false. > If you prefer [1] let me know. > > Also, cleaned up the code around a little. Good cleanups. ? John > Testing: failing test, manual (verified generated code), JPRT (in progress) > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 From morris.meyer at oracle.com Thu Dec 13 12:15:17 2012 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 13 Dec 2012 15:15:17 -0500 Subject: Request for reviews (S): 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 Message-ID: <50CA3755.8050303@oracle.com> Folks, Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. Thanks in advance, --morris meyer WEBREV - http://cr.openjdk.java.net/~twisti/8004250/ From morris.meyer at oracle.com Thu Dec 13 12:15:19 2012 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 13 Dec 2012 15:15:19 -0500 Subject: Request for reviews (S): 8004537: replace AbstractAssembler emit_long with emit_int32 Message-ID: <50CA3757.2050706@oracle.com> Folks, Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. Thanks in advance, --morris meyer WEBREV - http://cr.openjdk.java.net/~twisti/8004537/ From morris.meyer at oracle.com Thu Dec 13 12:15:22 2012 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 13 Dec 2012 15:15:22 -0500 Subject: Request for reviews (XS): 8004536: replace AbstractAssembler emit_word with emit_int16 Message-ID: <50CA375A.3070207@oracle.com> Folks, Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. Thanks in advance, --morris meyer WEBREV - http://cr.openjdk.java.net/~twisti/8004536 From vladimir.kozlov at oracle.com Thu Dec 13 15:05:45 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Dec 2012 15:05:45 -0800 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> References: <50CA5E90.7080708@oracle.com> <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> Message-ID: <50CA5F49.9000206@oracle.com> John, the barrier is before enum {} in simple fix. But I also prefer fast code. Vladimir I., You don't need second region node, use one. If you rearrange code to generate slow call first and the load on fast path last you may not need to preserve init_mem. Thanks, Vladimir K. On 12/13/12 2:31 PM, John Rose wrote: > On Dec 13, 2012, at 3:02 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 >> 31 lines changed: 16 ins; 6 del; 9 mod >> >> In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's possible to hoist the load of _interrupted flag out of the loop. The fix is to add a barrier to forbid such optimization. >> >> Proposed fix is cleaner that [1] (no explicit memory state management). >> The place for the barrier is deliberately chosen earlier than necessary and it blocks hoisting of some loop invariants when Thread.isInterrupted() is called in a loop. But I think it's a fair price since I don't think that Thread.isInterrupted(Z)Z performance in tight loops is critical. > > I don't see any new barrier in the simple fix. Where is it? It looks like the load of thr._interrupted can be hoisted under the same circumstances as before. If the slow path is somehow turned into a loop exit (via uncommon trap, maybe), then the memory state will fold up and the bit load can be hoisted. > > It seems like your "fast" fix is more robust, for this reason. > > Also, it's not your bug, but I'm not convinced that "slow_val = intcon(1)" is correct. I think another thread could come in and clear the interrupted bit, and this call to the native function could return false. > >> If you prefer [1] let me know. >> >> Also, cleaned up the code around a little. > > Good cleanups. > > ? John > >> Testing: failing test, manual (verified generated code), JPRT (in progress) >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 > From john.r.rose at oracle.com Thu Dec 13 15:25:36 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Dec 2012 15:25:36 -0800 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <50CA5F49.9000206@oracle.com> References: <50CA5E90.7080708@oracle.com> <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> <50CA5F49.9000206@oracle.com> Message-ID: <4657613A-0953-4058-AF32-831194C64AC8@oracle.com> On Dec 13, 2012, at 3:05 PM, Vladimir Kozlov wrote: > John, the barrier is before enum {} in simple fix. D'oh. Too simple for me, I guess. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121213/6a0a8791/attachment.html From vladimir.x.ivanov at oracle.com Thu Dec 13 16:29:49 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Dec 2012 03:29:49 +0300 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> References: <50CA5E90.7080708@oracle.com> <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> Message-ID: <50CA72FD.9090503@oracle.com> John, Thanks for the review! >> Proposed fix is cleaner that [1] (no explicit memory state management). >> The place for the barrier is deliberately chosen earlier than necessary and it blocks hoisting of some loop invariants when Thread.isInterrupted() is called in a loop. But I think it's a fair price since I don't think that Thread.isInterrupted(Z)Z performance in tight loops is critical. > > I don't see any new barrier in the simple fix. Where is it? It looks like the load of thr._interrupted can be hoisted under the same circumstances as before. If the slow path is somehow turned into a loop exit (via uncommon trap, maybe), then the memory state will fold up and the bit load can be hoisted. I placed it at the very beginning of the function. I'm not very comfortable with memory state management so far, but I don't see how it differs from "fast" fix. Memory graph seems almost the same between these 2 versions. The only difference is that the check of current thread is after the barrier. I'll experiment with converting slow call into uncommon trap and see how it works. > It seems like your "fast" fix is more robust, for this reason. > > Also, it's not your bug, but I'm not convinced that "slow_val = intcon(1)" is correct. I think another thread could come in and clear the interrupted bit, and this call to the native function could return false. Good catch! You are right, there's a window (though it's very small) when another thread can interrupt the thread. I didn't like known_current_thread variable and now I have a reason to completely remove it :-) Best regards, Vladimir Ivanov >> Proposed fix is cleaner that [1] (no explicit memory state management). >> The place for the barrier is deliberately chosen earlier than necessary and it blocks hoisting of some loop invariants when Thread.isInterrupted() is called in a loop. But I think it's a fair price since I don't think that Thread.isInterrupted(Z)Z performance in tight loops is critical. > > I don't see any new barrier in the simple fix. Where is it? It looks like the load of thr._interrupted can be hoisted under the same circumstances as before. If the slow path is somehow turned into a loop exit (via uncommon trap, maybe), then the memory state will fold up and the bit load can be hoisted. I placed it at the beginning of the function. > It seems like your "fast" fix is more robust, for this reason. > > Also, it's not your bug, but I'm not convinced that "slow_val = intcon(1)" is correct. I think another thread could come in and clear the interrupted bit, and this call to the native function could return false. Good catch! You are right, there's a very small window there. >> If you prefer [1] let me know. >> >> Also, cleaned up the code around a little. > > Good cleanups. > > ? John > >> Testing: failing test, manual (verified generated code), JPRT (in progress) >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 > From john.r.rose at oracle.com Thu Dec 13 15:32:57 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Dec 2012 15:32:57 -0800 Subject: Request for reviews (S): 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 In-Reply-To: <50CA3755.8050303@oracle.com> References: <50CA3755.8050303@oracle.com> Message-ID: Reviewed. ? John On Dec 13, 2012, at 12:15 PM, Morris Meyer wrote: > Folks, > > Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. > > Thanks in advance, > > --morris meyer > > WEBREV - http://cr.openjdk.java.net/~twisti/8004250/ From john.r.rose at oracle.com Thu Dec 13 15:33:03 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Dec 2012 15:33:03 -0800 Subject: Request for reviews (S): 8004537: replace AbstractAssembler emit_long with emit_int32 In-Reply-To: <50CA3757.2050706@oracle.com> References: <50CA3757.2050706@oracle.com> Message-ID: Reviewed. ? John On Dec 13, 2012, at 12:15 PM, Morris Meyer wrote: > Folks, > > Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. > > Thanks in advance, > > --morris meyer > > WEBREV - http://cr.openjdk.java.net/~twisti/8004537/ From john.r.rose at oracle.com Thu Dec 13 15:33:28 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Dec 2012 15:33:28 -0800 Subject: Request for reviews (XS): 8004536: replace AbstractAssembler emit_word with emit_int16 In-Reply-To: <50CA375A.3070207@oracle.com> References: <50CA375A.3070207@oracle.com> Message-ID: Reviewed. ? John (Third of three.) On Dec 13, 2012, at 12:15 PM, Morris Meyer wrote: > Folks, > > Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. > > Thanks in advance, > > --morris meyer > > WEBREV - http://cr.openjdk.java.net/~twisti/8004536 From john.r.rose at oracle.com Thu Dec 13 15:42:45 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Dec 2012 15:42:45 -0800 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <50CA72FD.9090503@oracle.com> References: <50CA5E90.7080708@oracle.com> <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> <50CA72FD.9090503@oracle.com> Message-ID: On Dec 13, 2012, at 4:29 PM, Vladimir Ivanov wrote: > I'm not very comfortable with memory state management so far, but I don't see how it differs from "fast" fix. Memory graph seems almost the same between these 2 versions. The only difference is that the check of current thread is after the barrier. > > I'll experiment with converting slow call into uncommon trap and see how it works. As long as there is a non-removable memory barrier (on the relevant memory slice) that dominates the loop backedge, you are good; the loop body will not hoist loads (on that memory slice). Almost any barrier position will work, I think, as long as it is unconditional in the loop (dominates backedge). My concern was that (being somehow blinded to your perfectly reasonable membar) the only barrier I could see was buried in the slow call, and that might go away in a strength-reduced loop, for any of a number of reasons. An uncommon trap would do it, and loop unswitching might do it, maybe. That is not a problem, though, in either of your fixes. >> > It seems like your "fast" fix is more robust, for this reason. I take that back! >> > Also, it's not your bug, but I'm not convinced that "slow_val = intcon(1)" is correct. I think another thread could come in and clear the interrupted bit, and this call to the native function could return false. > Good catch! You are right, there's a window (though it's very small) when another thread can interrupt the thread. I didn't like known_current_thread variable and now I have a reason to completely remove it :-) It might be a reasonable optimization, but if it can fail, even infrequently, it should be tested, like this: boolean tmp = makeSlowCall(...); if (tmp == false) uncommon_trap(); tmp = true; It's not clear that the optimization here is worth much, since it only kicks in if there has been a slow call, and surely the extra test would be noise. The best benefit is that the optimizer can speculate slightly better code after the slow call. The value of this is unclear. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121213/f861dcc9/attachment.html From vladimir.x.ivanov at oracle.com Thu Dec 13 16:55:13 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Dec 2012 03:55:13 +0300 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <50CA5F49.9000206@oracle.com> References: <50CA5E90.7080708@oracle.com> <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> <50CA5F49.9000206@oracle.com> Message-ID: <50CA78F1.70708@oracle.com> Vladimir K., Thanks for the review! > You don't need second region node, use one. Can you elaborate on this a little? Do you suggest to remove slow_region node? What should I use to point to slow path (for example, in generate_slow_guard(bol_thr, slow_call))? > If you rearrange code to generate slow call first and the load on fast path last you may not need to preserve init_mem. When considering moving slow path construction up, I was concerned about the case where there's no slow path: if (stopped()) { // There is no slow path. result_rgn->init_req(slow_result_path, top()); result_val->init_req(slow_result_path, top()); } else { Is it worth retaining? Best regards, Vladimir Ivanov On 12/14/12 2:05 AM, Vladimir Kozlov wrote: > John, the barrier is before enum {} in simple fix. > > But I also prefer fast code. > > Vladimir I., > > You don't need second region node, use one. > > If you rearrange code to generate slow call first and the load on fast > path last you may not need to preserve init_mem. > > Thanks, > Vladimir K. > > On 12/13/12 2:31 PM, John Rose wrote: >> On Dec 13, 2012, at 3:02 PM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 >>> 31 lines changed: 16 ins; 6 del; 9 mod >>> >>> In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's >>> possible to hoist the load of _interrupted flag out of the loop. The >>> fix is to add a barrier to forbid such optimization. >>> >>> Proposed fix is cleaner that [1] (no explicit memory state management). >>> The place for the barrier is deliberately chosen earlier than >>> necessary and it blocks hoisting of some loop invariants when >>> Thread.isInterrupted() is called in a loop. But I think it's a fair >>> price since I don't think that Thread.isInterrupted(Z)Z performance >>> in tight loops is critical. >> >> I don't see any new barrier in the simple fix. Where is it? It looks >> like the load of thr._interrupted can be hoisted under the same >> circumstances as before. If the slow path is somehow turned into a >> loop exit (via uncommon trap, maybe), then the memory state will fold >> up and the bit load can be hoisted. >> >> It seems like your "fast" fix is more robust, for this reason. >> >> Also, it's not your bug, but I'm not convinced that "slow_val = >> intcon(1)" is correct. I think another thread could come in and clear >> the interrupted bit, and this call to the native function could return >> false. >> >>> If you prefer [1] let me know. >>> >>> Also, cleaned up the code around a little. >> >> Good cleanups. >> >> ? John >> >>> Testing: failing test, manual (verified generated code), JPRT (in >>> progress) >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 >> From christian.thalinger at oracle.com Thu Dec 13 16:02:38 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 13 Dec 2012 16:02:38 -0800 Subject: Request for reviews (S): 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 In-Reply-To: <50CA3755.8050303@oracle.com> References: <50CA3755.8050303@oracle.com> Message-ID: <46FEE692-97B7-43A8-89FD-4A409768DB4A@oracle.com> Looks good. -- Chris On Dec 13, 2012, at 12:15 PM, Morris Meyer wrote: > Folks, > > Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. > > Thanks in advance, > > --morris meyer > > WEBREV - http://cr.openjdk.java.net/~twisti/8004250/ From christian.thalinger at oracle.com Thu Dec 13 16:02:56 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 13 Dec 2012 16:02:56 -0800 Subject: Request for reviews (XS): 8004536: replace AbstractAssembler emit_word with emit_int16 In-Reply-To: <50CA375A.3070207@oracle.com> References: <50CA375A.3070207@oracle.com> Message-ID: <927279BE-A35B-425B-9CC6-DDAB2EB13BF5@oracle.com> Looks good. -- Chris On Dec 13, 2012, at 12:15 PM, Morris Meyer wrote: > Folks, > > Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. > > Thanks in advance, > > --morris meyer > > WEBREV - http://cr.openjdk.java.net/~twisti/8004536 From christian.thalinger at oracle.com Thu Dec 13 16:03:31 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 13 Dec 2012 16:03:31 -0800 Subject: Request for reviews (S): 8004537: replace AbstractAssembler emit_long with emit_int32 In-Reply-To: <50CA3757.2050706@oracle.com> References: <50CA3757.2050706@oracle.com> Message-ID: <07C8A007-BEBE-4AE5-B68B-9D81B1D50FB4@oracle.com> Looks good. -- Chris On Dec 13, 2012, at 12:15 PM, Morris Meyer wrote: > Folks, > > Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. > > Thanks in advance, > > --morris meyer > > WEBREV - http://cr.openjdk.java.net/~twisti/8004537/ From vladimir.x.ivanov at oracle.com Thu Dec 13 17:03:36 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Dec 2012 04:03:36 +0300 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: References: <50CA5E90.7080708@oracle.com> <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> <50CA72FD.9090503@oracle.com> Message-ID: <50CA7AE8.2060508@oracle.com> John, Thank you for the detailed explanation. Best regards, Vladimir Ivanov On 12/14/12 2:42 AM, John Rose wrote: > On Dec 13, 2012, at 4:29 PM, Vladimir Ivanov wrote: > >> I'm not very comfortable with memory state management so far, but I >> don't see how it differs from "fast" fix. Memory graph seems almost >> the same between these 2 versions. The only difference is that the >> check of current thread is after the barrier. >> >> I'll experiment with converting slow call into uncommon trap and see >> how it works. > > As long as there is a non-removable memory barrier (on the relevant > memory slice) that dominates the loop backedge, you are good; the loop > body will not hoist loads (on that memory slice). Almost any barrier > position will work, I think, as long as it is unconditional in the loop > (dominates backedge). > > My concern was that (being somehow blinded to your perfectly reasonable > membar) the only barrier I could see was buried in the slow call, and > that might go away in a strength-reduced loop, for any of a number of > reasons. An uncommon trap would do it, and loop unswitching might do > it, maybe. That is not a problem, though, in either of your fixes. > >>> > It seems like your "fast" fix is more robust, for this reason. > I take that back! > >>> > Also, it's not your bug, but I'm not convinced that "slow_val = intcon(1)" is correct. I think another thread could come in and clear the interrupted bit, and this call to the native function could return false. > >> Good catch! You are right, there's a window (though it's very small) >> when another thread can interrupt the thread. I didn't like >> known_current_thread variable and now I have a reason to completely >> remove it :-) > > It might be a reasonable optimization, but if it can fail, even > infrequently, it should be tested, like this: > > boolean tmp = makeSlowCall(...); > if (tmp == false) uncommon_trap(); > tmp = true; > > It's not clear that the optimization here is worth much, since it only > kicks in if there has been a slow call, and surely the extra test would > be noise. The best benefit is that the optimizer can speculate slightly > better code after the slow call. The value of this is unclear. > > ? John From vladimir.kozlov at oracle.com Thu Dec 13 16:29:54 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Dec 2012 16:29:54 -0800 Subject: Request for reviews (S): 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 In-Reply-To: <50CA3755.8050303@oracle.com> References: <50CA3755.8050303@oracle.com> Message-ID: <50CA7302.2050808@oracle.com> Morris, Why you need the cast to uchar? ! __ emit_int8((unsigned char)0xB8); Thanks, Vladimir On 12/13/12 12:15 PM, Morris Meyer wrote: > Folks, > > Could I get a review of this cleanup requested by Christian Thalinger? > This has been tested on JPRT. > > Thanks in advance, > > --morris meyer > > WEBREV - http://cr.openjdk.java.net/~twisti/8004250/ From vladimir.kozlov at oracle.com Thu Dec 13 16:32:02 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Dec 2012 16:32:02 -0800 Subject: Request for reviews (S): 8004537: replace AbstractAssembler emit_long with emit_int32 In-Reply-To: <50CA3757.2050706@oracle.com> References: <50CA3757.2050706@oracle.com> Message-ID: <50CA7382.2000903@oracle.com> Good. Vladimir On 12/13/12 12:15 PM, Morris Meyer wrote: > Folks, > > Could I get a review of this cleanup requested by Christian Thalinger? > This has been tested on JPRT. > > Thanks in advance, > > --morris meyer > > WEBREV - http://cr.openjdk.java.net/~twisti/8004537/ From vladimir.kozlov at oracle.com Thu Dec 13 16:37:39 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Dec 2012 16:37:39 -0800 Subject: Request for reviews (XS): 8004536: replace AbstractAssembler emit_word with emit_int16 In-Reply-To: <50CA375A.3070207@oracle.com> References: <50CA375A.3070207@oracle.com> Message-ID: <50CA74D3.4030905@oracle.com> Good. Vladimir On 12/13/12 12:15 PM, Morris Meyer wrote: > Folks, > > Could I get a review of this cleanup requested by Christian Thalinger? > This has been tested on JPRT. > > Thanks in advance, > > --morris meyer > > WEBREV - http://cr.openjdk.java.net/~twisti/8004536 From vladimir.kozlov at oracle.com Thu Dec 13 17:11:36 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Dec 2012 17:11:36 -0800 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <50CA78F1.70708@oracle.com> References: <50CA5E90.7080708@oracle.com> <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> <50CA5F49.9000206@oracle.com> <50CA78F1.70708@oracle.com> Message-ID: <50CA7CC8.7010203@oracle.com> On 12/13/12 4:55 PM, Vladimir Ivanov wrote: > Vladimir K., > > Thanks for the review! > > > You don't need second region node, use one. > Can you elaborate on this a little? > Do you suggest to remove slow_region node? What should I use to point to > slow path (for example, in generate_slow_guard(bol_thr, slow_call))? Never mind this. We can't remove slow_region because there are 2 input paths. > > > If you rearrange code to generate slow call first and the load on > fast path last you may not need to preserve init_mem. It looks like "fast" approach is much more complicated than I thought. OK, go with "simple" case but move insert_mem_bar down (below enum) where we can see it. Your comments for enum values are incorrect. !TLS... should be switched like next: no_int_result_path = 1, // t == Thread.current() && !TLS._osthread._interrupted no_clear_result_path = 2, // t == Thread.current() && TLS._osthread._interrupted && !clear_int Thanks, Vladimir K. > When considering moving slow path construction up, I was concerned about > the case where there's no slow path: > if (stopped()) { > // There is no slow path. > result_rgn->init_req(slow_result_path, top()); > result_val->init_req(slow_result_path, top()); > } else { > > Is it worth retaining? > > Best regards, > Vladimir Ivanov > > On 12/14/12 2:05 AM, Vladimir Kozlov wrote: >> John, the barrier is before enum {} in simple fix. >> >> But I also prefer fast code. >> >> Vladimir I., >> >> You don't need second region node, use one. >> >> If you rearrange code to generate slow call first and the load on fast >> path last you may not need to preserve init_mem. >> >> Thanks, >> Vladimir K. >> >> On 12/13/12 2:31 PM, John Rose wrote: >>> On Dec 13, 2012, at 3:02 PM, Vladimir Ivanov wrote: >>> >>>> http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 >>>> 31 lines changed: 16 ins; 6 del; 9 mod >>>> >>>> In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's >>>> possible to hoist the load of _interrupted flag out of the loop. The >>>> fix is to add a barrier to forbid such optimization. >>>> >>>> Proposed fix is cleaner that [1] (no explicit memory state management). >>>> The place for the barrier is deliberately chosen earlier than >>>> necessary and it blocks hoisting of some loop invariants when >>>> Thread.isInterrupted() is called in a loop. But I think it's a fair >>>> price since I don't think that Thread.isInterrupted(Z)Z performance >>>> in tight loops is critical. >>> >>> I don't see any new barrier in the simple fix. Where is it? It looks >>> like the load of thr._interrupted can be hoisted under the same >>> circumstances as before. If the slow path is somehow turned into a >>> loop exit (via uncommon trap, maybe), then the memory state will fold >>> up and the bit load can be hoisted. >>> >>> It seems like your "fast" fix is more robust, for this reason. >>> >>> Also, it's not your bug, but I'm not convinced that "slow_val = >>> intcon(1)" is correct. I think another thread could come in and clear >>> the interrupted bit, and this call to the native function could return >>> false. >>> >>>> If you prefer [1] let me know. >>>> >>>> Also, cleaned up the code around a little. >>> >>> Good cleanups. >>> >>> ? John >>> >>>> Testing: failing test, manual (verified generated code), JPRT (in >>>> progress) >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 >>> From vladimir.kozlov at oracle.com Thu Dec 13 18:03:59 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Dec 2012 18:03:59 -0800 Subject: RFR(M): pass outputStream to more opto debug routines In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF73EB5AD@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF73EB5AD@DEWDFECCR03.wdf.sap.corp> Message-ID: <50CA890F.6030006@oracle.com> Thank you, Goetz, for doing this. Changes are good. One thing I want to ask you is a small codding style cleanup. We are converting all cases of "if( a )" to "if (a)" in a methods we touch. And I see you have cases like that. Thanks, Vladimir On 12/13/12 2:49 AM, Lindenmaier, Goetz wrote: > Hi, > > We pass the outputStream to much more debug routines than openJDK does, > > as we write a lot more information to files e.g., in case of a crash. > > I would like to contribute the changes that allow to pass the output > stream to > > node->dump() and everything reachable from there. > > This also fixes the usage of output stream in print_register_type() in > oopMap.cpp and > > in MachNullCheckNode::format(), where a single print command still used tty. > > Further we initialize _node_regs_max_index so that > node_regs_max_index() == 0 > > indicates that registers of a node can be accessed. This is also useful in > > debug output. > > http://cr.openjdk.java.net/~goetz/webrevs/webrev-os_in_nodeDump/ > > Best regards, > > Goetz. > From vladimir.kozlov at oracle.com Thu Dec 13 18:11:27 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Dec 2012 18:11:27 -0800 Subject: RFR(M): pass outputStream to more opto debug routines In-Reply-To: <50CA890F.6030006@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF73EB5AD@DEWDFECCR03.wdf.sap.corp> <50CA890F.6030006@oracle.com> Message-ID: <50CA8ACF.1070602@oracle.com> RFE created: 8005055: pass outputStream to more opto debug routines On 12/13/12 6:03 PM, Vladimir Kozlov wrote: > Thank you, Goetz, for doing this. > > Changes are good. One thing I want to ask you is a small codding style > cleanup. We are converting all cases of "if( a )" to "if (a)" in a > methods we touch. And I see you have cases like that. > > Thanks, > Vladimir > > On 12/13/12 2:49 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> We pass the outputStream to much more debug routines than openJDK does, >> >> as we write a lot more information to files e.g., in case of a crash. >> >> I would like to contribute the changes that allow to pass the output >> stream to >> >> node->dump() and everything reachable from there. >> >> This also fixes the usage of output stream in print_register_type() in >> oopMap.cpp and >> >> in MachNullCheckNode::format(), where a single print command still >> used tty. >> >> Further we initialize _node_regs_max_index so that >> node_regs_max_index() == 0 >> >> indicates that registers of a node can be accessed. This is also >> useful in >> >> debug output. >> >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-os_in_nodeDump/ >> >> Best regards, >> >> Goetz. >> From vladimir.kozlov at oracle.com Thu Dec 13 22:11:16 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 14 Dec 2012 06:11:16 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004713: Stackoverflowerror thrown when thread stack straddles 0x80000000 Message-ID: <20121214061120.A23064713F@hg.openjdk.java.net> Changeset: a70c88896791 Author: kvn Date: 2012-12-13 17:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a70c88896791 8004713: Stackoverflowerror thrown when thread stack straddles 0x80000000 Summary: use unsigned comparison when checking for stack overflow Reviewed-by: kvn, twisti Contributed-by: paul.nauman at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp From john.coomes at oracle.com Fri Dec 14 01:56:44 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 09:56:44 +0000 Subject: hg: hsx/hotspot-comp: 8 new changesets Message-ID: <20121214095644.CC94247149@hg.openjdk.java.net> Changeset: ab1ab9b148dd Author: smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ab1ab9b148dd 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties Changeset: ad54163c95f5 Author: lana Date: 2012-11-30 16:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ad54163c95f5 Merge Changeset: 04435608c613 Author: lana Date: 2012-12-10 20:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/04435608c613 Merge Changeset: 6b96b7744913 Author: erikj Date: 2012-12-07 17:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/6b96b7744913 8004045: build-infra: Error 12 from zip when updating src.zip Summary: Hiding this error from make so that it doesn't fail Reviewed-by: ohrstrom, dholmes ! common/makefiles/JavaCompilation.gmk Changeset: 2795874efd16 Author: erikj Date: 2012-12-11 11:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2795874efd16 8003945: build-infra: problems finding compiler when using --with-dev-kit Summary: Search all compiler names in dev-kit dir first. Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: e175ecff1391 Author: erikj Date: 2012-12-11 11:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/e175ecff1391 8001753: build-infra: mismatch with full debug symbol control for hotspot Summary: Enabling hotspot to use the FDS settings established at configure time Reviewed-by: dholmes, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/makefiles/NativeCompilation.gmk Changeset: cdb401a60cea Author: katleman Date: 2012-12-12 13:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/cdb401a60cea Merge Changeset: e9ec00893bb4 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/e9ec00893bb4 Added tag jdk8-b68 for changeset cdb401a60cea ! .hgtags From john.coomes at oracle.com Fri Dec 14 01:56:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 09:56:49 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b68 for changeset 82000531feaa Message-ID: <20121214095651.3DFA34714A@hg.openjdk.java.net> Changeset: 22ddcac208a8 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/22ddcac208a8 Added tag jdk8-b68 for changeset 82000531feaa ! .hgtags From john.coomes at oracle.com Fri Dec 14 01:56:55 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 09:56:55 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b68 for changeset b854e7008421 Message-ID: <20121214095703.71F944714B@hg.openjdk.java.net> Changeset: 789a855de959 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/789a855de959 Added tag jdk8-b68 for changeset b854e7008421 ! .hgtags From john.coomes at oracle.com Fri Dec 14 01:57:14 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 09:57:14 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b68 for changeset d3fe408f3a9a Message-ID: <20121214095719.4E5EC4714C@hg.openjdk.java.net> Changeset: 756323c99011 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/756323c99011 Added tag jdk8-b68 for changeset d3fe408f3a9a ! .hgtags From john.coomes at oracle.com Fri Dec 14 02:00:04 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 10:00:04 +0000 Subject: hg: hsx/hotspot-comp/jdk: 69 new changesets Message-ID: <20121214101357.44ACE4714F@hg.openjdk.java.net> Changeset: 39f9b2cc5738 Author: bae Date: 2012-11-28 12:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39f9b2cc5738 4649812: GIFImageReader handles transparency incorrectly Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Changeset: 6569819eb2fe Author: bae Date: 2012-11-28 12:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6569819eb2fe 5082749: GIF stream metadata specification of aspect ratio is incorrect Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev ! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html Changeset: 934595726263 Author: bae Date: 2012-11-28 14:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/934595726263 7064516: ImageIO.read() fails to load an image Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/image/ColorConvertOp.java + test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java Changeset: d54db1e16b97 Author: bae Date: 2012-11-30 11:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d54db1e16b97 7124223: [macosx] Regression test failure with new exception, when glyph is positioned explicitly Reviewed-by: jgodinez ! src/share/classes/sun/print/PathGraphics.java Changeset: bd3b3cda125d Author: lana Date: 2012-11-30 16:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bd3b3cda125d Merge Changeset: 3c5bf5ed45a9 Author: bae Date: 2012-12-03 16:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3c5bf5ed45a9 7124347: [macosx] java.lang.InternalError: not implemented yet on call Graphics2D.drawRenderedImage Reviewed-by: prr, flar ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java + test/sun/java2d/OpenGL/CustomCompositeTest.java Changeset: 1175410d98ea Author: serb Date: 2012-11-21 15:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1175410d98ea 7124552: [macosx] NullPointerException in getBufferStrategy() 7124219: [macosx] Unable to draw images to fullscreen Reviewed-by: bae, anthony ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java + src/macosx/classes/sun/lwawt/LWGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 5b2c31d20a64 Author: serb Date: 2012-11-21 15:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5b2c31d20a64 7193214: Consider simplifying CPlatformWindow.setResizable() Reviewed-by: anthony, denis ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: c9dead63607c Author: serb Date: 2012-11-21 15:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c9dead63607c 7154516: [macosx] Popup menus have no visible borders Reviewed-by: anthony, denis ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java Changeset: 9cd48409539e Author: kizune Date: 2012-11-21 20:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9cd48409539e 8003273: Missing testcase for 7171812 Reviewed-by: art, serb + test/javax/swing/dnd/7171812/JListWithScroll.java + test/javax/swing/dnd/7171812/bug7171812.java Changeset: 5600005b87fb Author: serb Date: 2012-11-27 17:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5600005b87fb 8002308: [macosx] 7198229 should be applied to the user action only Reviewed-by: anthony, skovatch ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java Changeset: 0e91d6f3019c Author: alexsch Date: 2012-11-29 07:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0e91d6f3019c 8000423: Diacritic is not applyed to a base letter on Linux Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: abee1d528df1 Author: kshefov Date: 2012-11-30 12:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/abee1d528df1 7124242: [macosx] Test doesn't work because of the frame round corners in the LaF Reviewed-by: anthony, yan, alexsch ! test/javax/swing/text/CSSBorder/6796710/bug6796710.java Changeset: 35d8085aa14a Author: lana Date: 2012-11-30 17:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/35d8085aa14a Merge Changeset: da55ef766e48 Author: alexsch Date: 2012-12-04 15:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/da55ef766e48 6671481: NPE at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection Reviewed-by: serb ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: bd175c70684c Author: alexsch Date: 2012-12-04 15:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bd175c70684c 8003830: NPE at BasicTreeUI$Actions.page:4470 Reviewed-by: serb, alexsch Contributed-by: Jaroslav Tulach ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/8003830/bug8003830.java Changeset: 009fd6e1d9f5 Author: alexsch Date: 2012-12-04 16:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/009fd6e1d9f5 8002077: Possible mnemonic issue on JFileChooser Save button on nimbus L&F Reviewed-by: serb ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java Changeset: 4aad3e6f68d2 Author: jviswana Date: 2012-12-04 17:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4aad3e6f68d2 4631925: JColor Chooser is not fully accessible Reviewed-by: alexsch ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorPanel.java ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java Changeset: ea20c9388d90 Author: aph Date: 2012-12-04 14:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ea20c9388d90 8004344: Fix a crash in ToolkitErrorHandler() in XlibWrapper.c Summary: Code does not check for JNU_GetEnv returning NULL. Reviewed-by: anthony ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: bbbb5c70aa59 Author: lana Date: 2012-12-04 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bbbb5c70aa59 Merge - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: f389bf27fc4f Author: dbuck Date: 2012-11-20 21:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f389bf27fc4f 7198904: (alt-rt) TreeMap.clone is broken Summary: Test case for cr7198904. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou, dholmes + test/java/util/TreeMap/Clone.java Changeset: ee6e5b7d5d55 Author: uta Date: 2012-11-23 13:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ee6e5b7d5d55 8003898: X11 toolkit can be chosen as the default toolkit Summary: XToolkit is not selected for any values of system-wide environment variables (ex. DISPLAY). Reviewed-by: anthony, art ! src/solaris/native/java/lang/java_props_macosx.c Changeset: 621c379d909d Author: xuelei Date: 2012-11-24 03:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/621c379d909d 8001751: Javadoc warnings in JSSE code Reviewed-by: alanb ! src/share/classes/javax/net/ssl/HostnameVerifier.java ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/SNIMatcher.java ! src/share/classes/javax/net/ssl/SNIServerName.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java Changeset: f7d45462b225 Author: xuelei Date: 2012-11-24 04:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f7d45462b225 8003950: Adds missing Override annotations and removes unnecessary imports in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHCrypt.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/ExtensionType.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/ServerNameExtension.java ! src/share/classes/sun/security/ssl/SessionId.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/UnknownExtension.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: d30c13172254 Author: xuelei Date: 2012-11-24 04:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d30c13172254 8003951: Removes unused variables in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: 8970128e040d Author: uta Date: 2012-11-26 15:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8970128e040d 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) Summary: In problem tests detection of AWT headless mode was introduced or AWT dependence was removed. Reviewed-by: alanb ! test/ProblemList.txt ! test/demo/jvmti/mtrace/TraceJFrame.java ! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java ! test/java/io/Serializable/resolveClass/deserializeButton/Test.java ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh Changeset: 054470092795 Author: mullan Date: 2012-11-26 08:12 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/054470092795 7167056: Clarify that BasicPermission names that contain non-wildcard asterisks are not invalid Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/net/ssl/SSLPermission.java ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java + test/java/security/BasicPermission/Wildcard.java Changeset: ea66140be78d Author: mullan Date: 2012-11-26 08:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ea66140be78d Merge - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java Changeset: d7ed56d57d97 Author: mullan Date: 2012-11-26 08:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d7ed56d57d97 Merge Changeset: c2e80176a697 Author: mduigou Date: 2012-11-26 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c2e80176a697 8001634: Initial set of functional interface types Summary: Add the core functional interfaces used by the JSR335 libraries. Reviewed-by: dholmes, briangoetz, darcy ! make/docs/CORE_PKGS.gmk ! make/java/java/Makefile + src/share/classes/java/util/function/BinaryOperator.java + src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/DoubleBinaryOperator.java + src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoubleSupplier.java + src/share/classes/java/util/function/DoubleUnaryOperator.java + src/share/classes/java/util/function/Function.java + src/share/classes/java/util/function/IntBinaryOperator.java + src/share/classes/java/util/function/IntBlock.java + src/share/classes/java/util/function/IntFunction.java + src/share/classes/java/util/function/IntSupplier.java + src/share/classes/java/util/function/IntUnaryOperator.java + src/share/classes/java/util/function/LongBinaryOperator.java + src/share/classes/java/util/function/LongBlock.java + src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongSupplier.java + src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/Supplier.java + src/share/classes/java/util/function/UnaryOperator.java + src/share/classes/java/util/function/package-info.java Changeset: ddf97baea570 Author: chegar Date: 2012-11-27 17:15 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ddf97baea570 8003833: Spurious NPE from Socket.getIn/OutputStream Reviewed-by: alanb, dsamersoff ! src/share/classes/java/net/AbstractPlainSocketImpl.java + test/java/net/Socket/Streams.java Changeset: 40311b5f478f Author: robm Date: 2012-11-28 00:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/40311b5f478f 8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests Reviewed-by: chegar + test/java/net/ResponseCache/Test.java + test/java/net/Socket/B6210227.java Changeset: 39b25d5880c6 Author: sherman Date: 2012-11-27 21:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39b25d5880c6 4235519: Make sun.misc.BASE64{De,En}coder classes public Summary: to add java.util.Base64 Reviewed-by: alanb, mduigou ! make/java/java/FILES_java.gmk Changeset: c6ed2c238d4f Author: sherman Date: 2012-11-27 22:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c6ed2c238d4f 8004088: hg push for bug#4235519 failed to push all files Summary: pushed all base64 files Reviewed-by: alanb, mduigou + src/share/classes/java/util/Base64.java + test/java/util/Base64/TestBase64.java + test/java/util/Base64/TestBase64Golden.java + test/java/util/Base64/baseEncode.txt + test/java/util/Base64/mimeEncode.txt + test/java/util/Base64/plain.txt + test/java/util/Base64/urlEncode.txt Changeset: 46c627801490 Author: xuelei Date: 2012-11-28 05:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/46c627801490 8004019: Removes unused method HandshakeHash.setCertificateVerifyAlg() Summary: certification verification in HandshakeHash was abandoned during TLS 1.2 implementation Reviewed-by: xuelei, weijun Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java Changeset: 735b93462eed Author: jfranck Date: 2012-11-28 09:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/735b93462eed 7154390: Add support for repeating annotations in j.l.r.AnnotatedElement Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/annotation/ContainedBy.java ! src/share/classes/java/lang/annotation/ContainerFor.java + src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java + test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedNonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/NonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/package-info.java Changeset: 3b6a2fe6d75c Author: dfuchs Date: 2012-11-28 15:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3b6a2fe6d75c 8003476: Cleanup warnings in com.sun.jmx.snmp code Reviewed-by: alanb, smarks ! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java ! src/share/classes/com/sun/jmx/snmp/Enumerated.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java ! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java ! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java Changeset: 262b3b2f3aa3 Author: dfuchs Date: 2012-11-28 10:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/262b3b2f3aa3 Merge Changeset: 09bef1e118e3 Author: mchung Date: 2012-11-28 10:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/09bef1e118e3 8003851: MethodHandleNatives dependency on java.sql.DriverManager Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 80ddee59a21d Author: mchung Date: 2012-11-28 10:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/80ddee59a21d 8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory dependency on java.util.logging Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java Changeset: 13ec794734f5 Author: michaelm Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/13ec794734f5 7200720: crash in net.dll during NTLM authentication Reviewed-by: chegar, dsamersoff ! make/java/net/Makefile ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c Changeset: ba5eabd6a37b Author: michaelm Date: 2012-11-29 09:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ba5eabd6a37b Merge Changeset: 2b829a5a46ee Author: jgish Date: 2012-11-29 12:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2b829a5a46ee 8003380: Compiler warnings in logging test code Summary: Use generics, suppress warnings where appropriate, remove unused imports, etc. Reviewed-by: lancea, chegar ! test/java/util/logging/ClassLoaderLeakTest.java ! test/java/util/logging/Listeners.java ! test/java/util/logging/ListenersWithSM.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/LoggingDeadlock4.java ! test/java/util/logging/LoggingMXBeanTest.java ! test/java/util/logging/LoggingMXBeanTest2.java ! test/java/util/logging/MemoryHandlerTest.java ! test/java/util/logging/ParentLoggersTest.java ! test/java/util/logging/SimpleFormatterFormat.java Changeset: d91e6cb1da41 Author: shade Date: 2012-11-29 17:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d91e6cb1da41 8004141: UnsafeStaticFieldAccessorImpl#base should be final Reviewed-by: chegar, alanb Contributed-by: peter.levart at gmail.com ! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java Changeset: bf6ceb6b8f80 Author: mduigou Date: 2012-11-29 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bf6ceb6b8f80 7175464: entrySetView field is never updated in NavigableSubMap Summary: The method entrySet() in AscendingSubMap and DescendingSubMap failed to cache the entrySetView. Reviewed-by: alanb, psandoz ! src/share/classes/java/util/TreeMap.java Changeset: 75cb07a7b622 Author: mduigou Date: 2012-11-29 14:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/75cb07a7b622 6553074: String{Buffer,Builder}.indexOf(Str, int) contains unnecessary allocation Summary: It is not necessary to extract the value array with toCharArray. The value array can now be used directly. Reviewed-by: alanb ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java Changeset: 83d9f30ebeed Author: smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/83d9f30ebeed 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties Changeset: 7ccf93c60c4d Author: smarks Date: 2012-11-29 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7ccf93c60c4d 8004134: More ProblemList.txt updates (11/2012) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt Changeset: 55f8ddc2f9c6 Author: sla Date: 2012-11-30 08:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/55f8ddc2f9c6 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo Reviewed-by: okutsu ! test/java/util/TimeZone/Bug6912560.java Changeset: e988de7465d4 Author: zhangshj Date: 2012-11-30 17:24 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e988de7465d4 8004211: Remove unused dlinfo local variable in launcher code Reviewed-by: alanb ! src/solaris/bin/java_md_solinux.c Changeset: 72d3d07b625d Author: alanb Date: 2012-11-30 11:18 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/72d3d07b625d 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties Reviewed-by: psandoz, mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: c370048be8fc Author: alanb Date: 2012-11-30 16:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c370048be8fc 7165762: (aio) Default thread pool should be configured so that threads terminated after a timeout period Reviewed-by: chegar ! src/share/classes/sun/nio/ch/ThreadPool.java Changeset: e7edb0da9c6a Author: jfranck Date: 2012-11-30 09:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e7edb0da9c6a 8004110: Remove debug code form sun/reflect/annotation/AnnotationSupport.java Reviewed-by: jjg, darcy ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java Changeset: 43d2e02c4098 Author: khazra Date: 2012-11-30 12:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/43d2e02c4098 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock" Summary: Set -Djava.util.prefs.userRoot to current working directory of user in the prefs tests Reviewed-by: alanb, chegar, weijun, dxu ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/CommentsInXml.java ! test/java/util/prefs/ConflictInFlush.java ! test/java/util/prefs/ExportNode.java ! test/java/util/prefs/ExportSubtree.java ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/prefs/RemoveNullKeyCheck.java ! test/java/util/prefs/RemoveReadOnlyNode.java ! test/java/util/prefs/RemoveUnregedListener.java Changeset: e66ec5b8c15e Author: lana Date: 2012-11-30 16:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e66ec5b8c15e Merge Changeset: fd8ba2d8baec Author: sherman Date: 2012-12-01 11:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fd8ba2d8baec 8004212: java.util.Base64 methods decodeArray and decodeBuffer should return the number of bytes written Summary: to return the length instead of position Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: f657adf4fe78 Author: alanb Date: 2012-12-02 16:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f657adf4fe78 8003846: Override mechanism for currency data should not require creating currency.properties in java.home Reviewed-by: naoto ! src/share/classes/java/util/Currency.java ! test/java/util/Currency/PropertiesTest.java ! test/java/util/Currency/PropertiesTest.sh Changeset: 60550cd2b527 Author: dholmes Date: 2012-12-02 19:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/60550cd2b527 7200297: agent code does not handle multiple boot library path elements correctly Summary: When bug 6819213 was fixed it enabled sun.boot.library.path property to contain multiple paths. Code in agents does not handle multiple paths when attempting to find dependent shared libs. Reviewed-by: dholmes, sspitsyn, dsamersoff Contributed-by: Bill Pittore ! src/share/back/debugInit.c ! src/share/back/error_messages.c ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/npt/npt_md.h ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c ! src/windows/npt/npt_md.h Changeset: a42da685dfca Author: weijun Date: 2012-12-03 17:14 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a42da685dfca 7198507: [TEST_BUG] sun/security/tools/keytool/console.sh should be rewritten Reviewed-by: xuelei ! test/sun/security/tools/keytool/console.sh Changeset: ead651efb271 Author: xuelei Date: 2012-12-03 06:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ead651efb271 8004184: security tests leave JSSEServer running Summary: Use othervm mode to release resources, and correct the system properties issues in JSSE Reviewed-by: chegar ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java Changeset: ee9846f351d7 Author: mullan Date: 2012-12-03 11:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ee9846f351d7 7199143: RFE: OCSP revocation checker should provide possibility to specify connection timeout Summary: Added com.sun.security.ocsp.timeout system property to control timeout Reviewed-by: mullan, vinnie Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: 38ec2838dd86 Author: dxu Date: 2012-12-04 14:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/38ec2838dd86 7142921: (fs) Files.probeContentType reports a MIME type of "text/plain" on Ubuntu 11.04 7144997: (fs) Files.probeContentType returns null on Solaris 64-bit Reviewed-by: alanb, mduigou ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/mapfiles/libnio/mapfile-linux ! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MagicFileTypeDetector.java + src/solaris/classes/sun/nio/fs/MimeTypesFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java + src/solaris/native/sun/nio/fs/MagicFileTypeDetector.c Changeset: 2e8863c4f7d0 Author: kmo Date: 2012-12-04 15:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2e8863c4f7d0 8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message Reviewed-by: twisti, alanb, dholmes ! test/java/lang/Math/DivModTests.java Changeset: 87028eb3f020 Author: lana Date: 2012-12-04 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/87028eb3f020 Merge Changeset: b68a5404de60 Author: lana Date: 2012-12-10 20:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b68a5404de60 Merge ! makefiles/CompileJavaClasses.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 379e3dfa521d Author: erikj Date: 2012-12-06 12:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/379e3dfa521d 8004104: build-infra: Minor cleanup Reviewed-by: ohrstrom, tbell ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 2689f6cfe835 Author: erikj Date: 2012-12-11 12:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2689f6cfe835 8001753: build-infra: mismatch with full debug symbol control for hotspot Summary: Changing boolean values of ENABLE_DEBUG_SYMBOLS. Reviewed-by: dholmes, ohair ! makefiles/CompileNativeLibraries.gmk Changeset: 53fb43e4d614 Author: katleman Date: 2012-12-12 13:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/53fb43e4d614 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 7fd56a5abd94 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7fd56a5abd94 Added tag jdk8-b68 for changeset 53fb43e4d614 ! .hgtags From john.coomes at oracle.com Fri Dec 14 02:16:10 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 10:16:10 +0000 Subject: hg: hsx/hotspot-comp/langtools: 13 new changesets Message-ID: <20121214101700.6149947152@hg.openjdk.java.net> Changeset: d9fe1f80515d Author: vromero Date: 2012-11-21 18:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d9fe1f80515d 7190862: javap shows an incorrect type for operands if the 'wide' prefix is used 7109747: (javap) classfile not treating iinc_w correctly. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/Opcode.java + test/tools/javap/T7190862.java Changeset: 3746b071d75b Author: vromero Date: 2012-11-21 19:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/3746b071d75b 6574624: javax.tools.JavaCompiler spec contains errors in sample code Reviewed-by: jjg, mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 4d68e2a05b50 Author: jjg Date: 2012-11-27 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4d68e2a05b50 8004068: Fix build problems caused by on-demand imports Reviewed-by: jjg Contributed-by: eric.caspole at amd.com ! src/share/classes/com/sun/tools/javac/code/Types.java Changeset: 1f41a5758cf7 Author: vromero Date: 2012-11-23 15:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1f41a5758cf7 7144981: javac should ignore ignorable characters in input Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java + test/tools/javac/7144981/IgnoreIgnorableCharactersInInput.java Changeset: 969c96b980b7 Author: vromero Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/969c96b980b7 7153958: add constant pool reference to class containing inlined constants Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java + test/tools/javac/7153958/pkg/ClassToBeStaticallyImported.java Changeset: 4f9853659bf1 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4f9853659bf1 8004105: Expression statement lambdas should be void-compatible Summary: Fix lambda compatibility rules as per latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/lambda/LambdaConv21.java ! test/tools/javac/lambda/LambdaConv21.out ! test/tools/javac/lambda/VoidCompatibility.out Changeset: 34d1ebaf4645 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/34d1ebaf4645 8004102: Add support for generic functional descriptors Summary: Method references are allowed to have a generic functional interface descriptor target Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java + test/tools/javac/lambda/FunctionalInterfaceConversionTest.java - test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/MethodReference57.java + test/tools/javac/lambda/MethodReference58.java + test/tools/javac/lambda/MethodReference58.out Changeset: 9b26c96f5138 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9b26c96f5138 8004101: Add checks for method reference well-formedness Summary: Bring method reference type-checking in sync with latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/diags/examples/StaticBoundMref.java + test/tools/javac/diags/examples/StaticMrefWithTargs.java ! test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference55.java + test/tools/javac/lambda/MethodReference55.out + test/tools/javac/lambda/MethodReference56.java + test/tools/javac/lambda/MethodReference56.out ! test/tools/javac/lambda/methodReference/MethodRef1.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java Changeset: f6f1fd261f57 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f6f1fd261f57 8002099: Add support for intersection types in cast expression Summary: Add parser and type-checking support for intersection types in cast expressions Reviewed-by: jjg + src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.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/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java + src/share/classes/javax/lang/model/type/IntersectionType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java + test/tools/javac/cast/intersection/IntersectionTypeCastTest.java + test/tools/javac/cast/intersection/IntersectionTypeParserTest.java + test/tools/javac/cast/intersection/model/Check.java + test/tools/javac/cast/intersection/model/IntersectionTypeInfo.java + test/tools/javac/cast/intersection/model/Member.java + test/tools/javac/cast/intersection/model/Model01.java + test/tools/javac/cast/intersection/model/ModelChecker.java + test/tools/javac/diags/examples/IntersectionTypesInCastNotSupported.java + test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java + test/tools/javac/lambda/Intersection01.java + test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaParserTest.java + test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Changeset: 98e14fc9ee11 Author: lana Date: 2012-11-30 16:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/98e14fc9ee11 Merge Changeset: 0e70eb71fec0 Author: mcimadamore Date: 2012-12-04 17:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0e70eb71fec0 8004360: regression test DefaultMethodRegressionTests fails in langtools Summary: ignore broken failing test Reviewed-by: jjg - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java + test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java Changeset: 014a6a11dfe5 Author: lana Date: 2012-12-10 20:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/014a6a11dfe5 Merge - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java - test/tools/javac/lambda/LambdaConversionTest.java Changeset: 13ccb5269f3d Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/13ccb5269f3d Added tag jdk8-b68 for changeset 014a6a11dfe5 ! .hgtags From vladimir.x.ivanov at oracle.com Fri Dec 14 04:08:22 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Dec 2012 15:08:22 +0300 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <50CA7CC8.7010203@oracle.com> References: <50CA5E90.7080708@oracle.com> <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> <50CA5F49.9000206@oracle.com> <50CA78F1.70708@oracle.com> <50CA7CC8.7010203@oracle.com> Message-ID: <50CB16B6.80009@oracle.com> John, Vladimir K., Here's updated version [1] Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.01/ On 12/14/12 4:11 AM, Vladimir Kozlov wrote: > On 12/13/12 4:55 PM, Vladimir Ivanov wrote: >> Vladimir K., >> >> Thanks for the review! >> >> > You don't need second region node, use one. >> Can you elaborate on this a little? >> Do you suggest to remove slow_region node? What should I use to point to >> slow path (for example, in generate_slow_guard(bol_thr, slow_call))? > > Never mind this. We can't remove slow_region because there are 2 input > paths. > >> >> > If you rearrange code to generate slow call first and the load on >> fast path last you may not need to preserve init_mem. > > It looks like "fast" approach is much more complicated than I thought. > OK, go with "simple" case but move insert_mem_bar down (below enum) > where we can see it. > > Your comments for enum values are incorrect. !TLS... should be switched > like next: > > no_int_result_path = 1, // t == Thread.current() && > !TLS._osthread._interrupted > no_clear_result_path = 2, // t == Thread.current() && > TLS._osthread._interrupted && !clear_int > > Thanks, > Vladimir K. > >> When considering moving slow path construction up, I was concerned about >> the case where there's no slow path: >> if (stopped()) { >> // There is no slow path. >> result_rgn->init_req(slow_result_path, top()); >> result_val->init_req(slow_result_path, top()); >> } else { >> >> Is it worth retaining? >> >> Best regards, >> Vladimir Ivanov >> >> On 12/14/12 2:05 AM, Vladimir Kozlov wrote: >>> John, the barrier is before enum {} in simple fix. >>> >>> But I also prefer fast code. >>> >>> Vladimir I., >>> >>> You don't need second region node, use one. >>> >>> If you rearrange code to generate slow call first and the load on fast >>> path last you may not need to preserve init_mem. >>> >>> Thanks, >>> Vladimir K. >>> >>> On 12/13/12 2:31 PM, John Rose wrote: >>>> On Dec 13, 2012, at 3:02 PM, Vladimir Ivanov wrote: >>>> >>>>> http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 >>>>> 31 lines changed: 16 ins; 6 del; 9 mod >>>>> >>>>> In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's >>>>> possible to hoist the load of _interrupted flag out of the loop. The >>>>> fix is to add a barrier to forbid such optimization. >>>>> >>>>> Proposed fix is cleaner that [1] (no explicit memory state >>>>> management). >>>>> The place for the barrier is deliberately chosen earlier than >>>>> necessary and it blocks hoisting of some loop invariants when >>>>> Thread.isInterrupted() is called in a loop. But I think it's a fair >>>>> price since I don't think that Thread.isInterrupted(Z)Z performance >>>>> in tight loops is critical. >>>> >>>> I don't see any new barrier in the simple fix. Where is it? It looks >>>> like the load of thr._interrupted can be hoisted under the same >>>> circumstances as before. If the slow path is somehow turned into a >>>> loop exit (via uncommon trap, maybe), then the memory state will fold >>>> up and the bit load can be hoisted. >>>> >>>> It seems like your "fast" fix is more robust, for this reason. >>>> >>>> Also, it's not your bug, but I'm not convinced that "slow_val = >>>> intcon(1)" is correct. I think another thread could come in and clear >>>> the interrupted bit, and this call to the native function could return >>>> false. >>>> >>>>> If you prefer [1] let me know. >>>>> >>>>> Also, cleaned up the code around a little. >>>> >>>> Good cleanups. >>>> >>>> ? John >>>> >>>>> Testing: failing test, manual (verified generated code), JPRT (in >>>>> progress) >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 >>>> From stefan.karlsson at oracle.com Fri Dec 14 03:20:24 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Fri, 14 Dec 2012 11:20:24 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005002: Crash because of a raw oop in ClassLoaderData::add_dependency Message-ID: <20121214112043.6A1B247167@hg.openjdk.java.net> Changeset: 1b1e16471e46 Author: stefank Date: 2012-12-12 22:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1b1e16471e46 8005002: Crash because of a raw oop in ClassLoaderData::add_dependency Summary: Move the handelization of 'last' to a point before the GC might enter. Reviewed-by: dholmes, sspitsyn, coleenp ! src/share/vm/classfile/classLoaderData.cpp From pavel.punegov at oracle.com Fri Dec 14 05:07:06 2012 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Fri, 14 Dec 2012 17:07:06 +0400 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <50CB16B6.80009@oracle.com> References: <50CA5E90.7080708@oracle.com> <50CA7CC8.7010203@oracle.com> <50CB16B6.80009@oracle.com> Message-ID: <1500513.xvTcpKUGNa@trisuli> Vladimir, it would be great if you add code from [1] as a regression test into repository [1] http://cs.oswego.edu/pipermail/concurrency-interest/2012- November/010184.html Best regards, Pavel On Friday 14 December 2012 15:08:22 Vladimir Ivanov wrote: >John, Vladimir K., > >Here's updated version [1] > >Best regards, >Vladimir Ivanov > >[1] http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.01/ > >On 12/14/12 4:11 AM, Vladimir Kozlov wrote: >> On 12/13/12 4:55 PM, Vladimir Ivanov wrote: >>> Vladimir K., >>> >>> Thanks for the review! >>> >>> > You don't need second region node, use one. >>> >>> Can you elaborate on this a little? >>> Do you suggest to remove slow_region node? What should I use to point to >>> slow path (for example, in generate_slow_guard(bol_thr, slow_call))? >> >> Never mind this. We can't remove slow_region because there are 2 input >> paths. >> >>> > If you rearrange code to generate slow call first and the load on >>> >>> fast path last you may not need to preserve init_mem. >> >> It looks like "fast" approach is much more complicated than I thought. >> OK, go with "simple" case but move insert_mem_bar down (below enum) >> where we can see it. >> >> Your comments for enum values are incorrect. !TLS... should be switched >> >> like next: >> no_int_result_path = 1, // t == Thread.current() && >> >> !TLS._osthread._interrupted >> >> no_clear_result_path = 2, // t == Thread.current() && >> >> TLS._osthread._interrupted && !clear_int >> >> Thanks, >> Vladimir K. >> >>> When considering moving slow path construction up, I was concerned about >>> >>> the case where there's no slow path: >>> if (stopped()) { >>> >>> // There is no slow path. >>> result_rgn->init_req(slow_result_path, top()); >>> result_val->init_req(slow_result_path, top()); >>> >>> } else { >>> >>> Is it worth retaining? >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 12/14/12 2:05 AM, Vladimir Kozlov wrote: >>>> John, the barrier is before enum {} in simple fix. >>>> >>>> But I also prefer fast code. >>>> >>>> Vladimir I., >>>> >>>> You don't need second region node, use one. >>>> >>>> If you rearrange code to generate slow call first and the load on fast >>>> path last you may not need to preserve init_mem. >>>> >>>> Thanks, >>>> Vladimir K. >>>> >>>> On 12/13/12 2:31 PM, John Rose wrote: >>>>> On Dec 13, 2012, at 3:02 PM, Vladimir Ivanov wrote: >>>>>> http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 >>>>>> 31 lines changed: 16 ins; 6 del; 9 mod >>>>>> >>>>>> In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's >>>>>> possible to hoist the load of _interrupted flag out of the loop. The >>>>>> fix is to add a barrier to forbid such optimization. >>>>>> >>>>>> Proposed fix is cleaner that [1] (no explicit memory state >>>>>> management). >>>>>> The place for the barrier is deliberately chosen earlier than >>>>>> necessary and it blocks hoisting of some loop invariants when >>>>>> Thread.isInterrupted() is called in a loop. But I think it's a fair >>>>>> price since I don't think that Thread.isInterrupted(Z)Z performance >>>>>> in tight loops is critical. >>>>> >>>>> I don't see any new barrier in the simple fix. Where is it? It looks >>>>> like the load of thr._interrupted can be hoisted under the same >>>>> circumstances as before. If the slow path is somehow turned into a >>>>> loop exit (via uncommon trap, maybe), then the memory state will fold >>>>> up and the bit load can be hoisted. >>>>> >>>>> It seems like your "fast" fix is more robust, for this reason. >>>>> >>>>> Also, it's not your bug, but I'm not convinced that "slow_val = >>>>> intcon(1)" is correct. I think another thread could come in and clear >>>>> the interrupted bit, and this call to the native function could return >>>>> false. >>>>> >>>>>> If you prefer [1] let me know. >>>>>> >>>>>> Also, cleaned up the code around a little. >>>>> >>>>> Good cleanups. >>>>> >>>>> ? John >>>>> >>>>>> Testing: failing test, manual (verified generated code), JPRT (in >>>>>> progress) >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121214/06fda16a/attachment-0001.html From vladimir.x.ivanov at oracle.com Fri Dec 14 06:22:19 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Dec 2012 17:22:19 +0300 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <1500513.xvTcpKUGNa@trisuli> References: <50CA5E90.7080708@oracle.com> <50CA7CC8.7010203@oracle.com> <50CB16B6.80009@oracle.com> <1500513.xvTcpKUGNa@trisuli> Message-ID: <50CB361B.9030605@oracle.com> Pavel, I considered adding it as a regression, but there are some problems with the test case [*] and I don't see an easy way to fix them. Otherwise, it'll produce intermittent failures in our automated test execution. Best regards, Vladimir Ivanov [*] - failure mode due to timeout, instead of explicit check - thread coordination is based on timing On 12/14/12 4:07 PM, Pavel Punegov wrote: > Vladimir, > > it would be great if you add code from [1] as a regression test into > repository > > [1] > http://cs.oswego.edu/pipermail/concurrency-interest/2012-November/010184.html > > Best regards, > > Pavel > > On Friday 14 December 2012 15:08:22 Vladimir Ivanov wrote: > > >John, Vladimir K., > > > > > >Here's updated version [1] > > > > > >Best regards, > > >Vladimir Ivanov > > > > > >[1] http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.01/ > > > > > >On 12/14/12 4:11 AM, Vladimir Kozlov wrote: > > >> On 12/13/12 4:55 PM, Vladimir Ivanov wrote: > > >>> Vladimir K., > > >>> > > >>> Thanks for the review! > > >>> > > >>> > You don't need second region node, use one. > > >>> > > >>> Can you elaborate on this a little? > > >>> Do you suggest to remove slow_region node? What should I use to > point to > > >>> slow path (for example, in generate_slow_guard(bol_thr, slow_call))? > > >> > > >> Never mind this. We can't remove slow_region because there are 2 input > > >> paths. > > >> > > >>> > If you rearrange code to generate slow call first and the load on > > >>> > > >>> fast path last you may not need to preserve init_mem. > > >> > > >> It looks like "fast" approach is much more complicated than I thought. > > >> OK, go with "simple" case but move insert_mem_bar down (below enum) > > >> where we can see it. > > >> > > >> Your comments for enum values are incorrect. !TLS... should be switched > > >> > > >> like next: > > >> no_int_result_path = 1, // t == Thread.current() && > > >> > > >> !TLS._osthread._interrupted > > >> > > >> no_clear_result_path = 2, // t == Thread.current() && > > >> > > >> TLS._osthread._interrupted && !clear_int > > >> > > >> Thanks, > > >> Vladimir K. > > >> > > >>> When considering moving slow path construction up, I was concerned > about > > >>> > > >>> the case where there's no slow path: > > >>> if (stopped()) { > > >>> > > >>> // There is no slow path. > > >>> result_rgn->init_req(slow_result_path, top()); > > >>> result_val->init_req(slow_result_path, top()); > > >>> > > >>> } else { > > >>> > > >>> Is it worth retaining? > > >>> > > >>> Best regards, > > >>> Vladimir Ivanov > > >>> > > >>> On 12/14/12 2:05 AM, Vladimir Kozlov wrote: > > >>>> John, the barrier is before enum {} in simple fix. > > >>>> > > >>>> But I also prefer fast code. > > >>>> > > >>>> Vladimir I., > > >>>> > > >>>> You don't need second region node, use one. > > >>>> > > >>>> If you rearrange code to generate slow call first and the load on fast > > >>>> path last you may not need to preserve init_mem. > > >>>> > > >>>> Thanks, > > >>>> Vladimir K. > > >>>> > > >>>> On 12/13/12 2:31 PM, John Rose wrote: > > >>>>> On Dec 13, 2012, at 3:02 PM, Vladimir Ivanov wrote: > > >>>>>> http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 > > >>>>>> 31 lines changed: 16 ins; 6 del; 9 mod > > >>>>>> > > >>>>>> In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's > > >>>>>> possible to hoist the load of _interrupted flag out of the loop. The > > >>>>>> fix is to add a barrier to forbid such optimization. > > >>>>>> > > >>>>>> Proposed fix is cleaner that [1] (no explicit memory state > > >>>>>> management). > > >>>>>> The place for the barrier is deliberately chosen earlier than > > >>>>>> necessary and it blocks hoisting of some loop invariants when > > >>>>>> Thread.isInterrupted() is called in a loop. But I think it's a fair > > >>>>>> price since I don't think that Thread.isInterrupted(Z)Z performance > > >>>>>> in tight loops is critical. > > >>>>> > > >>>>> I don't see any new barrier in the simple fix. Where is it? It looks > > >>>>> like the load of thr._interrupted can be hoisted under the same > > >>>>> circumstances as before. If the slow path is somehow turned into a > > >>>>> loop exit (via uncommon trap, maybe), then the memory state will fold > > >>>>> up and the bit load can be hoisted. > > >>>>> > > >>>>> It seems like your "fast" fix is more robust, for this reason. > > >>>>> > > >>>>> Also, it's not your bug, but I'm not convinced that "slow_val = > > >>>>> intcon(1)" is correct. I think another thread could come in and clear > > >>>>> the interrupted bit, and this call to the native function could > return > > >>>>> false. > > >>>>> > > >>>>>> If you prefer [1] let me know. > > >>>>>> > > >>>>>> Also, cleaned up the code around a little. > > >>>>> > > >>>>> Good cleanups. > > >>>>> > > >>>>> ? John > > >>>>> > > >>>>>> Testing: failing test, manual (verified generated code), JPRT (in > > >>>>>> progress) > > >>>>>> > > >>>>>> Thanks! > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Vladimir Ivanov > > >>>>>> > > >>>>>> [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 > From aleksey.shipilev at oracle.com Fri Dec 14 05:37:33 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 14 Dec 2012 17:37:33 +0400 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <50CB361B.9030605@oracle.com> References: <50CA5E90.7080708@oracle.com> <50CA7CC8.7010203@oracle.com> <50CB16B6.80009@oracle.com> <1500513.xvTcpKUGNa@trisuli> <50CB361B.9030605@oracle.com> Message-ID: <50CB2B9D.4030601@oracle.com> BTW, the minimized test case is available as part of java-concurrency-torture [1], which handles the stuck-on-failure running mode. ...and it is Pavel's bidding to integrate those tests. -Aleksey. [1] https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/interrupt/CurrentThreadIsInterruptedMethodTest.java On 12/14/2012 06:22 PM, Vladimir Ivanov wrote: > Pavel, > > I considered adding it as a regression, but there are some problems with > the test case [*] and I don't see an easy way to fix them. > > Otherwise, it'll produce intermittent failures in our automated test > execution. > > Best regards, > Vladimir Ivanov > > [*] - failure mode due to timeout, instead of explicit check > - thread coordination is based on timing > > On 12/14/12 4:07 PM, Pavel Punegov wrote: >> Vladimir, >> >> it would be great if you add code from [1] as a regression test into >> repository >> >> [1] >> http://cs.oswego.edu/pipermail/concurrency-interest/2012-November/010184.html >> >> >> Best regards, >> >> Pavel >> >> On Friday 14 December 2012 15:08:22 Vladimir Ivanov wrote: >> >> >John, Vladimir K., >> >> > >> >> >Here's updated version [1] >> >> > >> >> >Best regards, >> >> >Vladimir Ivanov >> >> > >> >> >[1] http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.01/ >> >> > >> >> >On 12/14/12 4:11 AM, Vladimir Kozlov wrote: >> >> >> On 12/13/12 4:55 PM, Vladimir Ivanov wrote: >> >> >>> Vladimir K., >> >> >>> >> >> >>> Thanks for the review! >> >> >>> >> >> >>> > You don't need second region node, use one. >> >> >>> >> >> >>> Can you elaborate on this a little? >> >> >>> Do you suggest to remove slow_region node? What should I use to >> point to >> >> >>> slow path (for example, in generate_slow_guard(bol_thr, slow_call))? >> >> >> >> >> >> Never mind this. We can't remove slow_region because there are 2 >> input >> >> >> paths. >> >> >> >> >> >>> > If you rearrange code to generate slow call first and the load on >> >> >>> >> >> >>> fast path last you may not need to preserve init_mem. >> >> >> >> >> >> It looks like "fast" approach is much more complicated than I >> thought. >> >> >> OK, go with "simple" case but move insert_mem_bar down (below enum) >> >> >> where we can see it. >> >> >> >> >> >> Your comments for enum values are incorrect. !TLS... should be >> switched >> >> >> >> >> >> like next: >> >> >> no_int_result_path = 1, // t == Thread.current() && >> >> >> >> >> >> !TLS._osthread._interrupted >> >> >> >> >> >> no_clear_result_path = 2, // t == Thread.current() && >> >> >> >> >> >> TLS._osthread._interrupted && !clear_int >> >> >> >> >> >> Thanks, >> >> >> Vladimir K. >> >> >> >> >> >>> When considering moving slow path construction up, I was concerned >> about >> >> >>> >> >> >>> the case where there's no slow path: >> >> >>> if (stopped()) { >> >> >>> >> >> >>> // There is no slow path. >> >> >>> result_rgn->init_req(slow_result_path, top()); >> >> >>> result_val->init_req(slow_result_path, top()); >> >> >>> >> >> >>> } else { >> >> >>> >> >> >>> Is it worth retaining? >> >> >>> >> >> >>> Best regards, >> >> >>> Vladimir Ivanov >> >> >>> >> >> >>> On 12/14/12 2:05 AM, Vladimir Kozlov wrote: >> >> >>>> John, the barrier is before enum {} in simple fix. >> >> >>>> >> >> >>>> But I also prefer fast code. >> >> >>>> >> >> >>>> Vladimir I., >> >> >>>> >> >> >>>> You don't need second region node, use one. >> >> >>>> >> >> >>>> If you rearrange code to generate slow call first and the load >> on fast >> >> >>>> path last you may not need to preserve init_mem. >> >> >>>> >> >> >>>> Thanks, >> >> >>>> Vladimir K. >> >> >>>> >> >> >>>> On 12/13/12 2:31 PM, John Rose wrote: >> >> >>>>> On Dec 13, 2012, at 3:02 PM, Vladimir Ivanov wrote: >> >> >>>>>> http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 >> >> >>>>>> 31 lines changed: 16 ins; 6 del; 9 mod >> >> >>>>>> >> >> >>>>>> In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's >> >> >>>>>> possible to hoist the load of _interrupted flag out of the >> loop. The >> >> >>>>>> fix is to add a barrier to forbid such optimization. >> >> >>>>>> >> >> >>>>>> Proposed fix is cleaner that [1] (no explicit memory state >> >> >>>>>> management). >> >> >>>>>> The place for the barrier is deliberately chosen earlier than >> >> >>>>>> necessary and it blocks hoisting of some loop invariants when >> >> >>>>>> Thread.isInterrupted() is called in a loop. But I think it's a >> fair >> >> >>>>>> price since I don't think that Thread.isInterrupted(Z)Z >> performance >> >> >>>>>> in tight loops is critical. >> >> >>>>> >> >> >>>>> I don't see any new barrier in the simple fix. Where is it? It >> looks >> >> >>>>> like the load of thr._interrupted can be hoisted under the same >> >> >>>>> circumstances as before. If the slow path is somehow turned into a >> >> >>>>> loop exit (via uncommon trap, maybe), then the memory state >> will fold >> >> >>>>> up and the bit load can be hoisted. >> >> >>>>> >> >> >>>>> It seems like your "fast" fix is more robust, for this reason. >> >> >>>>> >> >> >>>>> Also, it's not your bug, but I'm not convinced that "slow_val = >> >> >>>>> intcon(1)" is correct. I think another thread could come in and >> clear >> >> >>>>> the interrupted bit, and this call to the native function could >> return >> >> >>>>> false. >> >> >>>>> >> >> >>>>>> If you prefer [1] let me know. >> >> >>>>>> >> >> >>>>>> Also, cleaned up the code around a little. >> >> >>>>> >> >> >>>>> Good cleanups. >> >> >>>>> >> >> >>>>> ? John >> >> >>>>> >> >> >>>>>> Testing: failing test, manual (verified generated code), JPRT (in >> >> >>>>>> progress) >> >> >>>>>> >> >> >>>>>> Thanks! >> >> >>>>>> >> >> >>>>>> Best regards, >> >> >>>>>> Vladimir Ivanov >> >> >>>>>> >> >> >>>>>> [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 >> From roland.westrelin at oracle.com Fri Dec 14 05:58:04 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 14 Dec 2012 14:58:04 +0100 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: <50CA3C61.5090902@oracle.com> References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> <50CA3C61.5090902@oracle.com> Message-ID: <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> Hi Vladimir, Thanks for reviewing this. > Why you removed asserts in callnode.cpp? If inlining happens after the graph has been transformed then useless projections may have gone away. Anyway, this doesn't belong in this cleanup so I moved it to the incremental inlining change. I put the assert back but it's disabled if inlining is happening after the first round of parsing. > I think "chunk" word is not appropriate for this. Maybe "Event" or something: > > PrintInliningChunk --> PrintInliningEvent > _print_inlining_chunks --> _print_inlining_list > > Allocate the list in comp arena for use in later inlining: new(comp_arena()) Ok. > LogCompilation output will be also affected. I remember fixing the tool for StringOpts. Could you verify that it works and fix it if it does not? It's indeed broken but it doesn't look like a trivial fix to me. Can this be done separately? If yes, I'll file a new CR. Also: in the current LogCompilation late_inline entries are listed at the end: 13 spec.benchmarks._213_javac.ScannerInputStream::read (513 bytes) @ 32 java.io.InputStream::read (0 bytes) type profile java/io/InputStream -> java/io/BufferedInputStream (100%) @ 32 java.io.BufferedInputStream::read (49 bytes) @ 95 java.io.InputStream::read (0 bytes) type profile java/io/InputStream -> java/io/BufferedInputStream (100%) @ 95 java.io.BufferedInputStream::read too big @ 151 java.io.InputStream::read (0 bytes) @ 151 java.io.InputStream::read (0 bytes) @ 408 spec.benchmarks._213_javac.Environment::error never executed @ 435 java.io.InputStream::read (0 bytes) @ 469 java.io.InputStream::read (0 bytes) late inline: @ 32 java.io.BufferedInputStream::read (49 bytes) (end time: 1.7170 nodes: 792 live: 538) @ 12 java.io.BufferedInputStream::fill too big @ 29 java.io.BufferedInputStream::getBufIfOpen (21 bytes) @ 32 java.io.BufferedInputStream::read (49 bytes) @ 29 java.io.BufferedInputStream::getBufIfOpen (21 bytes) (end time: 1.7180 nodes: 826 live: 569) (strange that @29 is twice in the late inline section) But if there's a lot of late inlining going on, wouldn't we want to have everything together: 13 spec.benchmarks._213_javac.ScannerInputStream::read (513 bytes) @ 32 java.io.InputStream::read (0 bytes) type profile java/io/InputStream -> java/io/BufferedInputStream (100%) @ 32 java.io.BufferedInputStream::read (49 bytes) (end time: 1.7170 nodes: 792 live: 538) @ 12 java.io.BufferedInputStream::fill too big @ 29 java.io.BufferedInputStream::getBufIfOpen (21 bytes) @ 95 java.io.InputStream::read (0 bytes) type profile java/io/InputStream -> java/io/BufferedInputStream (100%) @ 95 java.io.BufferedInputStream::read too big @ 151 java.io.InputStream::read (0 bytes) @ 151 java.io.InputStream::read (0 bytes) @ 408 spec.benchmarks._213_javac.Environment::error never executed @ 435 java.io.InputStream::read (0 bytes) @ 469 java.io.InputStream::read (0 bytes) with maybe an annotation that marked some call site as late inline. What do you think? > I think you should put it on igvn._worklist because PhaseIterGVN::optimize() does removal of nodes with outcount() == 0. I don't think it is safe to do it inside Ideal() call. Ok. > Also, file RFE (starter_task) to find all similar cases (may be add the check for input nodes in transform_old()). Ok. Here is a new webrev: http://cr.openjdk.java.net/~roland/8005031/webrev.01/ Roland. From roland.westrelin at oracle.com Fri Dec 14 07:13:29 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 14 Dec 2012 16:13:29 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 Message-ID: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> http://cr.openjdk.java.net/~roland/8005071/webrev.00/ Current inlining heuristics are driven by the number of created nodes which is unrelated to the number of live nodes especially after optimizations are applied. C2 should perform inlining in a loop: while (more_inlining_candidates) { apply_optimizations(); if (number_of_live_nodes > some_number) break; inline_more(); } In this change, C2 starts inlining at parse-time as usual until the existing heuristics kick in and prevent any further inlining. It then starts enqueuing candidates for further inlining. The candidates are restricted to the methods marked with the ForceInline annotation for now. It then enters the loop above. The optimizations applied are restricted to an igvn and a simple pass of loop clean up for now. Roland. From richard.reingruber at sap.com Fri Dec 14 08:44:45 2012 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 14 Dec 2012 17:44:45 +0100 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: <50CA2207.2070102@oracle.com> References: <50CA2207.2070102@oracle.com> Message-ID: Hi Dean, thanks for looking at the patch. > convI2L_reg_zex doesn't use the mask Yes, in convI2L_reg_zex the mask is only there for matching the zero-extension pattern in the ideal graph. It's not needed as real immediate value. With the expand it's not needed at all (could be set to 0xdeadbeef), but it doesn't hurt either. There is no overhead I would be aware of. Especially not at runtime. > so would shrI_reg_imm5(dst, src, 0) or shrI_reg_reg(dst, src, R_G0) work > just as well? Probably, I thought the purpose (zero-extension) would be clearer when using convI2L_reg_zex. Cheers, Richard. -----Original Message----- From: Dean Long [mailto:dean.long at oracle.com] Sent: Donnerstag, 13. Dezember 2012 19:44 To: Reingruber, Richard Cc: hotspot compiler (hotspot-compiler-dev at openjdk.java.net) Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 convI2L_reg_zex doesn't use the mask, so would shrI_reg_imm5(dst, src, 0) or shrI_reg_reg(dst, src, R_G0) work just as well? dl On 12/13/2012 9:09 AM, Reingruber, Richard wrote: > Hi, > > I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. > > On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). > > I have prepared a small webrev with the suggested fix and a regression test: > > http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ > > Could you please review the patch and create a bug id? Thanks! > > Cheers, > Richard. > > BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) > From richard.reingruber at sap.com Fri Dec 14 08:48:38 2012 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 14 Dec 2012 17:48:38 +0100 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: <50CA310B.4030701@oracle.com> References: <50CA310B.4030701@oracle.com> Message-ID: Thanks, Vladimir and Chris, for your reviews and the bug id. > It would seem easier to just write two assembler instructions instead of using expand. That's what I did first, and it was easier ;) > Is there a particular reason you are using expand? With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. Is there a reason _not_ to use the expand? And here's the webrev updated with the bug id: http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_02/ Cheers, Richard. -----Original Message----- From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Donnerstag, 13. Dezember 2012 20:48 To: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 We should use macroassembler instructions and we have special instruction to clear upper half: ins_encode %{ __ clruwu($src$$Register); __ popc($src$$Register, $dst$$Register); %} Vladimir On 12/13/12 10:46 AM, Christian Thalinger wrote: > > On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: > >> Hi, >> >> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >> >> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >> >> I have prepared a small webrev with the suggested fix and a regression test: >> >> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >> >> Could you please review the patch and create a bug id? Thanks! > > Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: > > 8005033: clear high word for integer pop count on SPARC > > It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? > > -- Chris > >> >> Cheers, >> Richard. >> >> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >> > From vladimir.kozlov at oracle.com Fri Dec 14 08:53:45 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Dec 2012 08:53:45 -0800 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <50CB16B6.80009@oracle.com> References: <50CA5E90.7080708@oracle.com> <1462ED9E-D964-4AE8-AC6E-91A7BE108C1E@oracle.com> <50CA5F49.9000206@oracle.com> <50CA78F1.70708@oracle.com> <50CA7CC8.7010203@oracle.com> <50CB16B6.80009@oracle.com> Message-ID: <50CB5999.2000709@oracle.com> Looks good. Vladimir On 12/14/12 4:08 AM, Vladimir Ivanov wrote: > John, Vladimir K., > > Here's updated version [1] > > Best regards, > Vladimir Ivanov > > [1] http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.01/ > > On 12/14/12 4:11 AM, Vladimir Kozlov wrote: >> On 12/13/12 4:55 PM, Vladimir Ivanov wrote: >>> Vladimir K., >>> >>> Thanks for the review! >>> >>> > You don't need second region node, use one. >>> Can you elaborate on this a little? >>> Do you suggest to remove slow_region node? What should I use to point to >>> slow path (for example, in generate_slow_guard(bol_thr, slow_call))? >> >> Never mind this. We can't remove slow_region because there are 2 input >> paths. >> >>> >>> > If you rearrange code to generate slow call first and the load on >>> fast path last you may not need to preserve init_mem. >> >> It looks like "fast" approach is much more complicated than I thought. >> OK, go with "simple" case but move insert_mem_bar down (below enum) >> where we can see it. >> >> Your comments for enum values are incorrect. !TLS... should be switched >> like next: >> >> no_int_result_path = 1, // t == Thread.current() && >> !TLS._osthread._interrupted >> no_clear_result_path = 2, // t == Thread.current() && >> TLS._osthread._interrupted && !clear_int >> >> Thanks, >> Vladimir K. >> >>> When considering moving slow path construction up, I was concerned about >>> the case where there's no slow path: >>> if (stopped()) { >>> // There is no slow path. >>> result_rgn->init_req(slow_result_path, top()); >>> result_val->init_req(slow_result_path, top()); >>> } else { >>> >>> Is it worth retaining? >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 12/14/12 2:05 AM, Vladimir Kozlov wrote: >>>> John, the barrier is before enum {} in simple fix. >>>> >>>> But I also prefer fast code. >>>> >>>> Vladimir I., >>>> >>>> You don't need second region node, use one. >>>> >>>> If you rearrange code to generate slow call first and the load on fast >>>> path last you may not need to preserve init_mem. >>>> >>>> Thanks, >>>> Vladimir K. >>>> >>>> On 12/13/12 2:31 PM, John Rose wrote: >>>>> On Dec 13, 2012, at 3:02 PM, Vladimir Ivanov wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 >>>>>> 31 lines changed: 16 ins; 6 del; 9 mod >>>>>> >>>>>> In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's >>>>>> possible to hoist the load of _interrupted flag out of the loop. The >>>>>> fix is to add a barrier to forbid such optimization. >>>>>> >>>>>> Proposed fix is cleaner that [1] (no explicit memory state >>>>>> management). >>>>>> The place for the barrier is deliberately chosen earlier than >>>>>> necessary and it blocks hoisting of some loop invariants when >>>>>> Thread.isInterrupted() is called in a loop. But I think it's a fair >>>>>> price since I don't think that Thread.isInterrupted(Z)Z performance >>>>>> in tight loops is critical. >>>>> >>>>> I don't see any new barrier in the simple fix. Where is it? It looks >>>>> like the load of thr._interrupted can be hoisted under the same >>>>> circumstances as before. If the slow path is somehow turned into a >>>>> loop exit (via uncommon trap, maybe), then the memory state will fold >>>>> up and the bit load can be hoisted. >>>>> >>>>> It seems like your "fast" fix is more robust, for this reason. >>>>> >>>>> Also, it's not your bug, but I'm not convinced that "slow_val = >>>>> intcon(1)" is correct. I think another thread could come in and clear >>>>> the interrupted bit, and this call to the native function could return >>>>> false. >>>>> >>>>>> If you prefer [1] let me know. >>>>>> >>>>>> Also, cleaned up the code around a little. >>>>> >>>>> Good cleanups. >>>>> >>>>> ? John >>>>> >>>>>> Testing: failing test, manual (verified generated code), JPRT (in >>>>>> progress) >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 >>>>> From vladimir.kozlov at oracle.com Fri Dec 14 09:00:30 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Dec 2012 09:00:30 -0800 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> <50CA3C61.5090902@oracle.com> <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> Message-ID: <50CB5B2E.7010901@oracle.com> Yes, we can do LogCompilation fix later (after late_inline push), file bug for that. These changes are good. Thanks, Vladimir On 12/14/12 5:58 AM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for reviewing this. > > >> Why you removed asserts in callnode.cpp? > > If inlining happens after the graph has been transformed then useless projections may have gone away. Anyway, this doesn't belong in this cleanup so I moved it to the incremental inlining change. I put the assert back but it's disabled if inlining is happening after the first round of parsing. > >> I think "chunk" word is not appropriate for this. Maybe "Event" or something: >> >> PrintInliningChunk --> PrintInliningEvent >> _print_inlining_chunks --> _print_inlining_list >> >> Allocate the list in comp arena for use in later inlining: new(comp_arena()) > > Ok. > >> LogCompilation output will be also affected. I remember fixing the tool for StringOpts. Could you verify that it works and fix it if it does not? > > It's indeed broken but it doesn't look like a trivial fix to me. Can this be done separately? If yes, I'll file a new CR. > Also: in the current LogCompilation late_inline entries are listed at the end: > > 13 spec.benchmarks._213_javac.ScannerInputStream::read (513 bytes) > @ 32 java.io.InputStream::read (0 bytes) > type profile java/io/InputStream -> java/io/BufferedInputStream (100%) > @ 32 java.io.BufferedInputStream::read (49 bytes) > @ 95 java.io.InputStream::read (0 bytes) > type profile java/io/InputStream -> java/io/BufferedInputStream (100%) > @ 95 java.io.BufferedInputStream::read too big > @ 151 java.io.InputStream::read (0 bytes) > @ 151 java.io.InputStream::read (0 bytes) > @ 408 spec.benchmarks._213_javac.Environment::error never executed > @ 435 java.io.InputStream::read (0 bytes) > @ 469 java.io.InputStream::read (0 bytes) > late inline: > @ 32 java.io.BufferedInputStream::read (49 bytes) (end time: 1.7170 nodes: 792 live: 538) > @ 12 java.io.BufferedInputStream::fill too big > @ 29 java.io.BufferedInputStream::getBufIfOpen (21 bytes) > @ 32 java.io.BufferedInputStream::read (49 bytes) > @ 29 java.io.BufferedInputStream::getBufIfOpen (21 bytes) (end time: 1.7180 nodes: 826 live: 569) > > (strange that @29 is twice in the late inline section) > But if there's a lot of late inlining going on, wouldn't we want to have everything together: > 13 spec.benchmarks._213_javac.ScannerInputStream::read (513 bytes) > @ 32 java.io.InputStream::read (0 bytes) > type profile java/io/InputStream -> java/io/BufferedInputStream (100%) > @ 32 java.io.BufferedInputStream::read (49 bytes) (end time: 1.7170 nodes: 792 live: 538) > @ 12 java.io.BufferedInputStream::fill too big > @ 29 java.io.BufferedInputStream::getBufIfOpen (21 bytes) > @ 95 java.io.InputStream::read (0 bytes) > type profile java/io/InputStream -> java/io/BufferedInputStream (100%) > @ 95 java.io.BufferedInputStream::read too big > @ 151 java.io.InputStream::read (0 bytes) > @ 151 java.io.InputStream::read (0 bytes) > @ 408 spec.benchmarks._213_javac.Environment::error never executed > @ 435 java.io.InputStream::read (0 bytes) > @ 469 java.io.InputStream::read (0 bytes) > > with maybe an annotation that marked some call site as late inline. What do you think? > >> I think you should put it on igvn._worklist because PhaseIterGVN::optimize() does removal of nodes with outcount() == 0. I don't think it is safe to do it inside Ideal() call. > > Ok. > >> Also, file RFE (starter_task) to find all similar cases (may be add the check for input nodes in transform_old()). > > Ok. > > Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8005031/webrev.01/ > > Roland. > From roland.westrelin at oracle.com Fri Dec 14 09:10:52 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 14 Dec 2012 18:10:52 +0100 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: <50CB5B2E.7010901@oracle.com> References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> <50CA3C61.5090902@oracle.com> <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> <50CB5B2E.7010901@oracle.com> Message-ID: <524EE939-0C9B-41A3-A5EA-FFCFB564B50B@oracle.com> > Yes, we can do LogCompilation fix later (after late_inline push), file bug for that. > > These changes are good. Thanks for the review. Roland. From vladimir.kozlov at oracle.com Fri Dec 14 09:23:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Dec 2012 09:23:31 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: References: <50CA310B.4030701@oracle.com> Message-ID: <50CB6093.3020409@oracle.com> On 12/14/12 8:48 AM, Reingruber, Richard wrote: > Thanks, Vladimir and Chris, for your reviews and the bug id. > > > It would seem easier to just write two assembler instructions instead of using expand. > > That's what I did first, and it was easier ;) > > > Is there a particular reason you are using expand? > > With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. > > Is there a reason _not_ to use the expand? It is harder to understand what instruction does and follow when debugging a problem. Yes, it could be scheduled separately but it hit-and-miss. Also your code uses an additional (long) register which we should avoid. Adding 0xffffff immediate further complicated the code. We use expand rules if we need to use the same sequence of few instructions in several mach nodes. Or historically because we used emit_data() complicated encoding before. After we switched to macroassembler instructions we are trying to avoid expand encoding. Thanks, Vladimir > > And here's the webrev updated with the bug id: > > http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_02/ > > Cheers, Richard. > > -----Original Message----- > From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Donnerstag, 13. Dezember 2012 20:48 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 > > We should use macroassembler instructions and we have special > instruction to clear upper half: > > ins_encode %{ > __ clruwu($src$$Register); > __ popc($src$$Register, $dst$$Register); > %} > > Vladimir > > On 12/13/12 10:46 AM, Christian Thalinger wrote: >> >> On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: >> >>> Hi, >>> >>> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >>> >>> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >>> >>> I have prepared a small webrev with the suggested fix and a regression test: >>> >>> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >>> >>> Could you please review the patch and create a bug id? Thanks! >> >> Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: >> >> 8005033: clear high word for integer pop count on SPARC >> >> It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? >> >> -- Chris >> >>> >>> Cheers, >>> Richard. >>> >>> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >>> >> From bharadwaj.yadavalli at oracle.com Fri Dec 14 10:12:28 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 14 Dec 2012 13:12:28 -0500 Subject: RFR(S) - 8004548 : remove unused AbstractAssembler::print(Label&) In-Reply-To: <2F7CF88C-CA04-4925-B89D-16F5F3405272@oracle.com> References: <50C60E20.2050006@oracle.com> <2F7CF88C-CA04-4925-B89D-16F5F3405272@oracle.com> Message-ID: <50CB6C0C.40708@oracle.com> Please review webrev updated with suggested changes: http://cr.openjdk.java.net/~bharadwaj/8004548/webrev/ Thanks, Bharadwaj On 12/10/2012 5:41 PM, Christian Thalinger wrote: > On Dec 10, 2012, at 8:30 AM, Bharadwaj Yadavalli wrote: > >> Please review the requested cleanup done in the changes at http://cr.openjdk.java.net/~bharadwaj/8004548/webrev/ > src/cpu/sparc/vm/assembler_sparc.inline.hpp: > > Also remove now unused print_instruction (that's the method I started looking from to find that all this is old and unused). > > -- Chris > >> Thanks, >> >> Bharadwaj >> From vladimir.kozlov at oracle.com Fri Dec 14 10:39:12 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Dec 2012 10:39:12 -0800 Subject: RFR(S) - 8004548 : remove unused AbstractAssembler::print(Label&) In-Reply-To: <50CB6C0C.40708@oracle.com> References: <50C60E20.2050006@oracle.com> <2F7CF88C-CA04-4925-B89D-16F5F3405272@oracle.com> <50CB6C0C.40708@oracle.com> Message-ID: <50CB7250.9030108@oracle.com> Good. Thanks, Vladimir On 12/14/12 10:12 AM, Bharadwaj Yadavalli wrote: > Please review webrev updated with suggested changes: > > http://cr.openjdk.java.net/~bharadwaj/8004548/webrev/ > > Thanks, > > Bharadwaj > > > On 12/10/2012 5:41 PM, Christian Thalinger wrote: >> On Dec 10, 2012, at 8:30 AM, Bharadwaj >> Yadavalli wrote: >> >>> Please review the requested cleanup done in the changes at >>> http://cr.openjdk.java.net/~bharadwaj/8004548/webrev/ >> src/cpu/sparc/vm/assembler_sparc.inline.hpp: >> >> Also remove now unused print_instruction (that's the method I started >> looking from to find that all this is old and unused). >> >> -- Chris >> >>> Thanks, >>> >>> Bharadwaj >>> From christian.thalinger at oracle.com Fri Dec 14 12:10:04 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 14 Dec 2012 12:10:04 -0800 Subject: RFR(S) - 8004548 : remove unused AbstractAssembler::print(Label&) In-Reply-To: <50CB6C0C.40708@oracle.com> References: <50C60E20.2050006@oracle.com> <2F7CF88C-CA04-4925-B89D-16F5F3405272@oracle.com> <50CB6C0C.40708@oracle.com> Message-ID: <67C36BCE-0EDA-4091-95C6-5A7506165BB8@oracle.com> Looks good. -- Chris On Dec 14, 2012, at 10:12 AM, Bharadwaj Yadavalli wrote: > Please review webrev updated with suggested changes: > > http://cr.openjdk.java.net/~bharadwaj/8004548/webrev/ > > Thanks, > > Bharadwaj > > > On 12/10/2012 5:41 PM, Christian Thalinger wrote: >> On Dec 10, 2012, at 8:30 AM, Bharadwaj Yadavalli wrote: >> >>> Please review the requested cleanup done in the changes at http://cr.openjdk.java.net/~bharadwaj/8004548/webrev/ >> src/cpu/sparc/vm/assembler_sparc.inline.hpp: >> >> Also remove now unused print_instruction (that's the method I started looking from to find that all this is old and unused). >> >> -- Chris >> >>> Thanks, >>> >>> Bharadwaj >>> From pavel.punegov at oracle.com Fri Dec 14 12:32:56 2012 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Sat, 15 Dec 2012 00:32:56 +0400 Subject: RFR (S): 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop In-Reply-To: <50CB2B9D.4030601@oracle.com> References: <50CA5E90.7080708@oracle.com> <50CB361B.9030605@oracle.com> <50CB2B9D.4030601@oracle.com> Message-ID: <3309536.UEZiuvFhIm@work-dell> Yes, these tests will be integrated to our testing as new component soon. So, we'll have the test case for this issue in regular testing. Thanks, Pavel On 17:37:33, Aleksey Shipilev wrote: > BTW, the minimized test case is available as part of > java-concurrency-torture [1], which handles the stuck-on-failure running > mode. ...and it is Pavel's bidding to integrate those tests. > > -Aleksey. > > [1] > https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/ja > va/org/openjdk/concurrent/torture/tests/interrupt/CurrentThreadIsInterrupted > MethodTest.java > On 12/14/2012 06:22 PM, Vladimir Ivanov wrote: > > Pavel, > > > > I considered adding it as a regression, but there are some problems with > > the test case [*] and I don't see an easy way to fix them. > > > > Otherwise, it'll produce intermittent failures in our automated test > > execution. > > > > Best regards, > > Vladimir Ivanov > > > > [*] - failure mode due to timeout, instead of explicit check > > > > - thread coordination is based on timing > > > > On 12/14/12 4:07 PM, Pavel Punegov wrote: > >> Vladimir, > >> > >> it would be great if you add code from [1] as a regression test into > >> repository > >> > >> [1] > >> http://cs.oswego.edu/pipermail/concurrency-interest/2012-November/010184. > >> html > >> > >> > >> Best regards, > >> > >> Pavel > >> > >> On Friday 14 December 2012 15:08:22 Vladimir Ivanov wrote: > >> >John, Vladimir K., > >> > > >> > > >> > > >> >Here's updated version [1] > >> > > >> > > >> > > >> >Best regards, > >> > > >> >Vladimir Ivanov > >> > > >> > > >> > > >> >[1] http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.01/ > >> > > >> >On 12/14/12 4:11 AM, Vladimir Kozlov wrote: > >> >> On 12/13/12 4:55 PM, Vladimir Ivanov wrote: > >> >>> Vladimir K., > >> >>> > >> >>> > >> >>> > >> >>> Thanks for the review! > >> >>> > >> >>> > You don't need second region node, use one. > >> >>> > >> >>> Can you elaborate on this a little? > >> >>> > >> >>> Do you suggest to remove slow_region node? What should I use to > >> > >> point to > >> > >> >>> slow path (for example, in generate_slow_guard(bol_thr, slow_call))? > >> >> > >> >> Never mind this. We can't remove slow_region because there are 2 > >> > >> input > >> > >> >> paths. > >> >> > >> >>> > If you rearrange code to generate slow call first and the load on > >> >>> > >> >>> fast path last you may not need to preserve init_mem. > >> >> > >> >> It looks like "fast" approach is much more complicated than I > >> > >> thought. > >> > >> >> OK, go with "simple" case but move insert_mem_bar down (below enum) > >> >> > >> >> where we can see it. > >> >> > >> >> > >> >> > >> >> Your comments for enum values are incorrect. !TLS... should be > >> > >> switched > >> > >> >> like next: > >> >> > >> >> no_int_result_path = 1, // t == Thread.current() && > >> >> > >> >> > >> >> > >> >> !TLS._osthread._interrupted > >> >> > >> >> > >> >> > >> >> no_clear_result_path = 2, // t == Thread.current() && > >> >> > >> >> > >> >> > >> >> TLS._osthread._interrupted && !clear_int > >> >> > >> >> > >> >> > >> >> Thanks, > >> >> > >> >> Vladimir K. > >> >> > >> >>> When considering moving slow path construction up, I was concerned > >> > >> about > >> > >> >>> the case where there's no slow path: > >> >>> > >> >>> if (stopped()) { > >> >>> > >> >>> > >> >>> > >> >>> // There is no slow path. > >> >>> > >> >>> result_rgn->init_req(slow_result_path, top()); > >> >>> > >> >>> result_val->init_req(slow_result_path, top()); > >> >>> > >> >>> > >> >>> > >> >>> } else { > >> >>> > >> >>> > >> >>> > >> >>> Is it worth retaining? > >> >>> > >> >>> > >> >>> > >> >>> Best regards, > >> >>> > >> >>> Vladimir Ivanov > >> >>> > >> >>> On 12/14/12 2:05 AM, Vladimir Kozlov wrote: > >> >>>> John, the barrier is before enum {} in simple fix. > >> >>>> > >> >>>> > >> >>>> > >> >>>> But I also prefer fast code. > >> >>>> > >> >>>> > >> >>>> > >> >>>> Vladimir I., > >> >>>> > >> >>>> > >> >>>> > >> >>>> You don't need second region node, use one. > >> >>>> > >> >>>> > >> >>>> > >> >>>> If you rearrange code to generate slow call first and the load > >> > >> on fast > >> > >> >>>> path last you may not need to preserve init_mem. > >> >>>> > >> >>>> > >> >>>> > >> >>>> Thanks, > >> >>>> > >> >>>> Vladimir K. > >> >>>> > >> >>>> On 12/13/12 2:31 PM, John Rose wrote: > >> >>>>> On Dec 13, 2012, at 3:02 PM, Vladimir Ivanov wrote: > >> >>>>>> http://cr.openjdk.java.net/~vlivanov/8003135/simple/webrev.00 > >> >>>>>> > >> >>>>>> 31 lines changed: 16 ins; 6 del; 9 mod > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> In the IR produced by Thread.isInterrupted(Z)Z intrinsic it's > >> >>>>>> > >> >>>>>> possible to hoist the load of _interrupted flag out of the > >> > >> loop. The > >> > >> >>>>>> fix is to add a barrier to forbid such optimization. > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> Proposed fix is cleaner that [1] (no explicit memory state > >> >>>>>> > >> >>>>>> management). > >> >>>>>> > >> >>>>>> The place for the barrier is deliberately chosen earlier than > >> >>>>>> > >> >>>>>> necessary and it blocks hoisting of some loop invariants when > >> >>>>>> > >> >>>>>> Thread.isInterrupted() is called in a loop. But I think it's a > >> > >> fair > >> > >> >>>>>> price since I don't think that Thread.isInterrupted(Z)Z > >> > >> performance > >> > >> >>>>>> in tight loops is critical. > >> >>>>> > >> >>>>> I don't see any new barrier in the simple fix. Where is it? It > >> > >> looks > >> > >> >>>>> like the load of thr._interrupted can be hoisted under the same > >> >>>>> > >> >>>>> circumstances as before. If the slow path is somehow turned into a > >> >>>>> > >> >>>>> loop exit (via uncommon trap, maybe), then the memory state > >> > >> will fold > >> > >> >>>>> up and the bit load can be hoisted. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> It seems like your "fast" fix is more robust, for this reason. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> Also, it's not your bug, but I'm not convinced that "slow_val = > >> >>>>> > >> >>>>> intcon(1)" is correct. I think another thread could come in and > >> > >> clear > >> > >> >>>>> the interrupted bit, and this call to the native function could > >> > >> return > >> > >> >>>>> false. > >> >>>>> > >> >>>>>> If you prefer [1] let me know. > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> Also, cleaned up the code around a little. > >> >>>>> > >> >>>>> Good cleanups. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ? John > >> >>>>> > >> >>>>>> Testing: failing test, manual (verified generated code), JPRT (in > >> >>>>>> > >> >>>>>> progress) > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> Thanks! > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> Best regards, > >> >>>>>> > >> >>>>>> Vladimir Ivanov > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> [1] http://cr.openjdk.java.net/~vlivanov/8003135/fast/webrev.00 From christian.thalinger at oracle.com Fri Dec 14 14:44:21 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 14 Dec 2012 14:44:21 -0800 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> <50CA3C61.5090902@oracle.com> <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> Message-ID: On Dec 14, 2012, at 5:58 AM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for reviewing this. > > >> Why you removed asserts in callnode.cpp? > > If inlining happens after the graph has been transformed then useless projections may have gone away. Anyway, this doesn't belong in this cleanup so I moved it to the incremental inlining change. I put the assert back but it's disabled if inlining is happening after the first round of parsing. > >> I think "chunk" word is not appropriate for this. Maybe "Event" or something: >> >> PrintInliningChunk --> PrintInliningEvent >> _print_inlining_chunks --> _print_inlining_list >> >> Allocate the list in comp arena for use in later inlining: new(comp_arena()) > > Ok. While I'm in favor of using something else than Chunk it seems that Event is not a good name choice given all the JFR events coming soon. Maybe Message? -- Chris > >> LogCompilation output will be also affected. I remember fixing the tool for StringOpts. Could you verify that it works and fix it if it does not? > > It's indeed broken but it doesn't look like a trivial fix to me. Can this be done separately? If yes, I'll file a new CR. > Also: in the current LogCompilation late_inline entries are listed at the end: > > 13 spec.benchmarks._213_javac.ScannerInputStream::read (513 bytes) > @ 32 java.io.InputStream::read (0 bytes) > type profile java/io/InputStream -> java/io/BufferedInputStream (100%) > @ 32 java.io.BufferedInputStream::read (49 bytes) > @ 95 java.io.InputStream::read (0 bytes) > type profile java/io/InputStream -> java/io/BufferedInputStream (100%) > @ 95 java.io.BufferedInputStream::read too big > @ 151 java.io.InputStream::read (0 bytes) > @ 151 java.io.InputStream::read (0 bytes) > @ 408 spec.benchmarks._213_javac.Environment::error never executed > @ 435 java.io.InputStream::read (0 bytes) > @ 469 java.io.InputStream::read (0 bytes) > late inline: > @ 32 java.io.BufferedInputStream::read (49 bytes) (end time: 1.7170 nodes: 792 live: 538) > @ 12 java.io.BufferedInputStream::fill too big > @ 29 java.io.BufferedInputStream::getBufIfOpen (21 bytes) > @ 32 java.io.BufferedInputStream::read (49 bytes) > @ 29 java.io.BufferedInputStream::getBufIfOpen (21 bytes) (end time: 1.7180 nodes: 826 live: 569) > > (strange that @29 is twice in the late inline section) > But if there's a lot of late inlining going on, wouldn't we want to have everything together: > 13 spec.benchmarks._213_javac.ScannerInputStream::read (513 bytes) > @ 32 java.io.InputStream::read (0 bytes) > type profile java/io/InputStream -> java/io/BufferedInputStream (100%) > @ 32 java.io.BufferedInputStream::read (49 bytes) (end time: 1.7170 nodes: 792 live: 538) > @ 12 java.io.BufferedInputStream::fill too big > @ 29 java.io.BufferedInputStream::getBufIfOpen (21 bytes) > @ 95 java.io.InputStream::read (0 bytes) > type profile java/io/InputStream -> java/io/BufferedInputStream (100%) > @ 95 java.io.BufferedInputStream::read too big > @ 151 java.io.InputStream::read (0 bytes) > @ 151 java.io.InputStream::read (0 bytes) > @ 408 spec.benchmarks._213_javac.Environment::error never executed > @ 435 java.io.InputStream::read (0 bytes) > @ 469 java.io.InputStream::read (0 bytes) > > with maybe an annotation that marked some call site as late inline. What do you think? > >> I think you should put it on igvn._worklist because PhaseIterGVN::optimize() does removal of nodes with outcount() == 0. I don't think it is safe to do it inside Ideal() call. > > Ok. > >> Also, file RFE (starter_task) to find all similar cases (may be add the check for input nodes in transform_old()). > > Ok. > > Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8005031/webrev.01/ > > Roland. From david.r.chase at oracle.com Fri Dec 14 18:03:23 2012 From: david.r.chase at oracle.com (David Chase) Date: Fri, 14 Dec 2012 21:03:23 -0500 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: <50CB6093.3020409@oracle.com> References: <50CA310B.4030701@oracle.com> <50CB6093.3020409@oracle.com> Message-ID: <0958C9F9-56A5-4915-BD60-EC190BA5515B@oracle.com> But the scheduling issue does seem a little interesting. Does the macroassembler deal with that? I'm just curious, because I am still new to this. There is also the possibility of a peephole-ish optimization (that can be informed by general flow analysis) that keeps track of zero bits in a word -- for instance, if the source of the data was a LDUW, there's no need to clear the bits. David On 2012-12-14, at 12:23 PM, Vladimir Kozlov wrote: > On 12/14/12 8:48 AM, Reingruber, Richard wrote: >> Thanks, Vladimir and Chris, for your reviews and the bug id. >> >> > It would seem easier to just write two assembler instructions instead of using expand. >> >> That's what I did first, and it was easier ;) >> >> > Is there a particular reason you are using expand? >> >> With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. >> >> Is there a reason _not_ to use the expand? > > It is harder to understand what instruction does and follow when debugging a problem. Yes, it could be scheduled separately but it hit-and-miss. Also your code uses an additional (long) register which we should avoid. Adding 0xffffff immediate further complicated the code. > > We use expand rules if we need to use the same sequence of few instructions in several mach nodes. Or historically because we used emit_data() complicated encoding before. After we switched to macroassembler instructions we are trying to avoid expand encoding. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Dec 14 19:21:11 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Dec 2012 19:21:11 -0800 Subject: RFR (M): 8004835: Improve AES intrinsics on x86 In-Reply-To: <50C8189E.8080004@oracle.com> References: <50C8189E.8080004@oracle.com> Message-ID: <50CBECA7.9080306@oracle.com> http://cr.openjdk.java.net/~kvn/8004835/webrev/ Enable AES intrinsics on non-AVX cpus (Westmere), pshufb instruction in load_key() method could be used without AVX because it references only aligned memory "key_shuffle_mask". Group together aes instructions in encryptBlock/decryptBlock stubs as recommended by Intel Optimization Guide. Modified test/compiler/7184394 to test "ECB" mode. Ran compiler regression tests and jdk crypto and security tests with SunJCE default provider. Thanks, Vladimir On 11/6/12 9:46 AM, Deneau, Tom wrote: > Thanks for the update... > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Tuesday, November 06, 2012 11:42 AM > To: Mikael Vidstedt > Cc: Deneau, Tom; Harle, Christophe; Venkatachalam, Vasanth > Subject: Re: review request: 7184394: add intrinsics to use AES instructions > > The changes were promoted to jdk8b63 last week. We have to wait about 2 weeks of > JDK testing to make sure it does not brake anything. After that I will backport > it into 7u12. > > Regards, > Vladimir > > Mikael Vidstedt wrote: >> >> >> Vladimir - can you please give Tom a status update? >> >> Cheers, >> Mikael >> >> On 2012-11-06 08:31, Deneau, Tom wrote: >>> Mikael -- >>> >>> Any update on this as far as getting it into 7u12? >>> I see that the webrev was checked into the hotspot trunk on Oct 24. >>> >>> -- Tom >>> >>> -----Original Message----- >>> From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com] >>> Sent: Thursday, October 11, 2012 1:12 PM >>> To: Deneau, Tom >>> Cc: Vladimir Kozlov; Caspole, Eric; Harle, Christophe; Joshi, Shrinivas >>> Subject: Re: review request: 7184394: add intrinsics to use AES >>> instructions >>> >>> >>> It does, and very specifically it enables us to check it into the >>> development branch through one of the group repositories. When it's been >>> integrated and has gone through the necessary testing we will be able to >>> backport it to jdk7. >>> >>> Cheers, >>> Mikael >>> >>> On 2012-10-11 11:07, Deneau, Tom wrote: >>>> Mikael -- >>>> >>>> OK, there was a question on our Oracle-AMD call as to whether JEP >>>> publication would enable something to get checked into *some* hotspot >>>> repository, even if it was not the repository to be used for the next >>>> update. >>>> >>>> -- Tom >>>> >>>> >>>> -----Original Message----- >>>> From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com] >>>> Sent: Thursday, October 11, 2012 12:54 PM >>>> To: Deneau, Tom >>>> Cc: Vladimir Kozlov; Caspole, Eric; Harle, Christophe; Joshi, Shrinivas >>>> Subject: Re: review request: 7184394: add intrinsics to use AES >>>> instructions >>>> >>>> >>>> The JEPs do not mention releases, it describes the enhancement ("why?" >>>> and "what?"). >>>> >>>> Now that we have the JEP we can proceed with the rest of the work - I'm >>>> working to make sure we get this picked up and integrated asap! >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 10/11/2012 10:46 AM, Deneau, Tom wrote: >>>>> Vladimir -- >>>>> >>>>> I see that the JEP for this has been published >>>>> http://openjdk.java.net/jeps/164 but not yet approved for a >>>>> particular JDK7 update. Does the JEP publication make any >>>>> difference as far as checking this in? >>>>> >>>>> -- Tom >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Wednesday, August 22, 2012 12:07 PM >>>>> To: Deneau, Tom >>>>> Cc: Caspole, Eric; Harle, Christophe; Joshi, Shrinivas; Mikael Vidstedt >>>>> Subject: Re: review request: 7184394: add intrinsics to use AES >>>>> instructions >>>>> >>>>> Code seems good. As I understand only formalities left, Oracle wants >>>>> AMD to file >>>>> formal JEP openjdk project and follow corresponding procedures (I >>>>> can't help >>>>> with that). >>>>> >>>>> We are skipping 7u8 (it will be derived from 7u6 sources). Current >>>>> HS24 sources >>>>> will go into 7u10 which will be "last" update for jdk7. We will do >>>>> fork of HS24 >>>>> into 7u10 next week (may be). But I will be able to put these >>>>> changes there if >>>>> it will be approved for 7 update. We will have several months to put >>>>> things into >>>>> 7u10. >>>>> >>>>> Vladimir >>>>> >>>>> Deneau, Tom wrote: >>>>>> Hi Vladimir -- >>>>>> >>>>>> >>>>>> I am back from vacation. Can I get an update on 7184394: add >>>>>> intrinsics to use AES instructions? >>>>>> >>>>>> I know Eric took care of some reviewer comments a few weeks ago but we >>>>>> have not heard anything since then. >>>>>> >>>>>> >>>>>> I realize there are other hurdles for getting this into 7U8 but I was >>>>>> just curious about the status of getting it into the trunk. >>>>>> >>>>>> >>>>>> -- Tom >>>>>> >>>>>> >>>> >>> >>> >> > > From vladimir.kozlov at oracle.com Fri Dec 14 19:29:42 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Dec 2012 19:29:42 -0800 Subject: RFR (M): 8004835: Improve AES intrinsics on x86 In-Reply-To: <50CBECA7.9080306@oracle.com> References: <50CBECA7.9080306@oracle.com> Message-ID: <50CBEEA6.9010101@oracle.com> http://cr.openjdk.java.net/~kvn/8004835/webrev/ Enable AES intrinsics on non-AVX cpus (Westmere), pshufb instruction in load_key() method could be used without AVX because it references only aligned memory "key_shuffle_mask". Group together aes instructions in encryptBlock/decryptBlock stubs as recommended by Intel Optimization Guide. Modified test/compiler/7184394 to test "ECB" mode. Ran compiler regression tests and jdk crypto and security tests with SunJCE default provider. Thanks, Vladimir From christian.thalinger at oracle.com Fri Dec 14 19:31:15 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 15 Dec 2012 03:31:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20121215033123.C029D47190@hg.openjdk.java.net> Changeset: 5c0931d15474 Author: twisti Date: 2012-12-14 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5c0931d15474 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java Reviewed-by: jrose, kvn ! src/share/vm/prims/methodHandles.cpp Changeset: 3c433d080bae Author: twisti Date: 2012-12-14 12:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3c433d080bae Merge From vladimir.kozlov at oracle.com Fri Dec 14 19:33:56 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Dec 2012 19:33:56 -0800 Subject: RFR (M): 8004835: Improve AES intrinsics on x86 In-Reply-To: <50CBECA7.9080306@oracle.com> References: <50C8189E.8080004@oracle.com> <50CBECA7.9080306@oracle.com> Message-ID: <50CBEFA4.2010304@oracle.com> Please, delete this mail. Thanks, Vladimir On 12/14/12 7:21 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8004835/webrev/ > > Enable AES intrinsics on non-AVX cpus (Westmere), pshufb instruction in > load_key() method could be used without AVX because it references only > aligned memory "key_shuffle_mask". > > Group together aes instructions in encryptBlock/decryptBlock stubs as > recommended by Intel Optimization Guide. > > Modified test/compiler/7184394 to test "ECB" mode. > > Ran compiler regression tests and jdk crypto and security tests with > SunJCE default provider. > > Thanks, > Vladimir > > > ... From vladimir.kozlov at oracle.com Sat Dec 15 14:05:41 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 15 Dec 2012 14:05:41 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> Message-ID: <50CCF435.4040208@oracle.com> Roland my main concern is GraphKit::kill_dead_call_outputs(). We avoiding such dead node elimination during paring since a graph may not complete and dominate information is not accurate. Can you bailout the round of later inlining if you detect such case and let PhaseRemoveUseless do cleanup for you? The same about Compile::look_for_dead_calls(). Why you need this check if you do PhaseRemoveUseless? Thanks, Vladimir On 12/14/12 7:13 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8005071/webrev.00/ > > Current inlining heuristics are driven by the number of created nodes which is unrelated to the number of live nodes especially after optimizations are applied. C2 should perform inlining in a loop: > > while (more_inlining_candidates) { > apply_optimizations(); > if (number_of_live_nodes > some_number) break; > inline_more(); > } > > In this change, C2 starts inlining at parse-time as usual until the existing heuristics kick in and prevent any further inlining. It then starts enqueuing candidates for further inlining. The candidates are restricted to the methods marked with the ForceInline annotation for now. It then enters the loop above. The optimizations applied are restricted to an igvn and a simple pass of loop clean up for now. > > Roland. > From vladimir.kozlov at oracle.com Sat Dec 15 14:09:05 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 15 Dec 2012 14:09:05 -0800 Subject: Request for reviews (M): 8004835: Improve AES intrinsics on x86 Message-ID: <50CCF501.7060409@oracle.com> http://cr.openjdk.java.net/~kvn/8004835/webrev/ Enable AES intrinsics on non-AVX cpus (Westmere), pshufb instruction in load_key() method could be used without AVX because it references only aligned memory "key_shuffle_mask". Group together aes instructions in encryptBlock/decryptBlock stubs as recommended by Intel Optimization Guide. Modified test/compiler/7184394 to test "ECB" mode. Ran compiler regression tests and jdk crypto and security tests with SunJCE default provider. Thanks, Vladimir From headius at headius.com Sun Dec 16 11:55:58 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 16 Dec 2012 13:55:58 -0600 Subject: Virtual dispatch bug in 292 impl Message-ID: I wasn't sure if this had been filed already by Christian, so I wanted to post here. It appears that in C1, method handles are not properly dispatching to an overridden version of a method. My reproduction case is tied to JRuby, but I can come up with something isolated if necessary. In JRuby, the ENV object is a subclass of a Ruby Hash. Rather than rebinding all of Hash's methods (defined on org.jruby.RubyHash), the ENV impl just overrides them at the Java level. When dispatching to the [] method on ENV with invokedynamic, the handle points at RubyHash.op_aref, the implementation of [] for Hash. The ENV version should raise an error...but it does not, because it dispatches to the superclass version rather than the subclass version. If I turn off tiered compilation, the code works as expected. Reproduction for JRuby is here: https://gist.github.com/4311979 I tested on hotspot-comp built yesterday: openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-headius_2012_12_15_16_45-b00) OpenJDK 64-Bit Server VM (build 25.0-b13, mixed mode) If I have time I'll try to investigate in more depth. - Charlie From kirk at kodewerk.com Sun Dec 16 14:32:34 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Sun, 16 Dec 2012 23:32:34 +0100 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> Message-ID: Hi, I think we should consider giving people access to the MSRs. As for dumbing things down.. that is the wrong way to deal with these low level issues. However, in the absence of a real measure people will guess at when an optimization should be applied. Should an optimization be applied? That depends on what the MSRs say. Regards, Kirk PS, I am looking forward to being able to test out these new features *even if*, I have reservations that this is the best way to expose them but.... On 2012-12-05, at 5:12 PM, Vitaly Davidovich wrote: > Hi Kirk, > > Your comments seem to be one of the more loudly opposed ones. So we know what problems @Contended and Fences are trying to fix. Do you have any actionable alternatives to suggest? I'm sure everyone would agree that if these things could somehow fit into java better, then we'd all prefer that over JVMese approach. But nothing has been put forth by the folks opposing this. Simply wishing for something or saying "let's think about it" won't help - who is going to think about it and then do something? > > At the end of the day, there will probably always be some things that can be expressed better by peeling away the layers of abstraction from Java proper. I think it's unreasonable and unrealistic to think that java will provide access to low-level details of the underlying hardware - this is at odds with the design of the language. However, the JVM is fast enough that a lot of people are using it to build high performance software. In that space, it's always nice to eek out that extra level of perf, even if you're now stepping out of the "safe" zone. I personally don't see anything wrong with letting people make the decision to go there - it's not an accidental venture, and they make the leap with all the warning labels in their face. What I don't think java should solve is a people problem - if developers plunge into this space without thinking it through and doing analysis, that's their problem, frankly; nobody forced their hand. > > If the philosophy is to dumb down the platform to prevent people shooting themselves, then we should also get rid of a bunch of existing constructs/knobs in the JVM. There are plenty of Hotspot cmdline flags that can be considered low-level and could be played around with by people not understanding them that can have worse problems than @Contended. > > It's also interesting that in the C# space, which has had unsafe options almost from the get go, I have never heard anyone complain about it. In fact, Mono even went further with providing SIMD intrinsics in their library and that's only been praised (from what I've seen). > > Cheers > > Sent from my phone > > On Dec 5, 2012 10:51 AM, "Kirk Pepperdine" wrote: > Hi Aleksey, > > > On 2012-12-05, at 2:56 PM, Aleksey Shipilev wrote: > > > On 12/05/2012 05:20 PM, David Chase wrote: > >> #2, a restatement of a previous complaint (that I will let slide for > >> now, but will bring up in the future again when we have time for > >> cleanup and reorg) is that we need to be quite careful about the > >> distinction between the various sorts of Unsafe. > > > > Totally agree. Now to constructive side: are you up to actually clean up > > Unsafe? *This* makes a perfect JEP to have the open discussion about. > > To my knowledge, n the history of the JDK.. no public exposed API has ever been cleaned up. Once exposed it will be used and once used it will be impossible to back off of it. Thus prudence needs to be preferred over expedience. What makes you believe that you will be able to clean Unsafe in the future? > > > > >> There's a natural tendency to say "we're on the implementation side, > >> we know what we're doing, this organizational stuff is not a good > >> use of our time, we have deadlines to meet" -- and I hope your > >> response is the eye-rolling "yeah, right". > > > > I understand this concern, but this might as well serve as the excuse of > > not doing anything at all, and only "exploring alternatives" for years, > > while key developers are fleeing away from the platform (I've almost > > used word "vibrant" here!). > > Do you have numbers to support this assumption that developers are fleeing. The way I see it, more and more people are understanding the advantages of the platform and are moving to adopt it. I'm seeing more and more code ported from C++ to Java for reasons of maintainability etc.... This is not an excuse to not do anything but to properly resource and look into a safe solution to a known deficiency. I would like these things to be solved but I also believe there is a way to solve them in the context of how Java functions. The VM has proven time and time again that being adaptive to the run time has provided many many benefits that are not reachable by average developers. > > > > > In fact, for fences, it was on the table for at least 3 years, and no > > better+practical approach emerged. That is why I get sincerely amused > > when somebody wants to have the discussion about fences again, and get > > double amused when exposing the intrinsics to out-of-band internal API > > somehow promotes to "omg, that breaks Java" stunts. > > Sorry to say this but I find this attitude both offensive and counter productive to community building. > > I will be giving a talk on concurrency at the Munich JUG in a few hours. We will talk about fences and I will show them how to do pointer manipulation in Java.. and how it can be used to implement wait-free, non-blocking algorithms.. I will show them how to get measurements to understand when their applications are fighting with the hardware... That said, I really wished that we had a better... safer way to achieve the same effect than exposing people to unsafe. > > Kind regards, > Kirk Pepperdine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121216/6ad7070c/attachment.html From suenaga.yasumasa at lab.ntt.co.jp Sun Dec 16 17:02:05 2012 From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga) Date: Mon, 17 Dec 2012 10:02:05 +0900 Subject: Request for reviews (M): 8004835: Improve AES intrinsics on x86 In-Reply-To: <50CCF501.7060409@oracle.com> References: <50CCF501.7060409@oracle.com> Message-ID: <50CE6F0D.2050003@lab.ntt.co.jp> Hi Vladimir, Source operand of Assembler::pshufb() seems to allow misaligned memory address. Instruction reference of PSHUFB says following: ---------- When the source operand is a 128-bit memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) will be generated. ---------- Not only non-AVX but also AVX CPU needs 16-byte aligned memory address for source operand of PSHUFB. So I think that assert condition for AVX does not required in Assembler::pshufb() . http://download.intel.com/products/processor/manual/325383.pdf Thanks, Yasumasa On 2012/12/16 7:09, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8004835/webrev/ > > Enable AES intrinsics on non-AVX cpus (Westmere), pshufb instruction in load_key() method could be used without AVX because it references only aligned memory "key_shuffle_mask". > > Group together aes instructions in encryptBlock/decryptBlock stubs as recommended by Intel Optimization Guide. > > Modified test/compiler/7184394 to test "ECB" mode. > > Ran compiler regression tests and jdk crypto and security tests with SunJCE default provider. > > Thanks, > Vladimir From aleksey.shipilev at oracle.com Mon Dec 17 01:07:32 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 17 Dec 2012 13:07:32 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> Message-ID: <50CEE0D4.4070907@oracle.com> On 12/17/2012 02:32 AM, Kirk Pepperdine wrote: > I think we should consider giving people access to the MSRs. This is at very least orthogonal, if not completely unrelated to Fences discussion. You should consider filing the JEP for exposing MSRs and work there to discuss the Java MSR support. -Aleksey. From kirk at kodewerk.com Mon Dec 17 01:37:08 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 17 Dec 2012 10:37:08 +0100 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50CEE0D4.4070907@oracle.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> <50CEE0D4.4070907@oracle.com> Message-ID: <51E6E8B0-EB6C-4722-8A62-70BFEC5BEE84@kodewerk.com> Hi Aleksey, I half agree with you on the orthogonality comment. But you know my mantra.. "Measure, don't guess" and what these JEPs are saying, no screaming... lets guess!!! I've been quiet because 1) I've not had the time to offer well thought through or even half-baked alternatives and 2) these JEPs do provide functionality that I recognize is necessary. That said, this functionality is only useful under certain conditions that are only visible in the run time environment. If those conditions change for any reason, it's unclear what the effects of these "optimizations" will have on the run time. This implies a trip back to the code to correct a guess that has been incorrectly made. Almost analogous to a developer deciding it's a great time to call System.gc(). They maybe right... and certainly in some cases they *are* right. So, I wouldn't want to take the ability to call System.gc() away from developers. That said, I'm very happy to have the JVM decide to make that call on it's own 'cos that often works out much better. Ok, knowing that memory is full is easy to sort out especially compared to the false sharing problem. That said, giving programmers an annotation to deal with it without adding the heuristics into the JVM to eliminate it in the first place or at least a flag or MXBean to allow for some control in the run time feels funny. Not having a way to get a measure to expose that you have the problem in the first place simply feels wrong. Hence, the tie in. If we're going to expose this low level stuff than we also need to think about a measure to say you're suffering from that problem. That is what's missing from this JEP assuming we can't bury this functionality into the JVM it's self. If we need a complimentary JEP to cover this off I'm happy to start a new document. -- Kirk On 2012-12-17, at 10:07 AM, Aleksey Shipilev wrote: > On 12/17/2012 02:32 AM, Kirk Pepperdine wrote: >> I think we should consider giving people access to the MSRs. > > This is at very least orthogonal, if not completely unrelated to Fences > discussion. You should consider filing the JEP for exposing MSRs and > work there to discuss the Java MSR support. > > -Aleksey. > From vitalyd at gmail.com Mon Dec 17 04:31:15 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 17 Dec 2012 07:31:15 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <51E6E8B0-EB6C-4722-8A62-70BFEC5BEE84@kodewerk.com> References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> <50CEE0D4.4070907@oracle.com> <51E6E8B0-EB6C-4722-8A62-70BFEC5BEE84@kodewerk.com> Message-ID: Hi Kirk, I'd expect *responsible* developers will use some hardware event profiler and/or experimentation to determine whether there's false sharing and padding actually helps the workload they're optimizing. If your concern is some people will simply guess and slap the annotation all over the place, then I don't think you can really help cases like this; such folks are likely to create a mess of anything they do if they're in the habit of guessing. I don't think the java platform should cater to that as it's no longer a technical problem but a people one. Thanks Sent from my phone On Dec 17, 2012 4:37 AM, "Kirk Pepperdine" wrote: > Hi Aleksey, > > I half agree with you on the orthogonality comment. But you know my > mantra.. "Measure, don't guess" and what these JEPs are saying, no > screaming... lets guess!!! I've been quiet because 1) I've not had the time > to offer well thought through or even half-baked alternatives and 2) these > JEPs do provide functionality that I recognize is necessary. That said, > this functionality is only useful under certain conditions that are only > visible in the run time environment. If those conditions change for any > reason, it's unclear what the effects of these "optimizations" will have on > the run time. This implies a trip back to the code to correct a guess that > has been incorrectly made. Almost analogous to a developer deciding it's a > great time to call System.gc(). They maybe right... and certainly in some > cases they *are* right. So, I wouldn't want to take the ability to call > System.gc() away from developers. That said, I'm very happy to have the JVM > decide to make that call on it's own 'cos that often works out much better. > Ok, knowing that memory is full is easy to sort out especially compared to > the false sharing problem. That said, giving programmers an annotation to > deal with it without adding the heuristics into the JVM to eliminate it in > the first place or at least a flag or MXBean to allow for some control in > the run time feels funny. Not having a way to get a measure to expose that > you have the problem in the first place simply feels wrong. Hence, the tie > in. If we're going to expose this low level stuff than we also need to > think about a measure to say you're suffering from that problem. That is > what's missing from this JEP assuming we can't bury this functionality into > the JVM it's self. If we need a complimentary JEP to cover this off I'm > happy to start a new document. > > -- Kirk > > On 2012-12-17, at 10:07 AM, Aleksey Shipilev > wrote: > > > On 12/17/2012 02:32 AM, Kirk Pepperdine wrote: > >> I think we should consider giving people access to the MSRs. > > > > This is at very least orthogonal, if not completely unrelated to Fences > > discussion. You should consider filing the JEP for exposing MSRs and > > work there to discuss the Java MSR support. > > > > -Aleksey. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121217/fb415aff/attachment-0001.html From kirk at kodewerk.com Mon Dec 17 04:41:58 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 17 Dec 2012 13:41:58 +0100 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> <50CEE0D4.4070907@oracle.com> <51E6E8B0-EB6C-4722-8A62-70BFEC5BEE84@kodewerk.com> Message-ID: Hi Vitaly, Despite the seemingly mothering nature of my recent email posts, I don't really buy into that attitude. I'm ok with Unsafe being there as it serves purposes that we've (unfortunately) not found a safer way to present to developers that need it. That said, my concern isn't about those that may slap these annotations every where (for me that is a business opportunity). I'm of the mind that the JVM comes to the table with more information than I have and even what reasonable developers have *even with careful experimentation*. If you can buy into that then it seems to me that I'd rather have the JVM decide that something should be padded rather than 1) have me experiment to discover it and then 2) correlate that experiment with some bit of code, 3) alter the code and then 4) hope that conditions don't change to something that invalidates my correction and 5) would prevent me from monitoring and re-experimenting to make sure my correction still applies. If there is no magic to look after all this, I'll take the annotation. Regards, Kirk On 2012-12-17, at 1:31 PM, Vitaly Davidovich wrote: > Hi Kirk, > > I'd expect *responsible* developers will use some hardware event profiler and/or experimentation to determine whether there's false sharing and padding actually helps the workload they're optimizing. > > If your concern is some people will simply guess and slap the annotation all over the place, then I don't think you can really help cases like this; such folks are likely to create a mess of anything they do if they're in the habit of guessing. I don't think the java platform should cater to that as it's no longer a technical problem but a people one. > > Thanks > > Sent from my phone > > On Dec 17, 2012 4:37 AM, "Kirk Pepperdine" wrote: > Hi Aleksey, > > I half agree with you on the orthogonality comment. But you know my mantra.. "Measure, don't guess" and what these JEPs are saying, no screaming... lets guess!!! I've been quiet because 1) I've not had the time to offer well thought through or even half-baked alternatives and 2) these JEPs do provide functionality that I recognize is necessary. That said, this functionality is only useful under certain conditions that are only visible in the run time environment. If those conditions change for any reason, it's unclear what the effects of these "optimizations" will have on the run time. This implies a trip back to the code to correct a guess that has been incorrectly made. Almost analogous to a developer deciding it's a great time to call System.gc(). They maybe right... and certainly in some cases they *are* right. So, I wouldn't want to take the ability to call System.gc() away from developers. That said, I'm very happy to have the JVM decide to make that call on it's own 'cos that often works out much better. Ok, knowing that memory is full is easy to sort out especially compared to the false sharing problem. That said, giving programmers an annotation to deal with it without adding the heuristics into the JVM to eliminate it in the first place or at least a flag or MXBean to allow for some control in the run time feels funny. Not having a way to get a measure to expose that you have the problem in the first place simply feels wrong. Hence, the tie in. If we're going to expose this low level stuff than we also need to think about a measure to say you're suffering from that problem. That is what's missing from this JEP assuming we can't bury this functionality into the JVM it's self. If we need a complimentary JEP to cover this off I'm happy to start a new document. > > -- Kirk > > On 2012-12-17, at 10:07 AM, Aleksey Shipilev wrote: > > > On 12/17/2012 02:32 AM, Kirk Pepperdine wrote: > >> I think we should consider giving people access to the MSRs. > > > > This is at very least orthogonal, if not completely unrelated to Fences > > discussion. You should consider filing the JEP for exposing MSRs and > > work there to discuss the Java MSR support. > > > > -Aleksey. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121217/37d986ca/attachment.html From vitalyd at gmail.com Mon Dec 17 04:53:59 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 17 Dec 2012 07:53:59 -0500 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: References: <50BD25B0.2060501@oracle.com> <7B6EF1A6-2711-47B8-B0B9-DEE5175E80C6@kodewerk.com> <50BE340C.9000108@oracle.com> <50BEFFAC.1010807@oracle.com> <50BF5272.9030100@oracle.com> <50CEE0D4.4070907@oracle.com> <51E6E8B0-EB6C-4722-8A62-70BFEC5BEE84@kodewerk.com> Message-ID: So I think everyone's in agreement that for any feature X, if JVM could do it better or automatically, then people would take that over manual knobs. However, unfortunately the JVM isn't some magic pixie dust - someone has to go and implement said feature, test it, and support it. In cases where you have a quick and simple way to enable the feature vs something much more involved that perhaps adds only marginally better experience and will take much longer to release, it's almost a no brainer to do the quick and easy one and then see how it pans out before plunging head first into the complex/longer variant. It just may be that people using it will find supplemental tools to make the experience better, and don't need the JVM to do it; in this case, the supplemental tool would be hardware event profilers, which people may already be using anyway. Cheers Sent from my phone On Dec 17, 2012 7:42 AM, "Kirk Pepperdine" wrote: > Hi Vitaly, > > Despite the seemingly mothering nature of my recent email posts, I don't > really buy into that attitude. I'm ok with Unsafe being there as it serves > purposes that we've (unfortunately) not found a safer way to present to > developers that need it. That said, my concern isn't about those that may > slap these annotations every where (for me that is a business opportunity). > I'm of the mind that the JVM comes to the table with more information than > I have and even what reasonable developers have *even with careful > experimentation*. If you can buy into that then it seems to me that I'd > rather have the JVM decide that something should be padded rather than 1) > have me experiment to discover it and then 2) correlate that experiment > with some bit of code, 3) alter the code and then 4) hope that conditions > don't change to something that invalidates my correction and 5) would > prevent me from monitoring and re-experimenting to make sure my correction > still applies. If there is no magic to look after all this, I'll take the > annotation. > > Regards, > Kirk > > On 2012-12-17, at 1:31 PM, Vitaly Davidovich wrote: > > Hi Kirk, > > I'd expect *responsible* developers will use some hardware event profiler > and/or experimentation to determine whether there's false sharing and > padding actually helps the workload they're optimizing. > > If your concern is some people will simply guess and slap the annotation > all over the place, then I don't think you can really help cases like this; > such folks are likely to create a mess of anything they do if they're in > the habit of guessing. I don't think the java platform should cater to > that as it's no longer a technical problem but a people one. > > Thanks > > Sent from my phone > On Dec 17, 2012 4:37 AM, "Kirk Pepperdine" wrote: > >> Hi Aleksey, >> >> I half agree with you on the orthogonality comment. But you know my >> mantra.. "Measure, don't guess" and what these JEPs are saying, no >> screaming... lets guess!!! I've been quiet because 1) I've not had the time >> to offer well thought through or even half-baked alternatives and 2) these >> JEPs do provide functionality that I recognize is necessary. That said, >> this functionality is only useful under certain conditions that are only >> visible in the run time environment. If those conditions change for any >> reason, it's unclear what the effects of these "optimizations" will have on >> the run time. This implies a trip back to the code to correct a guess that >> has been incorrectly made. Almost analogous to a developer deciding it's a >> great time to call System.gc(). They maybe right... and certainly in some >> cases they *are* right. So, I wouldn't want to take the ability to call >> System.gc() away from developers. That said, I'm very happy to have the JVM >> decide to make that call on it's own 'cos that often works out much better. >> Ok, knowing that memory is full is easy to sort out especially compared to >> the false sharing problem. That said, giving programmers an annotation to >> deal with it without adding the heuristics into the JVM to eliminate it in >> the first place or at least a flag or MXBean to allow for some control in >> the run time feels funny. Not having a way to get a measure to expose that >> you have the problem in the first place simply feels wrong. Hence, the tie >> in. If we're going to expose this low level stuff than we also need to >> think about a measure to say you're suffering from that problem. That is >> what's missing from this JEP assuming we can't bury this functionality into >> the JVM it's self. If we need a complimentary JEP to cover this off I'm >> happy to start a new document. >> >> -- Kirk >> >> On 2012-12-17, at 10:07 AM, Aleksey Shipilev >> wrote: >> >> > On 12/17/2012 02:32 AM, Kirk Pepperdine wrote: >> >> I think we should consider giving people access to the MSRs. >> > >> > This is at very least orthogonal, if not completely unrelated to Fences >> > discussion. You should consider filing the JEP for exposing MSRs and >> > work there to discuss the Java MSR support. >> > >> > -Aleksey. >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121217/ba2a43cb/attachment.html From roland.westrelin at oracle.com Mon Dec 17 08:49:26 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 17 Dec 2012 17:49:26 +0100 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> <50CA3C61.5090902@oracle.com> <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> Message-ID: <7BAAE96F-FD64-487D-A9AB-F1D60AF31012@oracle.com> >>> PrintInliningChunk --> PrintInliningEvent >>> _print_inlining_chunks --> _print_inlining_list > > While I'm in favor of using something else than Chunk it seems that Event is not a good name choice given all the JFR events coming soon. Maybe Message? What about PrintInliningBuffer (often, there will be more than one inlining message per buffer) and _print_inlining_list? Roland. From roland.westrelin at oracle.com Mon Dec 17 09:18:56 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 17 Dec 2012 18:18:56 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <50CCF435.4040208@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> Message-ID: <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> Vladimir, Thanks for reviewing this. > Roland my main concern is GraphKit::kill_dead_call_outputs(). We avoiding such dead node elimination during paring since a graph may not complete and dominate information is not accurate. Can you bailout the round of later inlining if you detect such case and let PhaseRemoveUseless do cleanup for you? Let's say we have 2 calls in a method: A() B() A() dominates B(). During parsing, we build a complete graph with CallNodes for A() and B(). Let's say we decide to inline A() after parsing so we build a subgraph with A()'s inputs as inputs to parsing and then we replace B()'s outputs with the resulting new subgraph. Now let's say A()'s outputs are dead and we try to inline B(). It depends on A()'s outputs but they are dead and often C2 will see an inconsistent state when it builds the subgraph for B(): control not top so it proceeds with inlining, but a MergedMem with some slices set to top or if B() uses the return from A(), top as an input. These lead to crashes. That doesn't happen with parse-time inlining because A()'s subgraph is built inside the main graph, all results from A()'s inlining are propagated forward to B() by the gvn, the input state for B() is consistent and we don't try to inlining B() because this is a dead path. I don't think PhaseRemoveUseless helps in this case. What we would need in the case of post parse inlining would be to inline A(), apply an igvn to propagate the results from the inlining forward to B(), then inline B(). But even an igvn is not sufficient if for instance, B() is inside a loop. That's why I use GraphKit::kill_dead_call_outputs(). I don't understand why it's dangerous since it operates in well defined conditions. In the example above, we have a complete graph with a DirectCall to A(). We are done with parsing for A() and the subgraph for A() uses A()'s inputs but it is not yet connected to the rest of the graph by it's outputs. We want to find calls that A()'s control outputs dominate and we work on a complete graph, the subgraph for A() doesn't really matter. > The same about Compile::look_for_dead_calls(). Why you need this check if you do PhaseRemoveUseless? With CTW, I found some rare cases, where an igvn pass makes some path dead but similar to what I describe above the state at a call that we want to inline is not consistent. Roland. From richard.reingruber at sap.com Mon Dec 17 09:36:35 2012 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Mon, 17 Dec 2012 18:36:35 +0100 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: <50CB6093.3020409@oracle.com> References: <50CA310B.4030701@oracle.com> <50CB6093.3020409@oracle.com> Message-ID: > We use expand rules if we need to use the same sequence of few instructions > in several mach nodes. Or historically because we used emit_data() > complicated encoding before. After we switched to macroassembler > instructions we are trying to avoid expand encoding. I've discussed this as well with my colleagues. We've always understood the expand mechanism as instrument for breaking up higher level ideal nodes into low level mach nodes allowing optimizer and scheduler to work effectively. But you are certainly right. Compound nodes make a developer's life easier, plus even in a micro benchmark, the performance advantage of the version with the expand would be, at most, minimal anyway. And I've noticed, that the other bit intrinsics are compound nodes, too. So I've prepared another webrev with the macroassembler solution: http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_03/ But just in case you want to give the expand a chance: I've prepared a 4th webrev using one of the forms Dean suggested. This version doesn't produce a long value. Maybe you like it: http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_04/ I trust you'll select the best version :) Thanks, Richard. -----Original Message----- From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Freitag, 14. Dezember 2012 18:24 To: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 On 12/14/12 8:48 AM, Reingruber, Richard wrote: > Thanks, Vladimir and Chris, for your reviews and the bug id. > > > It would seem easier to just write two assembler instructions instead of using expand. > > That's what I did first, and it was easier ;) > > > Is there a particular reason you are using expand? > > With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. > > Is there a reason _not_ to use the expand? It is harder to understand what instruction does and follow when debugging a problem. Yes, it could be scheduled separately but it hit-and-miss. Also your code uses an additional (long) register which we should avoid. Adding 0xffffff immediate further complicated the code. We use expand rules if we need to use the same sequence of few instructions in several mach nodes. Or historically because we used emit_data() complicated encoding before. After we switched to macroassembler instructions we are trying to avoid expand encoding. Thanks, Vladimir > > And here's the webrev updated with the bug id: > > http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_02/ > > Cheers, Richard. > > -----Original Message----- > From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Donnerstag, 13. Dezember 2012 20:48 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 > > We should use macroassembler instructions and we have special > instruction to clear upper half: > > ins_encode %{ > __ clruwu($src$$Register); > __ popc($src$$Register, $dst$$Register); > %} > > Vladimir > > On 12/13/12 10:46 AM, Christian Thalinger wrote: >> >> On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: >> >>> Hi, >>> >>> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >>> >>> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >>> >>> I have prepared a small webrev with the suggested fix and a regression test: >>> >>> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >>> >>> Could you please review the patch and create a bug id? Thanks! >> >> Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: >> >> 8005033: clear high word for integer pop count on SPARC >> >> It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? >> >> -- Chris >> >>> >>> Cheers, >>> Richard. >>> >>> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >>> >> From christian.thalinger at oracle.com Mon Dec 17 10:41:19 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Dec 2012 10:41:19 -0800 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: <7BAAE96F-FD64-487D-A9AB-F1D60AF31012@oracle.com> References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> <50CA3C61.5090902@oracle.com> <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> <7BAAE96F-FD64-487D-A9AB-F1D60AF31012@oracle.com> Message-ID: <10644F56-D226-4984-B346-E80D01CA97D8@oracle.com> On Dec 17, 2012, at 8:49 AM, Roland Westrelin wrote: >>>> PrintInliningChunk --> PrintInliningEvent >>>> _print_inlining_chunks --> _print_inlining_list >> >> While I'm in favor of using something else than Chunk it seems that Event is not a good name choice given all the JFR events coming soon. Maybe Message? > > What about PrintInliningBuffer (often, there will be more than one inlining message per buffer) and _print_inlining_list? Sounds good. -- Chris From christian.thalinger at oracle.com Mon Dec 17 10:51:51 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Dec 2012 10:51:51 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: References: <50CA310B.4030701@oracle.com> <50CB6093.3020409@oracle.com> Message-ID: <1138AC48-E44A-4610-8A82-0B8100AD2B20@oracle.com> On Dec 17, 2012, at 9:36 AM, "Reingruber, Richard" wrote: >> We use expand rules if we need to use the same sequence of few instructions >> in several mach nodes. Or historically because we used emit_data() >> complicated encoding before. After we switched to macroassembler >> instructions we are trying to avoid expand encoding. > > I've discussed this as well with my colleagues. We've always understood the > expand mechanism as instrument for breaking up higher level ideal nodes into low > level mach nodes allowing optimizer and scheduler to work effectively. > > But you are certainly right. Compound nodes make a developer's life easier, plus > even in a micro benchmark, the performance advantage of the version with the > expand would be, at most, minimal anyway. And I've noticed, that the other bit > intrinsics are compound nodes, too. So I've prepared another webrev with the > macroassembler solution: > > http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_03/ > > But just in case you want to give the expand a chance: I've prepared a 4th > webrev using one of the forms Dean suggested. This version doesn't produce a > long value. Maybe you like it: > > http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_04/ > > I trust you'll select the best version :) I will pick the first one. But I would like to use SRL directly instead of clruwu because the clr macro assembler instructions are not used right now: $ grep -r clruw src/cpu/sparc/vm/ src/cpu/sparc/vm/macroAssembler_sparc.hpp: inline void clruw( Register s, Register d ) { srl( s, G0, d); } src/cpu/sparc/vm/macroAssembler_sparc.hpp: inline void clruwu( Register d ) { srl( d, G0, d); } And in the near future I'd like to get rid of the format %{ %} blocks and have the instructions emit the format themselves. Then a CLRUWU would print SRL anyway. -- Chris > > Thanks, > Richard. > > -----Original Message----- > From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Freitag, 14. Dezember 2012 18:24 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 > > On 12/14/12 8:48 AM, Reingruber, Richard wrote: >> Thanks, Vladimir and Chris, for your reviews and the bug id. >> >>> It would seem easier to just write two assembler instructions instead of using expand. >> >> That's what I did first, and it was easier ;) >> >>> Is there a particular reason you are using expand? >> >> With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. >> >> Is there a reason _not_ to use the expand? > > It is harder to understand what instruction does and follow when > debugging a problem. Yes, it could be scheduled separately but it > hit-and-miss. Also your code uses an additional (long) register which we > should avoid. Adding 0xffffff immediate further complicated the code. > > We use expand rules if we need to use the same sequence of few > instructions in several mach nodes. Or historically because we used > emit_data() complicated encoding before. After we switched to > macroassembler instructions we are trying to avoid expand encoding. > > Thanks, > Vladimir > >> >> And here's the webrev updated with the bug id: >> >> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_02/ >> >> Cheers, Richard. >> >> -----Original Message----- >> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: Donnerstag, 13. Dezember 2012 20:48 >> To: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >> >> We should use macroassembler instructions and we have special >> instruction to clear upper half: >> >> ins_encode %{ >> __ clruwu($src$$Register); >> __ popc($src$$Register, $dst$$Register); >> %} >> >> Vladimir >> >> On 12/13/12 10:46 AM, Christian Thalinger wrote: >>> >>> On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: >>> >>>> Hi, >>>> >>>> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >>>> >>>> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >>>> >>>> I have prepared a small webrev with the suggested fix and a regression test: >>>> >>>> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >>>> >>>> Could you please review the patch and create a bug id? Thanks! >>> >>> Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: >>> >>> 8005033: clear high word for integer pop count on SPARC >>> >>> It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? >>> >>> -- Chris >>> >>>> >>>> Cheers, >>>> Richard. >>>> >>>> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >>>> >>> From christian.thalinger at oracle.com Mon Dec 17 11:01:23 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Dec 2012 11:01:23 -0800 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: <10644F56-D226-4984-B346-E80D01CA97D8@oracle.com> References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> <50CA3C61.5090902@oracle.com> <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> <7BAAE96F-FD64-487D-A9AB-F1D60AF31012@oracle.com> <10644F56-D226-4984-B346-E80D01CA97D8@oracle.com> Message-ID: On Dec 17, 2012, at 10:41 AM, Christian Thalinger wrote: > > On Dec 17, 2012, at 8:49 AM, Roland Westrelin wrote: > >>>>> PrintInliningChunk --> PrintInliningEvent >>>>> _print_inlining_chunks --> _print_inlining_list >>> >>> While I'm in favor of using something else than Chunk it seems that Event is not a good name choice given all the JFR events coming soon. Maybe Message? >> >> What about PrintInliningBuffer (often, there will be more than one inlining message per buffer) and _print_inlining_list? > > Sounds good. -- Chris I have one more question: src/share/vm/opto/library_call.cpp: - args[which_arg] = _gvn.transform(arg); + args[which_arg] = arg; Why is the transform not necessary? I guess it's because the incoming arguments are already transformed. -- Chris From christian.thalinger at oracle.com Mon Dec 17 11:10:21 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Dec 2012 11:10:21 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: <1138AC48-E44A-4610-8A82-0B8100AD2B20@oracle.com> References: <50CA310B.4030701@oracle.com> <50CB6093.3020409@oracle.com> <1138AC48-E44A-4610-8A82-0B8100AD2B20@oracle.com> Message-ID: On Dec 17, 2012, at 10:51 AM, Christian Thalinger wrote: > > On Dec 17, 2012, at 9:36 AM, "Reingruber, Richard" wrote: > >>> We use expand rules if we need to use the same sequence of few instructions >>> in several mach nodes. Or historically because we used emit_data() >>> complicated encoding before. After we switched to macroassembler >>> instructions we are trying to avoid expand encoding. >> >> I've discussed this as well with my colleagues. We've always understood the >> expand mechanism as instrument for breaking up higher level ideal nodes into low >> level mach nodes allowing optimizer and scheduler to work effectively. >> >> But you are certainly right. Compound nodes make a developer's life easier, plus >> even in a micro benchmark, the performance advantage of the version with the >> expand would be, at most, minimal anyway. And I've noticed, that the other bit >> intrinsics are compound nodes, too. So I've prepared another webrev with the >> macroassembler solution: >> >> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_03/ Oh, and the src register is destroyed in that changes. The shifted value needs to end up in dst: http://cr.openjdk.java.net/~twisti/8005033/ -- Chris >> >> But just in case you want to give the expand a chance: I've prepared a 4th >> webrev using one of the forms Dean suggested. This version doesn't produce a >> long value. Maybe you like it: >> >> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_04/ >> >> I trust you'll select the best version :) > > I will pick the first one. But I would like to use SRL directly instead of clruwu because the clr macro assembler instructions are not used right now: > > $ grep -r clruw src/cpu/sparc/vm/ > src/cpu/sparc/vm/macroAssembler_sparc.hpp: inline void clruw( Register s, Register d ) { srl( s, G0, d); } > src/cpu/sparc/vm/macroAssembler_sparc.hpp: inline void clruwu( Register d ) { srl( d, G0, d); } > > And in the near future I'd like to get rid of the format %{ %} blocks and have the instructions emit the format themselves. Then a CLRUWU would print SRL anyway. > > -- Chris > >> >> Thanks, >> Richard. >> >> -----Original Message----- >> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: Freitag, 14. Dezember 2012 18:24 >> To: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >> >> On 12/14/12 8:48 AM, Reingruber, Richard wrote: >>> Thanks, Vladimir and Chris, for your reviews and the bug id. >>> >>>> It would seem easier to just write two assembler instructions instead of using expand. >>> >>> That's what I did first, and it was easier ;) >>> >>>> Is there a particular reason you are using expand? >>> >>> With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. >>> >>> Is there a reason _not_ to use the expand? >> >> It is harder to understand what instruction does and follow when >> debugging a problem. Yes, it could be scheduled separately but it >> hit-and-miss. Also your code uses an additional (long) register which we >> should avoid. Adding 0xffffff immediate further complicated the code. >> >> We use expand rules if we need to use the same sequence of few >> instructions in several mach nodes. Or historically because we used >> emit_data() complicated encoding before. After we switched to >> macroassembler instructions we are trying to avoid expand encoding. >> >> Thanks, >> Vladimir >> >>> >>> And here's the webrev updated with the bug id: >>> >>> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_02/ >>> >>> Cheers, Richard. >>> >>> -----Original Message----- >>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>> Sent: Donnerstag, 13. Dezember 2012 20:48 >>> To: hotspot-compiler-dev at openjdk.java.net >>> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >>> >>> We should use macroassembler instructions and we have special >>> instruction to clear upper half: >>> >>> ins_encode %{ >>> __ clruwu($src$$Register); >>> __ popc($src$$Register, $dst$$Register); >>> %} >>> >>> Vladimir >>> >>> On 12/13/12 10:46 AM, Christian Thalinger wrote: >>>> >>>> On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: >>>> >>>>> Hi, >>>>> >>>>> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >>>>> >>>>> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >>>>> >>>>> I have prepared a small webrev with the suggested fix and a regression test: >>>>> >>>>> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >>>>> >>>>> Could you please review the patch and create a bug id? Thanks! >>>> >>>> Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: >>>> >>>> 8005033: clear high word for integer pop count on SPARC >>>> >>>> It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? >>>> >>>> -- Chris >>>> >>>>> >>>>> Cheers, >>>>> Richard. >>>>> >>>>> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >>>>> >>>> > From roland.westrelin at oracle.com Mon Dec 17 11:08:57 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 17 Dec 2012 20:08:57 +0100 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> <50CA3C61.5090902@oracle.com> <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> <7BAAE96F-FD64-487D-A9AB-F1D60AF31012@oracle.com> <10644F56-D226-4984-B346-E80D01CA97D8@oracle.com> Message-ID: > I have one more question: > > src/share/vm/opto/library_call.cpp: > > - args[which_arg] = _gvn.transform(arg); > + args[which_arg] = arg; > > Why is the transform not necessary? I guess it's because the incoming arguments are already transformed. Yes, it's because it's already transformed. Roland. From christian.thalinger at oracle.com Mon Dec 17 11:14:43 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Dec 2012 11:14:43 -0800 Subject: RFS(M): 8005031: Some cleanup in c2 to prepare for incremental inlining support In-Reply-To: References: <5BA6FEE7-B1C8-4FBB-80F7-F0D7FD865B77@oracle.com> <50CA3C61.5090902@oracle.com> <7A4874B1-FA06-4814-88B7-F46C939C0A3B@oracle.com> <7BAAE96F-FD64-487D-A9AB-F1D60AF31012@oracle.com> <10644F56-D226-4984-B346-E80D01CA97D8@oracle.com> Message-ID: On Dec 17, 2012, at 11:08 AM, Roland Westrelin wrote: >> I have one more question: >> >> src/share/vm/opto/library_call.cpp: >> >> - args[which_arg] = _gvn.transform(arg); >> + args[which_arg] = arg; >> >> Why is the transform not necessary? I guess it's because the incoming arguments are already transformed. > > > Yes, it's because it's already transformed. Then all looks good. -- Chris From christian.thalinger at oracle.com Mon Dec 17 12:33:36 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Dec 2012 12:33:36 -0800 Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF699BB95@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6931DF6@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6C39002@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6D1B1DD@DEWDFECCR03.wdf.sap.corp> <2A438E2B-8690-4D49-B15F-8E9B4DEDFE61@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BB95@DEWDFECCR03.wdf.sap.corp> Message-ID: <93D2D2A8-7911-46BE-B703-DA87130EB7BE@oracle.com> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz" wrote: > Hi Chris, > > Loading the constant takes 5 instructions, the other way only three, > in the code only one, if the constant pool base is in a register. > The 5 instructions are hard to patch atomically. The constant pool > is just a 64 bit store. > >> Sorry for being so persistent on this :-) > That's ok, I already found several places in our VM where it was easy to > change our code to get along without the shared changes we did in > first place. But I can't redesign everything, and I can not risk to break > anything in our product. > > If you feel like doing so, you can have a look at > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9 > which contains our bytecode interpreter profiling implementation. > If you think this is currently of use in the main branch, I would lift it to HS25 > (the permgen changes might cause trouble) and contribute it to hsx. Sorry for the long delay. Thinking about this problem again it seems that the correct solution would be to have a compiledIC_.cpp file. The CompiledIC instruction layout is platform dependent; it just happens to be the same for all architectures we have right now (well, except PPC) because we made it to be the same. Actually on SPARC we could also use a load from the constant table which would be simpler. Having a platform dependent file for this code feels right. What do you think? -- Chris > > Best regards, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Thursday, November 29, 2012 7:53 PM > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] > > > On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz" wrote: > >> Hi Chris, >> >>> Why can't you point the relocation to the method load instruction? It doesn't seem right to do that in shared code. >> Because the relocation is used >> 1.) to find the beginning of the stub to patch the call to go there >> 2.) to find the load to patch the IC. > > Got it. > >> >> Just have a look at CompiledStaticCall::set_to_interpreted(), >> the variable 'stub' is used twice. > > Sorry for being so persistent on this :-) What is the reason you have to load the constant from the constant table? On other architectures we materialize the constant. > > -- Chris > >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Donnerstag, 29. November 2012 01:35 >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] >> >> >> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi Chris, >>> >>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? >>> Shared code (class CompiledStaticCall) wants to patch the inline cache >>> in the stub which is emitted in platform code. >>> So the platform code should specify how the shared code can find the inline cache >>> in the stub, which it does through the constant I introduced. >>> >>>> Do you need two relocations? I'm confused. >>> No, three ;) >>> The relocation you mention is used to find the stub given the call. >>> The other relocations are needed to find the inline cache / call target >>> once the stub is found (see CompiledStaticCall::set_to_interpreted()). >>> It's just the same on x86_64: >>> >>> // static stub relocation stores the instruction address of the call >>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); >>> // static stub relocation also tags the methodOop in the code-stream. >>> __ movoop(rbx, (jobject) NULL); // method is zapped till fixup time >>> // This is recognized as unresolved by relocs/nativeinst/ic code >>> __ jump(RuntimeAddress(__ pc())); >>> >>> On PPC, we have to load the base of the constant table after generating the >>> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is >>> exactly what we store in the CompiledStaticCall::comp_to_int_load_offset constant. >> >> Why can't you point the relocation to the method load instruction? It doesn't seem right to do that in shared code. >> >> -- Chris >> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Dienstag, 27. November 2012 01:53 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-compiler-dev at openjdk.java.net >>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] >>> >>> >>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz" wrote: >>> >>>> Hi Chris, >>>> >>>> We put it into the ad file because it describes an offset into the stub that is >>>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), >>>> used by ir node CallStaticJavaDirect. Maybe I should not call it stub, but it's >>>> generated into the stubs section of the code buffer. >>>> If that stub generator is moved out of the ad file to shared compiler code, one should >>>> move the field with it, but for the current implementation I think that's fine. >>>> >>>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature? >>>> If so, one could protect the whole thing by #ifdef COMPILER2. >>> >>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? >>> >>> // Create a static stub relocation which relates this stub >>> // with the call instruction at insts_call_instruction_offset in the >>> // instructions code-section. >>> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset)); >>> >>> Do you need two relocations? I'm confused. >>> >>> -- Chris >>> >>>> >>>> Thanks for all the bugids! >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> Sent: Mittwoch, 21. November 2012 19:53 >>>> To: Lindenmaier, Goetz >>>> Cc: hotspot-compiler-dev at openjdk.java.net >>>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] >>>> >>>> >>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> yes, there is no C1 on ppc. >>>>> We do tiered compilation with a stripped C2. >>>> >>>> Right. But some other architecture (or in the future) might need this for C1 as well. We should find a better place for the value than the ad file. The obvious place would be compiledIC_.hpp but we don't have that file, yet. >>>> >>>> I filed: >>>> >>>> 8003853: specify offset of IC load in java_to_interp stub >>>> >>>> -- Chris >>>> >>>>> >>>>> Best regards, >>>>> Goetz >>>>> >>>>> -----Original Message----- >>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> Sent: Dienstag, 20. November 2012 22:19 >>>>> To: Lindenmaier, Goetz >>>>> Cc: hotspot-compiler-dev at openjdk.java.net >>>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub. >>>>> >>>>> >>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub >>>>>> to update the IC with NativeMovConstReg. The current implementation assumes that >>>>>> the load is always the first instruction in the stub. This is an artificial restriction. E.g., >>>>>> it might be useful to load the constant pool address (MachConstantBase) before the >>>>>> IC load (as we do on PPC). >>>>>> >>>>>> This change adds a constant specifying an offset from the beginning of the stub to >>>>>> the IC load. The offset is platform specific and 0 on sparc and x86. >>>>>> >>>>>> You can find the change here: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ >>>>> >>>>> That should be fixed indeed. >>>>> >>>>> +#ifndef COMPILER2 >>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0; >>>>> >>>>> There is no C1 for PPC (sorry, I didn't check)? >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> or in our ppc port: >>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 >>>>>> >>>>>> Thank you and best regards, >>>>>> Goetz >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Mon Dec 17 12:52:48 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Dec 2012 12:52:48 -0800 Subject: Request for reviews (M): 8004835: Improve AES intrinsics on x86 In-Reply-To: <50CE6F0D.2050003@lab.ntt.co.jp> References: <50CCF501.7060409@oracle.com> <50CE6F0D.2050003@lab.ntt.co.jp> Message-ID: <50CF8620.7060309@oracle.com> Hi, Yasumasa Thank you for looking on changes. On 12/16/12 5:02 PM, Yasumasa Suenaga wrote: > Hi Vladimir, > > Source operand of Assembler::pshufb() seems to allow misaligned memory > address. I assume you mean "to NOT allow" otherwise you statement contradict the quote. > Instruction reference of PSHUFB says following: > > ---------- > When the source operand is a 128-bit memory operand, the operand must be > aligned > on a 16-byte boundary or a general-protection exception (#GP) will be > generated. > ---------- > > Not only non-AVX but also AVX CPU needs 16-byte aligned memory address > for source > operand of PSHUFB. It is not true. It depends how you encode instructions when AVX available. Hotspot use VEX prefix in such case with which alignment is not required (2.5): http://software.intel.com/sites/default/files/319433-014.pdf (v)pshufb is "Type 4" exception class instruction (Table 2-7). For such instructions only legacy SSE encoded (REX prefix) instructions cause #GP exception with unaligned memory (Table 2-13). Note, in 325383.pdf corresponding tables are 2-14 and 2-20. Thanks, Vladimir > So I think that assert condition for AVX does not required in > Assembler::pshufb() . > > http://download.intel.com/products/processor/manual/325383.pdf > > > Thanks, > > Yasumasa > > > On 2012/12/16 7:09, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8004835/webrev/ >> >> Enable AES intrinsics on non-AVX cpus (Westmere), pshufb instruction >> in load_key() method could be used without AVX because it references >> only aligned memory "key_shuffle_mask". >> >> Group together aes instructions in encryptBlock/decryptBlock stubs as >> recommended by Intel Optimization Guide. >> >> Modified test/compiler/7184394 to test "ECB" mode. >> >> Ran compiler regression tests and jdk crypto and security tests with >> SunJCE default provider. >> >> Thanks, >> Vladimir From vladimir.kozlov at oracle.com Mon Dec 17 13:37:33 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Dec 2012 13:37:33 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: References: <50CA310B.4030701@oracle.com> <50CB6093.3020409@oracle.com> Message-ID: <50CF909D.3030309@oracle.com> I will take first one :) The second solution still use/kill additional tmp register. You may think that not using tmp register "shrI_reg_imm5(src, src, zero_shift_amount)" will give you the same result as macroassembler implementation. But it is not true because RA will see that "shrI_" modifies "src" and will spill it if there is an other use. If we had more cases like this we would add new operand iRegIupper0 and mach instruction which does shrl r,0,r to produce it. And let Matcher do the rest. Thanks, Vladimir On 12/17/12 9:36 AM, Reingruber, Richard wrote: > > We use expand rules if we need to use the same sequence of few instructions > > in several mach nodes. Or historically because we used emit_data() > > complicated encoding before. After we switched to macroassembler > > instructions we are trying to avoid expand encoding. > > I've discussed this as well with my colleagues. We've always understood the > expand mechanism as instrument for breaking up higher level ideal nodes into low > level mach nodes allowing optimizer and scheduler to work effectively. > > But you are certainly right. Compound nodes make a developer's life easier, plus > even in a micro benchmark, the performance advantage of the version with the > expand would be, at most, minimal anyway. And I've noticed, that the other bit > intrinsics are compound nodes, too. So I've prepared another webrev with the > macroassembler solution: > > http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_03/ > > But just in case you want to give the expand a chance: I've prepared a 4th > webrev using one of the forms Dean suggested. This version doesn't produce a > long value. Maybe you like it: > > http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_04/ > > I trust you'll select the best version :) > > Thanks, > Richard. > > -----Original Message----- > From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Freitag, 14. Dezember 2012 18:24 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 > > On 12/14/12 8:48 AM, Reingruber, Richard wrote: >> Thanks, Vladimir and Chris, for your reviews and the bug id. >> >> > It would seem easier to just write two assembler instructions instead of using expand. >> >> That's what I did first, and it was easier ;) >> >> > Is there a particular reason you are using expand? >> >> With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. >> >> Is there a reason _not_ to use the expand? > > It is harder to understand what instruction does and follow when > debugging a problem. Yes, it could be scheduled separately but it > hit-and-miss. Also your code uses an additional (long) register which we > should avoid. Adding 0xffffff immediate further complicated the code. > > We use expand rules if we need to use the same sequence of few > instructions in several mach nodes. Or historically because we used > emit_data() complicated encoding before. After we switched to > macroassembler instructions we are trying to avoid expand encoding. > > Thanks, > Vladimir > >> >> And here's the webrev updated with the bug id: >> >> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_02/ >> >> Cheers, Richard. >> >> -----Original Message----- >> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: Donnerstag, 13. Dezember 2012 20:48 >> To: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >> >> We should use macroassembler instructions and we have special >> instruction to clear upper half: >> >> ins_encode %{ >> __ clruwu($src$$Register); >> __ popc($src$$Register, $dst$$Register); >> %} >> >> Vladimir >> >> On 12/13/12 10:46 AM, Christian Thalinger wrote: >>> >>> On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: >>> >>>> Hi, >>>> >>>> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >>>> >>>> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >>>> >>>> I have prepared a small webrev with the suggested fix and a regression test: >>>> >>>> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >>>> >>>> Could you please review the patch and create a bug id? Thanks! >>> >>> Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: >>> >>> 8005033: clear high word for integer pop count on SPARC >>> >>> It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? >>> >>> -- Chris >>> >>>> >>>> Cheers, >>>> Richard. >>>> >>>> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >>>> >>> From vladimir.kozlov at oracle.com Mon Dec 17 13:44:59 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Dec 2012 13:44:59 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: References: <50CA310B.4030701@oracle.com> <50CB6093.3020409@oracle.com> <1138AC48-E44A-4610-8A82-0B8100AD2B20@oracle.com> Message-ID: <50CF925B.4080109@oracle.com> On 12/17/12 11:10 AM, Christian Thalinger wrote: > > On Dec 17, 2012, at 10:51 AM, Christian Thalinger wrote: > >> >> On Dec 17, 2012, at 9:36 AM, "Reingruber, Richard" wrote: >> >>>> We use expand rules if we need to use the same sequence of few instructions >>>> in several mach nodes. Or historically because we used emit_data() >>>> complicated encoding before. After we switched to macroassembler >>>> instructions we are trying to avoid expand encoding. >>> >>> I've discussed this as well with my colleagues. We've always understood the >>> expand mechanism as instrument for breaking up higher level ideal nodes into low >>> level mach nodes allowing optimizer and scheduler to work effectively. >>> >>> But you are certainly right. Compound nodes make a developer's life easier, plus >>> even in a micro benchmark, the performance advantage of the version with the >>> expand would be, at most, minimal anyway. And I've noticed, that the other bit >>> intrinsics are compound nodes, too. So I've prepared another webrev with the >>> macroassembler solution: >>> >>> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_03/ > > Oh, and the src register is destroyed in that changes. The shifted value needs to end up in dst: Only upper 32-bit are zeroed so it does not matter since the register's value is integer. But your suggestion better and I am also thinking we should use iRegIsafe for destination register in all bit counting mach nodes. Context switch may put garbage back into upper half. Vladimir > > http://cr.openjdk.java.net/~twisti/8005033/ > > -- Chris > >>> >>> But just in case you want to give the expand a chance: I've prepared a 4th >>> webrev using one of the forms Dean suggested. This version doesn't produce a >>> long value. Maybe you like it: >>> >>> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_04/ >>> >>> I trust you'll select the best version :) >> >> I will pick the first one. But I would like to use SRL directly instead of clruwu because the clr macro assembler instructions are not used right now: >> >> $ grep -r clruw src/cpu/sparc/vm/ >> src/cpu/sparc/vm/macroAssembler_sparc.hpp: inline void clruw( Register s, Register d ) { srl( s, G0, d); } >> src/cpu/sparc/vm/macroAssembler_sparc.hpp: inline void clruwu( Register d ) { srl( d, G0, d); } >> >> And in the near future I'd like to get rid of the format %{ %} blocks and have the instructions emit the format themselves. Then a CLRUWU would print SRL anyway. > >> >> -- Chris >> >>> >>> Thanks, >>> Richard. >>> >>> -----Original Message----- >>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>> Sent: Freitag, 14. Dezember 2012 18:24 >>> To: hotspot-compiler-dev at openjdk.java.net >>> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >>> >>> On 12/14/12 8:48 AM, Reingruber, Richard wrote: >>>> Thanks, Vladimir and Chris, for your reviews and the bug id. >>>> >>>>> It would seem easier to just write two assembler instructions instead of using expand. >>>> >>>> That's what I did first, and it was easier ;) >>>> >>>>> Is there a particular reason you are using expand? >>>> >>>> With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. >>>> >>>> Is there a reason _not_ to use the expand? >>> >>> It is harder to understand what instruction does and follow when >>> debugging a problem. Yes, it could be scheduled separately but it >>> hit-and-miss. Also your code uses an additional (long) register which we >>> should avoid. Adding 0xffffff immediate further complicated the code. >>> >>> We use expand rules if we need to use the same sequence of few >>> instructions in several mach nodes. Or historically because we used >>> emit_data() complicated encoding before. After we switched to >>> macroassembler instructions we are trying to avoid expand encoding. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> And here's the webrev updated with the bug id: >>>> >>>> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_02/ >>>> >>>> Cheers, Richard. >>>> >>>> -----Original Message----- >>>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>>> Sent: Donnerstag, 13. Dezember 2012 20:48 >>>> To: hotspot-compiler-dev at openjdk.java.net >>>> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >>>> >>>> We should use macroassembler instructions and we have special >>>> instruction to clear upper half: >>>> >>>> ins_encode %{ >>>> __ clruwu($src$$Register); >>>> __ popc($src$$Register, $dst$$Register); >>>> %} >>>> >>>> Vladimir >>>> >>>> On 12/13/12 10:46 AM, Christian Thalinger wrote: >>>>> >>>>> On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >>>>>> >>>>>> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >>>>>> >>>>>> I have prepared a small webrev with the suggested fix and a regression test: >>>>>> >>>>>> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >>>>>> >>>>>> Could you please review the patch and create a bug id? Thanks! >>>>> >>>>> Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: >>>>> >>>>> 8005033: clear high word for integer pop count on SPARC >>>>> >>>>> It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> Cheers, >>>>>> Richard. >>>>>> >>>>>> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >>>>>> >>>>> >> > From christian.thalinger at oracle.com Mon Dec 17 13:46:43 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 17 Dec 2012 21:46:43 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004548: remove unused AbstractAssembler::print(Label&) Message-ID: <20121217214647.A698E471F6@hg.openjdk.java.net> Changeset: 18d56ca3e901 Author: twisti Date: 2012-12-17 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/18d56ca3e901 8004548: remove unused AbstractAssembler::print(Label&) Reviewed-by: kvn, twisti Contributed-by: Bharadwaj Yadavalli ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp From christian.thalinger at oracle.com Mon Dec 17 17:39:09 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Dec 2012 17:39:09 -0800 Subject: Request for reviews (S): 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 In-Reply-To: <46FEE692-97B7-43A8-89FD-4A409768DB4A@oracle.com> References: <50CA3755.8050303@oracle.com> <46FEE692-97B7-43A8-89FD-4A409768DB4A@oracle.com> Message-ID: On Dec 13, 2012, at 4:02 PM, Christian Thalinger wrote: > Looks good. -- Chris Actually not: $ ack -a emit_byte src/ src/cpu/x86/vm/macroAssembler_x86.cpp 1026: emit_byte(0xC9); // LEAVE 2115: emit_byte(0x26); // es: 2116: emit_byte(0x2e); // cs: 2117: emit_byte(0x64); // fs: 2118: emit_byte(0x65); // gs: 2119: emit_byte(0x90); 2537: emit_byte(0x70 | cc); 2538: emit_byte((offs - short_size) & 0xFF); 2541: emit_byte(0x0F); 2542: emit_byte(0x80 | cc); src/cpu/zero/vm/assembler_zero.cpp 61: emit_byte(AbstractAssembler::code_fill_byte()); src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp 119: emit_byte (segment); 128: emit_byte (segment); src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp 33: emit_byte(0xCC); -- Chris > > On Dec 13, 2012, at 12:15 PM, Morris Meyer wrote: > >> Folks, >> >> Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. >> >> Thanks in advance, >> >> --morris meyer >> >> WEBREV - http://cr.openjdk.java.net/~twisti/8004250/ > From john.r.rose at oracle.com Mon Dec 17 17:39:10 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 17 Dec 2012 17:39:10 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: <0958C9F9-56A5-4915-BD60-EC190BA5515B@oracle.com> References: <50CA310B.4030701@oracle.com> <50CB6093.3020409@oracle.com> <0958C9F9-56A5-4915-BD60-EC190BA5515B@oracle.com> Message-ID: On Dec 14, 2012, at 6:03 PM, David Chase wrote: > There is also the possibility of a peephole-ish optimization (that can be informed by general flow analysis) that keeps track of zero bits in a word -- for instance, if the source of the data was a LDUW, there's no need to clear the bits. We do some really hacky stuff in that vein; see the flag SparcV9RegsHiBitsZero. The bug 8001436 requests a less hacky infrastructure for doing bitwise type propagation. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001436 ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121217/c8b65e7c/attachment.html From christian.thalinger at oracle.com Mon Dec 17 17:47:17 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Dec 2012 17:47:17 -0800 Subject: Virtual dispatch bug in 292 impl In-Reply-To: References: Message-ID: <62ECFA9C-7CBC-444B-8038-357F19C00289@oracle.com> On Dec 16, 2012, at 11:55 AM, Charles Oliver Nutter wrote: > I wasn't sure if this had been filed already by Christian, so I wanted > to post here. > > It appears that in C1, method handles are not properly dispatching to > an overridden version of a method. My reproduction case is tied to > JRuby, but I can come up with something isolated if necessary. > > In JRuby, the ENV object is a subclass of a Ruby Hash. Rather than > rebinding all of Hash's methods (defined on org.jruby.RubyHash), the > ENV impl just overrides them at the Java level. When dispatching to > the [] method on ENV with invokedynamic, the handle points at > RubyHash.op_aref, the implementation of [] for Hash. The ENV version > should raise an error...but it does not, because it dispatches to the > superclass version rather than the subclass version. > > If I turn off tiered compilation, the code works as expected. > > Reproduction for JRuby is here: https://gist.github.com/4311979 > > I tested on hotspot-comp built yesterday: > > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-headius_2012_12_15_16_45-b00) > OpenJDK 64-Bit Server VM (build 25.0-b13, mixed mode) > > If I have time I'll try to investigate in more depth. This is really odd. I've fixed a similar bug some time ago: https://jbs.oracle.com/bugs/browse/JDK-8000821 http://bugs.sun.com/view_bug.do?bug_id=8000821 And there is currently a bug with Nashorn that sounds like the same issue. Is it intermittent? Are you able to reproduce with TieredStopAtLevel=1? -- Chris > > - Charlie From suenaga.yasumasa at lab.ntt.co.jp Mon Dec 17 20:29:08 2012 From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga) Date: Tue, 18 Dec 2012 13:29:08 +0900 Subject: Request for reviews (M): 8004835: Improve AES intrinsics on x86 In-Reply-To: <50CF8620.7060309@oracle.com> References: <50CCF501.7060409@oracle.com> <50CE6F0D.2050003@lab.ntt.co.jp> <50CF8620.7060309@oracle.com> Message-ID: <50CFF114.30708@lab.ntt.co.jp> Hi Vladimir, Thank you for the explanation. I've not read 319433-014.pdf . Thanks, Yasumasa On 2012/12/18 5:52, Vladimir Kozlov wrote: > Hi, Yasumasa > > Thank you for looking on changes. > > On 12/16/12 5:02 PM, Yasumasa Suenaga wrote: >> Hi Vladimir, >> >> Source operand of Assembler::pshufb() seems to allow misaligned memory >> address. > > I assume you mean "to NOT allow" otherwise you statement contradict the quote. > >> Instruction reference of PSHUFB says following: >> >> ---------- >> When the source operand is a 128-bit memory operand, the operand must be >> aligned >> on a 16-byte boundary or a general-protection exception (#GP) will be >> generated. >> ---------- >> >> Not only non-AVX but also AVX CPU needs 16-byte aligned memory address >> for source >> operand of PSHUFB. > > It is not true. It depends how you encode instructions when AVX available. Hotspot use VEX prefix in such case with which alignment is not required (2.5): > > http://software.intel.com/sites/default/files/319433-014.pdf > > (v)pshufb is "Type 4" exception class instruction (Table 2-7). For such instructions only legacy SSE encoded (REX prefix) instructions cause #GP exception with unaligned memory (Table 2-13). Note, in 325383.pdf corresponding tables are 2-14 and 2-20. > > Thanks, > Vladimir > >> So I think that assert condition for AVX does not required in >> Assembler::pshufb() . >> >> http://download.intel.com/products/processor/manual/325383.pdf >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2012/12/16 7:09, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/8004835/webrev/ >>> >>> Enable AES intrinsics on non-AVX cpus (Westmere), pshufb instruction >>> in load_key() method could be used without AVX because it references >>> only aligned memory "key_shuffle_mask". >>> >>> Group together aes instructions in encryptBlock/decryptBlock stubs as >>> recommended by Intel Optimization Guide. >>> >>> Modified test/compiler/7184394 to test "ECB" mode. >>> >>> Ran compiler regression tests and jdk crypto and security tests with >>> SunJCE default provider. >>> >>> Thanks, >>> Vladimir From roland.westrelin at oracle.com Tue Dec 18 08:15:42 2012 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Tue, 18 Dec 2012 16:15:42 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005031: Some cleanup in c2 to prepare for incremental inlining support Message-ID: <20121218161545.0B29747222@hg.openjdk.java.net> Changeset: ad5dd04754ee Author: roland Date: 2012-12-18 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ad5dd04754ee 8005031: Some cleanup in c2 to prepare for incremental inlining support Summary: collection of small changes to prepare for incremental inlining. Reviewed-by: twisti, kvn ! src/share/vm/ci/ciField.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/stringopts.cpp From aleksey.shipilev at oracle.com Tue Dec 18 08:51:38 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 18 Dec 2012 20:51:38 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <74CE271C-D05F-4DFF-BD97-0C0E8B4A3C57@oracle.com> References: <50BD25B0.2060501@oracle.com> <50BE5357.60601@oracle.com> <50BE5A4D.2010400@oracle.com> <50BE5F78.6030608@oracle.com> <50BE6237.80100@cs.oswego.edu> <74CE271C-D05F-4DFF-BD97-0C0E8B4A3C57@oracle.com> Message-ID: <50D09F1A.3000600@oracle.com> Anyone? :) On 12/05/2012 01:12 AM, Christian Thalinger wrote: > On Dec 4, 2012, at 12:51 PM, Doug Lea
wrote: >> On 12/04/12 15:39, Vladimir Kozlov wrote: >>> Yes, this is good. We will select a sponsor for you to push this. >> >>>> This one is better? >>>> http://shipilev.net/pub/jdk/hotspot/fences/webrev-3/ -Aleksey. From richard.reingruber at sap.com Tue Dec 18 09:02:44 2012 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 18 Dec 2012 18:02:44 +0100 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: <50CF909D.3030309@oracle.com> References: <50CA310B.4030701@oracle.com> <50CB6093.3020409@oracle.com> <50CF909D.3030309@oracle.com> Message-ID: > I will take first one :) I thought so. Btw: for our platform ports we've got expand rules for all the bit intrinsics :) > The second solution still use/kill additional tmp register. You may think > that not using tmp register "shrI_reg_imm5(src, src, zero_shift_amount)" > will give you the same result as macroassembler implementation. But it is > not true because RA will see that "shrI_" modifies "src" and will spill it > if there is an other use. Yes, this can happen, but it's only the worst case. Thanks, Richard. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Montag, 17. Dezember 2012 22:38 To: Reingruber, Richard Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 I will take first one :) The second solution still use/kill additional tmp register. You may think that not using tmp register "shrI_reg_imm5(src, src, zero_shift_amount)" will give you the same result as macroassembler implementation. But it is not true because RA will see that "shrI_" modifies "src" and will spill it if there is an other use. If we had more cases like this we would add new operand iRegIupper0 and mach instruction which does shrl r,0,r to produce it. And let Matcher do the rest. Thanks, Vladimir On 12/17/12 9:36 AM, Reingruber, Richard wrote: > > We use expand rules if we need to use the same sequence of few instructions > > in several mach nodes. Or historically because we used emit_data() > > complicated encoding before. After we switched to macroassembler > > instructions we are trying to avoid expand encoding. > > I've discussed this as well with my colleagues. We've always understood the > expand mechanism as instrument for breaking up higher level ideal nodes into low > level mach nodes allowing optimizer and scheduler to work effectively. > > But you are certainly right. Compound nodes make a developer's life easier, plus > even in a micro benchmark, the performance advantage of the version with the > expand would be, at most, minimal anyway. And I've noticed, that the other bit > intrinsics are compound nodes, too. So I've prepared another webrev with the > macroassembler solution: > > http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_03/ > > But just in case you want to give the expand a chance: I've prepared a 4th > webrev using one of the forms Dean suggested. This version doesn't produce a > long value. Maybe you like it: > > http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_04/ > > I trust you'll select the best version :) > > Thanks, > Richard. > > -----Original Message----- > From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Freitag, 14. Dezember 2012 18:24 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 > > On 12/14/12 8:48 AM, Reingruber, Richard wrote: >> Thanks, Vladimir and Chris, for your reviews and the bug id. >> >> > It would seem easier to just write two assembler instructions instead of using expand. >> >> That's what I did first, and it was easier ;) >> >> > Is there a particular reason you are using expand? >> >> With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. >> >> Is there a reason _not_ to use the expand? > > It is harder to understand what instruction does and follow when > debugging a problem. Yes, it could be scheduled separately but it > hit-and-miss. Also your code uses an additional (long) register which we > should avoid. Adding 0xffffff immediate further complicated the code. > > We use expand rules if we need to use the same sequence of few > instructions in several mach nodes. Or historically because we used > emit_data() complicated encoding before. After we switched to > macroassembler instructions we are trying to avoid expand encoding. > > Thanks, > Vladimir > >> >> And here's the webrev updated with the bug id: >> >> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_02/ >> >> Cheers, Richard. >> >> -----Original Message----- >> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: Donnerstag, 13. Dezember 2012 20:48 >> To: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >> >> We should use macroassembler instructions and we have special >> instruction to clear upper half: >> >> ins_encode %{ >> __ clruwu($src$$Register); >> __ popc($src$$Register, $dst$$Register); >> %} >> >> Vladimir >> >> On 12/13/12 10:46 AM, Christian Thalinger wrote: >>> >>> On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: >>> >>>> Hi, >>>> >>>> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >>>> >>>> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >>>> >>>> I have prepared a small webrev with the suggested fix and a regression test: >>>> >>>> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >>>> >>>> Could you please review the patch and create a bug id? Thanks! >>> >>> Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: >>> >>> 8005033: clear high word for integer pop count on SPARC >>> >>> It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? >>> >>> -- Chris >>> >>>> >>>> Cheers, >>>> Richard. >>>> >>>> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >>>> >>> From roland.westrelin at oracle.com Tue Dec 18 09:08:41 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 18 Dec 2012 18:08:41 +0100 Subject: Request for reviews (M): 8004835: Improve AES intrinsics on x86 In-Reply-To: <50CCF501.7060409@oracle.com> References: <50CCF501.7060409@oracle.com> Message-ID: > http://cr.openjdk.java.net/~kvn/8004835/webrev/ It looks good to me. Roland. From vladimir.x.ivanov at oracle.com Tue Dec 18 10:08:22 2012 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Tue, 18 Dec 2012 18:08:22 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20121218180826.546D847229@hg.openjdk.java.net> Changeset: eb409f2f146e Author: vlivanov Date: 2012-12-18 06:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eb409f2f146e 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop Summary: Make the load of TLS._osthread._interrupted flag in Thread.isInterrupted(Z)Z intrinsic effectively volatile. Reviewed-by: kvn, jrose ! src/share/vm/opto/library_call.cpp Changeset: 620e502e3f47 Author: vlivanov Date: 2012-12-18 08:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/620e502e3f47 Merge ! src/share/vm/opto/library_call.cpp From vladimir.kozlov at oracle.com Tue Dec 18 10:18:15 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Dec 2012 10:18:15 -0800 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50D09F1A.3000600@oracle.com> References: <50BD25B0.2060501@oracle.com> <50BE5357.60601@oracle.com> <50BE5A4D.2010400@oracle.com> <50BE5F78.6030608@oracle.com> <50BE6237.80100@cs.oswego.edu> <74CE271C-D05F-4DFF-BD97-0C0E8B4A3C57@oracle.com> <50D09F1A.3000600@oracle.com> Message-ID: <50D0B367.2080200@oracle.com> On 12/18/12 8:51 AM, Aleksey Shipilev wrote: > Anyone? :) You need to be more specific in your question. Did you finish discussion? Do all agree? I see that JEP is in funded state. Vladimir K. > > On 12/05/2012 01:12 AM, Christian Thalinger wrote: >> On Dec 4, 2012, at 12:51 PM, Doug Lea
wrote: >>> On 12/04/12 15:39, Vladimir Kozlov wrote: >>>> Yes, this is good. We will select a sponsor for you to push this. >>> >>>>> This one is better? >>>>> http://shipilev.net/pub/jdk/hotspot/fences/webrev-3/ > > -Aleksey. > From aleksey.shipilev at oracle.com Tue Dec 18 10:23:07 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 18 Dec 2012 22:23:07 +0400 Subject: RFR (S): CR 8004318/JEP 171 Fences intrinsics In-Reply-To: <50D0B367.2080200@oracle.com> References: <50BD25B0.2060501@oracle.com> <50BE5357.60601@oracle.com> <50BE5A4D.2010400@oracle.com> <50BE5F78.6030608@oracle.com> <50BE6237.80100@cs.oswego.edu> <74CE271C-D05F-4DFF-BD97-0C0E8B4A3C57@oracle.com> <50D09F1A.3000600@oracle.com> <50D0B367.2080200@oracle.com> Message-ID: <50D0B48B.5060704@oracle.com> On 12/18/2012 10:18 PM, Vladimir Kozlov wrote: > On 12/18/12 8:51 AM, Aleksey Shipilev wrote: >> Anyone? :) > > You need to be more specific in your question. > > Did you finish discussion? Do all agree? I see that JEP is in funded state. I think we are in the agreement (at this point the new round of bikeshedding should start). The code is there, everything set and ready. -Aleksey. From vladimir.kozlov at oracle.com Tue Dec 18 10:26:04 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Dec 2012 10:26:04 -0800 Subject: Request for reviews (M): 8004835: Improve AES intrinsics on x86 In-Reply-To: References: <50CCF501.7060409@oracle.com> Message-ID: <50D0B53C.5060709@oracle.com> Thank you, Roland Vladimir K. On 12/18/12 9:08 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/8004835/webrev/ > > It looks good to me. > > Roland. > From vladimir.kozlov at oracle.com Tue Dec 18 11:54:48 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Dec 2012 11:54:48 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> Message-ID: <50D0CA08.4000706@oracle.com> On 12/17/12 9:18 AM, Roland Westrelin wrote: > > Vladimir, > > Thanks for reviewing this. > >> Roland my main concern is GraphKit::kill_dead_call_outputs(). We avoiding such dead node elimination during paring since a graph may not complete and dominate information is not accurate. Can you bailout the round of later inlining if you detect such case and let PhaseRemoveUseless do cleanup for you? > > Let's say we have 2 calls in a method: > > A() > > B() > > A() dominates B(). During parsing, we build a complete graph with CallNodes for A() and B(). Let's say we decide to inline A() after parsing so we build a subgraph with A()'s inputs as inputs to parsing and then we replace B()'s outputs with the resulting new subgraph. I assume you mean "replace A()'s outputs". > > Now let's say A()'s outputs are dead and we try to inline B(). It depends on A()'s outputs but they are dead and often C2 will see an inconsistent state when it builds the subgraph for B(): control not top so it proceeds with inlining, but a MergedMem with some slices set to top or if B() uses the return from A(), top as an input. These lead to crashes. Top inputs should be processed correctly. If we crash, it indicates that we are missing checks for top inputs in some ideal nodes methods (Ideal(), Value()). Also kill_dead_call_outputs() works only if final_ctl->is_top() which contradict to your case. > > That doesn't happen with parse-time inlining because A()'s subgraph is built inside the main graph, all results from A()'s inlining are propagated forward to B() by the gvn, the input state for B() is consistent and we don't try to inlining B() because this is a dead path. We don't inline B() if control is top (stopped()). So it is the same situation as with kill_dead_call_outputs(). > > I don't think PhaseRemoveUseless helps in this case. What we would need in the case of post parse inlining would be to inline A(), apply an igvn to propagate the results from the inlining forward to B(), then inline B(). But even an igvn is not sufficient if for instance, B() is inside a loop. May be IGVN is not enough (it does not have deliminators information and works on small subgraphs) but PhaseIdealLoop can do that (it was the reason I called it before EA). Which brings the question: why you call PhaseIdealLoop only when live nodes reach limit? > > That's why I use GraphKit::kill_dead_call_outputs(). I don't understand why it's dangerous since it operates in well defined conditions. In the example above, we have a complete graph with a DirectCall to A(). We are done with parsing for A() and the subgraph for A() uses A()'s inputs but it is not yet connected to the rest of the graph by it's outputs. We want to find calls that A()'s control outputs dominate and we work on a complete graph, the subgraph for A() doesn't really matter. I don't see the big need for new "dead code cleanup" code when we have already several implementations. We may need to adjust them to work for your case (PhaseIdealLoop work without inner loops). Thanks, Vladimir > >> The same about Compile::look_for_dead_calls(). Why you need this check if you do PhaseRemoveUseless? > > With CTW, I found some rare cases, where an igvn pass makes some path dead but similar to what I describe above the state at a call that we want to inline is not consistent. > > Roland. > From roland.westrelin at oracle.com Tue Dec 18 12:20:43 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 18 Dec 2012 21:20:43 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <50D0CA08.4000706@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> Message-ID: <397E1302-32FC-4673-9958-F9CDE18227F8@oracle.com> >> A() dominates B(). During parsing, we build a complete graph with CallNodes for A() and B(). Let's say we decide to inline A() after parsing so we build a subgraph with A()'s inputs as inputs to parsing and then we replace B()'s outputs with the resulting new subgraph. > > I assume you mean "replace A()'s outputs". I mean: we replace B()'s outputs with the outputs of the new subgraph. > Top inputs should be processed correctly. If we crash, it indicates that we are missing checks for top inputs in some ideal nodes methods (Ideal(), Value()). > > Also kill_dead_call_outputs() works only if final_ctl->is_top() which contradict to your case. > >> >> That doesn't happen with parse-time inlining because A()'s subgraph is built inside the main graph, all results from A()'s inlining are propagated forward to B() by the gvn, the input state for B() is consistent and we don't try to inlining B() because this is a dead path. > > We don't inline B() if control is top (stopped()). So it is the same situation as with kill_dead_call_outputs(). Let's say we have this: r = A() for () { B(r); } We inline A() and its outputs are dead if we move to B(), we'll see a non dead Region as control input, a non dead Phi as memory input and so we start inlining B but r is top and that confuses the parser. That's what I meant by inconsistent inputs and I found that would happen in many different ways if there's a lot of incremental inlining going on so it seemed to me that it makes more sense to clean the graph rather than make the parser robust to strange input states. >> I don't think PhaseRemoveUseless helps in this case. What we would need in the case of post parse inlining would be to inline A(), apply an igvn to propagate the results from the inlining forward to B(), then inline B(). But even an igvn is not sufficient if for instance, B() is inside a loop. > > May be IGVN is not enough (it does not have deliminators information and works on small subgraphs) but PhaseIdealLoop can do that (it was the reason I called it before EA). Which brings the question: why you call PhaseIdealLoop only when live nodes reach limit? Because I found it to be expensive when when we do a lot of inlining incrementally and we have to rebuild the CFG structures again and again so I tried to do it only once there's no more decrease in the graph size with IGVN. >> That's why I use GraphKit::kill_dead_call_outputs(). I don't understand why it's dangerous since it operates in well defined conditions. In the example above, we have a complete graph with a DirectCall to A(). We are done with parsing for A() and the subgraph for A() uses A()'s inputs but it is not yet connected to the rest of the graph by it's outputs. We want to find calls that A()'s control outputs dominate and we work on a complete graph, the subgraph for A() doesn't really matter. > > I don't see the big need for new "dead code cleanup" code when we have already several implementations. We may need to adjust them to work for your case (PhaseIdealLoop work without inner loops). I found PhaseIdeaLoop to be very expensive if we need to do a lot of it that's why I developed the custom clean up code that is triggered only along the dead outputs and that only works on the part of the graph that is being changed so it's less expensive and according to profiling I've done for the compiler threads when a lot of incremental inlining is happening, it's indeed no longer a bottleneck. Roland. From christian.thalinger at oracle.com Tue Dec 18 13:05:06 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 18 Dec 2012 21:05:06 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004536: replace AbstractAssembler emit_word with emit_int16 Message-ID: <20121218210509.50A4B4722F@hg.openjdk.java.net> Changeset: c4bd2eccea46 Author: twisti Date: 2012-12-18 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c4bd2eccea46 8004536: replace AbstractAssembler emit_word with emit_int16 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.hpp From vladimir.kozlov at oracle.com Tue Dec 18 19:41:13 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 19 Dec 2012 03:41:13 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004318: JEP-171: Support Unsafe fences intrinsics Message-ID: <20121219034118.2071747260@hg.openjdk.java.net> Changeset: 1e41b0bc58a0 Author: kvn Date: 2012-12-18 17:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1e41b0bc58a0 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/unsafe.cpp From aleksey.shipilev at oracle.com Tue Dec 18 23:34:34 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 19 Dec 2012 11:34:34 +0400 Subject: hg: hsx/hotspot-comp/hotspot: 8004318: JEP-171: Support Unsafe fences intrinsics In-Reply-To: <20121219034118.2071747260@hg.openjdk.java.net> References: <20121219034118.2071747260@hg.openjdk.java.net> Message-ID: <50D16E0A.7080101@oracle.com> Thanks! Only one attribution correction: Doug did most of the HotSpot work. On 12/19/2012 07:41 AM, vladimir.kozlov at oracle.com wrote: > Contributed-by: Aleksey Shipilev Contributed-by: dl, shade -Aleksey. From roland.westrelin at oracle.com Wed Dec 19 07:48:23 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 19 Dec 2012 16:48:23 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <50D0CA08.4000706@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> Message-ID: > I don't see the big need for new "dead code cleanup" code when we have already several implementations. We may need to adjust them to work for your case (PhaseIdealLoop work without inner loops). I tried doing a PhaseIdealLoop for every inlining and compilation time (as reported by CITime) on nashorn benchmarks doubled for several of them. This said, it doesn't seem to affect the peak performance of the benchmarks except for one maybe. But we're also not very aggressive in the inlining we do currently. I tried a CTW run with this change (with -XX:+AlwaysIncrementalInline: every inlining is done post parsing. That's how I've been stress testing things.) and there are several failures so it looks like if we decide to go that way, more time is required to get a clean run. Roland. From vladimir.kozlov at oracle.com Wed Dec 19 08:52:57 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Dec 2012 08:52:57 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> Message-ID: <50D1F0E9.4090002@oracle.com> Thank you, Roland, for checking this. While we are waiting Christian review, could you do some clean up in your changes? Remove IncrementalInlineAfterOpts flag since it is unused. Also may be IncrementalInlineOneByOne and AlwaysIncrementalInline flags because it looks like they were used just for experiment. But I don't see the flag which control new code usage. We should have one to be able switch new code totally OFF. MaxNodeLimit value should depend on that flag. Move whole later inlining loop into Incremental_Inline(igvn) to simplify code in Optimize(). Leave original igvn.optimize() call where it was before. In Incremental_Inline(igvn) do sequence: while(..) { if (needed) PhaseIdealLoop late inlining igvn } Add comment, explaining why you need low_live_nodes. bytecodeInfo.cpp: 213 if ( callee_method->should_inline()) { ^ remove space Move inlining_progress() up after clear_inlining_progress(): + void clear_inlining_progress() { _inlining_progress = false; } + int inlining_incrementally() const { return _inlining_incrementally; } + void set_inlining_incrementally() { _inlining_incrementally = true; } + int inlining_progress() const { return _inlining_progress; } I still don't like new dead code elimination code but with time constrain I may gave in. We should not crush without that code - and it should be fixed and not covered by this new code. Thanks, Vladimir On 12/19/12 7:48 AM, Roland Westrelin wrote: >> I don't see the big need for new "dead code cleanup" code when we have already several implementations. We may need to adjust them to work for your case (PhaseIdealLoop work without inner loops). > > > I tried doing a PhaseIdealLoop for every inlining and compilation time (as reported by CITime) on nashorn benchmarks doubled for several of them. This said, it doesn't seem to affect the peak performance of the benchmarks except for one maybe. But we're also not very aggressive in the inlining we do currently. > > I tried a CTW run with this change (with -XX:+AlwaysIncrementalInline: every inlining is done post parsing. That's how I've been stress testing things.) and there are several failures so it looks like if we decide to go that way, more time is required to get a clean run. > > Roland. > From roland.westrelin at oracle.com Wed Dec 19 09:31:59 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 19 Dec 2012 18:31:59 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <50D1F0E9.4090002@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> Message-ID: > While we are waiting Christian review, could you do some clean up in your changes? Sure. > Remove IncrementalInlineAfterOpts flag since it is unused. Also may be IncrementalInlineOneByOne and AlwaysIncrementalInline flags because it looks like they were used just for experiment. AlwaysIncrementalInline is useful for stress testing so I'd like to keep it. > But I don't see the flag which control new code usage. We should have one to be able switch new code totally OFF. MaxNodeLimit value should depend on that flag. -XX:LiveNodeCountInliningCutoff=0 turns the new code off but it doesn't adjust MaxNodeLimit. Do you think another flag is needed or checking for LiveNodeCountInliningCutoff=0 at startup and setting MaxNodeLimit to the former value is sufficient? > Move whole later inlining loop into Incremental_Inline(igvn) to simplify code in Optimize(). Leave original igvn.optimize() call where it was before. In Incremental_Inline(igvn) do sequence: > > while(..) { > if (needed) PhaseIdealLoop > late inlining > igvn > } Ok. > Add comment, explaining why you need low_live_nodes. Ok. > bytecodeInfo.cpp: > > 213 if ( callee_method->should_inline()) { > ^ remove space Ok. > Move inlining_progress() up after clear_inlining_progress(): > > + void clear_inlining_progress() { _inlining_progress = false; } > + int inlining_incrementally() const { return _inlining_incrementally; } > + void set_inlining_incrementally() { _inlining_incrementally = true; } > + int inlining_progress() const { return _inlining_progress; } Ok. > I still don't like new dead code elimination code but with time constrain I may gave in. We should not crush without that code - and it should be fixed and not covered by this new code. Ok. I welcome suggestions and I'll think about it more. Roland. From vladimir.kozlov at oracle.com Wed Dec 19 10:01:53 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Dec 2012 10:01:53 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> Message-ID: <50D20111.8000003@oracle.com> On 12/19/12 9:31 AM, Roland Westrelin wrote: >> While we are waiting Christian review, could you do some clean up in your changes? > > Sure. > >> Remove IncrementalInlineAfterOpts flag since it is unused. Also may be IncrementalInlineOneByOne and AlwaysIncrementalInline flags because it looks like they were used just for experiment. > > AlwaysIncrementalInline is useful for stress testing so I'd like to keep it. OK. > >> But I don't see the flag which control new code usage. We should have one to be able switch new code totally OFF. MaxNodeLimit value should depend on that flag. > > -XX:LiveNodeCountInliningCutoff=0 turns the new code off but it doesn't adjust MaxNodeLimit. Do you think another flag is needed or checking for LiveNodeCountInliningCutoff=0 at startup and setting MaxNodeLimit to the former value is sufficient? It is not obvious way. I would prefer separate product flag -XX:+IncrementalInline. Also verify that incremental inlining is off if we switch of all inlining -XX:-Inline. Thanks, Vladimir > >> Move whole later inlining loop into Incremental_Inline(igvn) to simplify code in Optimize(). Leave original igvn.optimize() call where it was before. In Incremental_Inline(igvn) do sequence: >> >> while(..) { >> if (needed) PhaseIdealLoop >> late inlining >> igvn >> } > > Ok. > >> Add comment, explaining why you need low_live_nodes. > > Ok. > >> bytecodeInfo.cpp: >> >> 213 if ( callee_method->should_inline()) { >> ^ remove space > > Ok. > >> Move inlining_progress() up after clear_inlining_progress(): >> >> + void clear_inlining_progress() { _inlining_progress = false; } >> + int inlining_incrementally() const { return _inlining_incrementally; } >> + void set_inlining_incrementally() { _inlining_incrementally = true; } >> + int inlining_progress() const { return _inlining_progress; } > > Ok. > >> I still don't like new dead code elimination code but with time constrain I may gave in. We should not crush without that code - and it should be fixed and not covered by this new code. > > Ok. I welcome suggestions and I'll think about it more. > > Roland. > From christian.thalinger at oracle.com Wed Dec 19 10:21:40 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 19 Dec 2012 10:21:40 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: <50CF925B.4080109@oracle.com> References: <50CA310B.4030701@oracle.com> <50CB6093.3020409@oracle.com> <1138AC48-E44A-4610-8A82-0B8100AD2B20@oracle.com> <50CF925B.4080109@oracle.com> Message-ID: <0EA2AE79-86F8-4465-AA44-94D5C1567199@oracle.com> On Dec 17, 2012, at 1:44 PM, Vladimir Kozlov wrote: > > > On 12/17/12 11:10 AM, Christian Thalinger wrote: >> >> On Dec 17, 2012, at 10:51 AM, Christian Thalinger wrote: >> >>> >>> On Dec 17, 2012, at 9:36 AM, "Reingruber, Richard" wrote: >>> >>>>> We use expand rules if we need to use the same sequence of few instructions >>>>> in several mach nodes. Or historically because we used emit_data() >>>>> complicated encoding before. After we switched to macroassembler >>>>> instructions we are trying to avoid expand encoding. >>>> >>>> I've discussed this as well with my colleagues. We've always understood the >>>> expand mechanism as instrument for breaking up higher level ideal nodes into low >>>> level mach nodes allowing optimizer and scheduler to work effectively. >>>> >>>> But you are certainly right. Compound nodes make a developer's life easier, plus >>>> even in a micro benchmark, the performance advantage of the version with the >>>> expand would be, at most, minimal anyway. And I've noticed, that the other bit >>>> intrinsics are compound nodes, too. So I've prepared another webrev with the >>>> macroassembler solution: >>>> >>>> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_03/ >> >> Oh, and the src register is destroyed in that changes. The shifted value needs to end up in dst: > > Only upper 32-bit are zeroed so it does not matter since the register's value is integer. But your suggestion better and I am also thinking we should use iRegIsafe for destination register in all bit counting mach nodes. Context switch may put garbage back into upper half. How about this: http://cr.openjdk.java.net/~twisti/8005033/ -- Chris > > Vladimir > >> >> http://cr.openjdk.java.net/~twisti/8005033/ >> >> -- Chris >> >>>> >>>> But just in case you want to give the expand a chance: I've prepared a 4th >>>> webrev using one of the forms Dean suggested. This version doesn't produce a >>>> long value. Maybe you like it: >>>> >>>> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_04/ >>>> >>>> I trust you'll select the best version :) >>> >>> I will pick the first one. But I would like to use SRL directly instead of clruwu because the clr macro assembler instructions are not used right now: >>> >>> $ grep -r clruw src/cpu/sparc/vm/ >>> src/cpu/sparc/vm/macroAssembler_sparc.hpp: inline void clruw( Register s, Register d ) { srl( s, G0, d); } >>> src/cpu/sparc/vm/macroAssembler_sparc.hpp: inline void clruwu( Register d ) { srl( d, G0, d); } >>> >>> And in the near future I'd like to get rid of the format %{ %} blocks and have the instructions emit the format themselves. Then a CLRUWU would print SRL anyway. >> >>> >>> -- Chris >>> >>>> >>>> Thanks, >>>> Richard. >>>> >>>> -----Original Message----- >>>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>>> Sent: Freitag, 14. Dezember 2012 18:24 >>>> To: hotspot-compiler-dev at openjdk.java.net >>>> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >>>> >>>> On 12/14/12 8:48 AM, Reingruber, Richard wrote: >>>>> Thanks, Vladimir and Chris, for your reviews and the bug id. >>>>> >>>>>> It would seem easier to just write two assembler instructions instead of using expand. >>>>> >>>>> That's what I did first, and it was easier ;) >>>>> >>>>>> Is there a particular reason you are using expand? >>>>> >>>>> With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. >>>>> >>>>> Is there a reason _not_ to use the expand? >>>> >>>> It is harder to understand what instruction does and follow when >>>> debugging a problem. Yes, it could be scheduled separately but it >>>> hit-and-miss. Also your code uses an additional (long) register which we >>>> should avoid. Adding 0xffffff immediate further complicated the code. >>>> >>>> We use expand rules if we need to use the same sequence of few >>>> instructions in several mach nodes. Or historically because we used >>>> emit_data() complicated encoding before. After we switched to >>>> macroassembler instructions we are trying to avoid expand encoding. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> And here's the webrev updated with the bug id: >>>>> >>>>> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_02/ >>>>> >>>>> Cheers, Richard. >>>>> >>>>> -----Original Message----- >>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>>>> Sent: Donnerstag, 13. Dezember 2012 20:48 >>>>> To: hotspot-compiler-dev at openjdk.java.net >>>>> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >>>>> >>>>> We should use macroassembler instructions and we have special >>>>> instruction to clear upper half: >>>>> >>>>> ins_encode %{ >>>>> __ clruwu($src$$Register); >>>>> __ popc($src$$Register, $dst$$Register); >>>>> %} >>>>> >>>>> Vladimir >>>>> >>>>> On 12/13/12 10:46 AM, Christian Thalinger wrote: >>>>>> >>>>>> On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >>>>>>> >>>>>>> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >>>>>>> >>>>>>> I have prepared a small webrev with the suggested fix and a regression test: >>>>>>> >>>>>>> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >>>>>>> >>>>>>> Could you please review the patch and create a bug id? Thanks! >>>>>> >>>>>> Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: >>>>>> >>>>>> 8005033: clear high word for integer pop count on SPARC >>>>>> >>>>>> It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Richard. >>>>>>> >>>>>>> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >>>>>>> >>>>>> >>> >> From vladimir.kozlov at oracle.com Wed Dec 19 10:27:47 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Dec 2012 10:27:47 -0800 Subject: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 In-Reply-To: <0EA2AE79-86F8-4465-AA44-94D5C1567199@oracle.com> References: <50CA310B.4030701@oracle.com> <50CB6093.3020409@oracle.com> <1138AC48-E44A-4610-8A82-0B8100AD2B20@oracle.com> <50CF925B.4080109@oracle.com> <0EA2AE79-86F8-4465-AA44-94D5C1567199@oracle.com> Message-ID: <50D20723.4000408@oracle.com> Good. Push it. Thanks, Vladimir On 12/19/12 10:21 AM, Christian Thalinger wrote: > > On Dec 17, 2012, at 1:44 PM, Vladimir Kozlov wrote: > >> >> >> On 12/17/12 11:10 AM, Christian Thalinger wrote: >>> >>> On Dec 17, 2012, at 10:51 AM, Christian Thalinger wrote: >>> >>>> >>>> On Dec 17, 2012, at 9:36 AM, "Reingruber, Richard" wrote: >>>> >>>>>> We use expand rules if we need to use the same sequence of few instructions >>>>>> in several mach nodes. Or historically because we used emit_data() >>>>>> complicated encoding before. After we switched to macroassembler >>>>>> instructions we are trying to avoid expand encoding. >>>>> >>>>> I've discussed this as well with my colleagues. We've always understood the >>>>> expand mechanism as instrument for breaking up higher level ideal nodes into low >>>>> level mach nodes allowing optimizer and scheduler to work effectively. >>>>> >>>>> But you are certainly right. Compound nodes make a developer's life easier, plus >>>>> even in a micro benchmark, the performance advantage of the version with the >>>>> expand would be, at most, minimal anyway. And I've noticed, that the other bit >>>>> intrinsics are compound nodes, too. So I've prepared another webrev with the >>>>> macroassembler solution: >>>>> >>>>> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_03/ >>> >>> Oh, and the src register is destroyed in that changes. The shifted value needs to end up in dst: >> >> Only upper 32-bit are zeroed so it does not matter since the register's value is integer. But your suggestion better and I am also thinking we should use iRegIsafe for destination register in all bit counting mach nodes. Context switch may put garbage back into upper half. > > How about this: > > http://cr.openjdk.java.net/~twisti/8005033/ > > -- Chris > >> >> Vladimir >> >>> >>> http://cr.openjdk.java.net/~twisti/8005033/ >>> >>> -- Chris >>> >>>>> >>>>> But just in case you want to give the expand a chance: I've prepared a 4th >>>>> webrev using one of the forms Dean suggested. This version doesn't produce a >>>>> long value. Maybe you like it: >>>>> >>>>> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_04/ >>>>> >>>>> I trust you'll select the best version :) >>>> >>>> I will pick the first one. But I would like to use SRL directly instead of clruwu because the clr macro assembler instructions are not used right now: >>>> >>>> $ grep -r clruw src/cpu/sparc/vm/ >>>> src/cpu/sparc/vm/macroAssembler_sparc.hpp: inline void clruw( Register s, Register d ) { srl( s, G0, d); } >>>> src/cpu/sparc/vm/macroAssembler_sparc.hpp: inline void clruwu( Register d ) { srl( d, G0, d); } >>>> >>>> And in the near future I'd like to get rid of the format %{ %} blocks and have the instructions emit the format themselves. Then a CLRUWU would print SRL anyway. >>> >>>> >>>> -- Chris >>>> >>>>> >>>>> Thanks, >>>>> Richard. >>>>> >>>>> -----Original Message----- >>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>>>> Sent: Freitag, 14. Dezember 2012 18:24 >>>>> To: hotspot-compiler-dev at openjdk.java.net >>>>> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >>>>> >>>>> On 12/14/12 8:48 AM, Reingruber, Richard wrote: >>>>>> Thanks, Vladimir and Chris, for your reviews and the bug id. >>>>>> >>>>>>> It would seem easier to just write two assembler instructions instead of using expand. >>>>>> >>>>>> That's what I did first, and it was easier ;) >>>>>> >>>>>>> Is there a particular reason you are using expand? >>>>>> >>>>>> With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block. >>>>>> >>>>>> Is there a reason _not_ to use the expand? >>>>> >>>>> It is harder to understand what instruction does and follow when >>>>> debugging a problem. Yes, it could be scheduled separately but it >>>>> hit-and-miss. Also your code uses an additional (long) register which we >>>>> should avoid. Adding 0xffffff immediate further complicated the code. >>>>> >>>>> We use expand rules if we need to use the same sequence of few >>>>> instructions in several mach nodes. Or historically because we used >>>>> emit_data() complicated encoding before. After we switched to >>>>> macroassembler instructions we are trying to avoid expand encoding. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> And here's the webrev updated with the bug id: >>>>>> >>>>>> http://www.sapjvm.com/rr/webrevs/8005033_bitCount_intrinsic_sparc_02/ >>>>>> >>>>>> Cheers, Richard. >>>>>> >>>>>> -----Original Message----- >>>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>>>>> Sent: Donnerstag, 13. Dezember 2012 20:48 >>>>>> To: hotspot-compiler-dev at openjdk.java.net >>>>>> Subject: Re: RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9 >>>>>> >>>>>> We should use macroassembler instructions and we have special >>>>>> instruction to clear upper half: >>>>>> >>>>>> ins_encode %{ >>>>>> __ clruwu($src$$Register); >>>>>> __ popc($src$$Register, $dst$$Register); >>>>>> %} >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 12/13/12 10:46 AM, Christian Thalinger wrote: >>>>>>> >>>>>>> On Dec 13, 2012, at 9:09 AM, "Reingruber, Richard" wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I would like to submit a bugfix for C2's Integer.bitCount() intrinsic on sparcv9. >>>>>>>> >>>>>>>> On sparcv9, the C2 intrinsic for Integer.bitCount() is a POPC instruction. POPC operates on the whole register, including the high word, but for Integer.bitCount(), this is not correct, because the value of the high word is undefined. There could be bits set as a result of an int overflow or from a shift operation for example. Of course the bits in the high word have to be ignored for Integer.bitCount(). >>>>>>>> >>>>>>>> I have prepared a small webrev with the suggested fix and a regression test: >>>>>>>> >>>>>>>> http://www.sapjvm.com/rr/webrevs/bitCount_intrinsic_sparc_01/ >>>>>>>> >>>>>>>> Could you please review the patch and create a bug id? Thanks! >>>>>>> >>>>>>> Thanks for contributing this patch. I added these instructions so I'll take care of it. Here is the bug: >>>>>>> >>>>>>> 8005033: clear high word for integer pop count on SPARC >>>>>>> >>>>>>> It would seem easier to just write two assembler instructions instead of using expand. Is there a particular reason you are using expand? >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Richard. >>>>>>>> >>>>>>>> BTW: my name is Richard Reingruber, and I'm working as an engineer in the JIT team at SAP in Germany. This is my first posting, so a minimal introduction is probably appropriate :) >>>>>>>> >>>>>>> >>>> >>> > From christian.thalinger at oracle.com Wed Dec 19 10:50:17 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 19 Dec 2012 10:50:17 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <50D20111.8000003@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> Message-ID: On Dec 19, 2012, at 10:01 AM, Vladimir Kozlov wrote: > On 12/19/12 9:31 AM, Roland Westrelin wrote: >>> While we are waiting Christian review, could you do some clean up in your changes? >> >> Sure. src/share/vm/opto/bytecodeInfo.cpp: - if (callee_method->force_inline() || callee_method->should_inline()) { + if ( callee_method->should_inline()) { Are ForceInline methods always inlined after this change? Because there are more checks after that line. I'm not so happy with your additional boolean arguments: delay no_late not_const We probably can't live without them (can we?) but more meaningful names would be good. src/share/vm/opto/compile.cpp: + // clean up the late inline lists + for (int j = 0; j < 2; j++) { + int shift = 0; + GrowableArray* inlines = j == 0 ? &_string_late_inlines : &_late_inlines; Why 2? Maybe you should move that loop into a method and call it with the arrays as an argument. src/share/vm/opto/compile.hpp: + uint _nb_mh_late; // number of method handle late inlining still pending Usually we have a _nof prefix for "number of" but can't we just call it like that? + uint _number_of_mh_late_inlines; // number of method handle late inlining still pending I don't like these abbreviations. + void Incremental_Inline(PhaseIterGVN& igvn, bool eager = false); + void String_Inline(bool parse_time); Let's not add new camel-case methods. -- Chris >> >>> Remove IncrementalInlineAfterOpts flag since it is unused. Also may be IncrementalInlineOneByOne and AlwaysIncrementalInline flags because it looks like they were used just for experiment. >> >> AlwaysIncrementalInline is useful for stress testing so I'd like to keep it. > > OK. > >> >>> But I don't see the flag which control new code usage. We should have one to be able switch new code totally OFF. MaxNodeLimit value should depend on that flag. >> >> -XX:LiveNodeCountInliningCutoff=0 turns the new code off but it doesn't adjust MaxNodeLimit. Do you think another flag is needed or checking for LiveNodeCountInliningCutoff=0 at startup and setting MaxNodeLimit to the former value is sufficient? > > It is not obvious way. I would prefer separate product flag -XX:+IncrementalInline. Also verify that incremental inlining is off if we switch of all inlining -XX:-Inline. > > Thanks, > Vladimir > >> >>> Move whole later inlining loop into Incremental_Inline(igvn) to simplify code in Optimize(). Leave original igvn.optimize() call where it was before. In Incremental_Inline(igvn) do sequence: >>> >>> while(..) { >>> if (needed) PhaseIdealLoop >>> late inlining >>> igvn >>> } >> >> Ok. >> >>> Add comment, explaining why you need low_live_nodes. >> >> Ok. >> >>> bytecodeInfo.cpp: >>> >>> 213 if ( callee_method->should_inline()) { >>> ^ remove space >> >> Ok. >> >>> Move inlining_progress() up after clear_inlining_progress(): >>> >>> + void clear_inlining_progress() { _inlining_progress = false; } >>> + int inlining_incrementally() const { return _inlining_incrementally; } >>> + void set_inlining_incrementally() { _inlining_incrementally = true; } >>> + int inlining_progress() const { return _inlining_progress; } >> >> Ok. >> >>> I still don't like new dead code elimination code but with time constrain I may gave in. We should not crush without that code - and it should be fixed and not covered by this new code. >> >> Ok. I welcome suggestions and I'll think about it more. >> >> Roland. >> From christian.thalinger at oracle.com Wed Dec 19 14:21:08 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 19 Dec 2012 14:21:08 -0800 Subject: Request for reviews (M): 8004835: Improve AES intrinsics on x86 In-Reply-To: <50CCF501.7060409@oracle.com> References: <50CCF501.7060409@oracle.com> Message-ID: <7DFFDE30-613B-404B-8311-4C0CECF0DD11@oracle.com> On Dec 15, 2012, at 2:09 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8004835/webrev/ > > Enable AES intrinsics on non-AVX cpus (Westmere), pshufb instruction in load_key() method could be used without AVX because it references only aligned memory "key_shuffle_mask". > > Group together aes instructions in encryptBlock/decryptBlock stubs as recommended by Intel Optimization Guide. > > Modified test/compiler/7184394 to test "ECB" mode. > > Ran compiler regression tests and jdk crypto and security tests with SunJCE default provider. src/cpu/x86/vm/assembler_x86.cpp: ! void Assembler::pshufb(XMMRegister dst, Address src, bool aligned_adr) { assert(VM_Version::supports_ssse3(), ""); ! assert((UseAVX > 0) || aligned_adr, "SSE mode requires address alignment 16 bytes"); Can we move that assert up into the MacroAssembler? We should try to keep the Assembler as clean as possible if we want to generate it in the future. Otherwise this looks good. -- Chris > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Dec 19 14:32:14 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Dec 2012 14:32:14 -0800 Subject: Request for reviews (M): 8004835: Improve AES intrinsics on x86 In-Reply-To: <7DFFDE30-613B-404B-8311-4C0CECF0DD11@oracle.com> References: <50CCF501.7060409@oracle.com> <7DFFDE30-613B-404B-8311-4C0CECF0DD11@oracle.com> Message-ID: <50D2406E.9020007@oracle.com> Thank you, Christian The MacroAssembler::pshufb() already has the same assert so I will just remove one from Assembler::pshufb(). Thanks, Vladimir On 12/19/12 2:21 PM, Christian Thalinger wrote: > > On Dec 15, 2012, at 2:09 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8004835/webrev/ >> >> Enable AES intrinsics on non-AVX cpus (Westmere), pshufb instruction in load_key() method could be used without AVX because it references only aligned memory "key_shuffle_mask". >> >> Group together aes instructions in encryptBlock/decryptBlock stubs as recommended by Intel Optimization Guide. >> >> Modified test/compiler/7184394 to test "ECB" mode. >> >> Ran compiler regression tests and jdk crypto and security tests with SunJCE default provider. > > src/cpu/x86/vm/assembler_x86.cpp: > > ! void Assembler::pshufb(XMMRegister dst, Address src, bool aligned_adr) { > assert(VM_Version::supports_ssse3(), ""); > ! assert((UseAVX > 0) || aligned_adr, "SSE mode requires address alignment 16 bytes"); > > Can we move that assert up into the MacroAssembler? We should try to keep the Assembler as clean as possible if we want to generate it in the future. > > Otherwise this looks good. > > -- Chris > >> >> Thanks, >> Vladimir > From christian.thalinger at oracle.com Wed Dec 19 18:53:28 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 20 Dec 2012 02:53:28 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005033: clear high word for integer pop count on SPARC Message-ID: <20121220025332.8ACF7472B7@hg.openjdk.java.net> Changeset: 65c8342f726a Author: twisti Date: 2012-12-19 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/65c8342f726a 8005033: clear high word for integer pop count on SPARC Reviewed-by: kvn, twisti Contributed-by: Richard Reingruber ! src/cpu/sparc/vm/sparc.ad + test/compiler/8005033/Test8005033.java From vladimir.kozlov at oracle.com Wed Dec 19 20:46:50 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 20 Dec 2012 04:46:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004835: Improve AES intrinsics on x86 Message-ID: <20121220044652.2E3E9472B9@hg.openjdk.java.net> Changeset: 2c7f594145dc Author: kvn Date: 2012-12-19 15:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2c7f594145dc 8004835: Improve AES intrinsics on x86 Summary: Enable AES intrinsics on non-AVX cpus, group together aes instructions in crypto stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! test/compiler/7184394/TestAESBase.java ! test/compiler/7184394/TestAESMain.java From vladimir.kozlov at oracle.com Wed Dec 19 22:52:56 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 20 Dec 2012 06:52:56 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004741: Missing compiled exception handle table entry for multidimensional array allocation Message-ID: <20121220065301.155E4472C1@hg.openjdk.java.net> Changeset: 2d6c433b1f38 Author: kvn Date: 2012-12-19 19:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2d6c433b1f38 8004741: Missing compiled exception handle table entry for multidimensional array allocation Summary: Added missing exception path for multidimensional array allocation and use Throwable type instead of OutOfMemoryError for allocation's exception. Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + test/compiler/8004741/Test8004741.java From aleksey.shipilev at oracle.com Thu Dec 20 05:08:07 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 20 Dec 2012 17:08:07 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50BF3144.4070404@oracle.com> References: <50BD2972.4090603@oracle.com> <50BD2ABB.30703@oracle.com> <50BF3144.4070404@oracle.com> Message-ID: <50D30DB7.4020701@oracle.com> Vladimir, Christian, Roland, anyone, can you please sponsor this trivial change? -Aleksey. On 12/05/2012 03:34 PM, Aleksey Shipilev wrote: > Friendly reminder to check this didn't fall into the trenches. > > -Aleksey. > > On 12/04/2012 02:42 AM, Aleksey Shipilev wrote: >> (I should have CC'ed Doug on this, doing now). >> >> -Aleksey. >> >> On 12/04/2012 02:36 AM, Aleksey Shipilev wrote: >>> (again, submitting on behalf of Doug Lea) >>> >>> Hi, >>> >>> This simple change is missing from recently committed CR 7023898. While >>> the VM support is there in Hotspot, no methods are exposed in Unsafe to >>> actually make use of those intrinsics. This is the webrev fixing that: >>> http://shipilev.net/pub/jdk/hotspot/unsafe-getandadd/webrev-1/ >>> >>> Testing: >>> - Built and tested in Linux x86_64 >>> - Doug had provided the AtomicIntegerV8 [1] version making use of this >>> new code, extensively tested on his platforms >>> - java-concurrency-torture [2] atomicity tests [3] are passed for >>> AtomicIntegerV8 on my and Doug's platforms >>> - no other testing is expected for this trivial change. >>> >>> I would need a sponsor to push this change. >>> >>> Thanks, >>> Aleksey. >>> >>> [1] >>> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/java/util/concurrent/atomic/AtomicIntegerV8.java >>> [2] https://github.com/shipilev/java-concurrency-torture/ >>> [3] >>> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java >>> >> From morris.meyer at oracle.com Thu Dec 20 05:45:01 2012 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 20 Dec 2012 08:45:01 -0500 Subject: Request for reviews (S): 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 In-Reply-To: References: <50CA3755.8050303@oracle.com> <46FEE692-97B7-43A8-89FD-4A409768DB4A@oracle.com> Message-ID: <50D3165D.9040204@oracle.com> Thanks for picking this up Christian. Here is the updated webrev that just passed its JPRT job. Thanks much, --morris WEBREV - http://javaweb.us.oracle.com/~mameyer/webrevs/02/JDK-8004250 On 12/17/12 8:39 PM, Christian Thalinger wrote: > On Dec 13, 2012, at 4:02 PM, Christian Thalinger wrote: > >> Looks good. -- Chris > Actually not: > > $ ack -a emit_byte src/ > src/cpu/x86/vm/macroAssembler_x86.cpp > 1026: emit_byte(0xC9); // LEAVE > 2115: emit_byte(0x26); // es: > 2116: emit_byte(0x2e); // cs: > 2117: emit_byte(0x64); // fs: > 2118: emit_byte(0x65); // gs: > 2119: emit_byte(0x90); > 2537: emit_byte(0x70 | cc); > 2538: emit_byte((offs - short_size) & 0xFF); > 2541: emit_byte(0x0F); > 2542: emit_byte(0x80 | cc); > > src/cpu/zero/vm/assembler_zero.cpp > 61: emit_byte(AbstractAssembler::code_fill_byte()); > > src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp > 119: emit_byte (segment); > 128: emit_byte (segment); > > src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp > 33: emit_byte(0xCC); > > -- Chris > >> On Dec 13, 2012, at 12:15 PM, Morris Meyer wrote: >> >>> Folks, >>> >>> Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. >>> >>> Thanks in advance, >>> >>> --morris meyer >>> >>> WEBREV -http://cr.openjdk.java.net/~twisti/8004250/ From vladimir.kozlov at oracle.com Thu Dec 20 08:25:17 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Dec 2012 08:25:17 -0800 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50D30DB7.4020701@oracle.com> References: <50BD2972.4090603@oracle.com> <50BD2ABB.30703@oracle.com> <50BF3144.4070404@oracle.com> <50D30DB7.4020701@oracle.com> Message-ID: <50D33BED.2080805@oracle.com> Hi Alan, Can we push it through our hotspot-main/jdk repo? I will send formal review into open today. Should I use core-libs-dev list for that? https://jbs.oracle.com/bugs/browse/JDK-8004330 http://shipilev.net/pub/jdk/hotspot/unsafe-getandadd/webrev-1/ As Aleksey pointed it is java side for Hotspot intrinsics we added some time ago: https://jbs.oracle.com/bugs/browse/JDK-7023898 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7eca5de9e0b6 Thanks, Vladimir On 12/20/12 5:08 AM, Aleksey Shipilev wrote: > Vladimir, Christian, Roland, anyone, can you please sponsor this trivial > change? > > -Aleksey. > > On 12/05/2012 03:34 PM, Aleksey Shipilev wrote: >> Friendly reminder to check this didn't fall into the trenches. >> >> -Aleksey. >> >> On 12/04/2012 02:42 AM, Aleksey Shipilev wrote: >>> (I should have CC'ed Doug on this, doing now). >>> >>> -Aleksey. >>> >>> On 12/04/2012 02:36 AM, Aleksey Shipilev wrote: >>>> (again, submitting on behalf of Doug Lea) >>>> >>>> Hi, >>>> >>>> This simple change is missing from recently committed CR 7023898. While >>>> the VM support is there in Hotspot, no methods are exposed in Unsafe to >>>> actually make use of those intrinsics. This is the webrev fixing that: >>>> http://shipilev.net/pub/jdk/hotspot/unsafe-getandadd/webrev-1/ >>>> >>>> Testing: >>>> - Built and tested in Linux x86_64 >>>> - Doug had provided the AtomicIntegerV8 [1] version making use of this >>>> new code, extensively tested on his platforms >>>> - java-concurrency-torture [2] atomicity tests [3] are passed for >>>> AtomicIntegerV8 on my and Doug's platforms >>>> - no other testing is expected for this trivial change. >>>> >>>> I would need a sponsor to push this change. >>>> >>>> Thanks, >>>> Aleksey. >>>> >>>> [1] >>>> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/java/util/concurrent/atomic/AtomicIntegerV8.java >>>> [2] https://github.com/shipilev/java-concurrency-torture/ >>>> [3] >>>> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java >>>> >>> > From aleksey.shipilev at oracle.com Thu Dec 20 08:38:26 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 20 Dec 2012 20:38:26 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50D33E26.10104@oracle.com> References: <50BD2972.4090603@oracle.com> <50BD2ABB.30703@oracle.com> <50BF3144.4070404@oracle.com> <50D30DB7.4020701@oracle.com> <50D33BED.2080805@oracle.com> <50D33E26.10104@oracle.com> Message-ID: <50D33F02.3090406@oracle.com> On 12/20/2012 08:34 PM, Alan Bateman wrote: > On 20/12/2012 16:25, Vladimir Kozlov wrote: > It would be nice to cc'ing core-libs-dev on the review. One little > comment is that it would be nice to have more complete javadoc, also > @since is useful. I can take care of that. Vladimir, do you want me to send the updated patch to corelib-dev once it's ready? -Aleksey. From vladimir.kozlov at oracle.com Thu Dec 20 09:10:55 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Dec 2012 09:10:55 -0800 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50D33F02.3090406@oracle.com> References: <50BD2972.4090603@oracle.com> <50BD2ABB.30703@oracle.com> <50BF3144.4070404@oracle.com> <50D30DB7.4020701@oracle.com> <50D33BED.2080805@oracle.com> <50D33E26.10104@oracle.com> <50D33F02.3090406@oracle.com> Message-ID: <50D3469F.9040505@oracle.com> Since it is for open webrev should be in cr.openjdk. Do you have OpenJDK id to do that? If not I will do it. An question about contributor: is only you or Doug also? Thanks, Vladimir On 12/20/12 8:38 AM, Aleksey Shipilev wrote: > On 12/20/2012 08:34 PM, Alan Bateman wrote: >> On 20/12/2012 16:25, Vladimir Kozlov wrote: >> It would be nice to cc'ing core-libs-dev on the review. One little >> comment is that it would be nice to have more complete javadoc, also >> @since is useful. > > I can take care of that. Vladimir, do you want me to send the updated > patch to corelib-dev once it's ready? > > -Aleksey. > From roland.westrelin at oracle.com Thu Dec 20 09:30:12 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 20 Dec 2012 18:30:12 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> Message-ID: Hi Christian, Thanks for the review. > src/share/vm/opto/bytecodeInfo.cpp: > > - if (callee_method->force_inline() || callee_method->should_inline()) { > + if ( callee_method->should_inline()) { > > Are ForceInline methods always inlined after this change? Because there are more checks after that line. Is there anything in the logic that you think can be a problem? > I'm not so happy with your additional boolean arguments: > > delay > no_late > not_const > > We probably can't live without them (can we?) but more meaningful names would be good. Ok. > > src/share/vm/opto/compile.cpp: > > + // clean up the late inline lists > + for (int j = 0; j < 2; j++) { > + int shift = 0; > + GrowableArray* inlines = j == 0 ? &_string_late_inlines : &_late_inlines; > > Why 2? Maybe you should move that loop into a method and call it with the arrays as an argument. Ok. > src/share/vm/opto/compile.hpp: > > + uint _nb_mh_late; // number of method handle late inlining still pending > > Usually we have a _nof prefix for "number of" but can't we just call it like that? > > + uint _number_of_mh_late_inlines; // number of method handle late inlining still pending > > I don't like these abbreviations. Ok. > + void Incremental_Inline(PhaseIterGVN& igvn, bool eager = false); > + void String_Inline(bool parse_time); > > Let's not add new camel-case methods. Ok. Roland. From vladimir.kozlov at oracle.com Thu Dec 20 10:44:22 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Dec 2012 10:44:22 -0800 Subject: Request for reviews (S): 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 In-Reply-To: <50D3165D.9040204@oracle.com> References: <50CA3755.8050303@oracle.com> <46FEE692-97B7-43A8-89FD-4A409768DB4A@oracle.com> <50D3165D.9040204@oracle.com> Message-ID: <50D35C86.1060901@oracle.com> Looks good. Vladimir On 12/20/12 5:45 AM, Morris Meyer wrote: > Thanks for picking this up Christian. > > Here is the updated webrev that just passed its JPRT job. > > Thanks much, > > --morris > > WEBREV - http://javaweb.us.oracle.com/~mameyer/webrevs/02/JDK-8004250 > > On 12/17/12 8:39 PM, Christian Thalinger wrote: >> On Dec 13, 2012, at 4:02 PM, Christian >> Thalinger wrote: >> >>> Looks good. -- Chris >> Actually not: >> >> $ ack -a emit_byte src/ >> src/cpu/x86/vm/macroAssembler_x86.cpp >> 1026: emit_byte(0xC9); // LEAVE >> 2115: emit_byte(0x26); // es: >> 2116: emit_byte(0x2e); // cs: >> 2117: emit_byte(0x64); // fs: >> 2118: emit_byte(0x65); // gs: >> 2119: emit_byte(0x90); >> 2537: emit_byte(0x70 | cc); >> 2538: emit_byte((offs - short_size) & 0xFF); >> 2541: emit_byte(0x0F); >> 2542: emit_byte(0x80 | cc); >> >> src/cpu/zero/vm/assembler_zero.cpp >> 61: emit_byte(AbstractAssembler::code_fill_byte()); >> >> src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp >> 119: emit_byte (segment); >> 128: emit_byte (segment); >> >> src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp >> 33: emit_byte(0xCC); >> >> -- Chris >> >>> On Dec 13, 2012, at 12:15 PM, Morris Meyer >>> wrote: >>> >>>> Folks, >>>> >>>> Could I get a review of this cleanup requested by Christian >>>> Thalinger? This has been tested on JPRT. >>>> >>>> Thanks in advance, >>>> >>>> --morris meyer >>>> >>>> WEBREV -http://cr.openjdk.java.net/~twisti/8004250/ > > From aleksey.shipilev at oracle.com Thu Dec 20 11:03:32 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 20 Dec 2012 23:03:32 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family Message-ID: <50D36104.8000701@oracle.com> Hi, Sorry for cross-list posting, but this change affects both HS and JDK. This simple change is missing from recently committed CR 7023898. While the VM support is there in Hotspot, no methods are exposed in Unsafe to actually make use of those intrinsics. This is the webrev fixing that: http://cr.openjdk.java.net/~shade/8004330/webrev.00/ It turns out the getAndSet intrinsics HotSpot are overloaded, which had deluged both Doug and me in the previous patch. These namings are inconsistent with other Unsafe intrinsic naming convention, so this change fixes that as well. Testing: - Built and tested in Linux x86_64 - java-concurrency-torture [1] atomicity tests are passed for AtomicIntegerV8 [2] and AtomicLongV8 [3] making use of those intrinsics on Linux x86_64 - running the java-concurrency-torture tests "-XX:+PrintInlining | grep Unsafe" tells all intrinsics have been successfully inlined - no other testing is expected for this trivial change. I would need a sponsor to push this. Thanks for your patience and reviews! Contributors: - dl: original patch, testing - shade: due diligence, messing with reviews, tests, and rebuilds -Aleksey. [1] https://github.com/shipilev/java-concurrency-torture/ [2] https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java [3] https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/longs/AtomicLongV8PairwiseTests.java From vladimir.kozlov at oracle.com Thu Dec 20 11:21:51 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Dec 2012 11:21:51 -0800 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50D36104.8000701@oracle.com> References: <50D36104.8000701@oracle.com> Message-ID: <50D3654F.2030106@oracle.com> Looks good for me. I will sponsor these changes after we get a review from JDK side. Thanks, Vladimir On 12/20/12 11:03 AM, Aleksey Shipilev wrote: > Hi, > > Sorry for cross-list posting, but this change affects both HS and JDK. > > This simple change is missing from recently committed CR 7023898. While > the VM support is there in Hotspot, no methods are exposed in Unsafe to > actually make use of those intrinsics. This is the webrev fixing that: > http://cr.openjdk.java.net/~shade/8004330/webrev.00/ > > It turns out the getAndSet intrinsics HotSpot are overloaded, which had > deluged both Doug and me in the previous patch. These namings are > inconsistent with other Unsafe intrinsic naming convention, so this > change fixes that as well. > > Testing: > - Built and tested in Linux x86_64 > - java-concurrency-torture [1] atomicity tests are passed for > AtomicIntegerV8 [2] and AtomicLongV8 [3] making use of those intrinsics > on Linux x86_64 > - running the java-concurrency-torture tests "-XX:+PrintInlining | > grep Unsafe" tells all intrinsics have been successfully inlined > - no other testing is expected for this trivial change. > > I would need a sponsor to push this. Thanks for your patience and reviews! > > Contributors: > - dl: original patch, testing > - shade: due diligence, messing with reviews, tests, and rebuilds > > -Aleksey. > > [1] https://github.com/shipilev/java-concurrency-torture/ > [2] > https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java > [3] > https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/longs/AtomicLongV8PairwiseTests.java > From christian.thalinger at oracle.com Thu Dec 20 11:31:52 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 20 Dec 2012 11:31:52 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> Message-ID: <7BA3B3D3-CF1A-4DEF-BF66-65DDD4C02797@oracle.com> On Dec 20, 2012, at 9:30 AM, Roland Westrelin wrote: > Hi Christian, > > Thanks for the review. > >> src/share/vm/opto/bytecodeInfo.cpp: >> >> - if (callee_method->force_inline() || callee_method->should_inline()) { >> + if ( callee_method->should_inline()) { >> >> Are ForceInline methods always inlined after this change? Because there are more checks after that line. > > Is there anything in the logic that you think can be a problem? Only this one: } else if (!callee_method->was_executed_more_than(MIN2(MinInliningThreshold, CompileThreshold >> 1))) { return "executed < MinInliningThreshold times"; } -- Chris > >> I'm not so happy with your additional boolean arguments: >> >> delay >> no_late >> not_const >> >> We probably can't live without them (can we?) but more meaningful names would be good. > > Ok. > >> >> src/share/vm/opto/compile.cpp: >> >> + // clean up the late inline lists >> + for (int j = 0; j < 2; j++) { >> + int shift = 0; >> + GrowableArray* inlines = j == 0 ? &_string_late_inlines : &_late_inlines; >> >> Why 2? Maybe you should move that loop into a method and call it with the arrays as an argument. > > Ok. > >> src/share/vm/opto/compile.hpp: >> >> + uint _nb_mh_late; // number of method handle late inlining still pending >> >> Usually we have a _nof prefix for "number of" but can't we just call it like that? >> >> + uint _number_of_mh_late_inlines; // number of method handle late inlining still pending >> >> I don't like these abbreviations. > > Ok. > >> + void Incremental_Inline(PhaseIterGVN& igvn, bool eager = false); >> + void String_Inline(bool parse_time); >> >> Let's not add new camel-case methods. > > Ok. > > Roland. > From christian.thalinger at oracle.com Thu Dec 20 11:37:28 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 20 Dec 2012 11:37:28 -0800 Subject: Request for reviews (S): 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 In-Reply-To: <50D3165D.9040204@oracle.com> References: <50CA3755.8050303@oracle.com> <46FEE692-97B7-43A8-89FD-4A409768DB4A@oracle.com> <50D3165D.9040204@oracle.com> Message-ID: <3CDAA29B-240C-4388-8777-608AA69D500B@oracle.com> Looks good. It's in the JPRT queue. -- Chris On Dec 20, 2012, at 5:45 AM, Morris Meyer wrote: > Thanks for picking this up Christian. > > Here is the updated webrev that just passed its JPRT job. > > Thanks much, > > --morris > > WEBREV - http://javaweb.us.oracle.com/~mameyer/webrevs/02/JDK-8004250 > > On 12/17/12 8:39 PM, Christian Thalinger wrote: >> On Dec 13, 2012, at 4:02 PM, Christian Thalinger wrote: >> >>> Looks good. -- Chris >> Actually not: >> >> $ ack -a emit_byte src/ >> src/cpu/x86/vm/macroAssembler_x86.cpp >> 1026: emit_byte(0xC9); // LEAVE >> 2115: emit_byte(0x26); // es: >> 2116: emit_byte(0x2e); // cs: >> 2117: emit_byte(0x64); // fs: >> 2118: emit_byte(0x65); // gs: >> 2119: emit_byte(0x90); >> 2537: emit_byte(0x70 | cc); >> 2538: emit_byte((offs - short_size) & 0xFF); >> 2541: emit_byte(0x0F); >> 2542: emit_byte(0x80 | cc); >> >> src/cpu/zero/vm/assembler_zero.cpp >> 61: emit_byte(AbstractAssembler::code_fill_byte()); >> >> src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp >> 119: emit_byte (segment); >> 128: emit_byte (segment); >> >> src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp >> 33: emit_byte(0xCC); >> >> -- Chris >> >>> On Dec 13, 2012, at 12:15 PM, Morris Meyer wrote: >>> >>>> Folks, >>>> >>>> Could I get a review of this cleanup requested by Christian Thalinger? This has been tested on JPRT. >>>> >>>> Thanks in advance, >>>> >>>> --morris meyer >>>> >>>> WEBREV -http://cr.openjdk.java.net/~twisti/8004250/ > > From roland.westrelin at oracle.com Thu Dec 20 11:34:52 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 20 Dec 2012 20:34:52 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> Message-ID: Here is a new webrev: http://cr.openjdk.java.net/~roland/8005031/webrev.01/ - I dropped the special purpose dead code elimination, made stricter checks of inputs when inlining incrementally, and now do one igvn for every successful inlining - I made a couple fixes to PhaseStringOpts so it works ok when it happens after all inlining - I took all suggestions that Vladimir and Christian made into account Roland. From vladimir.kozlov at oracle.com Thu Dec 20 12:24:16 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Dec 2012 12:24:16 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> Message-ID: <50D373F0.7030504@oracle.com> Roland, you sent link to wrong webrev. Is this correct one?: http://cr.openjdk.java.net/~roland/8005071/webrev.01/ I'm looking on it now. Thanks, Vladimir On 12/20/12 11:34 AM, Roland Westrelin wrote: > Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8005031/webrev.01/ > > - I dropped the special purpose dead code elimination, made stricter checks of inputs when inlining incrementally, and now do one igvn for every successful inlining > > - I made a couple fixes to PhaseStringOpts so it works ok when it happens after all inlining > > - I took all suggestions that Vladimir and Christian made into account > > Roland. > From roland.westrelin at oracle.com Thu Dec 20 12:56:39 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 20 Dec 2012 21:56:39 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <50D373F0.7030504@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> Message-ID: <0A270D29-40CF-410A-8921-62B655278AF8@oracle.com> > you sent link to wrong webrev. Is this correct one?: > > http://cr.openjdk.java.net/~roland/8005071/webrev.01/ Yes. Sorry. Roland. From vladimir.kozlov at oracle.com Thu Dec 20 15:40:54 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Dec 2012 15:40:54 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <50D373F0.7030504@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> Message-ID: <50D3A206.2010009@oracle.com> This is better. MaxNodeLimit value setting logic should be reversed: default is 65000 (as before) and if IncrementalInline is true set to 110000. cfgnode.cpp: We draw subgraph in comments vertically, not horizontally. has_unique_phi() does the same as your first part of try_clean_mem_phi(). Also use phi->as_Phi()->is_diamond_phi() instead of region's inputs checks. Don't use second loop, you only have 2 inputs to check so use in(3-i). compile.cpp: string_inline() - no need empty separating lines in while() loop. incremental_inline_one() - remove outer "{}", I don't see the need for them. No need empty separating lines in first loop. Thanks, Vladimir On 12/20/12 12:24 PM, Vladimir Kozlov wrote: > Roland, > > you sent link to wrong webrev. Is this correct one?: > > http://cr.openjdk.java.net/~roland/8005071/webrev.01/ > > I'm looking on it now. > > Thanks, > Vladimir > > On 12/20/12 11:34 AM, Roland Westrelin wrote: >> Here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8005031/webrev.01/ >> >> - I dropped the special purpose dead code elimination, made stricter >> checks of inputs when inlining incrementally, and now do one igvn for >> every successful inlining >> >> - I made a couple fixes to PhaseStringOpts so it works ok when it >> happens after all inlining >> >> - I took all suggestions that Vladimir and Christian made into account >> >> Roland. >> From vladimir.kozlov at oracle.com Thu Dec 20 17:56:15 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 21 Dec 2012 01:56:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004330: Add missing Unsafe entry points for addAndGet() family Message-ID: <20121221015617.D14A047318@hg.openjdk.java.net> Changeset: a46457045d66 Author: kvn Date: 2012-12-20 14:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a46457045d66 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Fix java names for getAndSet intrinsics Reviewed-by: kvn Contributed-by: aleksey.shipilev at oracle.com ! src/share/vm/classfile/vmSymbols.hpp From john.r.rose at oracle.com Thu Dec 20 20:48:31 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 20 Dec 2012 20:48:31 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <0A270D29-40CF-410A-8921-62B655278AF8@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> <0A270D29-40CF-410A-8921-62B655278AF8@oracle.com> Message-ID: <3F0EDD06-D849-462A-A99F-73E4C5D09814@oracle.com> On Dec 20, 2012, at 12:56 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8005071/webrev.01/ This is shaping up very well. Here are some more comments: Suggest a more descriptive name: s/update_with/replace_with/ For updating a boolean field (_inlining_incrementally, _inlining_progress), it is at least 5x more common to use the form "set_foo(bool z)" than a combination of "set_foo()" and "clear_foo()". I suggest using a boolean parameter instead of a set/clear pair. (A quick and dirty grep catches 125 "set_foo(bool z) {...}", 26 "set_foo() {...true...}", and 2 "clear_foo() {...false...}".) Consider adding an accessor function CallNode::set_cg, and maybe also a getter cg(). There's a lot of '->_cg'; it might look better with member functions. Perhaps s/cg/generator/. Basically, field accessors should have really uninteresting names, "foo" and "set_foo" for "_foo". See: https://wikis.oracle.com/display/HotSpotInternals/StyleGuide#StyleGuide-Naming There are a few places where you omit the space after "if" and "for". The majority usage is to include spaces: "if (" and "for (". New code should have spaces. (I added a line about this to the StyleGuide page.) Similar comment about 'Node *n' vs. 'Node* n'. The latter is preferable, and we should be going for reasonable consistency in any case. Some of the lines need a good sprinkle of whitespace. For example: - for(uint i=1; ireq(); ++i) { + for (uint i = 1; i < phi->req(); ++i) { In compile.cpp, the expression 'n->isa_Call() != NULL' can be simplified to 'n->is_Call()'. With remove_useless_late_inlines, I suggest passing 'GrowableArray* inlines' as an operand, instead of a magic boolean. And it should probably be the first operand, so that the output value is to the right of the input. Is there a way to name 'Compile::string_inline' as a verb phrase? Like 'inline_string_calls'? Same question about 'incremental_inline_one' and 'incremental_inline'. Maybe 'inline_incrementally' and 'inline_incrementally_once'. In CallNode::Ideal, you can replace Compile::current() by phase->C. Suggest guarding or asserting with MethodHandles::has_member_arg in 'else' of CallNode::Ideal, since it is a trailing member argument that you are checking for ConP. In RegionNode::try_clean_mem_phi, it appears you can get a SEGV if your Region has no Phi nodes at all. Actually, you can remove the loop, and use the utility function RegionNode::has_unique_phi. The boolean return value of try_clean_mem_phi is confusing. It should be documented, or else inverted to be a more intuitive "success" indicator: + if (has_phis && try_clean_mem_phi(phase)) { + has_phis = false; // cleaned out all phis + } There are two declarations of the index variable 'uint i', and one shadows the other. This may cause warnings on some compilers, and is (anyway) confusing. Use 'j' or 'i2' for the nested guy. In fact, the nested loops are confusing. I think you can do the job more clearly (and with more comments, please) in two consecutive loops, one to find the first MergeMemNode and, then another loop to check that the other edges can be discarded. The way I read the code, the memory phi must have inputs which are limited to NULL, a unique MergeMem m (with an out-count of 1, meaning the Phi is the only consumer), or m's base-memory (which must not itself be a MergeMem, for some reason I don't get). Given such a Phi, it follows that the Region node represents the merge of code like this: if (predicate) { memory.x = xval; //and maybe more memory2.y = yval... } In this case, the MergeMem collects one or more side effects. And your transformation replaces the Phi by an unconditional memory update: if (predicate) { } if (true) { memory.x = xval; //and maybe more memory2.y = yval... } I think this code needs more commenting to explain why it is a safe transformation. It actually seems unsafe to me! Perhaps an alternative transformation (that would be more safe) would be to replace this: if (top) {foo} else {bar} with this: if (false) {foo} else {bar} After all, if the code is not dead, but the predicate tops out, then we are allowed to choose an arbitrary branch of the if. (In order to prevent indeterminacy, both foo and bar should have exactly the same effects, but that is impossible to prove in general, and we may hope it is true.) ? John From christian.thalinger at oracle.com Fri Dec 21 00:29:25 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 21 Dec 2012 08:29:25 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 Message-ID: <20121221082929.E94214732A@hg.openjdk.java.net> Changeset: d02120b7a34f Author: twisti Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d02120b7a34f 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp From roland.westrelin at oracle.com Fri Dec 21 05:41:46 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 21 Dec 2012 14:41:46 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <3F0EDD06-D849-462A-A99F-73E4C5D09814@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> <0A270D29-40CF-410A-8921-62B655278AF8@oracle.com> <3F0EDD06-D849-462A-A99F-73E4C5D09814@oracle.com> Message-ID: Hi John, Thanks for the review. I'm updating the code following your suggestions and I'll send an updated webrev later today. > In RegionNode::try_clean_mem_phi, it appears you can get a SEGV if your Region has no Phi nodes at all. > > Actually, you can remove the loop, and use the utility function RegionNode::has_unique_phi. > > The boolean return value of try_clean_mem_phi is confusing. It should be documented, or else inverted to be a more intuitive "success" indicator: > > + if (has_phis && try_clean_mem_phi(phase)) { > + has_phis = false; // cleaned out all phis > + } > > There are two declarations of the index variable 'uint i', and one shadows the other. This may cause warnings on some compilers, and is (anyway) confusing. Use 'j' or 'i2' for the nested guy. > > In fact, the nested loops are confusing. I think you can do the job more clearly (and with more comments, please) in two consecutive loops, one to find the first MergeMemNode and, then another loop to check that the other edges can be discarded. As Vladimir suggested there's no need for 2 loops because we only have 2 inputs to the Phi and if one looks good for the transformation, we just want to look at the other one. > The way I read the code, the memory phi must have inputs which are limited to NULL, a unique MergeMem m (with an out-count of 1, meaning the Phi is the only consumer), or m's base-memory (which must not itself be a MergeMem, for some reason I don't get). Given such a Phi, it follows that the Region node represents the merge of code like this: > > if (predicate) { > memory.x = xval; > //and maybe more memory2.y = yval... > } > > In this case, the MergeMem collects one or more side effects. And your transformation replaces the Phi by an unconditional memory update: > > if (predicate) { } > if (true) { > memory.x = xval; > //and maybe more memory2.y = yval... > } > > I think this code needs more commenting to explain why it is a safe transformation. It actually seems unsafe to me! The outcnt() == 1 test is on the region's i input for the Phi's i input which guarantees, I think, that the region is the only use for the If projection and so there's nothing in this branch of the If and so nothing that updates memory and is an input to the MergeMem. So your if example above is not transformed. Roland. From roland.westrelin at oracle.com Fri Dec 21 05:46:35 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 21 Dec 2012 14:46:35 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <50D3A206.2010009@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> <50D3A206.2010009@oracle.com> Message-ID: <18D54339-1DAA-4803-84F3-C05D54735CDE@oracle.com> Hi Vladimir, Thanks for taking another look at this. I've applied all your suggestions but this one: > Also use phi->as_Phi()->is_diamond_phi() instead of region's inputs checks. I don't think that would work in every cases. Because one of the input is top, the CmpP, if it's ahead of the Region in the igvn's worklist, will go away and be replaced by top and then when the Region is processed, phi->as_Phi()->is_diamond_phi() won't return true. Roland. From roland.westrelin at oracle.com Fri Dec 21 05:48:03 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 21 Dec 2012 14:48:03 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <7BA3B3D3-CF1A-4DEF-BF66-65DDD4C02797@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <7BA3B3D3-CF1A-4DEF-BF66-65DDD4C02797@oracle.com> Message-ID: <398A1417-D164-44B2-B414-E5E11EFE36C7@oracle.com> Hi Chris, >> Is there anything in the logic that you think can be a problem? > > Only this one: > > } else if (!callee_method->was_executed_more_than(MIN2(MinInliningThreshold, > CompileThreshold >> 1))) { > return "executed < MinInliningThreshold times"; > } Are you suggesting that I change the code so that this call ends up on the late inlines list? FWIW, I tried and it doesn't seem to make a difference performance-wise. Roland. From vladimir.kozlov at oracle.com Fri Dec 21 07:39:23 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Dec 2012 07:39:23 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <18D54339-1DAA-4803-84F3-C05D54735CDE@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> <50D3A206.2010009@oracle.com> <18D54339-1DAA-4803-84F3-C05D54735CDE@oracle.com> Message-ID: <50D482AB.8040605@oracle.com> On 12/21/12 5:46 AM, Roland Westrelin wrote: > > Hi Vladimir, > > Thanks for taking another look at this. > > I've applied all your suggestions but this one: > >> Also use phi->as_Phi()->is_diamond_phi() instead of region's inputs checks. > > I don't think that would work in every cases. Because one of the input is top, the CmpP, if it's ahead of the Region in the igvn's worklist, will go away and be replaced by top and then when the Region is processed, phi->as_Phi()->is_diamond_phi() won't return true. But in such case nothing prevents this diamond-shape subgraph collapse into top before you will have a chance to process the Region. Can we detect that one of Cmp's inputs is Top early in StringOpts and replace Bool with 'false' as John suggested? Or in IfNode::Ideal detect and do this to prevent collapsing. Also you are missing in(1)->in(0)->is_If() check if you can't use is_diamond_phi(). Vladimir > > Roland. > From roland.westrelin at oracle.com Fri Dec 21 07:40:54 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 21 Dec 2012 16:40:54 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <398A1417-D164-44B2-B414-E5E11EFE36C7@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <7BA3B3D3-CF1A-4DEF-BF66-65DDD4C02797@oracle.com> <398A1417-D164-44B2-B414-E5E11EFE36C7@oracle.com> Message-ID: <3B8D4B10-E443-436F-8B1D-CBFFEF6E7FEB@oracle.com> Here is a new webrev: http://cr.openjdk.java.net/~roland/8005071/webrev.02/ with Vladimir & John's suggestions. I also limited the MaxNodeLimit bump to 75000 which seems to be sufficient according my latest experiments and in RegionNode::try_clean_mem_phi() I dropped the, I believe, unnecessary check for in(i)->outcnt() on the branch that doesn't have the MergeMem. Roland. From roland.westrelin at oracle.com Fri Dec 21 08:26:29 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 21 Dec 2012 17:26:29 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <50D482AB.8040605@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> <50D3A206.2010009@oracle.com> <18D54339-1DAA-4803-84F3-C05D54735CDE@oracle.com> <50D482AB.8040605@oracle.com> Message-ID: <1BCAFFFE-54A1-48E7-87F4-ACAAB3950AFC@oracle.com> > But in such case nothing prevents this diamond-shape subgraph collapse into top before you will have a chance to process the Region. Can we detect that one of Cmp's inputs is Top early in StringOpts and replace Bool with 'false' as John suggested? Or in IfNode::Ideal detect and do this to prevent collapsing. It's true of the current code as well (without incremental inlining) so all RegionNode::try_clean_mem_phi() does is make sure what we have today works similarly. For the diamond-shape subgraph to collapse into top, the whole subgraph would need to be in the igvn worklist ahead of the Region which doesn't seem possible. FWIW, I used to test for is_diamond_phi() in RegionNode::try_clean_mem_phi() and it worked fine. I didn't keep it to be extra safe. Roland. From vladimir.kozlov at oracle.com Fri Dec 21 08:37:52 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Dec 2012 08:37:52 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <1BCAFFFE-54A1-48E7-87F4-ACAAB3950AFC@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> <50D3A206.2010009@oracle.com> <18D54339-1DAA-4803-84F3-C05D54735CDE@oracle.com> <50D482AB.8040605@oracle.com> <1BCAFFFE-54A1-48E7-87F4-ACAAB3950AFC@oracle.com> Message-ID: <50D49060.40407@oracle.com> On 12/21/12 8:26 AM, Roland Westrelin wrote: >> But in such case nothing prevents this diamond-shape subgraph collapse into top before you will have a chance to process the Region. Can we detect that one of Cmp's inputs is Top early in StringOpts and replace Bool with 'false' as John suggested? Or in IfNode::Ideal detect and do this to prevent collapsing. > > It's true of the current code as well (without incremental inlining) so all RegionNode::try_clean_mem_phi() does is make sure what we have today works similarly. For the diamond-shape subgraph to collapse into top, the whole subgraph would need to be in the igvn worklist ahead of the Region which doesn't seem possible. It is possible because of how UniqueNodeList works. It is not queue so nodes pushed on the list later could be processed early than older nodes. What save us is it is a rare event since we have several nodes to processed for that to happened. So it needs to be fixed but not now, not in this changes. File bug explaining possible case so we will not forget about it. > > FWIW, I used to test for is_diamond_phi() in RegionNode::try_clean_mem_phi() and it worked fine. I didn't keep it to be extra safe. OK. But add is_If() check as I asked. Thanks, Vladimir > > Roland. > From roland.westrelin at oracle.com Fri Dec 21 09:13:27 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 21 Dec 2012 18:13:27 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <50D49060.40407@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> <50D3A206.2010009@oracle.com> <18D54339-1DAA-4803-84F3-C05D54735CDE@oracle.com> <50D482AB.8040605@oracle.com> <1BCAFFFE-54A1-48E7-87F4-ACAAB3950AFC@oracle.com> <50D49060.40407@oracle.com> Message-ID: <8C30CFA8-A5A4-47DF-9417-02DDFE6DB89E@oracle.com> > It is possible because of how UniqueNodeList works. It is not queue so nodes pushed on the list later could be processed early than older nodes. I didn't realize that. I'll file the bug. > OK. But add is_If() check as I asked. Ok. Roland. From christian.thalinger at oracle.com Fri Dec 21 11:57:09 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 21 Dec 2012 11:57:09 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <398A1417-D164-44B2-B414-E5E11EFE36C7@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <7BA3B3D3-CF1A-4DEF-BF66-65DDD4C02797@oracle.com> <398A1417-D164-44B2-B414-E5E11EFE36C7@oracle.com> Message-ID: <6854302F-FE7F-43A0-8F19-9C34E668E121@oracle.com> On Dec 21, 2012, at 5:48 AM, Roland Westrelin wrote: > Hi Chris, > >>> Is there anything in the logic that you think can be a problem? >> >> Only this one: >> >> } else if (!callee_method->was_executed_more_than(MIN2(MinInliningThreshold, >> CompileThreshold >> 1))) { >> return "executed < MinInliningThreshold times"; >> } > > Are you suggesting that I change the code so that this call ends up on the late inlines list? FWIW, I tried and it doesn't seem to make a difference performance-wise. I wasn't suggesting that but thanks for trying :-) -- Chris From christian.thalinger at oracle.com Fri Dec 21 11:59:29 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 21 Dec 2012 11:59:29 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <3B8D4B10-E443-436F-8B1D-CBFFEF6E7FEB@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <7BA3B3D3-CF1A-4DEF-BF66-65DDD4C02797@oracle.com> <398A1417-D164-44B2-B414-E5E11EFE36C7@oracle.com> <3B8D4B10-E443-436F-8B1D-CBFFEF6E7FEB@oracle.com> Message-ID: <1336C8B2-0038-4C70-BF6D-F9B6D2E49F4B@oracle.com> On Dec 21, 2012, at 7:40 AM, Roland Westrelin wrote: > Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8005071/webrev.02/ > > with Vladimir & John's suggestions. I also limited the MaxNodeLimit bump to 75000 which seems to be sufficient according my latest experiments What do your experiments include? Did you run JRuby benchmarks as well? -- Chris > and in RegionNode::try_clean_mem_phi() I dropped the, I believe, unnecessary check for in(i)->outcnt() on the branch that doesn't have the MergeMem. > > Roland. From christian.thalinger at oracle.com Fri Dec 21 12:01:27 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 21 Dec 2012 12:01:27 -0800 Subject: Virtual dispatch bug in 292 impl In-Reply-To: <62ECFA9C-7CBC-444B-8038-357F19C00289@oracle.com> References: <62ECFA9C-7CBC-444B-8038-357F19C00289@oracle.com> Message-ID: On Dec 17, 2012, at 5:47 PM, Christian Thalinger wrote: > > On Dec 16, 2012, at 11:55 AM, Charles Oliver Nutter wrote: > >> I wasn't sure if this had been filed already by Christian, so I wanted >> to post here. >> >> It appears that in C1, method handles are not properly dispatching to >> an overridden version of a method. My reproduction case is tied to >> JRuby, but I can come up with something isolated if necessary. I filed: https://jbs.oracle.com/bugs/browse/JDK-8005418 But it seems to be C2, not C1: cthaling at sc14ia01:~/jruby$ jruby -J-showversion -J-client test_env.rb java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b69) Java HotSpot(TM) Client VM (build 25.0-b13, mixed mode) Run options: # Running tests: . Finished tests in 53.285000s, 0.0188 tests/s, 1876.7008 assertions/s. 1 tests, 100000 assertions, 0 failures, 0 errors, 0 skips cthaling at sc14ia01:~/jruby$ jruby -J-showversion -J-server -J-XX:-TieredCompilation test_env.rb java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b69) Java HotSpot(TM) Server VM (build 25.0-b13, mixed mode) Run options: # Running tests: F Finished tests in 2.222000s, 0.4500 tests/s, 424.8425 assertions/s. 1) Failure: test_bracket(TestEnv) [test_env.rb:11]: TypeError expected but nothing was raised. 1 tests, 944 assertions, 1 failures, 0 errors, 0 skips cthaling at sc14ia01:~/jruby$ jruby -J-showversion -J-server -J-XX:+TieredCompilation -J-XX:TieredStopAtLevel=3 test_env.rb java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b69) Java HotSpot(TM) Server VM (build 25.0-b13, mixed mode) Run options: # Running tests: . Finished tests in 90.676000s, 0.0110 tests/s, 1102.8277 assertions/s. 1 tests, 100000 assertions, 0 failures, 0 errors, 0 skips -- Chris >> >> In JRuby, the ENV object is a subclass of a Ruby Hash. Rather than >> rebinding all of Hash's methods (defined on org.jruby.RubyHash), the >> ENV impl just overrides them at the Java level. When dispatching to >> the [] method on ENV with invokedynamic, the handle points at >> RubyHash.op_aref, the implementation of [] for Hash. The ENV version >> should raise an error...but it does not, because it dispatches to the >> superclass version rather than the subclass version. >> >> If I turn off tiered compilation, the code works as expected. >> >> Reproduction for JRuby is here: https://gist.github.com/4311979 >> >> I tested on hotspot-comp built yesterday: >> >> openjdk version "1.8.0-internal" >> OpenJDK Runtime Environment (build 1.8.0-internal-headius_2012_12_15_16_45-b00) >> OpenJDK 64-Bit Server VM (build 25.0-b13, mixed mode) >> >> If I have time I'll try to investigate in more depth. > > This is really odd. I've fixed a similar bug some time ago: > > https://jbs.oracle.com/bugs/browse/JDK-8000821 > http://bugs.sun.com/view_bug.do?bug_id=8000821 > > And there is currently a bug with Nashorn that sounds like the same issue. > > Is it intermittent? Are you able to reproduce with TieredStopAtLevel=1? > > -- Chris > >> >> - Charlie > From christian.thalinger at oracle.com Fri Dec 21 12:30:22 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 21 Dec 2012 12:30:22 -0800 Subject: Virtual dispatch bug in 292 impl In-Reply-To: References: <62ECFA9C-7CBC-444B-8038-357F19C00289@oracle.com> Message-ID: On Dec 21, 2012, at 12:01 PM, Christian Thalinger wrote: > > On Dec 17, 2012, at 5:47 PM, Christian Thalinger wrote: > >> >> On Dec 16, 2012, at 11:55 AM, Charles Oliver Nutter wrote: >> >>> I wasn't sure if this had been filed already by Christian, so I wanted >>> to post here. >>> >>> It appears that in C1, method handles are not properly dispatching to >>> an overridden version of a method. My reproduction case is tied to >>> JRuby, but I can come up with something isolated if necessary. > > I filed: > > https://jbs.oracle.com/bugs/browse/JDK-8005418 > > But it seems to be C2, not C1: > > cthaling at sc14ia01:~/jruby$ jruby -J-showversion -J-client test_env.rb > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b69) > Java HotSpot(TM) Client VM (build 25.0-b13, mixed mode) > > Run options: > > # Running tests: > > . > > Finished tests in 53.285000s, 0.0188 tests/s, 1876.7008 assertions/s. > > 1 tests, 100000 assertions, 0 failures, 0 errors, 0 skips > cthaling at sc14ia01:~/jruby$ jruby -J-showversion -J-server -J-XX:-TieredCompilation test_env.rb > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b69) > Java HotSpot(TM) Server VM (build 25.0-b13, mixed mode) > > Run options: > > # Running tests: > > F > > Finished tests in 2.222000s, 0.4500 tests/s, 424.8425 assertions/s. > > 1) Failure: > test_bracket(TestEnv) [test_env.rb:11]: > TypeError expected but nothing was raised. > > 1 tests, 944 assertions, 1 failures, 0 errors, 0 skips > cthaling at sc14ia01:~/jruby$ jruby -J-showversion -J-server -J-XX:+TieredCompilation -J-XX:TieredStopAtLevel=3 test_env.rb > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b69) > Java HotSpot(TM) Server VM (build 25.0-b13, mixed mode) > > Run options: > > # Running tests: > > . > > Finished tests in 90.676000s, 0.0110 tests/s, 1102.8277 assertions/s. > > 1 tests, 100000 assertions, 0 failures, 0 errors, 0 skips > > -- Chris > >>> >>> In JRuby, the ENV object is a subclass of a Ruby Hash. Rather than >>> rebinding all of Hash's methods (defined on org.jruby.RubyHash), the >>> ENV impl just overrides them at the Java level. When dispatching to >>> the [] method on ENV with invokedynamic, the handle points at >>> RubyHash.op_aref, the implementation of [] for Hash. The ENV version >>> should raise an error...but it does not, because it dispatches to the >>> superclass version rather than the subclass version. What's the name of the [] implementation of ENV? Is it StringOnlyRubyHash.op_aref? Could this be the compile that goes wrong? 12903 956 java.lang.invoke.LambdaForm$MH/847376::convert (52 bytes) @ 15 java.lang.invoke.LambdaForm$BMH/23638730::reinvoke (26 bytes) inline (hot) @ 12 java.lang.invoke.BoundMethodHandle$Species_LL::reinvokerTarget (8 bytes) inline (hot) @ 22 java.lang.invoke.LambdaForm$DMH/20340225::invokeStatic_LL_L (15 bytes) inline (hot) @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) inline (hot) @ 11 sun.invoke.util.ValueConversions::castReference (6 bytes) inline (hot) @ 2 java.lang.Class::cast (27 bytes) inline (hot) @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) @ 33 java.lang.Class::cast (27 bytes) inline (hot) @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) @ 43 java.lang.Class::cast (27 bytes) inline (hot) @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) @ 48 java.lang.invoke.LambdaForm$DMH/32367447::invokeVirtual_LLL_L (18 bytes) inline (hot) @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) inline (hot) @ 14 org.jruby.RubyHash::op_aref (23 bytes) inline (hot) @ 2 org.jruby.RubyHash::internalGet (9 bytes) inline (hot) \-> TypeProfile (5247/5247 counts) = org/jruby/RubyHash @ 2 org.jruby.RubyHash::internalGetEntry (51 bytes) inline (hot) @ 1 java.lang.Object::hashCode (0 bytes) (intrinsic, virtual) @ 4 org.jruby.RubyHash::hashValue (5 bytes) inline (hot) @ 1 org.jruby.RubyHash::MRIHashValue (5 bytes) inline (hot) @ 18 org.jruby.RubyHash::bucketIndex (6 bytes) inline (hot) @ 2 org.jruby.RubyHash::MRIBucketIndex (7 bytes) inline (hot) @ 31 org.jruby.RubyHash::internalKeyExist (42 bytes) inline (hot) @ 1 org.jruby.RubyHash$RubyHashEntry::access$300 (5 bytes) inline (hot) @ 9 org.jruby.RubyHash$RubyHashEntry::access$500 (5 bytes) inline (hot) @ 40 org.jruby.RubyHash$RubyHashEntry::access$200 (5 bytes) inline (hot) @ 5 org.jruby.RubyHash$RubyHashEntry::access$400 (5 bytes) inline (hot) -- Chris >>> >>> If I turn off tiered compilation, the code works as expected. >>> >>> Reproduction for JRuby is here: https://gist.github.com/4311979 >>> >>> I tested on hotspot-comp built yesterday: >>> >>> openjdk version "1.8.0-internal" >>> OpenJDK Runtime Environment (build 1.8.0-internal-headius_2012_12_15_16_45-b00) >>> OpenJDK 64-Bit Server VM (build 25.0-b13, mixed mode) >>> >>> If I have time I'll try to investigate in more depth. >> >> This is really odd. I've fixed a similar bug some time ago: >> >> https://jbs.oracle.com/bugs/browse/JDK-8000821 >> http://bugs.sun.com/view_bug.do?bug_id=8000821 >> >> And there is currently a bug with Nashorn that sounds like the same issue. >> >> Is it intermittent? Are you able to reproduce with TieredStopAtLevel=1? >> >> -- Chris >> >>> >>> - Charlie >> > From alejandro.murillo at oracle.com Fri Dec 21 20:08:24 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 22 Dec 2012 04:08:24 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 29 new changesets Message-ID: <20121222040921.780DC47364@hg.openjdk.java.net> Changeset: 8af7d22f1f8f Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8af7d22f1f8f Added tag jdk8-b68 for changeset 121aa71316af ! .hgtags Changeset: 442f942757c0 Author: johnc Date: 2012-10-01 09:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/442f942757c0 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack Summary: Set the value of MarkStackSize to a value based on the number of parallel marking threads with a reasonable minimum. Expand the marking stack if we have to restart marking due to an overflow up to a reasonable maximum. Allocate the underlying space for the marking stack from virtual memory. Reviewed-by: jmasa, brutisso ! 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/runtime/arguments.cpp Changeset: a14c5698a162 Author: johnc Date: 2012-12-07 16:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a14c5698a162 Merge Changeset: 2aa953165ade Author: brutisso Date: 2012-12-13 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2aa953165ade 8004661: Comment and function name java_lang_String::toHash is wrong Summary: renamed to hash_code Reviewed-by: dholmes, coleenp, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp Changeset: db8a7163c682 Author: stefank Date: 2012-12-13 09:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/db8a7163c682 8004674: Add necessary .inline.hpp files to fix non-PCH build Reviewed-by: stefank, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp ! src/share/vm/gc_implementation/shared/gcStats.cpp Changeset: 4459ef2189f5 Author: stefank Date: 2012-12-13 09:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4459ef2189f5 Merge Changeset: fd74228fd5ca Author: jiangli Date: 2012-12-11 12:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fd74228fd5ca 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Summary: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Reviewed-by: coleenp, minqi, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 807f1d348f7b Author: collins Date: 2012-12-14 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/807f1d348f7b Merge Changeset: b6c9c0109a60 Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b6c9c0109a60 Merge Changeset: cb8a4e04bc8c Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cb8a4e04bc8c Added tag hs25-b13 for changeset b6c9c0109a60 ! .hgtags Changeset: 8b4810c80f5d Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4810c80f5d Added tag jdk8-b69 for changeset cb8a4e04bc8c ! .hgtags Changeset: 1f323009c3ea Author: amurillo Date: 2012-12-14 14:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1f323009c3ea 8005036: new hotspot build - hs25-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 892acf0431ef Author: dcubed Date: 2012-12-14 10:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/892acf0431ef 7153050: remove crufty '_g' support from HotSpot repo makefiles Summary: Phase 1 is removing '_g' support from the Makefiles. Reviewed-by: dcubed, sspitsyn, coleenp, tbell Contributed-by: ron.durbin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/debug.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/jvmg.make ! make/bsd/makefiles/optimized.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/vm.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/debug.make ! make/linux/makefiles/fastdebug.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/jvmg.make ! make/linux/makefiles/optimized.make ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/projectfiles/compiler2/ADLCompiler.dsp ! make/windows/projectfiles/tiered/ADLCompiler.dsp Changeset: 30866cd626b0 Author: coleenp Date: 2012-12-12 11:39 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/30866cd626b0 8004883: NPG: clean up anonymous class fix Summary: Add klass_holder() to return either mirror or class_loader depending on if the class is anonymous or not. Reviewed-by: stefank, jrose ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp Changeset: 18712b1caf7a Author: rkennke Date: 2012-12-12 21:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/18712b1caf7a 8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 Summary: fix opto/library_call.cpp compilation errors Reviewed-by: twisti, coleenp ! src/share/vm/opto/library_call.cpp Changeset: 8580f22db905 Author: coleenp Date: 2012-12-14 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8580f22db905 Merge Changeset: 3f84e17b6bca Author: zgu Date: 2012-12-17 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3f84e17b6bca 8004802: jcmd VM.native_memory baseline=false crashes VM Summary: NMT has to check option's value also to determine which command to execute Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/nmtDCmd.cpp Changeset: 805aa223d540 Author: zgu Date: 2012-12-17 10:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/805aa223d540 Merge Changeset: 594b9b2119ed Author: minqi Date: 2012-12-19 16:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/594b9b2119ed Merge Changeset: c52660592f37 Author: roland Date: 2012-12-21 01:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c52660592f37 Merge ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/opto/library_call.cpp Changeset: 0b3d19153cc6 Author: johnc Date: 2012-12-12 12:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0b3d19153cc6 8001028: Improve GC option handling Summary: If there are not enough native resources to create the ReferenceHandler or Finalizer Java threads, the VM will attempt to throw an OOME before the java.lang.Class class has been initialized. This can result in assertion failures and other crashes. Move the initialization of the java.lang.Class class to just before the initialization of the java.lang.ref.Finalizer class. Reviewed-by: jwilhelm, dholmes, coleenp ! src/share/vm/runtime/thread.cpp Changeset: 730cc4ddd550 Author: brutisso Date: 2012-12-17 08:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/730cc4ddd550 7173959: Jvm crashed during coherence exabus (tmb) testing Summary: Mapping of aligned memory needs to be MT safe. Also reviewed by: vitalyd at gmail.com Reviewed-by: dholmes, coleenp, zgu ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 32164d89fe9c Author: brutisso Date: 2012-12-17 15:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/32164d89fe9c 8004845: Catch incorrect usage of new and delete during compile time for value objects and stack objects Summary: Makes the "new" and "delete" operator of _ValueObj and StackObj private Reviewed-by: dholmes, coleenp Contributed-by: erik.helin at oracle.com ! src/share/vm/memory/allocation.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: c71879335291 Author: stefank Date: 2012-12-18 10:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c71879335291 8005108: NPG: MetaspaceAux::used_in_bytes(), capacity_in_bytes() and reserved_in_bytes() return inconsistent numbers Summary: Reverted the changes to these functions from JDK-8000662 Reviewed-by: brutisso, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 345bd97a77be Author: brutisso Date: 2012-12-20 05:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/345bd97a77be 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag Reviewed-by: stefank, brutisso, kvn, ctornqvi Contributed-by: erik.helin at oracle.com + test/sanity/ExecuteInternalVMTests.java Changeset: 69627aa9ab10 Author: jwilhelm Date: 2012-12-21 16:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/69627aa9ab10 Merge ! src/share/vm/runtime/thread.cpp Changeset: 990bbd393c23 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/990bbd393c23 Merge Changeset: 6a1fc440b396 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6a1fc440b396 Added tag hs25-b14 for changeset 990bbd393c23 ! .hgtags Changeset: cd962e15c08e Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cd962e15c08e 8005382: new hotspot build - hs25-b15 Reviewed-by: jcoomes ! make/hotspot_version From john.r.rose at oracle.com Sat Dec 22 15:49:10 2012 From: john.r.rose at oracle.com (John Rose) Date: Sat, 22 Dec 2012 15:49:10 -0800 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> <0A270D29-40CF-410A-8921-62B655278AF8@oracle.com> <3F0EDD06-D849-462A-A99F-73E4C5D09814@oracle.com> Message-ID: <2F82ED04-986B-48C6-9A2F-0A77684A889C@oracle.com> On Dec 21, 2012, at 5:41 AM, Roland Westrelin wrote: >> if (predicate) { } >> if (true) { >> memory.x = xval; >> //and maybe more memory2.y = yval... >> } >> >> I think this code needs more commenting to explain why it is a safe transformation. It actually seems unsafe to me! > > The outcnt() == 1 test is on the region's i input for the Phi's i input which guarantees, I think, that the region is the only use for the If projection and so there's nothing in this branch of the If and so nothing that updates memory and is an input to the MergeMem. So your if example above is not transformed. I see. (I misread whose outcnt was being tested.) I suggest comments like: + if (ii && ii->is_MergeMem() && in(i)->outcnt() == 1) { ++ // Nothing is control-dependent on path #i except the region itself. + m = ii->as_MergeMem(); + uint j = 3 - i; + Node* other = phi->in(j); + if (other && other == m->base_memory()) { ++ // m is a successor memory to other, and is not pinned inside the diamond, so push it out. ++ // This will allow the diamond to collapse completely. + phase->is_IterGVN()->replace_node(phi, m); + return true; + } Also suggest: ++ assert(phi->req() == 3, "same as region"); ++ for (uint i = 1; i < 3; ++i) { That makes the 'j = 3 - i' easier to follow. Also, since 'ii' is a memory state, call it something more descriptive, like 'mem'. On Dec 21, 2012, at 5:46 AM, Roland Westrelin wrote: >> >> Also use phi->as_Phi()->is_diamond_phi() instead of region's inputs checks. > > I don't think that would work in every cases. Because one of the input is top, the CmpP, if it's ahead of the Region in the igvn's worklist, will go away and be replaced by top and then when the Region is processed, phi->as_Phi()->is_diamond_phi() won't return true. I sympathize with Vladimir here, since this thing is hard to follow: in(1) && in(2) && in(1)->in(0) == in(2)->in(0) I suggest adding an optional boolean option to is_diamond_phi: // If check_control_only is true, do not inspect the If node at the top, and return -1 (not an edge number) on success. int PhiNode::is_diamond_phi(bool check_control_only = false) const { // Check for a 2-path merge Node *region = in(0); if( !region ) return 0; if( region->req() != 3 ) return 0; if( req() != 3 ) return 0; // Check that both paths come from the same If Node *ifp1 = region->in(1); Node *ifp2 = region->in(2); if( !ifp1 || !ifp2 ) return 0; if (check_control_only) return (ifp1 == ifp2) ? -1 : 0; That way the pattern match can build on the useful concept of a diamond. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121222/fab90c65/attachment.html From roland.westrelin at oracle.com Sun Dec 23 01:32:11 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Sun, 23 Dec 2012 10:32:11 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <1336C8B2-0038-4C70-BF6D-F9B6D2E49F4B@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <7BA3B3D3-CF1A-4DEF-BF66-65DDD4C02797@oracle.com> <398A1417-D164-44B2-B414-E5E11EFE36C7@oracle.com> <3B8D4B10-E443-436F-8B1D-CBFFEF6E7FEB@oracle.com> <1336C8B2-0038-4C70-BF6D-F9B6D2E49F4B@oracle.com> Message-ID: <372D091F-938E-474C-99DB-790D52569ADE@oracle.com> > What do your experiments include? Did you run JRuby benchmarks as well? No. v8 tests with nashorn only. Roland. From roland.westrelin at oracle.com Sun Dec 23 08:37:33 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Sun, 23 Dec 2012 17:37:33 +0100 Subject: RFR(L): 8005071: Incremental inlining for JSR 292 In-Reply-To: <2F82ED04-986B-48C6-9A2F-0A77684A889C@oracle.com> References: <2FA9F9D4-7DAB-45DD-AF70-D6ABF466F0DD@oracle.com> <50CCF435.4040208@oracle.com> <7AD4F2C1-93B0-4297-8A29-EDDF570911BC@oracle.com> <50D0CA08.4000706@oracle.com> <50D1F0E9.4090002@oracle.com> <50D20111.8000003@oracle.com> <50D373F0.7030504@oracle.com> <0A270D29-40CF-410A-8921-62B655278AF8@oracle.com> <3F0EDD06-D849-462A-A99F-73E4C5D09814@oracle.com> <2F82ED04-986B-48C6-9A2F-0A77684A889C@oracle.com> Message-ID: <53E02A39-F326-4265-B748-79684BED6806@oracle.com> Hi John, Thanks for the suggestions. I kept all of them except the is_diamond_phi that wasn't quite right. > int PhiNode::is_diamond_phi(bool check_control_only = false) const { > // Check for a 2-path merge > Node *region = in(0); > if( !region ) return 0; > if( region->req() != 3 ) return 0; > if( req() != 3 ) return 0; > // Check that both paths come from the same If > Node *ifp1 = region->in(1); > Node *ifp2 = region->in(2); > if( !ifp1 || !ifp2 ) return 0; > if (check_control_only) return (ifp1 == ifp2) ? -1 : 0; int PhiNode::is_diamond_phi(bool check_control_only) const { // Check for a 2-path merge Node *region = in(0); if( !region ) return 0; if( region->req() != 3 ) return 0; if( req() != 3 ) return 0; // Check that both paths come from the same If Node *ifp1 = region->in(1); Node *ifp2 = region->in(2); if( !ifp1 || !ifp2 ) return 0; Node *iff = ifp1->in(0); if( !iff || !iff->is_If() ) return 0; if( iff != ifp2->in(0) ) return 0; if (check_control_only) return -1; Roland. From roland.westrelin at oracle.com Sun Dec 23 11:56:19 2012 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Sun, 23 Dec 2012 19:56:19 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005071: Incremental inlining for JSR 292 Message-ID: <20121223195628.798004737D@hg.openjdk.java.net> Changeset: d092d1b31229 Author: roland Date: 2012-12-23 17:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d092d1b31229 8005071: Incremental inlining for JSR 292 Summary: post parse inlining driven by number of live nodes. Reviewed-by: twisti, kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/arguments.cpp From vladimir.kozlov at oracle.com Wed Dec 26 19:57:00 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Dec 2012 19:57:00 -0800 Subject: Request for reviews (S): 8005522: use fast-string instructions on x86 for zeroing In-Reply-To: <50CCF501.7060409@oracle.com> References: <50CCF501.7060409@oracle.com> Message-ID: <50DBC70C.2050502@oracle.com> http://cr.openjdk.java.net/~kvn/8005522/webrev/ 8005522: use fast-string instructions on x86 for zeroing New x86 processors enhanced the operation of the REP MOVSB and REP STOSB instructions. Use 'rep stosb' instead of 'rep stosq' when fast-string operations are available (cpuid ERMS bit is set). Ran compiler regression tests on machine which has fast-string operations with 64- and 32-bit VM. Thanks, Vladimir From vladimir.kozlov at oracle.com Thu Dec 27 14:33:17 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Dec 2012 14:33:17 -0800 Subject: Request for reviews (S): 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Message-ID: <50DCCCAD.3050604@oracle.com> http://cr.openjdk.java.net/~kvn/8005544/webrev/ New x86 processors with AVX2 have wide memory bus and improved memory operations with YMM registers. Use them to copy data in arraycopy stubs. Most changes in stubGenerator_x86_64.cpp are renaming of copy_32_bytes to copy_bytes since now the code copies 64 or 32 bytes per iteration. Ran compiler regression tests with 64- and 32-bit VM. Thanks, Vladimir From vladimir.kozlov at oracle.com Thu Dec 27 17:15:25 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Dec 2012 17:15:25 -0800 Subject: Request for reviews (S): 8005544: Use 256bit YMM registers in arraycopy stubs on x86 In-Reply-To: <50DCCCAD.3050604@oracle.com> References: <50DCCCAD.3050604@oracle.com> Message-ID: <50DCF2AD.50701@oracle.com> On 12/27/12 2:33 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8005544/webrev/ > > New x86 processors with AVX2 have wide memory bus and improved memory > operations with YMM registers. Use them to copy data in arraycopy stubs. Also use them in array_fill code. > > Most changes in stubGenerator_x86_64.cpp are renaming of copy_32_bytes > to copy_bytes since now the code copies 64 or 32 bytes per iteration. > > Ran compiler regression tests with 64- and 32-bit VM. > > Thanks, > Vladimir > From john.coomes at oracle.com Thu Dec 27 20:51:02 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 04:51:02 +0000 Subject: hg: hsx/hotspot-comp: 10 new changesets Message-ID: <20121228045103.4B905473FA@hg.openjdk.java.net> Changeset: fb1bf5e5bc9e Author: henryjen Date: 2012-12-06 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/fb1bf5e5bc9e 8004685: add java.util.function to CORE_PKGS.gmk Reviewed-by: mduigou ! common/makefiles/javadoc/CORE_PKGS.gmk Changeset: e08b0096058f Author: lana Date: 2012-12-14 11:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/e08b0096058f Merge Changeset: 8e36a0fabf58 Author: ohrstrom Date: 2012-12-18 09:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8e36a0fabf58 8004145: New improved hgforest.sh, ctrl-c now properly terminates mercurial processes. Reviewed-by: ohair, erikj + common/bin/hgforest.sh ! get_source.sh Changeset: 51d3b65b8093 Author: erikj Date: 2012-12-18 17:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/51d3b65b8093 8001901: build-infra: Fix "misbehaving" which command on Solaris Summary: Removed all uses of which in configure on solaris. Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: 6ee8080a6efe Author: katleman Date: 2012-12-19 13:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/6ee8080a6efe Merge Changeset: 32148e971ac8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/32148e971ac8 Added tag jdk8-b69 for changeset 6ee8080a6efe ! .hgtags Changeset: 6b93e7a4401d Author: dholmes Date: 2012-12-20 01:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/6b93e7a4401d 7190137: Add support for JVM_VARIANT minimal1 Summary: Allow configuration of minimal1 as a target VM along with client and server Reviewed-by: ohair, erikj ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: cd06b2ea58dd Author: katleman Date: 2012-12-20 16:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/cd06b2ea58dd 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! common/makefiles/RMICompilation.gmk Changeset: 105a25ffa4a4 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/105a25ffa4a4 Merge Changeset: 3fb32a5a2388 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/3fb32a5a2388 Added tag jdk8-b70 for changeset 105a25ffa4a4 ! .hgtags From john.coomes at oracle.com Thu Dec 27 20:51:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 04:51:07 +0000 Subject: hg: hsx/hotspot-comp/corba: 2 new changesets Message-ID: <20121228045109.9E575473FB@hg.openjdk.java.net> Changeset: 603cceb495c8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/603cceb495c8 Added tag jdk8-b69 for changeset 22ddcac208a8 ! .hgtags Changeset: 8171d23e914d Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/8171d23e914d Added tag jdk8-b70 for changeset 603cceb495c8 ! .hgtags From john.coomes at oracle.com Thu Dec 27 20:51:15 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 04:51:15 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 4 new changesets Message-ID: <20121228045130.2DB16473FC@hg.openjdk.java.net> Changeset: 27421008f050 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/27421008f050 Added tag jdk8-b69 for changeset 789a855de959 ! .hgtags Changeset: a72c8391cdd6 Author: katleman Date: 2012-12-20 16:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/a72c8391cdd6 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java Changeset: 6ec9edffc286 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/6ec9edffc286 Merge Changeset: 63815efd132f Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/63815efd132f Added tag jdk8-b70 for changeset 6ec9edffc286 ! .hgtags From john.coomes at oracle.com Thu Dec 27 20:51:34 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 04:51:34 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 2 new changesets Message-ID: <20121228045140.D3BA3473FD@hg.openjdk.java.net> Changeset: 3b1c2733d47e Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/3b1c2733d47e Added tag jdk8-b69 for changeset 756323c99011 ! .hgtags Changeset: f577a39c9fb3 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/f577a39c9fb3 Added tag jdk8-b70 for changeset 3b1c2733d47e ! .hgtags From john.coomes at oracle.com Thu Dec 27 20:53:00 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 04:53:00 +0000 Subject: hg: hsx/hotspot-comp/jdk: 52 new changesets Message-ID: <20121228050309.01F8A473FE@hg.openjdk.java.net> Changeset: e8b54ae97344 Author: jviswana Date: 2012-12-12 13:28 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e8b54ae97344 8004316: Printer - tempfile having incorrect extension Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: fd9e6b4c8488 Author: lana Date: 2012-12-14 11:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fd9e6b4c8488 Merge Changeset: c69424f78060 Author: serb Date: 2012-12-11 19:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c69424f78060 7154778: [macosx] NSView-based implementation of sun.awt.EmbeddedFrame Summary: The new implementation of EmbeddedFrame to support SWT_AWT Bridge Reviewed-by: anthony, serb, leonidr Contributed-by: Petr Pchelko ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java + src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java + src/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTSurfaceLayers.m ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CCursorManager.m ! src/macosx/native/sun/awt/CWrapper.m ! src/macosx/native/sun/awt/awt.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: e016ad35a764 Author: kshefov Date: 2012-12-13 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e016ad35a764 7132385: [macosx] IconifyTest of RepaintManager could use some delay Reviewed-by: serb, alexsch + test/javax/swing/RepaintManager/IconifyTest/IconifyTest.java Changeset: 71e03e17c183 Author: kshefov Date: 2012-12-14 13:32 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/71e03e17c183 6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction Reviewed-by: serb, alexsch + test/javax/swing/JInternalFrame/5066752/bug5066752.java Changeset: 9fc7460ca3ac Author: lana Date: 2012-12-14 11:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9fc7460ca3ac Merge Changeset: 7004848974a2 Author: jgish Date: 2012-12-04 20:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7004848974a2 8003596: TEST_BUG: java/util/logging/CheckLockLocationTest.java failing [win] Reviewed-by: alanb ! test/ProblemList.txt ! test/java/util/logging/CheckLockLocationTest.java Changeset: 44ae777564eb Author: mullan Date: 2012-12-04 17:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/44ae777564eb 8004188: Rename src/share/lib/security/java.security to java.security-linux Reviewed-by: mullan, mchung Contributed-by: jason.uh at oracle.com ! make/java/security/Makefile - src/share/lib/security/java.security + src/share/lib/security/java.security-linux Changeset: b54a5b7d2e65 Author: alanb Date: 2012-12-05 12:20 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b54a5b7d2e65 8004491: Build breakage on Linux due to 8004188 Reviewed-by: chegar, erikj ! makefiles/CopyFiles.gmk Changeset: a971516029ab Author: jgish Date: 2012-12-05 21:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a971516029ab 8004317: TestLibrary.getUnusedRandomPort() fails intermittently, but exception not reported Reviewed-by: alanb, dmocek, smarks ! test/java/rmi/testlibrary/TestLibrary.java Changeset: 41a1b110f34d Author: lancea Date: 2012-12-06 15:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/41a1b110f34d 8004374: CachedRowSetSwriter.writeData reports wrong number of conflicts in SyncProviderException Reviewed-by: naoto ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java Changeset: 896d4af2ebfd Author: rfield Date: 2012-12-06 21:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/896d4af2ebfd 8003881: Prevent lambda implementing inner classes from allowing the creation of new instances Summary: Lambda implementing inner classes now has private constructor (thanks Kumar) Reviewed-by: ksrini ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java + test/java/lang/invoke/lambda/LambdaAccessControlTest.java Changeset: da387f0cecb7 Author: ksrini Date: 2012-12-09 07:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/da387f0cecb7 8004042: Arrrghs.java test failed on windows with access error. Reviewed-by: smarks, jjh, ksrini Contributed-by: david.dehaven at oracle.com ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: 343615aa0539 Author: dxu Date: 2012-12-09 19:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/343615aa0539 7194370: (fs) WatchService fails if volume S/N is 0 [win] Reviewed-by: alanb, forax ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java Changeset: fda257689786 Author: okutsu Date: 2012-12-10 10:52 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fda257689786 8000983: Support narrow display names for calendar fields 8003267: Support generic time zone names in TimeZoneNameProvider (SPI) Reviewed-by: naoto ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/BundleGenerator.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java ! make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java ! make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/java/util/spi/TimeZoneNameProvider.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/be/FormatData_be.java ! src/share/classes/sun/text/resources/bg/FormatData_bg.java ! src/share/classes/sun/text/resources/ca/FormatData_ca.java ! src/share/classes/sun/text/resources/cs/FormatData_cs.java ! src/share/classes/sun/text/resources/da/FormatData_da.java ! src/share/classes/sun/text/resources/de/FormatData_de.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/es/FormatData_es.java ! src/share/classes/sun/text/resources/et/FormatData_et.java ! src/share/classes/sun/text/resources/fi/FormatData_fi.java ! src/share/classes/sun/text/resources/fr/FormatData_fr.java ! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/hu/FormatData_hu.java ! src/share/classes/sun/text/resources/is/FormatData_is.java ! src/share/classes/sun/text/resources/it/FormatData_it.java ! src/share/classes/sun/text/resources/iw/FormatData_iw.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/lt/FormatData_lt.java ! src/share/classes/sun/text/resources/lv/FormatData_lv.java ! src/share/classes/sun/text/resources/mk/FormatData_mk.java ! src/share/classes/sun/text/resources/ms/FormatData_ms.java ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! src/share/classes/sun/text/resources/nl/FormatData_nl.java ! src/share/classes/sun/text/resources/pl/FormatData_pl.java ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! src/share/classes/sun/text/resources/ro/FormatData_ro.java ! src/share/classes/sun/text/resources/ru/FormatData_ru.java ! src/share/classes/sun/text/resources/sk/FormatData_sk.java ! src/share/classes/sun/text/resources/sl/FormatData_sl.java ! src/share/classes/sun/text/resources/sq/FormatData_sq.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/th/FormatData_th.java ! src/share/classes/sun/text/resources/tr/FormatData_tr.java ! src/share/classes/sun/text/resources/uk/FormatData_uk.java ! src/share/classes/sun/text/resources/vi/FormatData_vi.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java + test/java/util/Calendar/GenericTimeZoneNamesTest.java + test/java/util/Calendar/GenericTimeZoneNamesTest.sh + test/java/util/Calendar/NarrowNamesTest.java + test/java/util/Calendar/NarrowNamesTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.sh ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: fda2b2b5b98b Author: michaelm Date: 2012-12-10 14:56 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fda2b2b5b98b 8003948: NTLM/Negotiate authentication problem Reviewed-by: chegar, weijun ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/MessageHeaderTest.java Changeset: cac1bfaceaaa Author: mchung Date: 2012-12-10 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cac1bfaceaaa 4819681: Typo in http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html Summary: Simple capitalization typo in LogManager() description Reviewed-by: darcy, mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: 883feced1cdd Author: dingxmin Date: 2012-12-11 10:42 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/883feced1cdd 6512101: Incorrect encoding in NetworkInterface.getDisplayName() Reviewed-by: chegar, dsamersoff ! src/windows/native/java/net/NetworkInterface.c Changeset: d206e52bf8a6 Author: weijun Date: 2012-12-11 13:14 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d206e52bf8a6 8004488: wrong permissions checked in krb5 Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java + test/sun/security/krb5/auto/KeyPermissions.java ! test/sun/security/krb5/auto/KeyTabCompat.java Changeset: c4bd81de2868 Author: akhil Date: 2012-12-11 15:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c4bd81de2868 8003246: Add InitialValue Supplier to ThreadLocal Reviewed-by: mduigou, forax, dl, chegar, briangoetz ! src/share/classes/java/lang/ThreadLocal.java + test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java Changeset: 6c795437f212 Author: mduigou Date: 2012-12-11 20:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6c795437f212 8004905: Correct license of test to remove classpath exception Reviewed-by: akhil ! test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java Changeset: 12fba0974a9d Author: weijun Date: 2012-12-12 18:39 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/12fba0974a9d 8004904: Makefile for ntlm Reviewed-by: erikj, chegar ! make/com/sun/security/Makefile + make/com/sun/security/ntlm/Makefile Changeset: 806cf26e5063 Author: chegar Date: 2012-12-12 11:35 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/806cf26e5063 8004921: Trivial javadoc warnings in Base64 Reviewed-by: darcy ! src/share/classes/java/util/Base64.java Changeset: 81640e75c7a7 Author: alanb Date: 2012-12-12 13:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/81640e75c7a7 8004874: Reduce dependency on java.beans to only add/removePropertyChangeListener Reviewed-by: ksrini, mchung, dholmes ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/java/util/logging/LogManager.java Changeset: 346c0af4af41 Author: mullan Date: 2012-12-12 09:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/346c0af4af41 8004064: Downgrade normative references to ${java.home}/lib/security/java.security Reviewed-by: alanb, vinnie, xuelei ! src/share/classes/com/sun/net/ssl/KeyManagerFactory.java ! src/share/classes/com/sun/net/ssl/TrustManagerFactory.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/java/net/doc-files/net-properties.html ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/callback/CallbackHandler.java ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/cert/X509Certificate.java Changeset: c7f86908d5fd Author: mullan Date: 2012-12-12 09:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c7f86908d5fd Merge - src/share/lib/security/java.security Changeset: 68374c6e65c1 Author: robm Date: 2012-12-12 15:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/68374c6e65c1 8004337: java/sql tests aren't run in test/Makefile Reviewed-by: lancea, alanb ! test/Makefile Changeset: bd84d0927a2e Author: smarks Date: 2012-12-12 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bd84d0927a2e 8004748: clean up @build tags in RMI tests Reviewed-by: alanb, darcy, mchung ! test/java/rmi/MarshalledObject/compare/Compare.java ! test/java/rmi/MarshalledObject/compare/HashCode.java ! test/java/rmi/MarshalledObject/compare/NullReference.java ! test/java/rmi/Naming/DefaultRegistryPort.java ! test/java/rmi/Naming/LookupIPv6.java ! test/java/rmi/Naming/RmiIsNoScheme.java ! test/java/rmi/Naming/UnderscoreHost.java ! test/java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java ! test/java/rmi/RMISecurityManager/checkPackageAccess/CheckPackageAccess.java ! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java ! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java ! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java ! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java ! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java ! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java ! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java ! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java ! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java ! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java ! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java ! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java ! test/java/rmi/activation/Activatable/restartService/RestartService.java ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java ! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java ! test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java ! test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/CommandEnvironment/NullOptions.java ! test/java/rmi/activation/CommandEnvironment/SetChildEnv.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/activation/log/LogTest.java ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/dgc/VMID/CheckVMID.java ! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java ! test/java/rmi/dgc/dgcImplInsulation/DGCImplInsulation.java ! test/java/rmi/dgc/retryDirtyCalls/RetryDirtyCalls.java ! test/java/rmi/invalidName/InvalidName.java ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/checkusage/CheckUsage.java ! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/java/rmi/registry/interfaceHash/InterfaceHash.java ! test/java/rmi/registry/multipleRegistries/MultipleRegistries.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/reliability/benchmark/runRmiBench.sh ! test/java/rmi/reliability/benchmark/runSerialBench.sh ! test/java/rmi/reliability/juicer/AppleUserImpl.java ! test/java/rmi/server/ObjID/randomIDs/RandomIDs.java ! test/java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java ! test/java/rmi/server/RMIClassLoader/delegateToContextLoader/DelegateToContextLoader.java ! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java ! test/java/rmi/server/RMIClassLoader/getClassAnnotation/NullClass.java ! test/java/rmi/server/RMIClassLoader/getClassLoader/GetClassLoader.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java ! test/java/rmi/server/RMIClassLoader/noSecurityManager/NoSecurityManager.java ! test/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java ! test/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Installed.java ! test/java/rmi/server/RMIClassLoader/spi/InvalidProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Property.java ! test/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java ! test/java/rmi/server/RMIClassLoader/useGetURLs/UseGetURLs.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java ! test/java/rmi/server/RemoteObject/notExtending/NotExtending.java ! test/java/rmi/server/RemoteObject/verifyRemoteEquals/VerifyRemoteEquals.java ! test/java/rmi/server/RemoteServer/AddrInUse.java ! test/java/rmi/server/UnicastRemoteObject/changeHostName/ChangeHostName.java ! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/KeepAliveDuringCall.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport2.java ! test/java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java ! test/java/rmi/server/Unmarshal/PrimitiveClasses.java + test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshal.java ! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshalOnStopThread.java - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java ! test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java ! test/java/rmi/server/Unreferenced/marshalledObjectGet/MarshalledObjectGet.java ! test/java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java ! test/java/rmi/server/clientStackTrace/ClientStackTrace.java ! test/java/rmi/server/getRemoteClass/GetRemoteClass.java ! test/java/rmi/server/serverStackTrace/ServerStackTrace.java ! test/java/rmi/server/serverStackTrace/SuppressStackTraces.java ! test/java/rmi/server/useCustomRef/UseCustomRef.java ! test/java/rmi/transport/acceptLoop/CloseServerSocketOnTermination.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java ! test/java/rmi/transport/handshakeFailure/HandshakeFailure.java ! test/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java ! test/java/rmi/transport/httpSocket/HttpSocketTest.java ! test/java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java ! test/java/rmi/transport/readTimeout/ReadTimeoutTest.java ! test/java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java ! test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java ! test/javax/rmi/ssl/SocketFactoryTest.java ! test/sun/rmi/log/ReliableLog/LogAlignmentTest.java ! test/sun/rmi/log/ReliableLog/SnapshotSize.java ! test/sun/rmi/rmic/RMIGenerator/RmicDefault.java ! test/sun/rmi/rmic/newrmic/equivalence/run.sh ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java ! test/sun/rmi/server/MarshalOutputStream/marshalForeignStub/MarshalForeignStub.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java ! test/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java Changeset: 56fd5479a98f Author: jgish Date: 2012-12-12 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/56fd5479a98f 8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win) Summary: Failure to delete test log file should be a warning instead of test failure Reviewed-by: mduigou, smarks ! test/java/util/logging/CheckLockLocationTest.java Changeset: 5a2ab2c3f106 Author: weijun Date: 2012-12-13 08:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5a2ab2c3f106 8004235: Disable native JGSS provider on Mac Reviewed-by: erikj, valeriep ! make/sun/security/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java Changeset: 7a8978a5bb6e Author: lancea Date: 2012-12-12 20:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7a8978a5bb6e 8004357: Implement various methods in SerialBlob/Clob/Array and specify Thread Safety Reviewed-by: naoto ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: 775b0050144a Author: chegar Date: 2012-12-13 09:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/775b0050144a 8004925: java/net/Socks/SocksV4Test.java failing on all platforms Reviewed-by: alanb, dsamersoff ! test/java/net/Socks/SocksV4Test.java Changeset: 682d2d3ccff5 Author: chegar Date: 2012-12-13 14:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/682d2d3ccff5 8004675: Inet6Address.getHostAddress should use string scope identifier where available Summary: ...and some minor stylistic cleanup Reviewed-by: khazra, dsamersoff, michaelm ! src/share/classes/java/net/Inet6Address.java ! src/share/native/java/net/Inet6Address.c + test/java/net/Inet6Address/StringScope.java Changeset: c97618a3c8c2 Author: juh Date: 2012-12-13 09:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c97618a3c8c2 7193792: sun/security/pkcs11/ec/TestECDSA.java failing intermittently Reviewed-by: vinnie, wetmore ! test/ProblemList.txt ! test/sun/security/pkcs11/ec/TestECDSA.java Changeset: 7b697da6626a Author: mullan Date: 2012-12-13 09:37 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7b697da6626a Merge Changeset: ae5d04dbacd6 Author: chegar Date: 2012-12-13 14:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ae5d04dbacd6 8003890: corelibs test scripts should pass TESTVMOPTS Reviewed-by: chegar, alanb Contributed-by: Mark Sheppard ! test/com/oracle/net/sanity.sh ! test/com/sun/corba/cachedSocket/7056731.sh ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/com/sun/tools/attach/ApplicationSetup.sh ! test/com/sun/tools/attach/BasicTests.sh ! test/com/sun/tools/attach/PermissionTests.sh ! test/com/sun/tools/attach/ProviderTests.sh ! test/com/sun/tools/extcheck/TestExtcheckArgs.sh ! test/demo/zipfs/basic.sh ! test/java/io/File/GetXSpace.sh ! test/java/io/File/MacPathTest.sh ! test/java/io/File/basic.sh ! test/java/io/FileOutputStream/FileOpen.sh ! test/java/io/Serializable/class/run.sh ! test/java/io/Serializable/evolution/AddedExternField/run.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/maskSyntheticModifier/run.sh ! test/java/io/Serializable/packageAccess/run.sh ! test/java/io/Serializable/resolveClass/consTest/run.sh ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh ! test/java/io/Serializable/subclass/run.sh ! test/java/io/Serializable/superclassDataLoss/run.sh ! test/java/io/Serializable/unnamedPackageSwitch/run.sh ! test/java/lang/Class/forName/NonJavaNames.sh ! test/java/lang/ClassLoader/Assert.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/ClassLoader/getdotresource.sh ! test/java/lang/Runtime/exec/setcwd.sh ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/System/finalization/FinExit.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/InetAddress/ptr/lookup.sh ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/getresourceasstream/test.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/UNCTest.sh ! test/java/nio/Buffer/LimitDirectMemory.sh ! test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh ! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh ! test/java/nio/charset/Charset/default.sh ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/spi/basic.sh ! test/java/nio/file/Files/delete_on_close.sh ! test/java/nio/file/Files/walkFileTree/walk_file_tree.sh ! test/java/nio/file/Path/MacPathTest.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/reliability/benchmark/runSerialBench.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/security/cert/CertificateFactory/slowstream.sh ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh ! test/java/util/ServiceLoader/basic.sh ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.sh ! test/java/util/zip/3GBZipFiles.sh ! test/java/util/zip/ZipFile/deletetempjar.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/print/applet/AppletPrintLookup.sh ! test/javax/script/ProviderTest.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/misc/Cleaner/exitOnThrow.sh ! test/sun/net/InetAddress/nameservice/dns/cname.sh ! test/sun/net/sdp/sanity.sh ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/file/DirPermissionDenied.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/getcontenttype.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/rmi/rmic/manifestClassPath/run.sh ! test/sun/rmi/rmic/minimizeWrapperInstances/run.sh ! test/sun/rmi/rmic/oldjavacRemoved/sunToolsJavacMain.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/krb5/tools/ktcheck.sh ! test/sun/security/mscapi/AccessKeyStore.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/mscapi/KeyStoreCompatibilityMode.sh ! test/sun/security/mscapi/PublicKeyInterop.sh ! test/sun/security/mscapi/RSAEncryptDecrypt.sh ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/mscapi/SignUsingNONEwithRSA.sh ! test/sun/security/mscapi/SignUsingSHA2withRSA.sh ! test/sun/security/pkcs11/KeyStore/Basic.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh ! test/sun/security/pkcs11/KeyStore/Solaris.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/jarsigner/emptymanifest.sh ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/tools/launcher/6842838/Test6842838.sh ! test/tools/launcher/MultipleJRE.sh Changeset: 087425441a48 Author: robm Date: 2012-12-13 15:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/087425441a48 8000525: Java.net.httpcookie api does not support 2-digit year format Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/B6791927.java ! test/java/net/CookieHandler/CookieManagerTest.java + test/java/net/HttpCookie/ExpiredCookieTest.java Changeset: 8d7323a9d8ed Author: dholmes Date: 2012-12-13 21:18 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8d7323a9d8ed 8003632: HPROF class file version java.lang.RuntimeException errors Reviewed-by: mchung, lancea ! src/share/javavm/export/classfile_constants.h Changeset: de6b54a60d60 Author: lana Date: 2012-12-14 13:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/de6b54a60d60 Merge ! makefiles/CompileNativeLibraries.gmk - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 4ea0ac8e02d2 Author: erikj Date: 2012-12-19 09:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4ea0ac8e02d2 8004803: build-infra: Cannot use icedtea as boot for closed build. Summary: Set bootclasspath to javac and not the running jvm Reviewed-by: ohair ! makefiles/CreateJars.gmk Changeset: a8012d8d7e9c Author: katleman Date: 2012-12-19 13:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a8012d8d7e9c Merge Changeset: 4d5db5c038b4 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4d5db5c038b4 Added tag jdk8-b69 for changeset a8012d8d7e9c ! .hgtags Changeset: ad6097d547e1 Author: kvn Date: 2012-12-18 17:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ad6097d547e1 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/classes/sun/misc/Unsafe.java Changeset: 12fa4d7ecaf5 Author: twisti Date: 2012-12-20 11:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/12fa4d7ecaf5 8005345: JSR 292: JDK performance tweaks Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/sun/invoke/util/ValueConversions.java Changeset: 8cf5b18488d1 Author: dl Date: 2012-12-20 12:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8cf5b18488d1 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Add Unsafe addAndGet() methods which have intrinsics in Hotspot (7023898) Reviewed-by: alanb, kvn ! src/share/classes/sun/misc/Unsafe.java Changeset: 6b41b40526c6 Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6b41b40526c6 Merge Changeset: 1ad29569d6e9 Author: erikj Date: 2012-12-20 13:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1ad29569d6e9 8005178: build-infra: Dependency on libfdlibm on mac is broken Reviewed-by: tbell, ohair ! makefiles/CompileNativeLibraries.gmk Changeset: a68090f0dc1a Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a68090f0dc1a 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/macosx/native/sun/font/CCharToGlyphMapper.m ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java ! src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/native/java/util/zip/zlib-1.2.5/gzlib.c ! src/solaris/native/common/jdk_util_md.h ! src/solaris/native/sun/tools/attach/BsdVirtualMachine.c ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/native/common/jdk_util_md.h ! test/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI/7089914/bug7089914.java ! test/java/awt/Focus/6981400/Test1.java ! test/java/awt/Focus/6981400/Test2.java ! test/java/awt/Focus/6981400/Test3.java ! test/java/awt/Frame/ResizeAfterSetFont/ResizeAfterSetFont.java ! test/java/awt/JAWT/JAWT.sh ! test/java/awt/JAWT/Makefile.cygwin ! test/java/awt/JAWT/Makefile.unix ! test/java/awt/JAWT/Makefile.win ! test/java/awt/JAWT/MyCanvas.java ! test/java/awt/JAWT/myfile.c ! test/java/awt/JAWT/myfile.cpp ! test/java/awt/TextArea/DisposeTest/TestDispose.java ! test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java ! test/java/awt/TextField/DisposeTest/TestDispose.java ! test/java/lang/Integer/Unsigned.java ! test/java/lang/Long/Unsigned.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Tests.java ! test/java/lang/StringBuffer/TestSynchronization.java ! test/java/lang/invoke/remote/RemoteExample.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/net/Inet4Address/PingThis.java ! test/java/net/ProxySelector/MultiThreadedSystemProxies.java ! test/java/security/Signature/VerifyRangeCheckOverflow.java ! test/java/util/AbstractCollection/ToArrayTest.java ! test/java/util/Map/EntryHashCode.java ! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/SimpleFormatterFormat.java ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB.xml ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB_ja.xml ! test/javax/swing/JComponent/7154030/bug7154030.java ! test/javax/swing/JTabbedPane/4310381/bug4310381.java ! test/javax/swing/JTable/4235420/bug4235420.java ! test/javax/swing/JTable/6788484/bug6788484.java ! test/javax/swing/JTable/7055065/bug7055065.java ! test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java ! test/javax/swing/JTextArea/7049024/bug7049024.java ! test/javax/swing/border/Test7022041.java ! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java ! test/sun/management/AgentCMETest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/nio/ch/SelProvider.java ! test/sun/rmi/rmic/classpath/RMICClassPathTest.java ! test/sun/security/krb5/auto/ReplayCache.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java ! test/sun/tools/jps/jps-V_2.sh ! test/tools/jar/JarBackSlash.java ! test/tools/launcher/UnicodeTest.java Changeset: 9dc1990c7d90 Author: yhuang Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9dc1990c7d90 7195759: ISO 4217 Amendment 154 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/CurrencyNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cbf255324369 Author: yhuang Date: 2012-12-23 19:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cbf255324369 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: a996b57e5541 Author: katleman Date: 2012-12-26 14:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a996b57e5541 Merge Changeset: 8d7651351cfe Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8d7651351cfe Added tag jdk8-b70 for changeset a996b57e5541 ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:05:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:05:26 +0000 Subject: hg: hsx/hotspot-comp/langtools: 10 new changesets Message-ID: <20121228050555.8FFB6473FF@hg.openjdk.java.net> Changeset: c78acf6c2f3e Author: mcimadamore Date: 2012-12-10 12:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c78acf6c2f3e 8004094: Javac compiler error - synthetic method accessor generated with duplicate name Summary: method clash check logic should skip methods marked with ACC_SYNTHETIC Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/8004094/B.java + test/tools/javac/generics/8004094/T8004094.java Changeset: fcf89720ae71 Author: vromero Date: 2012-12-10 16:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fcf89720ae71 8003967: detect and remove all mutable implicit static enum fields in langtools Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/javac/Server.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/javax/lang/model/element/Modifier.java ! src/share/classes/javax/lang/model/util/ElementFilter.java ! src/share/classes/javax/tools/StandardLocation.java + test/tools/javac/T8003967/DetectMutableStaticFields.java Changeset: cfde9737131e Author: jjg Date: 2012-12-11 15:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/cfde9737131e 8004828: refactor init of *DocImpl classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java Changeset: 170e486632d9 Author: jlahoda Date: 2012-12-12 20:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/170e486632d9 8004504: ListBuffer could reuse List.nil() as the sentinel element Summary: ListBuffer.last now points to the last elements with client data, or null if none. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java + test/tools/javac/util/list/ListBufferTest.java Changeset: 376d6c1b49e5 Author: jfranck Date: 2012-12-03 11:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/376d6c1b49e5 8001114: Container annotation is not checked for semantic correctness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out + test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java + test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/tools/javac/diags/examples/ContainedByNonDefault.java + test/tools/javac/diags/examples/InvalidDuplicateAnnotation.java Changeset: d7360bf35ee1 Author: lana Date: 2012-12-14 13:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d7360bf35ee1 Merge Changeset: 2001991b1b40 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2001991b1b40 Added tag jdk8-b69 for changeset d7360bf35ee1 ! .hgtags Changeset: 7d34e91f66bb Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/7d34e91f66bb 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! make/Makefile-classic ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! test/tools/javac/StringsInSwitch/StringSwitches.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java ! test/tools/javac/diags/examples/DuplicateAnnotation.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 47f71d7c124f Author: katleman Date: 2012-12-26 14:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/47f71d7c124f Merge Changeset: 7d5032c2d747 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/7d5032c2d747 Added tag jdk8-b70 for changeset 47f71d7c124f ! .hgtags From vladimir.kozlov at oracle.com Fri Dec 28 17:07:13 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 28 Dec 2012 17:07:13 -0800 Subject: RFR (S) 8003251: ARM: move MacroAssembler into separate file In-Reply-To: <50DDBB78.4090102@oracle.com> References: <50DDBB78.4090102@oracle.com> Message-ID: <50DE4241.7030601@oracle.com> Looks good. I created webrev on open server: http://cr.openjdk.java.net/~kvn/8003251/webrev/ Thanks, Vladimir On 12/28/12 7:32 AM, Morris Meyer wrote: > Folks, > > Could I get a review of this refactoring requested by Christian > Thalinger? Per the workflow I've done a JPRT run. > > Thanks in advance, > > --mm > > WEBREV - > http://javaweb.us.oracle.com/~mameyer/webrevs/01/JDK-8003251-hotspot From Alan.Bateman at oracle.com Thu Dec 20 08:34:52 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Dec 2012 16:34:52 -0000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50D33BED.2080805@oracle.com> References: <50BD2972.4090603@oracle.com> <50BD2ABB.30703@oracle.com> <50BF3144.4070404@oracle.com> <50D30DB7.4020701@oracle.com> <50D33BED.2080805@oracle.com> Message-ID: <50D33E26.10104@oracle.com> On 20/12/2012 16:25, Vladimir Kozlov wrote: > Hi Alan, > > Can we push it through our hotspot-main/jdk repo? I will send formal > review into open today. Should I use core-libs-dev list for that? > > https://jbs.oracle.com/bugs/browse/JDK-8004330 > http://shipilev.net/pub/jdk/hotspot/unsafe-getandadd/webrev-1/ > > As Aleksey pointed it is java side for Hotspot intrinsics we added > some time ago: > > https://jbs.oracle.com/bugs/browse/JDK-7023898 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7eca5de9e0b6 > > Thanks, > Vladimir I don't see a problem pushing it via hotspot-main/jdk, I'm pretty sure the jsr292 changes to the jdk repo take that route. It would be nice to cc'ing core-libs-dev on the review. One little comment is that it would be nice to have more complete javadoc, also @since is useful. -Alan