From kim.barrett at oracle.com Tue Feb 7 01:03:44 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 6 Feb 2017 20:03:44 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: References: Message-ID: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> Apologies for taking so long to respond to earlier comments. I've been distracted by some other tasks, and it took a while to figure out what to do about the problem Mikael reported. Martin Doerr - Thanks for the ppc and s390 native call generator modifications. Do you want a contributed-by credit when pushed? Andrew Haley - Thanks for the syntax fix. The new version with always tagged jweaks (see below) makes testing easier, and there's a new test included. Testing the G1-specific behavior still needs the whitebox extension. I've updated the G1-specific test (which is still not part of the changeset for JDK 9). Per Liden - I tried your suggestion of making jweak unconditionally tagged. It doesn't eliminate much of the INCLUDE_ALL_GCS conditionals, since those are still needed to protect references to G1-specific code. (The littering of otherwise generic runtime code with this G1-specific stuff should be a cleanup task for JDK 10.) However, it does simplify some of the code, and simplifies testing. The cost is a "bit-test and (predicted taken) conditional branch" in the handling of an oop result from a native call. I agree that's unlikely to be noticable, and the benefits seem worthwhile, so I've made that change. I've attempted to update the platform-specific native call return handling changes for all of the platforms, including those I don't have access to (aarch64, ppc, s390). I also fixed the zero change I'd made earlier. And I made shark error, to force anyone using it to fix the handling of an oop result by SharkNativeWrapper::initialize(). There might be other zero/shark changes that I've missed. All of these should be checked by appropriate platform experts. I had to fix a JVMTI bug as part of this; FollowReferences wasn't doing as much argument checking as expected. This was unconvered by a closed test that unexpectedly asserted. This test would have similarly asserted previously if CheckJNICalls was true; I removed that conditionalization in JNIHandles::resolve, as it was only there to avoid an expensive check for the jobject being a jweak, and in the new code we already know it isn't. There might be other JVMTI functions with similar issues. Mikael - There are some ugly worms lurking under that rock! I think I've dealt with the problem, tripping over some other bugs along the way. Thanks for the test case. I tweaked it a bit and included it in the updated changeset. The passing of arguments involves collecting them into a JavaCallArguments object. oop arguments are in some handlized form (either jobject or Handle). The existing code heavily cheats; for example, it assumes one can correctly cast from a jobject to an oop* and dereference that pointer. Obviously, a tagged jweak breaks that assumption. Even worse, there are casts from oop* to oop and back! (These are so nasty they *must* use C-style cast syntax.) I'm thinking about some followup cleanup bugs in that area. To address this, I changed JavaCallArguments to avoid conversions from jobject to Handle/oop*. To support that, it now keeps more accurate track of the state of the object references in the collected arguments. It also delays resolving jobjects to their designated oops, avoiding intermediate Handle objects. (This was a place where cheating was going on, in order to avoid intermediate Handle allocations. We're now accomplishing that without crashing through the JNIHandles abstraction.) CR: https://bugs.openjdk.java.net/browse/JDK-8166188 New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04 incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.inc The full webrev may be more useful than the incremental; some of the incremental changes are pretty hard to read. Some additional webrevs that might be helpful: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.other-platforms Incremental changes for aarch64, ppc, and s390 supplied by Andrew and Martin. http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.always_tag[.full] Incremental [full] changes to always tag jweaks. The full webrev may be more useful than the incremental; some of the incremental changes are pretty hard to read. http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.java_call Incremental changes to address the java call problem found by Mikael. hotspot.04 == hotspot.02 + hotspot.04.inc hotspot.04 == hotspot.04.always_tag.full + hotspot.04.java_call hotspot.04 == hotspot.02 + hotspot.04.other-platforms + hotspot.04.always_tag + hotspot.04.java_call The updated G1-specific test requiring the whitebox extension is http://cr.openjdk.java.net/~kbarrett/8166188/test.04 The whitebox extension has not changed: http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/ http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/ From martin.doerr at sap.com Tue Feb 7 13:59:16 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 7 Feb 2017 13:59:16 +0000 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> Message-ID: <4f5a4b9c9ea4422b95b49a7824c2b1db@DEWDFE13DE02.global.corp.sap> Hi Kim, thanks for adding and adapting my code. There's only one minor bug on PPC64. Please use the correct label name for the conditional branch as shown in the diff below. If you like, you can add simonis and mdoerr as contributors, but I don't insist on it. I guess SignatureChekker was written with "kk" to distinguish it from something else? Besides that, the change looks good to me. Thanks and best regards, Martin --- a/src/cpu/ppc/vm/sharedRuntime_ppc.cpp Tue Feb 07 12:48:05 2017 +0100 +++ b/src/cpu/ppc/vm/sharedRuntime_ppc.cpp Tue Feb 07 14:30:48 2017 +0100 @@ -2483,7 +2483,7 @@ if (ret_type == T_OBJECT || ret_type == T_ARRAY) { Label done, not_weak; __ cmpdi(CCR0, R3_RET, 0); - __ beq(CCR0, null_result); // Use NULL as-is. + __ beq(CCR0, done); // Use NULL as-is. __ andi_(r_temp_1, R3_RET, JNIHandles::weak_tag_mask); __ beq(CCR0, not_weak); // Test for jweak tag. -----Original Message----- From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Kim Barrett Sent: Dienstag, 7. Februar 2017 02:04 To: hotspot-dev developers Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles Apologies for taking so long to respond to earlier comments. I've been distracted by some other tasks, and it took a while to figure out what to do about the problem Mikael reported. Martin Doerr - Thanks for the ppc and s390 native call generator modifications. Do you want a contributed-by credit when pushed? Andrew Haley - Thanks for the syntax fix. The new version with always tagged jweaks (see below) makes testing easier, and there's a new test included. Testing the G1-specific behavior still needs the whitebox extension. I've updated the G1-specific test (which is still not part of the changeset for JDK 9). Per Liden - I tried your suggestion of making jweak unconditionally tagged. It doesn't eliminate much of the INCLUDE_ALL_GCS conditionals, since those are still needed to protect references to G1-specific code. (The littering of otherwise generic runtime code with this G1-specific stuff should be a cleanup task for JDK 10.) However, it does simplify some of the code, and simplifies testing. The cost is a "bit-test and (predicted taken) conditional branch" in the handling of an oop result from a native call. I agree that's unlikely to be noticable, and the benefits seem worthwhile, so I've made that change. I've attempted to update the platform-specific native call return handling changes for all of the platforms, including those I don't have access to (aarch64, ppc, s390). I also fixed the zero change I'd made earlier. And I made shark error, to force anyone using it to fix the handling of an oop result by SharkNativeWrapper::initialize(). There might be other zero/shark changes that I've missed. All of these should be checked by appropriate platform experts. I had to fix a JVMTI bug as part of this; FollowReferences wasn't doing as much argument checking as expected. This was unconvered by a closed test that unexpectedly asserted. This test would have similarly asserted previously if CheckJNICalls was true; I removed that conditionalization in JNIHandles::resolve, as it was only there to avoid an expensive check for the jobject being a jweak, and in the new code we already know it isn't. There might be other JVMTI functions with similar issues. Mikael - There are some ugly worms lurking under that rock! I think I've dealt with the problem, tripping over some other bugs along the way. Thanks for the test case. I tweaked it a bit and included it in the updated changeset. The passing of arguments involves collecting them into a JavaCallArguments object. oop arguments are in some handlized form (either jobject or Handle). The existing code heavily cheats; for example, it assumes one can correctly cast from a jobject to an oop* and dereference that pointer. Obviously, a tagged jweak breaks that assumption. Even worse, there are casts from oop* to oop and back! (These are so nasty they *must* use C-style cast syntax.) I'm thinking about some followup cleanup bugs in that area. To address this, I changed JavaCallArguments to avoid conversions from jobject to Handle/oop*. To support that, it now keeps more accurate track of the state of the object references in the collected arguments. It also delays resolving jobjects to their designated oops, avoiding intermediate Handle objects. (This was a place where cheating was going on, in order to avoid intermediate Handle allocations. We're now accomplishing that without crashing through the JNIHandles abstraction.) CR: https://bugs.openjdk.java.net/browse/JDK-8166188 New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04 incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.inc The full webrev may be more useful than the incremental; some of the incremental changes are pretty hard to read. Some additional webrevs that might be helpful: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.other-platforms Incremental changes for aarch64, ppc, and s390 supplied by Andrew and Martin. http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.always_tag[.full] Incremental [full] changes to always tag jweaks. The full webrev may be more useful than the incremental; some of the incremental changes are pretty hard to read. http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.java_call Incremental changes to address the java call problem found by Mikael. hotspot.04 == hotspot.02 + hotspot.04.inc hotspot.04 == hotspot.04.always_tag.full + hotspot.04.java_call hotspot.04 == hotspot.02 + hotspot.04.other-platforms + hotspot.04.always_tag + hotspot.04.java_call The updated G1-specific test requiring the whitebox extension is http://cr.openjdk.java.net/~kbarrett/8166188/test.04 The whitebox extension has not changed: http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/ http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/ From kim.barrett at oracle.com Tue Feb 7 22:29:22 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 7 Feb 2017 17:29:22 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <4f5a4b9c9ea4422b95b49a7824c2b1db@DEWDFE13DE02.global.corp.sap> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <4f5a4b9c9ea4422b95b49a7824c2b1db@DEWDFE13DE02.global.corp.sap> Message-ID: <840D74CC-0ABA-43C4-BDC8-9A012E44CA79@oracle.com> > On Feb 7, 2017, at 8:59 AM, Doerr, Martin wrote: > > Hi Kim, > > thanks for adding and adapting my code. There's only one minor bug on PPC64. Please use the correct label name for the conditional branch as shown in the diff below. > > If you like, you can add simonis and mdoerr as contributors, but I don't insist on it. > > I guess SignatureChekker was written with "kk" to distinguish it from something else? > > Besides that, the change looks good to me. > > Thanks and best regards, > Martin > > > --- a/src/cpu/ppc/vm/sharedRuntime_ppc.cpp Tue Feb 07 12:48:05 2017 +0100 > +++ b/src/cpu/ppc/vm/sharedRuntime_ppc.cpp Tue Feb 07 14:30:48 2017 +0100 > @@ -2483,7 +2483,7 @@ > if (ret_type == T_OBJECT || ret_type == T_ARRAY) { > Label done, not_weak; > __ cmpdi(CCR0, R3_RET, 0); > - __ beq(CCR0, null_result); // Use NULL as-is. > + __ beq(CCR0, done); // Use NULL as-is. > > __ andi_(r_temp_1, R3_RET, JNIHandles::weak_tag_mask); > __ beq(CCR0, not_weak); // Test for jweak tag. Oops. Thanks for the fix. And thanks for the review. From kim.barrett at oracle.com Wed Feb 8 03:02:31 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 7 Feb 2017 22:02:31 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <08918c3d-395c-2e29-36e5-d06128f45122@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <08918c3d-395c-2e29-36e5-d06128f45122@oracle.com> Message-ID: > On Feb 7, 2017, at 6:56 PM, dean.long at oracle.com wrote: > > Hi Kim. I took a look at the sharedRuntime_ and templateInterpreterGenerator_ for arm, sparc, and x86. > > In sharedRuntime_arm.cpp, I suggest simplifying: > > 1750 #ifdef AARCH64 > 1751 __ cbz(R0, done); // Use NULL as-is. > 1752 STATIC_ASSERT(JNIHandles::weak_tag_mask == 1u); > 1753 __ tbz(R0, 0, not_weak); // Test for jweak tag. > 1754 #else // !AARCH64 > > 1755 __ cmp(R0, 0); > > 1756 __ b(done, eq); // Use NULL as-is. > 1757 __ tst(R0, JNIHandles::weak_tag_mask); // Test for jweak tag. > 1758 __ b(not_weak, eq); > 1759 #endif // !AARCH64 > to the equivalent: > > 1751 __ cbz(R0, done); // Use NULL as-is. > 1752 STATIC_ASSERT(JNIHandles::weak_tag_mask == 1u); > 1753 __ tbz(R0, 0, not_weak); // Test for jweak tag. > as cbz and tbz expand to cmp/b and tst/b on arm32. The others look good. Nice! That will make it much more readable. Thanks. From kim.barrett at oracle.com Thu Feb 9 00:00:44 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 8 Feb 2017 19:00:44 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> Message-ID: <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> On Feb 8, 2017, at 5:13 PM, Daniel D. Daugherty wrote: > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04 > src/share/vm/runtime/javaCalls.cpp > L526: "signature does not matched pushed arguments: %u", state); > Typo: 'matched' -> 'match' > > For the guarantees on L522 and L525, would the (_pos - 1) value > be useful for diagnostic purposes? Done. > L569: if (v != 0 ) { > Not your bug, but there's an extra blank before the ")". Done. > L571: if (t < (size_t)os::vm_page_size()) { > Again, not your issue, but that size < page size check means > the oop is bad is screaming for a short comment. Added comment. Also removed the unnecessary intermediate variable t, thereby eliminating some casts. I'm not completly convinced by the comment, but remaining true to the existing code. Here's the diff: @@ -566,9 +568,10 @@ uint value_state = _value_state[p]; if (is_value_state_indirect_oop(value_state)) { intptr_t v = _value[p]; - if (v != 0 ) { - size_t t = (size_t)v; - if (t < (size_t)os::vm_page_size()) { + if (v != 0) { + if (v < os::vm_page_size()) { + // v is a "handle" referring to an oop, cast to integral type. + // There ought not be any handles in very low memory. bad = true; } else if (!resolve_indirect_oop(v, value_state)->is_oop_or_null(true)) { bad = true; > src/share/vm/runtime/jniHandles.cpp > (old) L115 assert(!CheckJNICalls || is_weak_global_handle(handle), "Invalid delete of weak global JNI handle"); > > Don't like the old assert? Is is_weak_global_handle() now obsolete? There is an is_jweak assert in jweak_ref. That's cheap (unlike is_weak_global_handle), so not conditional on CheckJNICalls. There are still a few calls to is_weak_global_handle. They all occur as alternatives with is_global_handle &etc, so I was reluctant to replace them with is_jweak (which would also require making that public). > src/cpu/s390/vm/templateInterpreterGenerator_s390.cpp > (old) L1705: __ verify_oop(Rlresult); > The delete of the verify_oop() call after the store_oop_result > label threw me for a few minutes. Then I realized that the > only uses of the store_oop_result label appear to be when we > have a NULL oop. New code is cleaner. There's another, after the G1 block. But it's preceeded by a verify_oop of its own. > src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp > Not your bug, but unlike sharedRuntime_sparc.cpp, there are no > verify_oop calls here. > > src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp > Not your bug, but unlike sharedRuntime_x86{32,64}.cpp, > there are no verify_oop calls here. I didn't add them where they weren't already present. I could be convinced to change that. > test/runtime/jni/CallWithJNIWeak/CallWithJNIWeak.java > jcheck will likely complain about the empty line at the end > of the file. > > test/runtime/jni/CallWithJNIWeak/libCallWithJNIWeak.c > Same empty line at the end of the file comment. Okay. I don't use jcheck until preparing to push, because it doesn't understand mq patches. > Thumbs up! If you choose to fix any of the nits above, I don't > need to see another webrev. Thanks, Dan. From dean.long at oracle.com Tue Feb 7 23:56:31 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 7 Feb 2017 15:56:31 -0800 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> Message-ID: <08918c3d-395c-2e29-36e5-d06128f45122@oracle.com> Hi Kim. I took a look at the sharedRuntime_ and templateInterpreterGenerator_ for arm, sparc, and x86. In sharedRuntime_arm.cpp, I suggest simplifying: 1750 #ifdef AARCH64 1751 __ cbz(R0, done); // Use NULL as-is. 1752 STATIC_ASSERT(JNIHandles::weak_tag_mask == 1u); 1753 __ tbz(R0, 0, not_weak); // Test for jweak tag. 1754 #else // !AARCH64 1755 __ cmp(R0, 0); 1756 __ b(done, eq); // Use NULL as-is. 1757 __ tst(R0, JNIHandles::weak_tag_mask); // Test for jweak tag. 1758 __ b(not_weak, eq); 1759 #endif // !AARCH64 to the equivalent: 1751 __ cbz(R0, done); // Use NULL as-is. 1752 STATIC_ASSERT(JNIHandles::weak_tag_mask == 1u); 1753 __ tbz(R0, 0, not_weak); // Test for jweak tag. as cbz and tbz expand to cmp/b and tst/b on arm32. The others look good. dl On 2/6/17 5:03 PM, Kim Barrett wrote: > Apologies for taking so long to respond to earlier comments. I've > been distracted by some other tasks, and it took a while to figure out > what to do about the problem Mikael reported. > > Martin Doerr - Thanks for the ppc and s390 native call generator > modifications. Do you want a contributed-by credit when pushed? > > Andrew Haley - Thanks for the syntax fix. The new version with always > tagged jweaks (see below) makes testing easier, and there's a new test > included. Testing the G1-specific behavior still needs the whitebox > extension. I've updated the G1-specific test (which is still not part > of the changeset for JDK 9). > > Per Liden - I tried your suggestion of making jweak unconditionally > tagged. It doesn't eliminate much of the INCLUDE_ALL_GCS > conditionals, since those are still needed to protect references to > G1-specific code. (The littering of otherwise generic runtime code > with this G1-specific stuff should be a cleanup task for JDK 10.) > However, it does simplify some of the code, and simplifies testing. > The cost is a "bit-test and (predicted taken) conditional branch" in > the handling of an oop result from a native call. I agree that's > unlikely to be noticable, and the benefits seem worthwhile, so I've > made that change. > > I've attempted to update the platform-specific native call return > handling changes for all of the platforms, including those I don't > have access to (aarch64, ppc, s390). I also fixed the zero change I'd > made earlier. And I made shark error, to force anyone using it to fix > the handling of an oop result by SharkNativeWrapper::initialize(). > There might be other zero/shark changes that I've missed. All of > these should be checked by appropriate platform experts. > > I had to fix a JVMTI bug as part of this; FollowReferences wasn't > doing as much argument checking as expected. This was unconvered by a > closed test that unexpectedly asserted. This test would have > similarly asserted previously if CheckJNICalls was true; I removed > that conditionalization in JNIHandles::resolve, as it was only there > to avoid an expensive check for the jobject being a jweak, and in the > new code we already know it isn't. There might be other JVMTI > functions with similar issues. > > Mikael - There are some ugly worms lurking under that rock! I think > I've dealt with the problem, tripping over some other bugs along the > way. Thanks for the test case. I tweaked it a bit and included it in > the updated changeset. > > The passing of arguments involves collecting them into a > JavaCallArguments object. oop arguments are in some handlized form > (either jobject or Handle). The existing code heavily cheats; for > example, it assumes one can correctly cast from a jobject to an oop* > and dereference that pointer. Obviously, a tagged jweak breaks that > assumption. Even worse, there are casts from oop* to oop and back! > (These are so nasty they *must* use C-style cast syntax.) I'm thinking > about some followup cleanup bugs in that area. > > To address this, I changed JavaCallArguments to avoid conversions > from jobject to Handle/oop*. To support that, it now keeps more > accurate track of the state of the object references in the collected > arguments. It also delays resolving jobjects to their designated > oops, avoiding intermediate Handle objects. (This was a place where > cheating was going on, in order to avoid intermediate Handle > allocations. We're now accomplishing that without crashing through > the JNIHandles abstraction.) > > CR: > https://bugs.openjdk.java.net/browse/JDK-8166188 > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04 > incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.inc > The full webrev may be more useful than the incremental; some of the > incremental changes are pretty hard to read. > > Some additional webrevs that might be helpful: > http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.other-platforms > Incremental changes for aarch64, ppc, and s390 supplied by Andrew and > Martin. > > http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.always_tag[.full] > Incremental [full] changes to always tag jweaks. > The full webrev may be more useful than the incremental; some of the > incremental changes are pretty hard to read. > > http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.java_call > Incremental changes to address the java call problem found by Mikael. > > hotspot.04 == hotspot.02 + hotspot.04.inc > hotspot.04 == hotspot.04.always_tag.full + hotspot.04.java_call > hotspot.04 == hotspot.02 + hotspot.04.other-platforms + > hotspot.04.always_tag + hotspot.04.java_call > > The updated G1-specific test requiring the whitebox extension is > http://cr.openjdk.java.net/~kbarrett/8166188/test.04 > > The whitebox extension has not changed: > http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/ > http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/ > > From daniel.daugherty at oracle.com Wed Feb 8 22:13:20 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Feb 2017 15:13:20 -0700 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> Message-ID: > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04 make/test/JtregNative.gmk No comments. src/share/vm/runtime/javaCalls.hpp No comments. src/share/vm/runtime/javaCalls.cpp L526: "signature does not matched pushed arguments: %u", state); Typo: 'matched' -> 'match' For the guarantees on L522 and L525, would the (_pos - 1) value be useful for diagnostic purposes? L569: if (v != 0 ) { Not your bug, but there's an extra blank before the ")". L571: if (t < (size_t)os::vm_page_size()) { Again, not your issue, but that size < page size check means the oop is bad is screaming for a short comment. src/share/vm/runtime/jniHandles.hpp (old) L208: *((oop*)handle) = deleted_handle(); // Mark the handle as deleted, allocate will reuse it The old comment was too obvious so you didn't keep it? :-) It threw me for a second when JNIHandles::resolve_non_null() was switched to use resolve_impl() instead of guard_value(), then I figured out that resolve_impl() uses guard_value(). src/share/vm/runtime/jniHandles.cpp (old) L115 assert(!CheckJNICalls || is_weak_global_handle(handle), "Invalid delete of weak global JNI handle"); Don't like the old assert? Is is_weak_global_handle() now obsolete? src/share/vm/prims/jni.cpp No comments. src/share/vm/prims/jvmtiEnv.cpp Need a copyright year update in this file. src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp No comments. src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp No comments. src/cpu/arm/vm/interp_masm_arm.cpp No comments on the code deletion. src/cpu/arm/vm/interp_masm_arm.hpp No comments on the code deletion. src/cpu/arm/vm/macroAssembler_arm.cpp OK, the code from interp_masm_arm.cpp moved here. Did not try to compare the two versions. src/cpu/arm/vm/macroAssembler_arm.hpp OK, the code from interp_masm_arm.hpp moved here. Did not try to compare the two versions. src/cpu/arm/vm/sharedRuntime_arm.cpp No comments. src/cpu/arm/vm/templateInterpreterGenerator_arm.cpp No comments. src/cpu/ppc/vm/frame_ppc.cpp No comments. src/cpu/ppc/vm/sharedRuntime_ppc.cpp No comments. src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp No comments. src/cpu/s390/vm/sharedRuntime_s390.cpp No comments. src/cpu/s390/vm/templateInterpreterGenerator_s390.cpp (old) L1705: __ verify_oop(Rlresult); The delete of the verify_oop() call after the store_oop_result label threw me for a few minutes. Then I realized that the only uses of the store_oop_result label appear to be when we have a NULL oop. New code is cleaner. src/cpu/sparc/vm/sharedRuntime_sparc.cpp No comments. src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp Not your bug, but unlike sharedRuntime_sparc.cpp, there are no verify_oop calls here. src/cpu/x86/vm/sharedRuntime_x86_32.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_64.cpp No comments. src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp Not your bug, but unlike sharedRuntime_x86{32,64}.cpp, there are no verify_oop calls here. src/cpu/zero/vm/cppInterpreter_zero.cpp No comments. src/share/vm/shark/sharkNativeWrapper.cpp No comments. test/runtime/jni/CallWithJNIWeak/CallWithJNIWeak.java jcheck will likely complain about the empty line at the end of the file. test/runtime/jni/CallWithJNIWeak/libCallWithJNIWeak.c Same empty line at the end of the file comment. test/runtime/jni/ReturnJNIWeak/ReturnJNIWeak.java No comments. test/runtime/jni/ReturnJNIWeak/libReturnJNIWeak.c Nit - libCallWithJNIWeak.c uses an indent of 4 spaces; this file uses an indent of 2 spaces. Should probably pick one... Thumbs up! If you choose to fix any of the nits above, I don't need to see another webrev. Dan On 2/6/17 6:03 PM, Kim Barrett wrote: > Apologies for taking so long to respond to earlier comments. I've > been distracted by some other tasks, and it took a while to figure out > what to do about the problem Mikael reported. > > Martin Doerr - Thanks for the ppc and s390 native call generator > modifications. Do you want a contributed-by credit when pushed? > > Andrew Haley - Thanks for the syntax fix. The new version with always > tagged jweaks (see below) makes testing easier, and there's a new test > included. Testing the G1-specific behavior still needs the whitebox > extension. I've updated the G1-specific test (which is still not part > of the changeset for JDK 9). > > Per Liden - I tried your suggestion of making jweak unconditionally > tagged. It doesn't eliminate much of the INCLUDE_ALL_GCS > conditionals, since those are still needed to protect references to > G1-specific code. (The littering of otherwise generic runtime code > with this G1-specific stuff should be a cleanup task for JDK 10.) > However, it does simplify some of the code, and simplifies testing. > The cost is a "bit-test and (predicted taken) conditional branch" in > the handling of an oop result from a native call. I agree that's > unlikely to be noticable, and the benefits seem worthwhile, so I've > made that change. > > I've attempted to update the platform-specific native call return > handling changes for all of the platforms, including those I don't > have access to (aarch64, ppc, s390). I also fixed the zero change I'd > made earlier. And I made shark error, to force anyone using it to fix > the handling of an oop result by SharkNativeWrapper::initialize(). > There might be other zero/shark changes that I've missed. All of > these should be checked by appropriate platform experts. > > I had to fix a JVMTI bug as part of this; FollowReferences wasn't > doing as much argument checking as expected. This was unconvered by a > closed test that unexpectedly asserted. This test would have > similarly asserted previously if CheckJNICalls was true; I removed > that conditionalization in JNIHandles::resolve, as it was only there > to avoid an expensive check for the jobject being a jweak, and in the > new code we already know it isn't. There might be other JVMTI > functions with similar issues. > > Mikael - There are some ugly worms lurking under that rock! I think > I've dealt with the problem, tripping over some other bugs along the > way. Thanks for the test case. I tweaked it a bit and included it in > the updated changeset. > > The passing of arguments involves collecting them into a > JavaCallArguments object. oop arguments are in some handlized form > (either jobject or Handle). The existing code heavily cheats; for > example, it assumes one can correctly cast from a jobject to an oop* > and dereference that pointer. Obviously, a tagged jweak breaks that > assumption. Even worse, there are casts from oop* to oop and back! > (These are so nasty they *must* use C-style cast syntax.) I'm thinking > about some followup cleanup bugs in that area. > > To address this, I changed JavaCallArguments to avoid conversions > from jobject to Handle/oop*. To support that, it now keeps more > accurate track of the state of the object references in the collected > arguments. It also delays resolving jobjects to their designated > oops, avoiding intermediate Handle objects. (This was a place where > cheating was going on, in order to avoid intermediate Handle > allocations. We're now accomplishing that without crashing through > the JNIHandles abstraction.) > > CR: > https://bugs.openjdk.java.net/browse/JDK-8166188 > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04 > incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.inc > The full webrev may be more useful than the incremental; some of the > incremental changes are pretty hard to read. > > Some additional webrevs that might be helpful: > http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.other-platforms > Incremental changes for aarch64, ppc, and s390 supplied by Andrew and > Martin. > > http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.always_tag[.full] > Incremental [full] changes to always tag jweaks. > The full webrev may be more useful than the incremental; some of the > incremental changes are pretty hard to read. > > http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04.java_call > Incremental changes to address the java call problem found by Mikael. > > hotspot.04 == hotspot.02 + hotspot.04.inc > hotspot.04 == hotspot.04.always_tag.full + hotspot.04.java_call > hotspot.04 == hotspot.02 + hotspot.04.other-platforms + > hotspot.04.always_tag + hotspot.04.java_call > > The updated G1-specific test requiring the whitebox extension is > http://cr.openjdk.java.net/~kbarrett/8166188/test.04 > > The whitebox extension has not changed: > http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/ > http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/ > > > From thomas.schatzl at oracle.com Fri Feb 10 10:49:50 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 10 Feb 2017 11:49:50 +0100 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> Message-ID: <1486723790.2702.39.camel@oracle.com> Hi Kim, On Mon, 2017-02-06 at 20:03 -0500, Kim Barrett wrote: > Apologies for taking so long to respond to earlier comments.??I've > been distracted by some other tasks, and it took a while to figure > out what to do about the problem Mikael reported. > > [...] > CR: > https://bugs.openjdk.java.net/browse/JDK-8166188 > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04 ?- ReturnJNIWeak.java: please make sure that the test is not called with -XX:+ExplicitGCInvokesConcurrent. It will most likely fail in this case. ?- jniHandles.hpp: it might be useful to explain the external_guard template parameter to the new guard_value/resolve_impl methods. This might be due to my unfamiliarity to the code, so skip this if you think it is "obvious" what this means. >From the callers of JNIHandles::resolve() I am actually not sure if the extra performance due to templatizing the parameter has any impact. Again, your call. ?- it would be nice if JNIHandles::weak_oops_do(BoolObjectClosure, OopClosure) would have an assert_at_safepoint_or_JNI_lock_locked() - but that's probably another issue. Same with the _global_handles array. ?- jniHandles.hpp:58. Not sure why the "int" type specifier for weak_tag_value has an extra space in front of it. ?- isn't is_global_handle() thread-unsafe too? The assert uses JNIHandleBlock::chain_contains(), which iterates over the JNIHandles array unguarded, but it seems possible to add entries concurrently using e.g. make_global()? I.e. one thread adding a global handle, another thread calling e.g. jni_GetObjectRefType? That may be another issue. Same with the accesses to _weak_global_handle value. ?- javaCalls.hpp: in line 135 I would prefer if the two increment statements were put on separate lines. I looked over the second one a few times too many. ?- javaCalls.cpp:449: s/Invaild/Invalid/ ?- javaCalls.cpp:526: s/matched/match/ ; maybe also upper case the initial word of the sentence. ?- javaCalls.cpp: somebody already asked for a comment for the t < os::vm_page_size() check. ?- in SignatureChekker::check_obj(), maybe put the declaration of the "bad" bool into the if-scope as it is never used outside. ?- I would prefer that the tagging mechanism would be described better in JNIHandles.hpp. "Low tag bit in jobject used to distinguish a jweak" seems not sufficient to explain what and why we do the tagging (or how it works). Particularly because some code (shareNativeWrapper.cpp) refers to an explanation in JNIHandles.hpp which is not there. ?- templateInterpreterGenerator_sparc.cpp, line 1523: am I correct that in case of jweaks, this generates a guaranteed unaligned load? E.g. the sequence: brx(Assembler::zero, true, Assembler::pt, store_result); delayed()->ld_ptr(O0, 0, O0); ?// <--- this one I think is a guaranteed unaligned load if O0 contains a jweak. ld_ptr(O0, -JNIHandles::weak_tag_value, O0); On some machines this may cause a SIGBUS afaik - depending on OS configuration/capabilities. I would prefer if the code would not attempt to be clever here. Apparently the same for sharedRuntime_sparc.cpp. ?- I am also not sure why some of the code generation methods have the STATIC_ASSERT(JNIHandles::weak_tag_mask == 1u) and others not. (E.g. ARM32/64 code has it, others apparently not). I would kind of prefer to have it everywhere, but I am also fine with one e.g. in JNIHandles.cpp with a big fat comment. Thanks, ? Thomas From kim.barrett at oracle.com Sat Feb 11 00:30:38 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 10 Feb 2017 19:30:38 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <1486723790.2702.39.camel@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <1486723790.2702.39.camel@oracle.com> Message-ID: > On Feb 10, 2017, at 5:49 AM, Thomas Schatzl wrote: > > Hi Kim, > > On Mon, 2017-02-06 at 20:03 -0500, Kim Barrett wrote: >> Apologies for taking so long to respond to earlier comments. I've >> been distracted by some other tasks, and it took a while to figure >> out what to do about the problem Mikael reported. >> >> > [...] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8166188 >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.04 Thanks for looking at this. I?ll have a new webrev containing changes discussed here and elsewhere soon; need to do some testing first. > - ReturnJNIWeak.java: please make sure that the test is not called > with -XX:+ExplicitGCInvokesConcurrent. It will most likely fail in this > case. Yes, I noticed that yesterday. Thanks. > - jniHandles.hpp: it might be useful to explain the external_guard > template parameter to the new guard_value/resolve_impl methods. > > This might be due to my unfamiliarity to the code, so skip this if you > think it is "obvious" what this means. I've added some commentary. The template parameter is just whether these helpers are being called from resolve_external_guard or not. That variant resolves some erroneous cases to NULL, rather than treating them as (possibly unchecked) errors. > From the callers of JNIHandles::resolve() I am actually not sure if the > extra performance due to templatizing the parameter has any impact. I expect making external_guard an ordinary bool argument and letting the compiler constant fold would produce equivalent code. I went with a template parameter because, semantically, my intent is that the value must be a constant, and making it a template parameter enforces that. > - it would be nice if JNIHandles::weak_oops_do(BoolObjectClosure, > OopClosure) would have an assert_at_safepoint_or_JNI_lock_locked() - > but that's probably another issue. Same with the _global_handles array. Separate issue. File an RFE? > - jniHandles.hpp:58. Not sure why the "int" type specifier for > weak_tag_value has an extra space in front of it. ? TBD > - isn't is_global_handle() thread-unsafe too? The assert uses > JNIHandleBlock::chain_contains(), which iterates over the JNIHandles > array unguarded, but it seems possible to add entries concurrently > using e.g. make_global()? > > I.e. one thread adding a global handle, another thread calling e.g. > jni_GetObjectRefType? > > That may be another issue. Same with the accesses to > _weak_global_handle value. Separate issue. File a bug? > - javaCalls.hpp: in line 135 I would prefer if the two increment > statements were put on separate lines. I looked over the second one a > few times too many. Agreed. Done. > - javaCalls.cpp:449: s/Invaild/Invalid/ > > - javaCalls.cpp:526: s/matched/match/ ; maybe also upper case the > initial word of the sentence. Typos fixed. signature is the name of the variable, so I prefer not capitalizing. > - javaCalls.cpp: somebody already asked for a comment for the t < > os::vm_page_size() check. Already added. Still not totally convinced this is appropriate. > - in SignatureChekker::check_obj(), maybe put the declaration of the > "bad" bool into the if-scope as it is never used outside. Done. Also eliminated p variable, which I don?t think helps readability. And cleaned up the comments nearby. > - I would prefer that the tagging mechanism would be described better > in JNIHandles.hpp. "Low tag bit in jobject used to distinguish a jweak" > seems not sufficient to explain what and why we do the tagging (or how > it works). > Particularly because some code (shareNativeWrapper.cpp) refers to an > explanation in JNIHandles.hpp which is not there. Added more description. > - templateInterpreterGenerator_sparc.cpp, line 1523: am I correct that > in case of jweaks, this generates a guaranteed unaligned load? > > E.g. the sequence: > > brx(Assembler::zero, true, Assembler::pt, store_result); > delayed()->ld_ptr(O0, 0, O0); // <--- this one I think is a guaranteed > unaligned load if O0 contains a jweak. > ld_ptr(O0, -JNIHandles::weak_tag_value, O0); The code is correct, there is no unaligned access. In the brx, the second argument is true. That?s the annul flag. That means the instruction in the delay slot will only be executed if the branch is taken, and will be treated as a nop if the branch is not taken. If the annul flag is false then the instruction in the delay slot will be executed whether the branch is taken or not. > On some machines this may cause a SIGBUS afaik - depending on OS > configuration/capabilities. I would prefer if the code would not > attempt to be clever here. > > Apparently the same for sharedRuntime_sparc.cpp. > > - I am also not sure why some of the code generation methods have the > STATIC_ASSERT(JNIHandles::weak_tag_mask == 1u) and others not. (E.g. > ARM32/64 code has it, others apparently not). > I would kind of prefer to have it everywhere, but I am also fine with > one e.g. in JNIHandles.cpp with a big fat comment. In non-ARM code, there?s no dependency on the size of the tag. The ARM/AARCH64 code is using a tbz instruction, test a single bit (specifically bit 0 in this case, see the second argument) and branch if zero. So we?re assuming the tag field is one bit wide and at bit zero, e.g. mask == 1. Hence the static assert. From kim.barrett at oracle.com Sat Feb 11 04:02:17 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 10 Feb 2017 23:02:17 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> Message-ID: <1EA40A56-7BEB-44C8-9D24-98904DA003A9@oracle.com> > On Feb 8, 2017, at 7:00 PM, Kim Barrett wrote: >> L571: if (t < (size_t)os::vm_page_size()) { >> Again, not your issue, but that size < page size check means >> the oop is bad is screaming for a short comment. > > Added comment. Also removed the unnecessary intermediate variable t, > thereby eliminating some casts. I'm not completly convinced by the > comment, but remaining true to the existing code. Here's the diff: > > @@ -566,9 +568,10 @@ > uint value_state = _value_state[p]; > if (is_value_state_indirect_oop(value_state)) { > intptr_t v = _value[p]; > - if (v != 0 ) { > - size_t t = (size_t)v; > - if (t < (size_t)os::vm_page_size()) { > + if (v != 0) { > + if (v < os::vm_page_size()) { > + // v is a "handle" referring to an oop, cast to integral type. > + // There ought not be any handles in very low memory. > bad = true; > } else if (!resolve_indirect_oop(v, value_state)->is_oop_or_null(true)) { > bad = true; Well, that was dumb. v can be negative, and vm_page_size return (positive) int. Just pretend you never saw that? From kim.barrett at oracle.com Mon Feb 13 04:25:45 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 12 Feb 2017 23:25:45 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <1EA40A56-7BEB-44C8-9D24-98904DA003A9@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> <1EA40A56-7BEB-44C8-9D24-98904DA003A9@oracle.com> Message-ID: <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> Here's the updated webrevs, incorporating feedback received so far. full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05/ incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05.inc/ For x86 and ARM I added resolve_jobject functions to their respective macroAssembler files, and call those to generate the return object handling code. Merging the two cases for Sparc is harder and I'm going to leave it to someone else. I'm also leaving any such merging for other (non-Oracle) ports to their respective maintainers. Rewrote the error checking in SignatureChekker::check_obj to simplify the control flow and provide more information. Rather than conditionally selecting between ReportJNIFatalError or assert to report problems, instead just always use guarantee. Recall that we only get here if CheckJNICalls or in a debug build. This made SignatureChekker::_thread unused, so removed it. From martin.doerr at sap.com Mon Feb 13 14:25:41 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 13 Feb 2017 14:25:41 +0000 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> <1EA40A56-7BEB-44C8-9D24-98904DA003A9@oracle.com> <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> Message-ID: <0216acc686a44788b0451dce7d94e491@sap.com> Hi Kim, I have factored out resolve_jobject on PPC64 and s390. Complete webrev is here: http://cr.openjdk.java.net/~mdoerr/8166188_s390_ppc64/webrev.06/ Incremental patch (based on webrev.05): http://cr.openjdk.java.net/~mdoerr/8166188_s390_ppc64/webrev.06/8166188_s390_ppc64_incr.patch I prefer masking out the weak tag and only checking it if G1 is used. (The additional check and branch is only needed for G1. Also, see new PPC64 and s390 implementation.) What is preferable on x86? Btw. the indentation looks inconsistent in resolve_jobject. Best regards, Martin -----Original Message----- From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Kim Barrett Sent: Montag, 13. Februar 2017 05:26 To: hotspot-dev developers Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles Here's the updated webrevs, incorporating feedback received so far. full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05/ incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05.inc/ For x86 and ARM I added resolve_jobject functions to their respective macroAssembler files, and call those to generate the return object handling code. Merging the two cases for Sparc is harder and I'm going to leave it to someone else. I'm also leaving any such merging for other (non-Oracle) ports to their respective maintainers. Rewrote the error checking in SignatureChekker::check_obj to simplify the control flow and provide more information. Rather than conditionally selecting between ReportJNIFatalError or assert to report problems, instead just always use guarantee. Recall that we only get here if CheckJNICalls or in a debug build. This made SignatureChekker::_thread unused, so removed it. From kim.barrett at oracle.com Tue Feb 14 15:49:11 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 14 Feb 2017 10:49:11 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <0216acc686a44788b0451dce7d94e491@sap.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> <1EA40A56-7BEB-44C8-9D24-98904DA003A9@oracle.com> <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> <0216acc686a44788b0451dce7d94e491@sap.com> Message-ID: <53F38C3F-A599-41A7-B1DB-2225AFC4F659@oracle.com> > On Feb 13, 2017, at 9:25 AM, Doerr, Martin wrote: > > Hi Kim, > > I have factored out resolve_jobject on PPC64 and s390. > > Complete webrev is here: > http://cr.openjdk.java.net/~mdoerr/8166188_s390_ppc64/webrev.06/ > > Incremental patch (based on webrev.05): > http://cr.openjdk.java.net/~mdoerr/8166188_s390_ppc64/webrev.06/8166188_s390_ppc64_incr.patch Thanks. I?ll add that to my patch set. > I prefer masking out the weak tag and only checking it if G1 is used. (The additional check and branch is only needed for G1. Also, see new PPC64 and s390 implementation.) I considered that, but chose to not penalize the G1 case (the default case now) to perhaps slightly improve the non-G1 (non-default) case. (Branch prediction may mitigate the extra branch cost.) But it?s unlikely to matter either way. > What is preferable on x86? Btw. the indentation looks inconsistent in resolve_jobject. Thanks for noticing the mis-indentation. Will fix. > > Best regards, > Martin > > > -----Original Message----- > From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Kim Barrett > Sent: Montag, 13. Februar 2017 05:26 > To: hotspot-dev developers > Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles > > Here's the updated webrevs, incorporating feedback received so far. > > full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05/ > incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05.inc/ > > For x86 and ARM I added resolve_jobject functions to their respective > macroAssembler files, and call those to generate the return object > handling code. Merging the two cases for Sparc is harder and I'm > going to leave it to someone else. I'm also leaving any such merging > for other (non-Oracle) ports to their respective maintainers. > > Rewrote the error checking in SignatureChekker::check_obj to simplify > the control flow and provide more information. Rather than > conditionally selecting between ReportJNIFatalError or assert to > report problems, instead just always use guarantee. Recall that we > only get here if CheckJNICalls or in a debug build. This made > SignatureChekker::_thread unused, so removed it. From mikael.gerdin at oracle.com Tue Feb 14 16:26:56 2017 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 14 Feb 2017 17:26:56 +0100 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> <1EA40A56-7BEB-44C8-9D24-98904DA003A9@oracle.com> <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> Message-ID: <214376fc-ebae-4f0e-2074-1a3595ce5e1e@oracle.com> Hi Kim, On 2017-02-13 05:25, Kim Barrett wrote: > Here's the updated webrevs, incorporating feedback received so far. > > full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05/ > incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05.inc/ I think your change is ready to go, consider it Reviewed by me. I can't really say that I think this looks good due to the fact that I'm still traumatized by JavaCallArguments and how it uses something I've come to think of as "alternative code" to handle oop parameters but that is something that I hope we can clean up at some point in the future. Thanks for fixing this! /Mikael > > For x86 and ARM I added resolve_jobject functions to their respective > macroAssembler files, and call those to generate the return object > handling code. Merging the two cases for Sparc is harder and I'm > going to leave it to someone else. I'm also leaving any such merging > for other (non-Oracle) ports to their respective maintainers. > > Rewrote the error checking in SignatureChekker::check_obj to simplify > the control flow and provide more information. Rather than > conditionally selecting between ReportJNIFatalError or assert to > report problems, instead just always use guarantee. Recall that we > only get here if CheckJNICalls or in a debug build. This made > SignatureChekker::_thread unused, so removed it. > From kim.barrett at oracle.com Tue Feb 14 22:10:01 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 14 Feb 2017 17:10:01 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <214376fc-ebae-4f0e-2074-1a3595ce5e1e@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> <1EA40A56-7BEB-44C8-9D24-98904DA003A9@oracle.com> <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> <214376fc-ebae-4f0e-2074-1a3595ce5e1e@oracle.com> Message-ID: <7712EEA3-E080-4153-83A4-70455F830C7D@oracle.com> > On Feb 14, 2017, at 11:26 AM, Mikael Gerdin wrote: > > Hi Kim, > > On 2017-02-13 05:25, Kim Barrett wrote: >> Here's the updated webrevs, incorporating feedback received so far. >> >> full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05/ >> incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05.inc/ > > I think your change is ready to go, consider it Reviewed by me. Thanks. > > I can't really say that I think this looks good due to the fact that I'm still traumatized by JavaCallArguments and how it uses something I've come to think of as "alternative code" to handle oop parameters but that is something that I hope we can clean up at some point in the future. > > Thanks for fixing this! > /Mikael > >> >> For x86 and ARM I added resolve_jobject functions to their respective >> macroAssembler files, and call those to generate the return object >> handling code. Merging the two cases for Sparc is harder and I'm >> going to leave it to someone else. I'm also leaving any such merging >> for other (non-Oracle) ports to their respective maintainers. >> >> Rewrote the error checking in SignatureChekker::check_obj to simplify >> the control flow and provide more information. Rather than >> conditionally selecting between ReportJNIFatalError or assert to >> report problems, instead just always use guarantee. Recall that we >> only get here if CheckJNICalls or in a debug build. This made >> SignatureChekker::_thread unused, so removed it. From thomas.schatzl at oracle.com Wed Feb 15 09:12:56 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 15 Feb 2017 10:12:56 +0100 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> <1EA40A56-7BEB-44C8-9D24-98904DA003A9@oracle.com> <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> Message-ID: <1487149976.3359.13.camel@oracle.com> Hi, On Sun, 2017-02-12 at 23:25 -0500, Kim Barrett wrote: > Here's the updated webrevs, incorporating feedback received so far. > > full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05/ > incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05.inc/ > ? Ship it. Thanks, ? Thomas From daniel.daugherty at oracle.com Wed Feb 15 16:34:04 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Feb 2017 09:34:04 -0700 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> <1EA40A56-7BEB-44C8-9D24-98904DA003A9@oracle.com> <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> Message-ID: On 2/12/17 9:25 PM, Kim Barrett wrote: > Here's the updated webrevs, incorporating feedback received so far. > > full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05/ src/share/vm/runtime/javaCalls.hpp No comments. src/share/vm/runtime/javaCalls.cpp No comments. src/share/vm/runtime/jniHandles.hpp No comments. src/share/vm/runtime/jniHandles.cpp No comments. src/share/vm/prims/jni.cpp No comments. src/share/vm/prims/jvmtiEnv.cpp No comments. make/test/JtregNative.gmk No comments. src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp No comments. src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp No comments. src/cpu/arm/vm/interp_masm_arm.cpp No comments. src/cpu/arm/vm/interp_masm_arm.hpp No comments. src/cpu/arm/vm/macroAssembler_arm.cpp No comments. src/cpu/arm/vm/macroAssembler_arm.hpp No comments. src/cpu/arm/vm/sharedRuntime_arm.cpp No comments. src/cpu/arm/vm/templateInterpreterGenerator_arm.cpp No comments. src/cpu/ppc/vm/frame_ppc.cpp No comments. src/cpu/ppc/vm/sharedRuntime_ppc.cpp No comments. src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp No comments. src/cpu/s390/vm/sharedRuntime_s390.cpp No comments. src/cpu/s390/vm/templateInterpreterGenerator_s390.cpp No comments. src/cpu/sparc/vm/sharedRuntime_sparc.cpp No comments. src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp No comments. src/cpu/x86/vm/macroAssembler_x86.cpp No comments. src/cpu/x86/vm/macroAssembler_x86.hpp No comments. src/cpu/x86/vm/sharedRuntime_x86_32.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_64.cpp No comments. src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp No comments. src/cpu/zero/vm/cppInterpreter_zero.cpp No comments. src/share/vm/shark/sharkNativeWrapper.cpp No comments. test/runtime/jni/CallWithJNIWeak/CallWithJNIWeak.java No comments. test/runtime/jni/CallWithJNIWeak/libCallWithJNIWeak.c No comments. test/runtime/jni/ReturnJNIWeak/ReturnJNIWeak.java No comments. test/runtime/jni/ReturnJNIWeak/libReturnJNIWeak.c No comments. Thumbs up! Dan > incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05.inc/ > > For x86 and ARM I added resolve_jobject functions to their respective > macroAssembler files, and call those to generate the return object > handling code. Merging the two cases for Sparc is harder and I'm > going to leave it to someone else. I'm also leaving any such merging > for other (non-Oracle) ports to their respective maintainers. > > Rewrote the error checking in SignatureChekker::check_obj to simplify > the control flow and provide more information. Rather than > conditionally selecting between ReportJNIFatalError or assert to > report problems, instead just always use guarantee. Recall that we > only get here if CheckJNICalls or in a debug build. This made > SignatureChekker::_thread unused, so removed it. > From kim.barrett at oracle.com Wed Feb 15 19:47:43 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 15 Feb 2017 14:47:43 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: References: <1519B166-C6A7-45A3-9C68-105177D9D601@oracle.com> <66F01296-FCA8-4C60-9AF3-FB937E5F3EDA@oracle.com> <1EA40A56-7BEB-44C8-9D24-98904DA003A9@oracle.com> <745EFBBD-AA95-4A5C-A4FB-56F41F8A778E@oracle.com> Message-ID: > On Feb 15, 2017, at 11:34 AM, Daniel D. Daugherty wrote: > > On 2/12/17 9:25 PM, Kim Barrett wrote: >> Here's the updated webrevs, incorporating feedback received so far. >> >> full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05/ Thanks Dan. > > src/share/vm/runtime/javaCalls.hpp > No comments. > > src/share/vm/runtime/javaCalls.cpp > No comments. > > src/share/vm/runtime/jniHandles.hpp > No comments. > > src/share/vm/runtime/jniHandles.cpp > No comments. > > src/share/vm/prims/jni.cpp > No comments. > > src/share/vm/prims/jvmtiEnv.cpp > No comments. > > make/test/JtregNative.gmk > No comments. > > src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp > No comments. > > src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp > No comments. > > src/cpu/arm/vm/interp_masm_arm.cpp > No comments. > > src/cpu/arm/vm/interp_masm_arm.hpp > No comments. > > src/cpu/arm/vm/macroAssembler_arm.cpp > No comments. > > src/cpu/arm/vm/macroAssembler_arm.hpp > No comments. > > src/cpu/arm/vm/sharedRuntime_arm.cpp > No comments. > > src/cpu/arm/vm/templateInterpreterGenerator_arm.cpp > No comments. > > src/cpu/ppc/vm/frame_ppc.cpp > No comments. > > src/cpu/ppc/vm/sharedRuntime_ppc.cpp > No comments. > > src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > No comments. > > src/cpu/s390/vm/sharedRuntime_s390.cpp > No comments. > > src/cpu/s390/vm/templateInterpreterGenerator_s390.cpp > No comments. > > src/cpu/sparc/vm/sharedRuntime_sparc.cpp > No comments. > > src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp > No comments. > > src/cpu/x86/vm/macroAssembler_x86.cpp > No comments. > > src/cpu/x86/vm/macroAssembler_x86.hpp > No comments. > > src/cpu/x86/vm/sharedRuntime_x86_32.cpp > No comments. > > src/cpu/x86/vm/sharedRuntime_x86_64.cpp > No comments. > > src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp > No comments. > > src/cpu/zero/vm/cppInterpreter_zero.cpp > No comments. > > src/share/vm/shark/sharkNativeWrapper.cpp > No comments. > > test/runtime/jni/CallWithJNIWeak/CallWithJNIWeak.java > No comments. > > test/runtime/jni/CallWithJNIWeak/libCallWithJNIWeak.c > No comments. > > test/runtime/jni/ReturnJNIWeak/ReturnJNIWeak.java > No comments. > > test/runtime/jni/ReturnJNIWeak/libReturnJNIWeak.c > No comments. > > Thumbs up! > > Dan > > >> incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05.inc/ >> >> For x86 and ARM I added resolve_jobject functions to their respective >> macroAssembler files, and call those to generate the return object >> handling code. Merging the two cases for Sparc is harder and I'm >> going to leave it to someone else. I'm also leaving any such merging >> for other (non-Oracle) ports to their respective maintainers. >> >> Rewrote the error checking in SignatureChekker::check_obj to simplify >> the control flow and provide more information. Rather than >> conditionally selecting between ReportJNIFatalError or assert to >> report problems, instead just always use guarantee. Recall that we >> only get here if CheckJNICalls or in a debug build. This made >> SignatureChekker::_thread unused, so removed it. From daniel.daugherty at oracle.com Thu Feb 16 19:21:22 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Feb 2017 12:21:22 -0700 Subject: URGENT: RFR: [BACKOUT] fix for JDK-8166188 Message-ID: <66ddf3ea-83e0-ab69-443f-e33dc3be7b8f@oracle.com> Greetings, Sending this backout code review to the same aliases used for: JDK-8166188 G1 Needs pre barrier on dereference of weak JNI handles https://bugs.openjdk.java.net/browse/JDK-8166188 more as a heads up that JDK-8166188 might be getting backed out. I only need reviews from Kim and Jesper. Doing a contingent backout of Kim's fix for the above due to some unexpected test failures with some JDK tests: JDK-8175085 8166188 causes JDK test failures https://bugs.openjdk.java.net/browse/JDK-8175085 JDK-8175086 [BACKOUT] fix for JDK-8166188 https://bugs.openjdk.java.net/browse/JDK-8175086 Webrev URL: http://cr.openjdk.java.net/~dcubed/8175086-webrev/0-jdk9-hs/ I used "hg backout 3bc68ff68250" which created a child changeset of Kim's: changeset: 12639:3bc68ff68250 user: kbarrett date: Wed Feb 15 22:19:13 2017 -0500 summary: 8166188: G1 Needs pre barrier on dereference of weak JNI handles The backout changeset: changeset: 12644:ee34d6aabf5f parent: 12639:3bc68ff68250 user: dcubed date: Thu Feb 16 10:41:19 2017 -0800 summary: 8175086: [BACKOUT] fix for JDK-8166188 and then I used "hg merge" to merge with current tip. This was a "branch" merge with no conflicts. Sanity checks: - The parent of Kim's changeset is: changeset: 12638:35db0413819a user: roland date: Wed Feb 15 17:26:37 2017 -0800 summary: 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops - hg diff -r 35db0413819a -r ee34d6aabf5f shows no output so the backout is clean. - $ wc -l files.list 37 files.list - $ hg diff -r 35db0413819a -r tip `cat files.list` shows no output so the merge with the tip is clean. Thanks, in advance, for reviews from Jesper and Kim!! Dan From kim.barrett at oracle.com Thu Feb 16 19:43:59 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 16 Feb 2017 14:43:59 -0500 Subject: URGENT: RFR: [BACKOUT] fix for JDK-8166188 In-Reply-To: <66ddf3ea-83e0-ab69-443f-e33dc3be7b8f@oracle.com> References: <66ddf3ea-83e0-ab69-443f-e33dc3be7b8f@oracle.com> Message-ID: <41EAF2BB-30D8-4D9B-8134-F557D4D83543@oracle.com> looks good. > On Feb 16, 2017, at 2:21 PM, Daniel D. Daugherty wrote: > > Greetings, > > Sending this backout code review to the same aliases used for: > > JDK-8166188 G1 Needs pre barrier on dereference of weak JNI handles > https://bugs.openjdk.java.net/browse/JDK-8166188 > > more as a heads up that JDK-8166188 might be getting backed out. > > I only need reviews from Kim and Jesper. > > Doing a contingent backout of Kim's fix for the above due to some > unexpected test failures with some JDK tests: > > JDK-8175085 8166188 causes JDK test failures > https://bugs.openjdk.java.net/browse/JDK-8175085 > > JDK-8175086 [BACKOUT] fix for JDK-8166188 > https://bugs.openjdk.java.net/browse/JDK-8175086 > > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8175086-webrev/0-jdk9-hs/ > > > I used "hg backout 3bc68ff68250" which created a child > changeset of Kim's: > > changeset: 12639:3bc68ff68250 > user: kbarrett > date: Wed Feb 15 22:19:13 2017 -0500 > summary: 8166188: G1 Needs pre barrier on dereference of weak JNI handles > > The backout changeset: > > changeset: 12644:ee34d6aabf5f > parent: 12639:3bc68ff68250 > user: dcubed > date: Thu Feb 16 10:41:19 2017 -0800 > summary: 8175086: [BACKOUT] fix for JDK-8166188 > > and then I used "hg merge" to merge with current tip. > This was a "branch" merge with no conflicts. > > > Sanity checks: > > - The parent of Kim's changeset is: > > changeset: 12638:35db0413819a > user: roland > date: Wed Feb 15 17:26:37 2017 -0800 > summary: 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops > > - hg diff -r 35db0413819a -r ee34d6aabf5f > > shows no output so the backout is clean. > > - $ wc -l files.list > 37 files.list > > - $ hg diff -r 35db0413819a -r tip `cat files.list` > > shows no output so the merge with the tip is clean. > > Thanks, in advance, for reviews from Jesper and Kim!! > > Dan From daniel.daugherty at oracle.com Thu Feb 16 20:43:41 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Feb 2017 13:43:41 -0700 Subject: URGENT: RFR: [BACKOUT] fix for JDK-8166188 In-Reply-To: <41EAF2BB-30D8-4D9B-8134-F557D4D83543@oracle.com> References: <66ddf3ea-83e0-ab69-443f-e33dc3be7b8f@oracle.com> <41EAF2BB-30D8-4D9B-8134-F557D4D83543@oracle.com> Message-ID: <1335e5aa-2256-d414-c65b-68f8d3e32c14@oracle.com> Thanks for the quick review! Dan On 2/16/17 12:43 PM, Kim Barrett wrote: > looks good. > >> On Feb 16, 2017, at 2:21 PM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> Sending this backout code review to the same aliases used for: >> >> JDK-8166188 G1 Needs pre barrier on dereference of weak JNI handles >> https://bugs.openjdk.java.net/browse/JDK-8166188 >> >> more as a heads up that JDK-8166188 might be getting backed out. >> >> I only need reviews from Kim and Jesper. >> >> Doing a contingent backout of Kim's fix for the above due to some >> unexpected test failures with some JDK tests: >> >> JDK-8175085 8166188 causes JDK test failures >> https://bugs.openjdk.java.net/browse/JDK-8175085 >> >> JDK-8175086 [BACKOUT] fix for JDK-8166188 >> https://bugs.openjdk.java.net/browse/JDK-8175086 >> >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8175086-webrev/0-jdk9-hs/ >> >> >> I used "hg backout 3bc68ff68250" which created a child >> changeset of Kim's: >> >> changeset: 12639:3bc68ff68250 >> user: kbarrett >> date: Wed Feb 15 22:19:13 2017 -0500 >> summary: 8166188: G1 Needs pre barrier on dereference of weak JNI handles >> >> The backout changeset: >> >> changeset: 12644:ee34d6aabf5f >> parent: 12639:3bc68ff68250 >> user: dcubed >> date: Thu Feb 16 10:41:19 2017 -0800 >> summary: 8175086: [BACKOUT] fix for JDK-8166188 >> >> and then I used "hg merge" to merge with current tip. >> This was a "branch" merge with no conflicts. >> >> >> Sanity checks: >> >> - The parent of Kim's changeset is: >> >> changeset: 12638:35db0413819a >> user: roland >> date: Wed Feb 15 17:26:37 2017 -0800 >> summary: 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops >> >> - hg diff -r 35db0413819a -r ee34d6aabf5f >> >> shows no output so the backout is clean. >> >> - $ wc -l files.list >> 37 files.list >> >> - $ hg diff -r 35db0413819a -r tip `cat files.list` >> >> shows no output so the merge with the tip is clean. >> >> Thanks, in advance, for reviews from Jesper and Kim!! >> >> Dan > From daniel.daugherty at oracle.com Thu Feb 16 20:43:53 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Feb 2017 13:43:53 -0700 Subject: URGENT: RFR: [BACKOUT] fix for JDK-8166188 In-Reply-To: <1a37f025-1101-50e5-0171-c7e28a941668@oracle.com> References: <66ddf3ea-83e0-ab69-443f-e33dc3be7b8f@oracle.com> <1a37f025-1101-50e5-0171-c7e28a941668@oracle.com> Message-ID: <172bd1c5-3785-7bce-00b4-e4eb8d102e89@oracle.com> Thanks for the quick review! Dan On 2/16/17 12:56 PM, Jesper Wilhelmsson wrote: > Looks good! > > /Jesper > > > On 2017-02-16 20:21, Daniel D. Daugherty wrote: >> Greetings, >> >> Sending this backout code review to the same aliases used for: >> >> JDK-8166188 G1 Needs pre barrier on dereference of weak JNI handles >> https://bugs.openjdk.java.net/browse/JDK-8166188 >> >> more as a heads up that JDK-8166188 might be getting backed out. >> >> I only need reviews from Kim and Jesper. >> >> Doing a contingent backout of Kim's fix for the above due to some >> unexpected test failures with some JDK tests: >> >> JDK-8175085 8166188 causes JDK test failures >> https://bugs.openjdk.java.net/browse/JDK-8175085 >> >> JDK-8175086 [BACKOUT] fix for JDK-8166188 >> https://bugs.openjdk.java.net/browse/JDK-8175086 >> >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8175086-webrev/0-jdk9-hs/ >> >> >> I used "hg backout 3bc68ff68250" which created a child >> changeset of Kim's: >> >> changeset: 12639:3bc68ff68250 >> user: kbarrett >> date: Wed Feb 15 22:19:13 2017 -0500 >> summary: 8166188: G1 Needs pre barrier on dereference of weak JNI >> handles >> >> The backout changeset: >> >> changeset: 12644:ee34d6aabf5f >> parent: 12639:3bc68ff68250 >> user: dcubed >> date: Thu Feb 16 10:41:19 2017 -0800 >> summary: 8175086: [BACKOUT] fix for JDK-8166188 >> >> and then I used "hg merge" to merge with current tip. >> This was a "branch" merge with no conflicts. >> >> >> Sanity checks: >> >> - The parent of Kim's changeset is: >> >> changeset: 12638:35db0413819a >> user: roland >> date: Wed Feb 15 17:26:37 2017 -0800 >> summary: 8174164: SafePointNode::_replaced_nodes breaks with >> irreducible loops >> >> - hg diff -r 35db0413819a -r ee34d6aabf5f >> >> shows no output so the backout is clean. >> >> - $ wc -l files.list >> 37 files.list >> >> - $ hg diff -r 35db0413819a -r tip `cat files.list` >> >> shows no output so the merge with the tip is clean. >> >> Thanks, in advance, for reviews from Jesper and Kim!! >> >> Dan >> > From martin.doerr at sap.com Fri Feb 17 12:07:41 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 17 Feb 2017 12:07:41 +0000 Subject: URGENT: RFR: [BACKOUT] fix for JDK-8166188 In-Reply-To: <172bd1c5-3785-7bce-00b4-e4eb8d102e89@oracle.com> References: <66ddf3ea-83e0-ab69-443f-e33dc3be7b8f@oracle.com> <1a37f025-1101-50e5-0171-c7e28a941668@oracle.com> <172bd1c5-3785-7bce-00b4-e4eb8d102e89@oracle.com> Message-ID: <1d2c4abf5b3b48d68093dc49e7400f4f@sap.com> Hi, I should have looked at our test results on SPARC earlier. There are also crashes in e.g. jni_fast_GetBooleanField. PPC64 and s390 don't have FastJNIAccessors at the moment. That's why I haven't seen such problems there. jni_GetBooleanField seems to work fine because it uses JNIHandles::resolve_non_null(obj). Best regards, Martin -----Original Message----- From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty Sent: Donnerstag, 16. Februar 2017 21:44 To: Jesper Wilhelmsson ; hotspot-dev developers ; s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: URGENT: RFR: [BACKOUT] fix for JDK-8166188 Thanks for the quick review! Dan On 2/16/17 12:56 PM, Jesper Wilhelmsson wrote: > Looks good! > > /Jesper > > > On 2017-02-16 20:21, Daniel D. Daugherty wrote: >> Greetings, >> >> Sending this backout code review to the same aliases used for: >> >> JDK-8166188 G1 Needs pre barrier on dereference of weak JNI handles >> https://bugs.openjdk.java.net/browse/JDK-8166188 >> >> more as a heads up that JDK-8166188 might be getting backed out. >> >> I only need reviews from Kim and Jesper. >> >> Doing a contingent backout of Kim's fix for the above due to some >> unexpected test failures with some JDK tests: >> >> JDK-8175085 8166188 causes JDK test failures >> https://bugs.openjdk.java.net/browse/JDK-8175085 >> >> JDK-8175086 [BACKOUT] fix for JDK-8166188 >> https://bugs.openjdk.java.net/browse/JDK-8175086 >> >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8175086-webrev/0-jdk9-hs/ >> >> >> I used "hg backout 3bc68ff68250" which created a child >> changeset of Kim's: >> >> changeset: 12639:3bc68ff68250 >> user: kbarrett >> date: Wed Feb 15 22:19:13 2017 -0500 >> summary: 8166188: G1 Needs pre barrier on dereference of weak JNI >> handles >> >> The backout changeset: >> >> changeset: 12644:ee34d6aabf5f >> parent: 12639:3bc68ff68250 >> user: dcubed >> date: Thu Feb 16 10:41:19 2017 -0800 >> summary: 8175086: [BACKOUT] fix for JDK-8166188 >> >> and then I used "hg merge" to merge with current tip. >> This was a "branch" merge with no conflicts. >> >> >> Sanity checks: >> >> - The parent of Kim's changeset is: >> >> changeset: 12638:35db0413819a >> user: roland >> date: Wed Feb 15 17:26:37 2017 -0800 >> summary: 8174164: SafePointNode::_replaced_nodes breaks with >> irreducible loops >> >> - hg diff -r 35db0413819a -r ee34d6aabf5f >> >> shows no output so the backout is clean. >> >> - $ wc -l files.list >> 37 files.list >> >> - $ hg diff -r 35db0413819a -r tip `cat files.list` >> >> shows no output so the merge with the tip is clean. >> >> Thanks, in advance, for reviews from Jesper and Kim!! >> >> Dan >> > From lutz.schmidt at sap.com Tue Feb 21 15:38:25 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 21 Feb 2017 15:38:25 +0000 Subject: RFR (XS) 8175267: [s390] cleanup stub code "handler_for_unsafe_access" Message-ID: Hi all, May I kindly request reviews for my very small cleanup change? Further down the road, I would need a sponsor, too. Bug: https://bugs.openjdk.java.net/browse/JDK-8175267 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175267/ Description: The "handler_for_unsafe_access? is a relic from former times, having survived only on s390x. The stub is generated, but never used (called). This change removes everything related. Thanks, Lutz From martin.doerr at sap.com Tue Feb 21 17:11:25 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 21 Feb 2017 17:11:25 +0000 Subject: RFR (XS) 8175267: [s390] cleanup stub code "handler_for_unsafe_access" In-Reply-To: References: Message-ID: <46d01d26ecc54e00bbc053a1a77b6dee@sap.com> Hi Lutz, thanks for doing this cleanup. Looks good to me. I think I can sponsor it as it only touches s390 files and is targeted for jdk10. However, we need a jdk10 reviewer, too. Best regards, Martin -----Original Message----- From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Dienstag, 21. Februar 2017 16:38 To: s390x-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: RFR (XS) 8175267: [s390] cleanup stub code "handler_for_unsafe_access" Hi all, May I kindly request reviews for my very small cleanup change? Further down the road, I would need a sponsor, too. Bug: https://bugs.openjdk.java.net/browse/JDK-8175267 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175267/ Description: The "handler_for_unsafe_access? is a relic from former times, having survived only on s390x. The stub is generated, but never used (called). This change removes everything related. Thanks, Lutz From lutz.schmidt at sap.com Tue Feb 21 19:30:39 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 21 Feb 2017 19:30:39 +0000 Subject: RFR (XS) 8175267: [s390] cleanup stub code "handler_for_unsafe_access" In-Reply-To: <46d01d26ecc54e00bbc053a1a77b6dee@sap.com> References: <46d01d26ecc54e00bbc053a1a77b6dee@sap.com> Message-ID: Thank you, Martin, for reviewing this one. Regards, Lutz > On 21 Feb 2017, at 18:11, Doerr, Martin wrote: > > Hi Lutz, > > thanks for doing this cleanup. Looks good to me. > I think I can sponsor it as it only touches s390 files and is targeted for jdk10. > However, we need a jdk10 reviewer, too. > > Best regards, > Martin > > > -----Original Message----- > From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Dienstag, 21. Februar 2017 16:38 > To: s390x-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: RFR (XS) 8175267: [s390] cleanup stub code "handler_for_unsafe_access" > > Hi all, > > May I kindly request reviews for my very small cleanup change? Further down the road, I would need a sponsor, too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175267 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175267/ > > Description: > The "handler_for_unsafe_access? is a relic from former times, having survived only on s390x. The stub is generated, but never used (called). This change removes everything related. > > Thanks, > Lutz > From chris.plummer at oracle.com Tue Feb 21 19:31:07 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 21 Feb 2017 11:31:07 -0800 Subject: RFR(10): 8172020: Internal Error (cpu/arm/vm/frame_arm.cpp:571): assert(obj == __null || Universe::heap()->is_in(obj)) failed: sanity check # Message-ID: <9550f15e-9b2b-7909-1856-eb68a6df2b5a@oracle.com> Hello, Please review the following: http://cr.openjdk.java.net/~cjplummer/8172020/webrev.01/webrev.hotspot/ https://bugs.openjdk.java.net/browse/JDK-8172020 [Note there are s390, ppc, and aarch64 changes in this bug fix that I will need to have someone verify for me or I won't be pushing them.] This bug turns up with a closed test so the CR is marked confidential. I'll try to provided the necessary details here. Sorry the explanation is lengthy, but it is a complex bug (with a relatively simple fix). If you are on the s390, ppc, or aarch64 teams and just want to help verify the fix, I would say it's not necessary to understand the details of the bug. What's most important is you test the changes. Unfortunately you won't be able to reproduce the issue since the test is closed, but you should at least verify the fix builds and introduces no new issues. I did test the open aarch64 port since I have the hardware, and someone was kind enough to provide me with binaries both without the patch (which reproduced the bug) and with the patch (which passed). No other aarch64 testing was done. Now on to an explanation of the bug and the fix: The test is testing the JDI/JVMTI forceEarlyReturn support. After the debugger side spawns the debugee process and the debugee thread is created, a vm.suspend() is issued to suspend all threads on the debugee side. The debugger side then issues a JDI forceEarlyReturn, which will cause the debugee thread to exit the currently executing method. Although the intent is to force exit of the run() method, the run() method does make some method calls to some very small methods with "inline" in their name, such as inlineMethodReturningObject(). If forceEarlyReturn is done while in one of them, JDI throws InvalidTargetException, which the test correctly handles and will pass if that happens. If the run() method is not yet compiled, what *normally* happens to force the thread to suspend is to swap in the interpreter safepoint dispatch table. This will result in a call_VM out to the interpreter to handle the safepointing. When later the thread is resumed (after initiating the forceEarlyReturn), there is code on the return side of call_VM to make sure the earlyret is handled immediately before any other bytecodes are exectuted. Thus the method that was executing at the time of the forceEarlyReturn should be the same as the method when the earlyret is handled. In fact it should be the same bytetcode(bci). Like I said, this is what *normally* happens, but is not the way the bug is exposed. The bug turns up when the run() method is not yet compiled, and when the suspend is attempted we are in one of the small "inline" methods, and it is compiled. In this case thread suspension is achieved in a different manner. When a compiled method executes its return code, it first pops its frame, and then the " poll_return" safepoint polling instruction is executed. This allows the thread to be suspended. We are technically in the run() method at this point since the frame of the "inline" method has been popped. Therefore the forceEarlyReturn is allowed. When the thread is resumed, the return from the "inline" method finally happens, which puts us in code generated by TemplateInterpreterGenerator::generate_return_entry_for(). However, there are no checks for an earlyret here, so we start executing bytecodes until we finally hit an earlyret check. This happens when the next invokespecial is done. There is a call_VM after the frame is pushed, and the call_VM always does an earlyret check. The problem is now the topmost frame (in the case where it asserts) is inlineMethodReturningObject(). Since it returns an object type, the earlyret code expects there to be an oop in the earlyret slot on the stack. But there isn't because the forceEarlyReturn was done on the void run() method. So the earlyret code fetches garbage, does an validity test on it, and gets the assert you see in the bug title. So what is needed here is an earlyret check after the compiled "inline" method returns, and before any new bytecodes are executed. Since TemplateInterpreterGenerator::generate_return_entry_for() is always executed when the compiled "inline" method returns, the check was added here. For completeness, the popframe check was also added. The header file changes are just to make these methods public so they can be called. I tested the failed test at least 100 times on each supported platform. The assert usually showed up at least 1 in 50 times. I also ran a large set of tests on all supported platforms, including everything we do for nightly testing except for some of the longest running tests. thanks, Chris From serguei.spitsyn at oracle.com Tue Feb 21 23:29:45 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Feb 2017 15:29:45 -0800 Subject: RFR(10): 8172020: Internal Error (cpu/arm/vm/frame_arm.cpp:571): assert(obj == __null || Universe::heap()->is_in(obj)) failed: sanity check # In-Reply-To: <9550f15e-9b2b-7909-1856-eb68a6df2b5a@oracle.com> References: <9550f15e-9b2b-7909-1856-eb68a6df2b5a@oracle.com> Message-ID: Hi Chris, It looks good to me. But let me mediate on the fix a little bit more. Consider it reviewed if I'll not come back in 24 hours. :) Thank you a lot for this great investigation and fix! Serguei On 2/21/17 11:31, Chris Plummer wrote: > Hello, > > Please review the following: > > http://cr.openjdk.java.net/~cjplummer/8172020/webrev.01/webrev.hotspot/ > https://bugs.openjdk.java.net/browse/JDK-8172020 > > [Note there are s390, ppc, and aarch64 changes in this bug fix that I > will need to have someone verify for me or I won't be pushing them.] > > This bug turns up with a closed test so the CR is marked confidential. > I'll try to provided the necessary details here. Sorry the explanation > is lengthy, but it is a complex bug (with a relatively simple fix). > > If you are on the s390, ppc, or aarch64 teams and just want to help > verify the fix, I would say it's not necessary to understand the > details of the bug. What's most important is you test the changes. > Unfortunately you won't be able to reproduce the issue since the test > is closed, but you should at least verify the fix builds and > introduces no new issues. I did test the open aarch64 port since I > have the hardware, and someone was kind enough to provide me with > binaries both without the patch (which reproduced the bug) and with > the patch (which passed). No other aarch64 testing was done. > > Now on to an explanation of the bug and the fix: > > The test is testing the JDI/JVMTI forceEarlyReturn support. After the > debugger side spawns the debugee process and the debugee thread is > created, a vm.suspend() is issued to suspend all threads on the > debugee side. The debugger side then issues a JDI forceEarlyReturn, > which will cause the debugee thread to exit the currently executing > method. Although the intent is to force exit of the run() method, the > run() method does make some method calls to some very small methods > with "inline" in their name, such as inlineMethodReturningObject(). If > forceEarlyReturn is done while in one of them, JDI throws > InvalidTargetException, which the test correctly handles and will pass > if that happens. > > If the run() method is not yet compiled, what *normally* happens to > force the thread to suspend is to swap in the interpreter safepoint > dispatch table. This will result in a call_VM out to the interpreter > to handle the safepointing. When later the thread is resumed (after > initiating the forceEarlyReturn), there is code on the return side of > call_VM to make sure the earlyret is handled immediately before any > other bytecodes are exectuted. Thus the method that was executing at > the time of the forceEarlyReturn should be the same as the method when > the earlyret is handled. In fact it should be the same bytetcode(bci). > Like I said, this is what *normally* happens, but is not the way the > bug is exposed. > > The bug turns up when the run() method is not yet compiled, and when > the suspend is attempted we are in one of the small "inline" methods, > and it is compiled. In this case thread suspension is achieved in a > different manner. When a compiled method executes its return code, it > first pops its frame, and then the " poll_return" safepoint polling > instruction is executed. This allows the thread to be suspended. We > are technically in the run() method at this point since the frame of > the "inline" method has been popped. Therefore the forceEarlyReturn > is allowed. When the thread is resumed, the return from the "inline" > method finally happens, which puts us in code generated by > TemplateInterpreterGenerator::generate_return_entry_for(). However, > there are no checks for an earlyret here, so we start executing > bytecodes until we finally hit an earlyret check. This happens when > the next invokespecial is done. There is a call_VM after the frame is > pushed, and the call_VM always does an earlyret check. The problem is > now the topmost frame (in the case where it asserts) is > inlineMethodReturningObject(). Since it returns an object type, the > earlyret code expects there to be an oop in the earlyret slot on the > stack. But there isn't because the forceEarlyReturn was done on the > void run() method. So the earlyret code fetches garbage, does an > validity test on it, and gets the assert you see in the bug title. > > So what is needed here is an earlyret check after the compiled > "inline" method returns, and before any new bytecodes are executed. > Since TemplateInterpreterGenerator::generate_return_entry_for() is > always executed when the compiled "inline" method returns, the check > was added here. For completeness, the popframe check was also added. > The header file changes are just to make these methods public so they > can be called. > > I tested the failed test at least 100 times on each supported > platform. The assert usually showed up at least 1 in 50 times. I also > ran a large set of tests on all supported platforms, including > everything we do for nightly testing except for some of the longest > running tests. > > thanks, > > Chris > From chris.plummer at oracle.com Tue Feb 21 23:41:31 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 21 Feb 2017 15:41:31 -0800 Subject: RFR(10): 8172020: Internal Error (cpu/arm/vm/frame_arm.cpp:571): assert(obj == __null || Universe::heap()->is_in(obj)) failed: sanity check # In-Reply-To: References: <9550f15e-9b2b-7909-1856-eb68a6df2b5a@oracle.com> Message-ID: Thanks Serguei! On 2/21/17 3:29 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > It looks good to me. > But let me mediate on the fix a little bit more. > Consider it reviewed if I'll not come back in 24 hours. :) > > Thank you a lot for this great investigation and fix! > Serguei > > > On 2/21/17 11:31, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> http://cr.openjdk.java.net/~cjplummer/8172020/webrev.01/webrev.hotspot/ >> https://bugs.openjdk.java.net/browse/JDK-8172020 >> >> [Note there are s390, ppc, and aarch64 changes in this bug fix that I >> will need to have someone verify for me or I won't be pushing them.] >> >> This bug turns up with a closed test so the CR is marked >> confidential. I'll try to provided the necessary details here. Sorry >> the explanation is lengthy, but it is a complex bug (with a >> relatively simple fix). >> >> If you are on the s390, ppc, or aarch64 teams and just want to help >> verify the fix, I would say it's not necessary to understand the >> details of the bug. What's most important is you test the changes. >> Unfortunately you won't be able to reproduce the issue since the test >> is closed, but you should at least verify the fix builds and >> introduces no new issues. I did test the open aarch64 port since I >> have the hardware, and someone was kind enough to provide me with >> binaries both without the patch (which reproduced the bug) and with >> the patch (which passed). No other aarch64 testing was done. >> >> Now on to an explanation of the bug and the fix: >> >> The test is testing the JDI/JVMTI forceEarlyReturn support. After the >> debugger side spawns the debugee process and the debugee thread is >> created, a vm.suspend() is issued to suspend all threads on the >> debugee side. The debugger side then issues a JDI forceEarlyReturn, >> which will cause the debugee thread to exit the currently executing >> method. Although the intent is to force exit of the run() method, the >> run() method does make some method calls to some very small methods >> with "inline" in their name, such as inlineMethodReturningObject(). >> If forceEarlyReturn is done while in one of them, JDI throws >> InvalidTargetException, which the test correctly handles and will >> pass if that happens. >> >> If the run() method is not yet compiled, what *normally* happens to >> force the thread to suspend is to swap in the interpreter safepoint >> dispatch table. This will result in a call_VM out to the interpreter >> to handle the safepointing. When later the thread is resumed (after >> initiating the forceEarlyReturn), there is code on the return side of >> call_VM to make sure the earlyret is handled immediately before any >> other bytecodes are exectuted. Thus the method that was executing at >> the time of the forceEarlyReturn should be the same as the method >> when the earlyret is handled. In fact it should be the same >> bytetcode(bci). Like I said, this is what *normally* happens, but is >> not the way the bug is exposed. >> >> The bug turns up when the run() method is not yet compiled, and when >> the suspend is attempted we are in one of the small "inline" methods, >> and it is compiled. In this case thread suspension is achieved in a >> different manner. When a compiled method executes its return code, it >> first pops its frame, and then the " poll_return" safepoint polling >> instruction is executed. This allows the thread to be suspended. We >> are technically in the run() method at this point since the frame of >> the "inline" method has been popped. Therefore the forceEarlyReturn >> is allowed. When the thread is resumed, the return from the "inline" >> method finally happens, which puts us in code generated by >> TemplateInterpreterGenerator::generate_return_entry_for(). However, >> there are no checks for an earlyret here, so we start executing >> bytecodes until we finally hit an earlyret check. This happens when >> the next invokespecial is done. There is a call_VM after the frame is >> pushed, and the call_VM always does an earlyret check. The problem is >> now the topmost frame (in the case where it asserts) is >> inlineMethodReturningObject(). Since it returns an object type, the >> earlyret code expects there to be an oop in the earlyret slot on the >> stack. But there isn't because the forceEarlyReturn was done on the >> void run() method. So the earlyret code fetches garbage, does an >> validity test on it, and gets the assert you see in the bug title. >> >> So what is needed here is an earlyret check after the compiled >> "inline" method returns, and before any new bytecodes are executed. >> Since TemplateInterpreterGenerator::generate_return_entry_for() is >> always executed when the compiled "inline" method returns, the check >> was added here. For completeness, the popframe check was also added. >> The header file changes are just to make these methods public so they >> can be called. >> >> I tested the failed test at least 100 times on each supported >> platform. The assert usually showed up at least 1 in 50 times. I also >> ran a large set of tests on all supported platforms, including >> everything we do for nightly testing except for some of the longest >> running tests. >> >> thanks, >> >> Chris >> > From lutz.schmidt at sap.com Wed Feb 22 06:59:16 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 22 Feb 2017 06:59:16 +0000 Subject: RFR (XS) 8175267: [s390] cleanup stub code "handler_for_unsafe_access" In-Reply-To: <60f9e802-ca60-cbdd-e6ec-cc2d4f06b589@oracle.com> References: <60f9e802-ca60-cbdd-e6ec-cc2d4f06b589@oracle.com> Message-ID: <3C50656D-2D4C-4C2F-9B29-CBEDF19B5320@sap.com> Hi David, thanks for reviewing! Lutz On 22.02.17, 04:09, "David Holmes" wrote: Hi Lutz, I concur that this removes all code related to handler_for_unsafe_access in the s390 code. Reviewed. :) Thanks, David On 22/02/2017 1:38 AM, Schmidt, Lutz wrote: > Hi all, > > May I kindly request reviews for my very small cleanup change? Further down the road, I would need a sponsor, too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175267 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175267/ > > Description: > The "handler_for_unsafe_access? is a relic from former times, having survived only on s390x. The stub is generated, but never used (called). This change removes everything related. > > Thanks, > Lutz > From goetz.lindenmaier at sap.com Wed Feb 22 08:53:31 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 22 Feb 2017 08:53:31 +0000 Subject: RFR (XS) 8175267: [s390] cleanup stub code "handler_for_unsafe_access" In-Reply-To: <46d01d26ecc54e00bbc053a1a77b6dee@sap.com> References: <46d01d26ecc54e00bbc053a1a77b6dee@sap.com> Message-ID: <25b90d1e03ee45459a3e97cf375bccc2@sap.com> Hi Lutz, the change looks good. Best regards, Goetz. > -----Original Message----- > From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On > Behalf Of Doerr, Martin > Sent: Dienstag, 21. Februar 2017 19:11 > To: Schmidt, Lutz ; s390x-port- > dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: RE: RFR (XS) 8175267: [s390] cleanup stub code > "handler_for_unsafe_access" > > Hi Lutz, > > thanks for doing this cleanup. Looks good to me. > I think I can sponsor it as it only touches s390 files and is targeted for jdk10. > However, we need a jdk10 reviewer, too. > > Best regards, > Martin > > > -----Original Message----- > From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On > Behalf Of Schmidt, Lutz > Sent: Dienstag, 21. Februar 2017 16:38 > To: s390x-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: RFR (XS) 8175267: [s390] cleanup stub code > "handler_for_unsafe_access" > > Hi all, > > May I kindly request reviews for my very small cleanup change? Further > down the road, I would need a sponsor, too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175267 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175267/ > > Description: > The "handler_for_unsafe_access? is a relic from former times, having > survived only on s390x. The stub is generated, but never used (called). This > change removes everything related. > > Thanks, > Lutz From jesper.wilhelmsson at oracle.com Thu Feb 16 19:56:32 2017 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 16 Feb 2017 20:56:32 +0100 Subject: URGENT: RFR: [BACKOUT] fix for JDK-8166188 In-Reply-To: <66ddf3ea-83e0-ab69-443f-e33dc3be7b8f@oracle.com> References: <66ddf3ea-83e0-ab69-443f-e33dc3be7b8f@oracle.com> Message-ID: <1a37f025-1101-50e5-0171-c7e28a941668@oracle.com> Looks good! /Jesper On 2017-02-16 20:21, Daniel D. Daugherty wrote: > Greetings, > > Sending this backout code review to the same aliases used for: > > JDK-8166188 G1 Needs pre barrier on dereference of weak JNI handles > https://bugs.openjdk.java.net/browse/JDK-8166188 > > more as a heads up that JDK-8166188 might be getting backed out. > > I only need reviews from Kim and Jesper. > > Doing a contingent backout of Kim's fix for the above due to some > unexpected test failures with some JDK tests: > > JDK-8175085 8166188 causes JDK test failures > https://bugs.openjdk.java.net/browse/JDK-8175085 > > JDK-8175086 [BACKOUT] fix for JDK-8166188 > https://bugs.openjdk.java.net/browse/JDK-8175086 > > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8175086-webrev/0-jdk9-hs/ > > > I used "hg backout 3bc68ff68250" which created a child > changeset of Kim's: > > changeset: 12639:3bc68ff68250 > user: kbarrett > date: Wed Feb 15 22:19:13 2017 -0500 > summary: 8166188: G1 Needs pre barrier on dereference of weak JNI > handles > > The backout changeset: > > changeset: 12644:ee34d6aabf5f > parent: 12639:3bc68ff68250 > user: dcubed > date: Thu Feb 16 10:41:19 2017 -0800 > summary: 8175086: [BACKOUT] fix for JDK-8166188 > > and then I used "hg merge" to merge with current tip. > This was a "branch" merge with no conflicts. > > > Sanity checks: > > - The parent of Kim's changeset is: > > changeset: 12638:35db0413819a > user: roland > date: Wed Feb 15 17:26:37 2017 -0800 > summary: 8174164: SafePointNode::_replaced_nodes breaks with > irreducible loops > > - hg diff -r 35db0413819a -r ee34d6aabf5f > > shows no output so the backout is clean. > > - $ wc -l files.list > 37 files.list > > - $ hg diff -r 35db0413819a -r tip `cat files.list` > > shows no output so the merge with the tip is clean. > > Thanks, in advance, for reviews from Jesper and Kim!! > > Dan > From david.holmes at oracle.com Wed Feb 22 03:09:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Feb 2017 13:09:33 +1000 Subject: RFR (XS) 8175267: [s390] cleanup stub code "handler_for_unsafe_access" In-Reply-To: References: Message-ID: <60f9e802-ca60-cbdd-e6ec-cc2d4f06b589@oracle.com> Hi Lutz, I concur that this removes all code related to handler_for_unsafe_access in the s390 code. Reviewed. :) Thanks, David On 22/02/2017 1:38 AM, Schmidt, Lutz wrote: > Hi all, > > May I kindly request reviews for my very small cleanup change? Further down the road, I would need a sponsor, too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175267 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175267/ > > Description: > The "handler_for_unsafe_access? is a relic from former times, having survived only on s390x. The stub is generated, but never used (called). This change removes everything related. > > Thanks, > Lutz > From volker.simonis at gmail.com Thu Feb 23 16:52:28 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Feb 2017 17:52:28 +0100 Subject: RFR(10): 8172020: Internal Error (cpu/arm/vm/frame_arm.cpp:571): assert(obj == __null || Universe::heap()->is_in(obj)) failed: sanity check # In-Reply-To: <9550f15e-9b2b-7909-1856-eb68a6df2b5a@oracle.com> References: <9550f15e-9b2b-7909-1856-eb68a6df2b5a@oracle.com> Message-ID: Hi Chris, thanks for considering ppc64 and s390x! Your change builds and works on both platforms. Regards, Volker On Tue, Feb 21, 2017 at 8:31 PM, Chris Plummer wrote: > Hello, > > Please review the following: > > http://cr.openjdk.java.net/~cjplummer/8172020/webrev.01/webrev.hotspot/ > https://bugs.openjdk.java.net/browse/JDK-8172020 > > [Note there are s390, ppc, and aarch64 changes in this bug fix that I will > need to have someone verify for me or I won't be pushing them.] > > This bug turns up with a closed test so the CR is marked confidential. I'll > try to provided the necessary details here. Sorry the explanation is > lengthy, but it is a complex bug (with a relatively simple fix). > > If you are on the s390, ppc, or aarch64 teams and just want to help verify > the fix, I would say it's not necessary to understand the details of the > bug. What's most important is you test the changes. Unfortunately you won't > be able to reproduce the issue since the test is closed, but you should at > least verify the fix builds and introduces no new issues. I did test the > open aarch64 port since I have the hardware, and someone was kind enough to > provide me with binaries both without the patch (which reproduced the bug) > and with the patch (which passed). No other aarch64 testing was done. > > Now on to an explanation of the bug and the fix: > > The test is testing the JDI/JVMTI forceEarlyReturn support. After the > debugger side spawns the debugee process and the debugee thread is created, > a vm.suspend() is issued to suspend all threads on the debugee side. The > debugger side then issues a JDI forceEarlyReturn, which will cause the > debugee thread to exit the currently executing method. Although the intent > is to force exit of the run() method, the run() method does make some method > calls to some very small methods with "inline" in their name, such as > inlineMethodReturningObject(). If forceEarlyReturn is done while in one of > them, JDI throws InvalidTargetException, which the test correctly handles > and will pass if that happens. > > If the run() method is not yet compiled, what *normally* happens to force > the thread to suspend is to swap in the interpreter safepoint dispatch > table. This will result in a call_VM out to the interpreter to handle the > safepointing. When later the thread is resumed (after initiating the > forceEarlyReturn), there is code on the return side of call_VM to make sure > the earlyret is handled immediately before any other bytecodes are > exectuted. Thus the method that was executing at the time of the > forceEarlyReturn should be the same as the method when the earlyret is > handled. In fact it should be the same bytetcode(bci). Like I said, this is > what *normally* happens, but is not the way the bug is exposed. > > The bug turns up when the run() method is not yet compiled, and when the > suspend is attempted we are in one of the small "inline" methods, and it is > compiled. In this case thread suspension is achieved in a different manner. > When a compiled method executes its return code, it first pops its frame, > and then the " poll_return" safepoint polling instruction is executed. This > allows the thread to be suspended. We are technically in the run() method at > this point since the frame of the "inline" method has been popped. > Therefore the forceEarlyReturn is allowed. When the thread is resumed, the > return from the "inline" method finally happens, which puts us in code > generated by TemplateInterpreterGenerator::generate_return_entry_for(). > However, there are no checks for an earlyret here, so we start executing > bytecodes until we finally hit an earlyret check. This happens when the next > invokespecial is done. There is a call_VM after the frame is pushed, and the > call_VM always does an earlyret check. The problem is now the topmost frame > (in the case where it asserts) is inlineMethodReturningObject(). Since it > returns an object type, the earlyret code expects there to be an oop in the > earlyret slot on the stack. But there isn't because the forceEarlyReturn was > done on the void run() method. So the earlyret code fetches garbage, does an > validity test on it, and gets the assert you see in the bug title. > > So what is needed here is an earlyret check after the compiled "inline" > method returns, and before any new bytecodes are executed. Since > TemplateInterpreterGenerator::generate_return_entry_for() is always executed > when the compiled "inline" method returns, the check was added here. For > completeness, the popframe check was also added. The header file changes are > just to make these methods public so they can be called. > > I tested the failed test at least 100 times on each supported platform. The > assert usually showed up at least 1 in 50 times. I also ran a large set of > tests on all supported platforms, including everything we do for nightly > testing except for some of the longest running tests. > > thanks, > > Chris > From chris.plummer at oracle.com Mon Feb 27 18:41:55 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 27 Feb 2017 10:41:55 -0800 Subject: RFR(10): 8172020: Internal Error (cpu/arm/vm/frame_arm.cpp:571): assert(obj == __null || Universe::heap()->is_in(obj)) failed: sanity check # In-Reply-To: References: <9550f15e-9b2b-7909-1856-eb68a6df2b5a@oracle.com> Message-ID: Thanks Volker! On 2/23/17 8:52 AM, Volker Simonis wrote: > Hi Chris, > > thanks for considering ppc64 and s390x! > Your change builds and works on both platforms. > > Regards, > Volker > > > On Tue, Feb 21, 2017 at 8:31 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> http://cr.openjdk.java.net/~cjplummer/8172020/webrev.01/webrev.hotspot/ >> https://bugs.openjdk.java.net/browse/JDK-8172020 >> >> [Note there are s390, ppc, and aarch64 changes in this bug fix that I will >> need to have someone verify for me or I won't be pushing them.] >> >> This bug turns up with a closed test so the CR is marked confidential. I'll >> try to provided the necessary details here. Sorry the explanation is >> lengthy, but it is a complex bug (with a relatively simple fix). >> >> If you are on the s390, ppc, or aarch64 teams and just want to help verify >> the fix, I would say it's not necessary to understand the details of the >> bug. What's most important is you test the changes. Unfortunately you won't >> be able to reproduce the issue since the test is closed, but you should at >> least verify the fix builds and introduces no new issues. I did test the >> open aarch64 port since I have the hardware, and someone was kind enough to >> provide me with binaries both without the patch (which reproduced the bug) >> and with the patch (which passed). No other aarch64 testing was done. >> >> Now on to an explanation of the bug and the fix: >> >> The test is testing the JDI/JVMTI forceEarlyReturn support. After the >> debugger side spawns the debugee process and the debugee thread is created, >> a vm.suspend() is issued to suspend all threads on the debugee side. The >> debugger side then issues a JDI forceEarlyReturn, which will cause the >> debugee thread to exit the currently executing method. Although the intent >> is to force exit of the run() method, the run() method does make some method >> calls to some very small methods with "inline" in their name, such as >> inlineMethodReturningObject(). If forceEarlyReturn is done while in one of >> them, JDI throws InvalidTargetException, which the test correctly handles >> and will pass if that happens. >> >> If the run() method is not yet compiled, what *normally* happens to force >> the thread to suspend is to swap in the interpreter safepoint dispatch >> table. This will result in a call_VM out to the interpreter to handle the >> safepointing. When later the thread is resumed (after initiating the >> forceEarlyReturn), there is code on the return side of call_VM to make sure >> the earlyret is handled immediately before any other bytecodes are >> exectuted. Thus the method that was executing at the time of the >> forceEarlyReturn should be the same as the method when the earlyret is >> handled. In fact it should be the same bytetcode(bci). Like I said, this is >> what *normally* happens, but is not the way the bug is exposed. >> >> The bug turns up when the run() method is not yet compiled, and when the >> suspend is attempted we are in one of the small "inline" methods, and it is >> compiled. In this case thread suspension is achieved in a different manner. >> When a compiled method executes its return code, it first pops its frame, >> and then the " poll_return" safepoint polling instruction is executed. This >> allows the thread to be suspended. We are technically in the run() method at >> this point since the frame of the "inline" method has been popped. >> Therefore the forceEarlyReturn is allowed. When the thread is resumed, the >> return from the "inline" method finally happens, which puts us in code >> generated by TemplateInterpreterGenerator::generate_return_entry_for(). >> However, there are no checks for an earlyret here, so we start executing >> bytecodes until we finally hit an earlyret check. This happens when the next >> invokespecial is done. There is a call_VM after the frame is pushed, and the >> call_VM always does an earlyret check. The problem is now the topmost frame >> (in the case where it asserts) is inlineMethodReturningObject(). Since it >> returns an object type, the earlyret code expects there to be an oop in the >> earlyret slot on the stack. But there isn't because the forceEarlyReturn was >> done on the void run() method. So the earlyret code fetches garbage, does an >> validity test on it, and gets the assert you see in the bug title. >> >> So what is needed here is an earlyret check after the compiled "inline" >> method returns, and before any new bytecodes are executed. Since >> TemplateInterpreterGenerator::generate_return_entry_for() is always executed >> when the compiled "inline" method returns, the check was added here. For >> completeness, the popframe check was also added. The header file changes are >> just to make these methods public so they can be called. >> >> I tested the failed test at least 100 times on each supported platform. The >> assert usually showed up at least 1 in 50 times. I also ran a large set of >> tests on all supported platforms, including everything we do for nightly >> testing except for some of the longest running tests. >> >> thanks, >> >> Chris >>