From dean.long at oracle.com Wed Nov 1 03:03:09 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 31 Oct 2017 20:03:09 -0700 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> Message-ID: Much better.? But why does the test need -Xbatch -Xcomp?? To me this doesn't look like a compiler-only issue.? The test should give the same result with -Xint right?? Adding runtime alias for their input... dl On 10/31/17 12:37 PM, jamsheed wrote: > Hi Dean, > > Thank you for the review, > > tested with a test case, previously it was not working for > windows-x86, now it works. > > revised webrev with test > case:http://cr.openjdk.java.net/~jcm/8167408/webrev.01/ > > Best regards, > > Jamsheed > > > On Tuesday 31 October 2017 02:18 AM, dean.long at oracle.com wrote: >> I think you need a native test for Windows x86 that defines >> JavaCritical methods with various signatures (especially arrays) to >> make sure this is working correctly. >> >> dl >> >> >> On 10/30/17 9:45 AM, jamsheed wrote: >>> Hi, >>> >>> request for review, >>> >>> jbs : https://bugs.openjdk.java.net/browse/JDK-8167408 >>> >>> webrev: http://cr.openjdk.java.net/~jcm/8167408/webrev.00/ >>> >>> (contributed by Ioannis Tsakpinis) >>> >>> desc: >>> >>> -- it starts with JavaCritical_ instead of Java_; >>> -- it does not have extra JNIEnv* and jclass arguments; >>> -- Java arrays are passed in two arguments: the first is an array >>> length, and the second is a pointer to raw array data. That is, no >>> need to call GetArrayElements and friends, you can instantly use a >>> direct array pointer. >>> >>> updated arg_size calculation wrt above points. >>> >>> Best regards, >>> >>> Jamsheed >>> >> > From david.holmes at oracle.com Wed Nov 1 03:11:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Nov 2017 13:11:44 +1000 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> Message-ID: <10969e74-47a1-5457-fcb2-75c3d1271243@oracle.com> On 1/11/2017 1:03 PM, dean.long at oracle.com wrote: > Much better.? But why does the test need -Xbatch -Xcomp?? To me this > doesn't look like a compiler-only issue.? The test should give the same > result with -Xint right?? Adding runtime alias for their input... AFAICS this should be a completely compiler and platform agnostic issue. Good to add tests but they shouldn't be restricted to only 32-bit Windows (especially as we no longer support it or do promoted builds for it, or even build in Mach5!). Thanks, David > dl > > > On 10/31/17 12:37 PM, jamsheed wrote: >> Hi Dean, >> >> Thank you for the review, >> >> tested with a test case, previously it was not working for >> windows-x86, now it works. >> >> revised webrev with test >> case:http://cr.openjdk.java.net/~jcm/8167408/webrev.01/ >> >> Best regards, >> >> Jamsheed >> >> >> On Tuesday 31 October 2017 02:18 AM, dean.long at oracle.com wrote: >>> I think you need a native test for Windows x86 that defines >>> JavaCritical methods with various signatures (especially arrays) to >>> make sure this is working correctly. >>> >>> dl >>> >>> >>> On 10/30/17 9:45 AM, jamsheed wrote: >>>> Hi, >>>> >>>> request for review, >>>> >>>> jbs : https://bugs.openjdk.java.net/browse/JDK-8167408 >>>> >>>> webrev: http://cr.openjdk.java.net/~jcm/8167408/webrev.00/ >>>> >>>> (contributed by Ioannis Tsakpinis) >>>> >>>> desc: >>>> >>>> -- it starts with JavaCritical_ instead of Java_; >>>> -- it does not have extra JNIEnv* and jclass arguments; >>>> -- Java arrays are passed in two arguments: the first is an array >>>> length, and the second is a pointer to raw array data. That is, no >>>> need to call GetArrayElements and friends, you can instantly use a >>>> direct array pointer. >>>> >>>> updated arg_size calculation wrt above points. >>>> >>>> Best regards, >>>> >>>> Jamsheed >>>> >>> >> > From david.holmes at oracle.com Wed Nov 1 04:46:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Nov 2017 14:46:53 +1000 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: <10969e74-47a1-5457-fcb2-75c3d1271243@oracle.com> References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> <10969e74-47a1-5457-fcb2-75c3d1271243@oracle.com> Message-ID: <87e06194-5c4a-650c-8029-fe778182030a@oracle.com> On 1/11/2017 1:11 PM, David Holmes wrote: > On 1/11/2017 1:03 PM, dean.long at oracle.com wrote: >> Much better.? But why does the test need -Xbatch -Xcomp?? To me this >> doesn't look like a compiler-only issue.? The test should give the >> same result with -Xint right?? Adding runtime alias for their input... > > AFAICS this should be a completely compiler and platform agnostic issue. Platform agnostic yes, but the test fails without -Xcomp (doesn't seem to need -Xbatch). So there's something about this critical function mechanism that I don't understand. That said the test needs more logging so that if it does fail you can see what, if anything got executed. So the non-critical versions of the methods should print that they were called, and for good measure also the critical versions. Thanks, David From kim.barrett at oracle.com Wed Nov 1 05:03:38 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Nov 2017 01:03:38 -0400 Subject: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to jweak values In-Reply-To: References: <94B50A35-9898-47BA-8F20-A829FD7547AC@oracle.com> Message-ID: > On Oct 30, 2017, at 7:14 AM, Doug Simon wrote: > > Hi Kim, > > Thanks for the detailed review. > >> On 29 Oct 2017, at 23:29, Kim Barrett wrote: >> >> [added hotspot-gc-dev to cc list] >> >>> On Oct 27, 2017, at 5:05 PM, Doug Simon wrote: >>> >>> Please review this change that converts the JVMCI-specific object references in nmethod from oops to weak values. This removes GC API extensions added purely for these fields (e.g. so that G1 can insert it into the right remembered set, and when unloading an nmethod, to go and remove the nmethod from that remembered set). >>> >>> Testing: I've run the Graal unit tests (mx unittest --verbose --gc-after-test -Xlog:class+unload=trace) which trigger a lot of nmethod unloading. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8188102 >>> http://cr.openjdk.java.net/~dnsimon/8188102/ >> >> I didn't look at the .java, .py, or project files. >> >> ------------------------------------------------------------------------------ >> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp >> 1061 nmethod* nm = cb->as_nmethod_or_null(); >> >> This appears to be dead code now. > > Indeed. > >> ------------------------------------------------------------------------------ >> src/hotspot/share/code/nmethod.cpp >> 1023 assert(Universe::heap()->is_gc_active(), "should only be called during gc"); >> ... >> 1036 if (!Universe::heap()->is_gc_active() && cause != NULL) >> 1037 cause->klass()->print_on(&ls); >> >> I was going to mention that lines 1036-1037 are missing braces around >> the if-body. However, those lines appear to be dead code, given the >> assertion on line 1023. > > Good catch. That problem pre-dates this webrev but I will clean it up here. > >> ------------------------------------------------------------------------------ >> src/hotspot/share/code/nmethod.cpp >> 1504 bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >> ... >> 1506 oop installed_code = JNIHandles::resolve(_jvmci_installed_code); >> >> Resolving a weak reference can keep an otherwise dead referent alive. >> See JDK-8188055 for a discussion of the corresponding problem for >> j.l.r.Reference. >> >> Right now, I think JNIHandles doesn't provide a (public) solution to >> what I think is being attempted here that works for all collectors. >> There is in-progress work toward a solution, but it's just that, "in >> progress". >> >> As a (possibly interim) solution, a function like the following might >> be added to JNIHandles (put the definition near resolve_jweak). >> >> bool JNIHandles::is_global_weak_cleared(jweak handle) { >> assert(is_jweak(handle), "not a weak handle"); >> return guard_value(jweak_ref(handle)) == NULL; >> } > > Adding JNIHandles::is_global_weak_cleared makes sense. I've put it the public section near destroy_weak_global instead of the private section where resolve_jweak is declared. > >> (That's completely untested, and I haven't thought carefully about the >> name. And should get input from other GC folks on how to deal with >> this.) I *think* do_unloading_jvmci then becomes something like the >> following (again, completely untested) >> >> bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >> if (_jvmci_installed_code != NULL) { >> if (JNIHandles::is_global_weak_cleared(_jvmci_installed_code)) { >> if (_jvmci_installed_code_triggers_unloading) { >> make_unloaded(is_alive, NULL); >> return true; >> } else { >> clear_jvmci_installed_code(); >> } >> } >> } >> return false; >> } > > I think your change works but comes at the cost of potentially preventing nmethod unloading for 1 extra (full?) GC cycle. It assumes that jweak clearing occurs before nmethod scanning. Is that guaranteed? If not, then I think what we want is: > > bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { > if (_jvmci_installed_code != NULL) { > bool cleared = JNIHandles::is_global_weak_cleared(_jvmci_installed_code); > if (_jvmci_installed_code_triggers_unloading) { > if (cleared) { > // jweak reference processing has already cleared the referent > make_unloaded(is_alive, NULL); > return true; > } else { > oop installed_code = JNIHandles::resolve(_jvmci_installed_code); > if (can_unload(is_alive, (oop*)&installed_code, unloading_occurred)) { > return true; > } > } > } else { > if (cleared || !is_alive->do_object_b(JNIHandles::resolve(_jvmci_installed_code))) { > clear_jvmci_installed_code(); > } > } > } > return false; > } > > I've created a new webrev at http://cr.openjdk.java.net/~dnsimon/8188102_2. > > -Doug The old code was looking for objects that are no longer alive; that can't be determined until after reference processing, as finalization could change the answer. jweak clearing used to happen as part of reference processing, but there's been some recent refactoring. I don't think that was intended to change the order of jweak processing wrto other things, but I haven't looked at the code to verify I'm not overlooking something. In addition, I think } else { oop installed_code = JNIHandles::resolve(_jvmci_installed_code); if (can_unload(is_alive, (oop*)&installed_code, unloading_occurred)) { return true; } doesn't work for some collectors (like G1), since the resolve will force installed_code to be live (if jweak processing were performed after nmethod processing), so can_unload will always return false. From erik.osterlund at oracle.com Wed Nov 1 09:44:53 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 1 Nov 2017 10:44:53 +0100 Subject: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to jweak values In-Reply-To: References: <94B50A35-9898-47BA-8F20-A829FD7547AC@oracle.com> Message-ID: <59F99795.6090404@oracle.com> Hi Kim, On 2017-11-01 06:03, Kim Barrett wrote: >> On Oct 30, 2017, at 7:14 AM, Doug Simon wrote: >> >> Hi Kim, >> >> Thanks for the detailed review. >> >>> On 29 Oct 2017, at 23:29, Kim Barrett wrote: >>> >>> [added hotspot-gc-dev to cc list] >>> >>>> On Oct 27, 2017, at 5:05 PM, Doug Simon wrote: >>>> >>>> Please review this change that converts the JVMCI-specific object references in nmethod from oops to weak values. This removes GC API extensions added purely for these fields (e.g. so that G1 can insert it into the right remembered set, and when unloading an nmethod, to go and remove the nmethod from that remembered set). >>>> >>>> Testing: I've run the Graal unit tests (mx unittest --verbose --gc-after-test -Xlog:class+unload=trace) which trigger a lot of nmethod unloading. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8188102 >>>> http://cr.openjdk.java.net/~dnsimon/8188102/ >>> I didn't look at the .java, .py, or project files. >>> >>> ------------------------------------------------------------------------------ >>> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp >>> 1061 nmethod* nm = cb->as_nmethod_or_null(); >>> >>> This appears to be dead code now. >> Indeed. >> >>> ------------------------------------------------------------------------------ >>> src/hotspot/share/code/nmethod.cpp >>> 1023 assert(Universe::heap()->is_gc_active(), "should only be called during gc"); >>> ... >>> 1036 if (!Universe::heap()->is_gc_active() && cause != NULL) >>> 1037 cause->klass()->print_on(&ls); >>> >>> I was going to mention that lines 1036-1037 are missing braces around >>> the if-body. However, those lines appear to be dead code, given the >>> assertion on line 1023. >> Good catch. That problem pre-dates this webrev but I will clean it up here. >> >>> ------------------------------------------------------------------------------ >>> src/hotspot/share/code/nmethod.cpp >>> 1504 bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >>> ... >>> 1506 oop installed_code = JNIHandles::resolve(_jvmci_installed_code); >>> >>> Resolving a weak reference can keep an otherwise dead referent alive. >>> See JDK-8188055 for a discussion of the corresponding problem for >>> j.l.r.Reference. >>> >>> Right now, I think JNIHandles doesn't provide a (public) solution to >>> what I think is being attempted here that works for all collectors. >>> There is in-progress work toward a solution, but it's just that, "in >>> progress". >>> >>> As a (possibly interim) solution, a function like the following might >>> be added to JNIHandles (put the definition near resolve_jweak). >>> >>> bool JNIHandles::is_global_weak_cleared(jweak handle) { >>> assert(is_jweak(handle), "not a weak handle"); >>> return guard_value(jweak_ref(handle)) == NULL; >>> } >> Adding JNIHandles::is_global_weak_cleared makes sense. I've put it the public section near destroy_weak_global instead of the private section where resolve_jweak is declared. >> >>> (That's completely untested, and I haven't thought carefully about the >>> name. And should get input from other GC folks on how to deal with >>> this.) I *think* do_unloading_jvmci then becomes something like the >>> following (again, completely untested) >>> >>> bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >>> if (_jvmci_installed_code != NULL) { >>> if (JNIHandles::is_global_weak_cleared(_jvmci_installed_code)) { >>> if (_jvmci_installed_code_triggers_unloading) { >>> make_unloaded(is_alive, NULL); >>> return true; >>> } else { >>> clear_jvmci_installed_code(); >>> } >>> } >>> } >>> return false; >>> } >> I think your change works but comes at the cost of potentially preventing nmethod unloading for 1 extra (full?) GC cycle. It assumes that jweak clearing occurs before nmethod scanning. Is that guaranteed? If not, then I think what we want is: >> >> bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >> if (_jvmci_installed_code != NULL) { >> bool cleared = JNIHandles::is_global_weak_cleared(_jvmci_installed_code); >> if (_jvmci_installed_code_triggers_unloading) { >> if (cleared) { >> // jweak reference processing has already cleared the referent >> make_unloaded(is_alive, NULL); >> return true; >> } else { >> oop installed_code = JNIHandles::resolve(_jvmci_installed_code); >> if (can_unload(is_alive, (oop*)&installed_code, unloading_occurred)) { >> return true; >> } >> } >> } else { >> if (cleared || !is_alive->do_object_b(JNIHandles::resolve(_jvmci_installed_code))) { >> clear_jvmci_installed_code(); >> } >> } >> } >> return false; >> } >> >> I've created a new webrev at http://cr.openjdk.java.net/~dnsimon/8188102_2. >> >> -Doug > The old code was looking for objects that are no longer alive; that > can't be determined until after reference processing, as finalization > could change the answer. jweak clearing used to happen as part of > reference processing, but there's been some recent refactoring. I > don't think that was intended to change the order of jweak processing > wrto other things, but I haven't looked at the code to verify I'm not > overlooking something. > > In addition, I think > > } else { > oop installed_code = JNIHandles::resolve(_jvmci_installed_code); > if (can_unload(is_alive, (oop*)&installed_code, unloading_occurred)) { > return true; > } > > doesn't work for some collectors (like G1), since the resolve will > force installed_code to be live (if jweak processing were performed > after nmethod processing), so can_unload will always return false. > JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something? Having said that, I agree this should be a "peek" resolve, which we may implement soon. Thanks, /Erik From vladimir.x.ivanov at oracle.com Wed Nov 1 12:46:53 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 1 Nov 2017 15:46:53 +0300 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: <87e06194-5c4a-650c-8029-fe778182030a@oracle.com> References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> <10969e74-47a1-5457-fcb2-75c3d1271243@oracle.com> <87e06194-5c4a-650c-8029-fe778182030a@oracle.com> Message-ID: <4c6c9f5a-8680-9116-edef-990a9abccdeb@oracle.com> No magic here: the test isn't designed to be executed in interpreter and always expect LookUp::test() to be compiled first. Normal JNI entries are empty, but the test checks that the first element is written to on the first invocation. I agree that the bug is specific to JIT-compilers, since critical entry points (JavaCritical_) are called only from compiled code. Interpreter always goes through ordinary native counterparts (Java_). IMO using -Xcomp is fine to force the methods to be compiled. -Xbatch is redundant in that case. Best regards, Vladimir Ivanov On 11/1/17 7:46 AM, David Holmes wrote: > On 1/11/2017 1:11 PM, David Holmes wrote: >> On 1/11/2017 1:03 PM, dean.long at oracle.com wrote: >>> Much better.? But why does the test need -Xbatch -Xcomp?? To me this >>> doesn't look like a compiler-only issue.? The test should give the >>> same result with -Xint right?? Adding runtime alias for their input... >> >> AFAICS this should be a completely compiler and platform agnostic issue. > > Platform agnostic yes, but the test fails without -Xcomp (doesn't seem > to need -Xbatch). So there's something about this critical function > mechanism that I don't understand. > > That said the test needs more logging so that if it does fail you can > see what, if anything got executed. So the non-critical versions of the > methods should print that they were called, and for good measure also > the critical versions. > > Thanks, > David > From dmitry.chuyko at bell-sw.com Wed Nov 1 13:53:27 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 1 Nov 2017 16:53:27 +0300 Subject: [10] RFR: 8189745 - AARCH64: Use CRC32C intrinsic code in interpreter and C1 In-Reply-To: References: Message-ID: <5f387efb-d2a4-9038-d44b-4b3b8447e9b0@bell-sw.com> Andrew, thanks for an instant review. Dmitrij Pochepko has pushed the change. -Dmitry On 10/31/2017 08:25 PM, Andrew Haley wrote: > Hi, > > On 31/10/17 16:01, Dmitry Chuyko wrote: > >> Please review an improvement of CRC32C calculation on AArch64. The >> implementation is based on JDK-8155162 [1] and the code for CRC32. >> >> Intrinsics for array / byte buffer and direct byte buffer are enabled in >> C1 on AArch64, LIRGenerator::do_update_CRC32C calculates parameters and >> calls StubRoutines::updateBytesCRC32C(). >> Template interpreter now also generates >> TemplateInterpreterGenerator::generate_CRC32C_updateBytes_entry where it >> calculates parameters and jumps to StubRoutines::updateBytesCRC32C(). >> >> rfe: https://bugs.openjdk.java.net/browse/JDK-8189745 >> webrev: http://cr.openjdk.java.net/~dchuyko/8189745/webrev.00/ >> benchmark: >> http://cr.openjdk.java.net/~dchuyko/8189745/crc32c/CRC32CBench.java >> >> Performance results for T88 [2] show ~7x boost in C1 and ~30-50x boost >> in interpreter. >> >> For testing I made comparison of CRC32C result sets in C1 and >> interpreter for both array and direct byte buffer with zero and non-zero >> offset. > That looks good to me, thanks. > From dmitry.chuyko at bell-sw.com Wed Nov 1 16:24:55 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 1 Nov 2017 19:24:55 +0300 Subject: [10] RFR: 8189176 - AARCH64: Improve _updateBytesCRC32 intrinsic In-Reply-To: References: Message-ID: As per Derek's suggestion I made private MacroAssembler::kernel_crc32_using_crc32(). Register naming became more clear, numeric results are the same. webrev: http://cr.openjdk.java.net/~dchuyko/8189176/webrev.01/ -Dmitry On 10/28/2017 10:52 AM, Andrew Haley wrote: > On 27/10/17 23:31, White, Derek wrote: >> - The use of temp registers in the UseCRC32 case is kind of muddled, using tmp, and table0..table3 as temp registers, and the name "table" is confusing in this case. >> - Maybe it would be cleaner to refactor the UseCRC32 code into a separate kernel_crc32_using_crc32() subroutine (static or macro?). This would accept the main args and 4 registers for temps. The caller can supply some combination of table or tmp registers. >> - This would shrink the size of kernel_crc32() by a lot too. > That would be nice. > From jcbeyler at google.com Wed Nov 1 17:46:31 2017 From: jcbeyler at google.com (JC Beyler) Date: Wed, 1 Nov 2017 10:46:31 -0700 Subject: Low-Overhead Heap Profiling In-Reply-To: <1508935388.13554.11.camel@oracle.com> References: <1497366226.2829.109.camel@oracle.com> <1498215147.2741.34.camel@oracle.com> <044f8c75-72f3-79fd-af47-7ee875c071fd@oracle.com> <23f4e6f5-c94e-01f7-ef1d-5e328d4823c8@oracle.com> <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> Message-ID: Dear all, Here is the next webrev: http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a/ Incremental since the rebase: http://cr.openjdk.java.net/~rasbold/8171119/webrev.14_14a/ (I'm still not too familiar with hg so I had to do a fresh rebase so v14 is once the rebase was done and v14a integrates the changes requested from Thomas). I have also inlined answers to Thomas' email: > > A few minor issues: > > - weak reference handling has been factored out in JDK-8189359, now > you only need to add the additions required for this change to one > place. :) Please update the webrev :) > > That is awesome and very happily done :) > - the one issue Robin noticed. > > - in the declaration of CollectedHeap::sample_allocation, it would be > nice if the fix_sample_rate parameter would be described - it takes a > time to figure out what it's used for. I.e. in case an allocation goes > beyond the sampling watermark, this value which represents the amount > of overallocation is used to adjust the next sampling watermark to > sample at the correct rate. > Something like this - and if what I wrote is incorrect, there is even > more reason to document it. > Or maybe just renaming "fix_sample_rate" to something more descriptive > - but I have no good idea about that. > With lack of units in the type, it would also be nice to have the unit > in the identifier name, as done elsewhere. > Done for Robbin's issue and changed it to > > - some (or most actually) of the new setters and getters in the > ThreadLocalAllocBuffer class could be private I think. Also, we > typically do not use "simple" getters that just return a member in the > class where they are defined. > I removed all that were not used that I could see (not used outside the class) moved the ones that are not simple to private if they could be. I think it's a bit weird because now some of the setting of the tlab internal data is using methods, others are directly setting. Let me know what you think. > > - ThreadLocalAllocBuffer::set_sample_end(): please use > pointer_delta() for pointer subtractions. > Done! > > - ThreadLocalAllocBuffer::pick_next_sample() - I recommend making the > first check an assert - it seems that it is only useful to call this > with heap monitoring enabled, as is done right now. > Longer conversation below about this, It cannot be an assert (I could remove the test altogether though). > > - ThreadLocalAllocBuffer::pick_next_sample() - please use > "PTR_FORMAT" (or INTPTR_FORMAT - they are the same) as format string > for printing pointer values as is customary within Hotspot. %p output > is OS dependent. I.e. I heard that e.g. on Ubuntu it prints "null" > instead of 0x0...0 .... which is kind of annoying. > Done :) > > - personal preference: do not allocate > HeapMonitoring::AlwaysTrueClosure globally, but only locally when it's > used. Setting it up seems to be very cheap. > Done! > > - HeapMonitoring::next_random() - the different names for the > constants use different formatting. Preferable (to me) is > UpperCamelCase, but at least make them uniform. > > I think done the way you wanted! > - in HeapMonitoring::next_random(), you might want to use > right_n_bits() to create your mask. Done! > > - not really convinced that it is a good idea to not somehow guard > StartHeapSampling() and StopHeapSampling() against being called by > multiple threads. > > I added another mutex for the start/stop so that way it will protect from that. > Otherwise looks okay from what I can see. > Awesome, what do you think I still need for this before going to the next step (which is what by the way? :)). --------------- Ok now the longer conversation about this remark: > - ThreadLocalAllocBuffer::pick_next_sample() - I recommend making the > first check an assert - it seems that it is only useful to call this > with heap monitoring enabled, as is done right now. > You can't do this right now because this is how the mutexes work right now to ensure we allow things to work fast but safely: I) Background before I go into details 1) You can turn on/off whenever you like; which flips the switch of the HeapMonitoring::enabled() method. 2) When you hit the end of a tlab, you go to the slow path, check HeapMonitoring::enabled() 3) Later in the handling of the sample if enabled() returned true, you get to the point of choosing a new sampling rate Now imagine we have two threads A & B and imagine that enabled is currently returning true. Here is a series of events: i) Thread A hits the end of tlab, checks enabled at entrance, gets a stack ii) Meanwhile, Thread B turned off HeapMonitoring iii) Thread A now goes to pick a new sample rate and is going to check HeapMonitoring::enabled If put as an assert, clearly (iii) will fail, we don't want this. II) So it this really an issue? Is there something really broken? Not really, I can go into a bigger explanation as to why but really it boils down to: - Tlab asks the HeapMonitoring system if it should try to sample and thus move its end pointer a bit for the next sample - If it "missed" a disable event, it will try to sample, find out monitoring is disabled and just not pick a sample. - If it did the sample and sends it to HeapMonitoring, HeapMonitoring just ignores it and TLab goes back to do its thing Because of this producer/consumer relationship between Tlab and HeapMonitoring, there is no real need to ensure that we are not in a specific part of the code. The thread sensitive data that could get corrupted is in HeapMonitoring and guarded by a specific lock, the rest of it will just result in a bit of extra useless work but won't provoke an race issue. I put a few extra checks for the HeapMonitoring::enabled because they allow a quick exit of sampling but to be honest, we could check at the entrance of the code path and if ever it got disabled then we are really only sampling one extra object that will get discarded. Thanks for looking as always, welcome back and let me know if there are any other concerns/questions/criticisms, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Wed Nov 1 17:57:10 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Nov 2017 13:57:10 -0400 Subject: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to jweak values In-Reply-To: <59F99795.6090404@oracle.com> References: <94B50A35-9898-47BA-8F20-A829FD7547AC@oracle.com> <59F99795.6090404@oracle.com> Message-ID: <33980406-F96C-434E-AAB7-949B39D46026@oracle.com> > On Nov 1, 2017, at 5:44 AM, Erik ?sterlund wrote: > > Hi Kim, > > On 2017-11-01 06:03, Kim Barrett wrote: >>> On Oct 30, 2017, at 7:14 AM, Doug Simon wrote: >>> >>> Hi Kim, >>> >>> Thanks for the detailed review. >>> >>>> On 29 Oct 2017, at 23:29, Kim Barrett wrote: >>>> >>>> [added hotspot-gc-dev to cc list] >>>> >>>>> On Oct 27, 2017, at 5:05 PM, Doug Simon wrote: >>>>> >>>>> Please review this change that converts the JVMCI-specific object references in nmethod from oops to weak values. This removes GC API extensions added purely for these fields (e.g. so that G1 can insert it into the right remembered set, and when unloading an nmethod, to go and remove the nmethod from that remembered set). >>>>> >>>>> Testing: I've run the Graal unit tests (mx unittest --verbose --gc-after-test -Xlog:class+unload=trace) which trigger a lot of nmethod unloading. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8188102 >>>>> http://cr.openjdk.java.net/~dnsimon/8188102/ >>>> I didn't look at the .java, .py, or project files. >>>> >>>> ------------------------------------------------------------------------------ >>>> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp >>>> 1061 nmethod* nm = cb->as_nmethod_or_null(); >>>> >>>> This appears to be dead code now. >>> Indeed. >>> >>>> ------------------------------------------------------------------------------ >>>> src/hotspot/share/code/nmethod.cpp >>>> 1023 assert(Universe::heap()->is_gc_active(), "should only be called during gc"); >>>> ... >>>> 1036 if (!Universe::heap()->is_gc_active() && cause != NULL) >>>> 1037 cause->klass()->print_on(&ls); >>>> >>>> I was going to mention that lines 1036-1037 are missing braces around >>>> the if-body. However, those lines appear to be dead code, given the >>>> assertion on line 1023. >>> Good catch. That problem pre-dates this webrev but I will clean it up here. >>> >>>> ------------------------------------------------------------------------------ >>>> src/hotspot/share/code/nmethod.cpp >>>> 1504 bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >>>> ... >>>> 1506 oop installed_code = JNIHandles::resolve(_jvmci_installed_code); >>>> >>>> Resolving a weak reference can keep an otherwise dead referent alive. >>>> See JDK-8188055 for a discussion of the corresponding problem for >>>> j.l.r.Reference. >>>> >>>> Right now, I think JNIHandles doesn't provide a (public) solution to >>>> what I think is being attempted here that works for all collectors. >>>> There is in-progress work toward a solution, but it's just that, "in >>>> progress". >>>> >>>> As a (possibly interim) solution, a function like the following might >>>> be added to JNIHandles (put the definition near resolve_jweak). >>>> >>>> bool JNIHandles::is_global_weak_cleared(jweak handle) { >>>> assert(is_jweak(handle), "not a weak handle"); >>>> return guard_value(jweak_ref(handle)) == NULL; >>>> } >>> Adding JNIHandles::is_global_weak_cleared makes sense. I've put it the public section near destroy_weak_global instead of the private section where resolve_jweak is declared. >>> >>>> (That's completely untested, and I haven't thought carefully about the >>>> name. And should get input from other GC folks on how to deal with >>>> this.) I *think* do_unloading_jvmci then becomes something like the >>>> following (again, completely untested) >>>> >>>> bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >>>> if (_jvmci_installed_code != NULL) { >>>> if (JNIHandles::is_global_weak_cleared(_jvmci_installed_code)) { >>>> if (_jvmci_installed_code_triggers_unloading) { >>>> make_unloaded(is_alive, NULL); >>>> return true; >>>> } else { >>>> clear_jvmci_installed_code(); >>>> } >>>> } >>>> } >>>> return false; >>>> } >>> I think your change works but comes at the cost of potentially preventing nmethod unloading for 1 extra (full?) GC cycle. It assumes that jweak clearing occurs before nmethod scanning. Is that guaranteed? If not, then I think what we want is: >>> >>> bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >>> if (_jvmci_installed_code != NULL) { >>> bool cleared = JNIHandles::is_global_weak_cleared(_jvmci_installed_code); >>> if (_jvmci_installed_code_triggers_unloading) { >>> if (cleared) { >>> // jweak reference processing has already cleared the referent >>> make_unloaded(is_alive, NULL); >>> return true; >>> } else { >>> oop installed_code = JNIHandles::resolve(_jvmci_installed_code); >>> if (can_unload(is_alive, (oop*)&installed_code, unloading_occurred)) { >>> return true; >>> } >>> } >>> } else { >>> if (cleared || !is_alive->do_object_b(JNIHandles::resolve(_jvmci_installed_code))) { >>> clear_jvmci_installed_code(); >>> } >>> } >>> } >>> return false; >>> } >>> >>> I've created a new webrev at http://cr.openjdk.java.net/~dnsimon/8188102_2. >>> >>> -Doug >> The old code was looking for objects that are no longer alive; that >> can't be determined until after reference processing, as finalization >> could change the answer. jweak clearing used to happen as part of >> reference processing, but there's been some recent refactoring. I >> don't think that was intended to change the order of jweak processing >> wrto other things, but I haven't looked at the code to verify I'm not >> overlooking something. >> >> In addition, I think >> >> } else { >> oop installed_code = JNIHandles::resolve(_jvmci_installed_code); >> if (can_unload(is_alive, (oop*)&installed_code, unloading_occurred)) { >> return true; >> } >> >> doesn't work for some collectors (like G1), since the resolve will >> force installed_code to be live (if jweak processing were performed >> after nmethod processing), so can_unload will always return false. >> > > JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something? Does this nmethod pass get run during young collections? If not, then maybe you are right that it doesn?t matter. But I still think that a cleanup pass that is based on using weak references like this should just be properly ordered wrto weak reference processing, as it presumably already was. In which case the resolve and can_unload is effectively useless; either the jweak has been cleared and we won?t reach this clause, or the jweak has not been cleared because the referent is still live, in which case can_unload will always return false and there was no point in calling it. > Having said that, I agree this should be a "peek" resolve, which we may implement soon. I think there shouldn?t be a resolve at all, ?peek? or otherwise. From dean.long at oracle.com Wed Nov 1 18:08:58 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 1 Nov 2017 11:08:58 -0700 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: <4c6c9f5a-8680-9116-edef-990a9abccdeb@oracle.com> References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> <10969e74-47a1-5457-fcb2-75c3d1271243@oracle.com> <87e06194-5c4a-650c-8029-fe778182030a@oracle.com> <4c6c9f5a-8680-9116-edef-990a9abccdeb@oracle.com> Message-ID: OK, somehow I missed the part about JavaCritical methods only being called from compiled code.? So -Xcomp makes sense. dl On 11/1/17 5:46 AM, Vladimir Ivanov wrote: > No magic here: the test isn't designed to be executed in interpreter > and always expect LookUp::test() to be compiled first. > > Normal JNI entries are empty, but the test checks that the first > element is written to on the first invocation. > > I agree that the bug is specific to JIT-compilers, since critical > entry points (JavaCritical_) are called only from compiled code. > Interpreter always goes through ordinary native counterparts (Java_). > > IMO using -Xcomp is fine to force the methods to be compiled. -Xbatch > is redundant in that case. > > Best regards, > Vladimir Ivanov > > On 11/1/17 7:46 AM, David Holmes wrote: >> On 1/11/2017 1:11 PM, David Holmes wrote: >>> On 1/11/2017 1:03 PM, dean.long at oracle.com wrote: >>>> Much better.? But why does the test need -Xbatch -Xcomp?? To me >>>> this doesn't look like a compiler-only issue.? The test should give >>>> the same result with -Xint right?? Adding runtime alias for their >>>> input... >>> >>> AFAICS this should be a completely compiler and platform agnostic >>> issue. >> >> Platform agnostic yes, but the test fails without -Xcomp (doesn't >> seem to need -Xbatch). So there's something about this critical >> function mechanism that I don't understand. >> >> That said the test needs more logging so that if it does fail you can >> see what, if anything got executed. So the non-critical versions of >> the methods should print that they were called, and for good measure >> also the critical versions. >> >> Thanks, >> David >> From Derek.White at cavium.com Wed Nov 1 19:35:03 2017 From: Derek.White at cavium.com (White, Derek) Date: Wed, 1 Nov 2017 19:35:03 +0000 Subject: [10] RFR: 8189176 - AARCH64: Improve _updateBytesCRC32 intrinsic In-Reply-To: References: Message-ID: Hi Dmitry, That looks good to me. Thanks! - Derek > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Dmitry Chuyko > Sent: Wednesday, November 01, 2017 12:25 PM > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [10] RFR: 8189176 - AARCH64: Improve _updateBytesCRC32 > intrinsic > > As per Derek's suggestion I made private > MacroAssembler::kernel_crc32_using_crc32(). Register naming became more > clear, numeric results are the same. > > webrev: http://cr.openjdk.java.net/~dchuyko/8189176/webrev.01/ > > -Dmitry > > > On 10/28/2017 10:52 AM, Andrew Haley wrote: > > On 27/10/17 23:31, White, Derek wrote: > >> - The use of temp registers in the UseCRC32 case is kind of muddled, > using tmp, and table0..table3 as temp registers, and the name "table" is > confusing in this case. > >> - Maybe it would be cleaner to refactor the UseCRC32 code into a > separate kernel_crc32_using_crc32() subroutine (static or macro?). This > would accept the main args and 4 registers for temps. The caller can supply > some combination of table or tmp registers. > >> - This would shrink the size of kernel_crc32() by a lot too. > > That would be nice. > > From doug.simon at oracle.com Wed Nov 1 21:10:28 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Nov 2017 22:10:28 +0100 Subject: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to jweak values In-Reply-To: <33980406-F96C-434E-AAB7-949B39D46026@oracle.com> References: <94B50A35-9898-47BA-8F20-A829FD7547AC@oracle.com> <59F99795.6090404@oracle.com> <33980406-F96C-434E-AAB7-949B39D46026@oracle.com> Message-ID: <111F6116-A1A4-4308-BAEC-D471F9E974B9@oracle.com> > On 1 Nov 2017, at 18:57, Kim Barrett wrote: > >> On Nov 1, 2017, at 5:44 AM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> On 2017-11-01 06:03, Kim Barrett wrote: >>>> On Oct 30, 2017, at 7:14 AM, Doug Simon wrote: >>>> >>>> Hi Kim, >>>> >>>> Thanks for the detailed review. >>>> >>>>> On 29 Oct 2017, at 23:29, Kim Barrett wrote: >>>>> >>>>> [added hotspot-gc-dev to cc list] >>>>> >>>>>> On Oct 27, 2017, at 5:05 PM, Doug Simon wrote: >>>>>> >>>>>> Please review this change that converts the JVMCI-specific object references in nmethod from oops to weak values. This removes GC API extensions added purely for these fields (e.g. so that G1 can insert it into the right remembered set, and when unloading an nmethod, to go and remove the nmethod from that remembered set). >>>>>> >>>>>> Testing: I've run the Graal unit tests (mx unittest --verbose --gc-after-test -Xlog:class+unload=trace) which trigger a lot of nmethod unloading. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8188102 >>>>>> http://cr.openjdk.java.net/~dnsimon/8188102/ >>>>> I didn't look at the .java, .py, or project files. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp >>>>> 1061 nmethod* nm = cb->as_nmethod_or_null(); >>>>> >>>>> This appears to be dead code now. >>>> Indeed. >>>> >>>>> ------------------------------------------------------------------------------ >>>>> src/hotspot/share/code/nmethod.cpp >>>>> 1023 assert(Universe::heap()->is_gc_active(), "should only be called during gc"); >>>>> ... >>>>> 1036 if (!Universe::heap()->is_gc_active() && cause != NULL) >>>>> 1037 cause->klass()->print_on(&ls); >>>>> >>>>> I was going to mention that lines 1036-1037 are missing braces around >>>>> the if-body. However, those lines appear to be dead code, given the >>>>> assertion on line 1023. >>>> Good catch. That problem pre-dates this webrev but I will clean it up here. >>>> >>>>> ------------------------------------------------------------------------------ >>>>> src/hotspot/share/code/nmethod.cpp >>>>> 1504 bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >>>>> ... >>>>> 1506 oop installed_code = JNIHandles::resolve(_jvmci_installed_code); >>>>> >>>>> Resolving a weak reference can keep an otherwise dead referent alive. >>>>> See JDK-8188055 for a discussion of the corresponding problem for >>>>> j.l.r.Reference. >>>>> >>>>> Right now, I think JNIHandles doesn't provide a (public) solution to >>>>> what I think is being attempted here that works for all collectors. >>>>> There is in-progress work toward a solution, but it's just that, "in >>>>> progress". >>>>> >>>>> As a (possibly interim) solution, a function like the following might >>>>> be added to JNIHandles (put the definition near resolve_jweak). >>>>> >>>>> bool JNIHandles::is_global_weak_cleared(jweak handle) { >>>>> assert(is_jweak(handle), "not a weak handle"); >>>>> return guard_value(jweak_ref(handle)) == NULL; >>>>> } >>>> Adding JNIHandles::is_global_weak_cleared makes sense. I've put it the public section near destroy_weak_global instead of the private section where resolve_jweak is declared. >>>> >>>>> (That's completely untested, and I haven't thought carefully about the >>>>> name. And should get input from other GC folks on how to deal with >>>>> this.) I *think* do_unloading_jvmci then becomes something like the >>>>> following (again, completely untested) >>>>> >>>>> bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >>>>> if (_jvmci_installed_code != NULL) { >>>>> if (JNIHandles::is_global_weak_cleared(_jvmci_installed_code)) { >>>>> if (_jvmci_installed_code_triggers_unloading) { >>>>> make_unloaded(is_alive, NULL); >>>>> return true; >>>>> } else { >>>>> clear_jvmci_installed_code(); >>>>> } >>>>> } >>>>> } >>>>> return false; >>>>> } >>>> I think your change works but comes at the cost of potentially preventing nmethod unloading for 1 extra (full?) GC cycle. It assumes that jweak clearing occurs before nmethod scanning. Is that guaranteed? If not, then I think what we want is: >>>> >>>> bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool unloading_occurred) { >>>> if (_jvmci_installed_code != NULL) { >>>> bool cleared = JNIHandles::is_global_weak_cleared(_jvmci_installed_code); >>>> if (_jvmci_installed_code_triggers_unloading) { >>>> if (cleared) { >>>> // jweak reference processing has already cleared the referent >>>> make_unloaded(is_alive, NULL); >>>> return true; >>>> } else { >>>> oop installed_code = JNIHandles::resolve(_jvmci_installed_code); >>>> if (can_unload(is_alive, (oop*)&installed_code, unloading_occurred)) { >>>> return true; >>>> } >>>> } >>>> } else { >>>> if (cleared || !is_alive->do_object_b(JNIHandles::resolve(_jvmci_installed_code))) { >>>> clear_jvmci_installed_code(); >>>> } >>>> } >>>> } >>>> return false; >>>> } >>>> >>>> I've created a new webrev at http://cr.openjdk.java.net/~dnsimon/8188102_2. >>>> >>>> -Doug >>> The old code was looking for objects that are no longer alive; that >>> can't be determined until after reference processing, as finalization >>> could change the answer. jweak clearing used to happen as part of >>> reference processing, but there's been some recent refactoring. I >>> don't think that was intended to change the order of jweak processing >>> wrto other things, but I haven't looked at the code to verify I'm not >>> overlooking something. >>> >>> In addition, I think >>> >>> } else { >>> oop installed_code = JNIHandles::resolve(_jvmci_installed_code); >>> if (can_unload(is_alive, (oop*)&installed_code, unloading_occurred)) { >>> return true; >>> } >>> >>> doesn't work for some collectors (like G1), since the resolve will >>> force installed_code to be live (if jweak processing were performed >>> after nmethod processing), so can_unload will always return false. >>> >> >> JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something? > > Does this nmethod pass get run during young collections? If not, then maybe you are right that it doesn?t matter. > > But I still think that a cleanup pass that is based on using weak references like this should just be properly ordered > wrto weak reference processing, as it presumably already was. In which case the resolve and can_unload is > effectively useless; either the jweak has been cleared and we won?t reach this clause, or the jweak has not been > cleared because the referent is still live, in which case can_unload will always return false and there was no point > in calling it. I agree. As stated previously, my (defensive) code is based on assuming that nmethod unloading might happen before reference processing. If it never/rarely happens, then your suggested change is the right one. I did some extra testing and never saw it happen. Based on that, I'd like to adopt your solution. In the worst case, nmethod unloading will be delayed one full GC cycle if nmethod unloading precedes reference processing. I've created another rev based on this: http://cr.openjdk.java.net/~dnsimon/8188102_3 -Doug From kim.barrett at oracle.com Thu Nov 2 03:47:00 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Nov 2017 23:47:00 -0400 Subject: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to jweak values In-Reply-To: <111F6116-A1A4-4308-BAEC-D471F9E974B9@oracle.com> References: <94B50A35-9898-47BA-8F20-A829FD7547AC@oracle.com> <59F99795.6090404@oracle.com> <33980406-F96C-434E-AAB7-949B39D46026@oracle.com> <111F6116-A1A4-4308-BAEC-D471F9E974B9@oracle.com> Message-ID: > On Nov 1, 2017, at 5:10 PM, Doug Simon wrote: > > > >> On 1 Nov 2017, at 18:57, Kim Barrett wrote: >> >>> On Nov 1, 2017, at 5:44 AM, Erik ?sterlund wrote: >>> >>> Hi Kim, >>> >>> On 2017-11-01 06:03, Kim Barrett wrote: >>>>> On Oct 30, 2017, at 7:14 AM, Doug Simon wrote: >>> JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something? >> >> Does this nmethod pass get run during young collections? If not, then maybe you are right that it doesn?t matter. >> >> But I still think that a cleanup pass that is based on using weak references like this should just be properly ordered >> wrto weak reference processing, as it presumably already was. In which case the resolve and can_unload is >> effectively useless; either the jweak has been cleared and we won?t reach this clause, or the jweak has not been >> cleared because the referent is still live, in which case can_unload will always return false and there was no point >> in calling it. > > I agree. As stated previously, my (defensive) code is based on assuming that nmethod unloading might happen before reference processing. If it never/rarely happens, then your suggested change is the right one. I did some extra testing and never saw it happen. Based on that, I'd like to adopt your solution. In the worst case, nmethod unloading will be delayed one full GC cycle if nmethod unloading precedes reference processing. > > I've created another rev based on this: > > http://cr.openjdk.java.net/~dnsimon/8188102_3 > > -Doug This looks good. ------------------------------------------------------------------------------ src/hotspot/share/runtime/jniHandles.cpp I'd like is_global_weak_cleared moved up a few lines, immediately following the specializations of resolve_jweak, which I think it is closely related to. I don't need another webrev for this. ------------------------------------------------------------------------------ src/hotspot/share/code/nmethod.cpp 2934 char* nmethod::jvmci_installed_code_name(char* buf, size_t buflen) { 2935 if (!this->is_compiled_by_jvmci()) { 2936 return NULL; 2937 } 2938 oop installed_code = JNIHandles::resolve(_jvmci_installed_code); Are there any circumstances where it would be unfortunate to have getting the name keep alive the object? I was thinking logging. Or perhaps it's a feature that getting the name might artificially extend the lifetime? Looking at the callers, it doesn't seem like a problem right now. This is one of those places where a "peek" access (coming soon from the GC interface) might be appropriate. ------------------------------------------------------------------------------ From doug.simon at oracle.com Thu Nov 2 07:36:39 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 2 Nov 2017 08:36:39 +0100 Subject: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to jweak values In-Reply-To: References: <94B50A35-9898-47BA-8F20-A829FD7547AC@oracle.com> <59F99795.6090404@oracle.com> <33980406-F96C-434E-AAB7-949B39D46026@oracle.com> <111F6116-A1A4-4308-BAEC-D471F9E974B9@oracle.com> Message-ID: <79532B9B-F7B4-41F4-9156-8B03B9D6D30B@oracle.com> > On 2 Nov 2017, at 04:47, Kim Barrett wrote: > >> On Nov 1, 2017, at 5:10 PM, Doug Simon wrote: >> >> >> >>> On 1 Nov 2017, at 18:57, Kim Barrett wrote: >>> >>>> On Nov 1, 2017, at 5:44 AM, Erik ?sterlund wrote: >>>> >>>> Hi Kim, >>>> >>>> On 2017-11-01 06:03, Kim Barrett wrote: >>>>>> On Oct 30, 2017, at 7:14 AM, Doug Simon wrote: >>>> JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something? >>> >>> Does this nmethod pass get run during young collections? If not, then maybe you are right that it doesn?t matter. >>> >>> But I still think that a cleanup pass that is based on using weak references like this should just be properly ordered >>> wrto weak reference processing, as it presumably already was. In which case the resolve and can_unload is >>> effectively useless; either the jweak has been cleared and we won?t reach this clause, or the jweak has not been >>> cleared because the referent is still live, in which case can_unload will always return false and there was no point >>> in calling it. >> >> I agree. As stated previously, my (defensive) code is based on assuming that nmethod unloading might happen before reference processing. If it never/rarely happens, then your suggested change is the right one. I did some extra testing and never saw it happen. Based on that, I'd like to adopt your solution. In the worst case, nmethod unloading will be delayed one full GC cycle if nmethod unloading precedes reference processing. >> >> I've created another rev based on this: >> >> http://cr.openjdk.java.net/~dnsimon/8188102_3 >> >> -Doug > > This looks good. > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/jniHandles.cpp > > I'd like is_global_weak_cleared moved up a few lines, immediately > following the specializations of resolve_jweak, which I think it is > closely related to. > > I don't need another webrev for this. Will do. I updated the latest webrev in place. > ------------------------------------------------------------------------------ > src/hotspot/share/code/nmethod.cpp > > 2934 char* nmethod::jvmci_installed_code_name(char* buf, size_t buflen) { > 2935 if (!this->is_compiled_by_jvmci()) { > 2936 return NULL; > 2937 } > 2938 oop installed_code = JNIHandles::resolve(_jvmci_installed_code); > > Are there any circumstances where it would be unfortunate to have > getting the name keep alive the object? I was thinking logging. Or > perhaps it's a feature that getting the name might artificially extend > the lifetime? Looking at the callers, it doesn't seem like a problem > right now. Right, this is only called from tracing or debugging code. > This is one of those places where a "peek" access (coming soon from > the GC interface) might be appropriate. This potential for resolving a jweak keeping the referent alive is unfortunate but I'm guessing it's also unavoidable. Thanks once again for a very helpful review! -Doug From doug.simon at oracle.com Thu Nov 2 07:37:31 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 2 Nov 2017 08:37:31 +0100 Subject: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to jweak values In-Reply-To: References: <94B50A35-9898-47BA-8F20-A829FD7547AC@oracle.com> <59F99795.6090404@oracle.com> <33980406-F96C-434E-AAB7-949B39D46026@oracle.com> <111F6116-A1A4-4308-BAEC-D471F9E974B9@oracle.com> Message-ID: <53561CBA-6032-46D1-A677-251872708A12@oracle.com> > On 2 Nov 2017, at 04:47, Kim Barrett wrote: > >> On Nov 1, 2017, at 5:10 PM, Doug Simon wrote: >> >> >> >>> On 1 Nov 2017, at 18:57, Kim Barrett wrote: >>> >>>> On Nov 1, 2017, at 5:44 AM, Erik ?sterlund wrote: >>>> >>>> Hi Kim, >>>> >>>> On 2017-11-01 06:03, Kim Barrett wrote: >>>>>> On Oct 30, 2017, at 7:14 AM, Doug Simon wrote: >>>> JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something? >>> >>> Does this nmethod pass get run during young collections? If not, then maybe you are right that it doesn?t matter. >>> >>> But I still think that a cleanup pass that is based on using weak references like this should just be properly ordered >>> wrto weak reference processing, as it presumably already was. In which case the resolve and can_unload is >>> effectively useless; either the jweak has been cleared and we won?t reach this clause, or the jweak has not been >>> cleared because the referent is still live, in which case can_unload will always return false and there was no point >>> in calling it. >> >> I agree. As stated previously, my (defensive) code is based on assuming that nmethod unloading might happen before reference processing. If it never/rarely happens, then your suggested change is the right one. I did some extra testing and never saw it happen. Based on that, I'd like to adopt your solution. In the worst case, nmethod unloading will be delayed one full GC cycle if nmethod unloading precedes reference processing. >> >> I've created another rev based on this: >> >> http://cr.openjdk.java.net/~dnsimon/8188102_3 >> >> -Doug > > This looks good. Can I please get sign off from someone in the compiler team. Thanks. -Doug From aph at redhat.com Thu Nov 2 09:33:52 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 2 Nov 2017 09:33:52 +0000 Subject: [10] RFR: 8189176 - AARCH64: Improve _updateBytesCRC32 intrinsic In-Reply-To: References: Message-ID: <35073ed1-a326-5f4f-7809-56d6553ae083@redhat.com> On 01/11/17 16:24, Dmitry Chuyko wrote: > As per Derek's suggestion I made private > MacroAssembler::kernel_crc32_using_crc32(). Register naming became more > clear, numeric results are the same. > > webrev: http://cr.openjdk.java.net/~dchuyko/8189176/webrev.01/ It looks fine. One small thing to tidy up while you're working on it: ORNW should be MOVN. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitry.chuyko at bell-sw.com Thu Nov 2 14:35:02 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 2 Nov 2017 17:35:02 +0300 Subject: [10] RFR: 8189176 - AARCH64: Improve _updateBytesCRC32 intrinsic In-Reply-To: <35073ed1-a326-5f4f-7809-56d6553ae083@redhat.com> References: <35073ed1-a326-5f4f-7809-56d6553ae083@redhat.com> Message-ID: On 11/02/2017 12:33 PM, Andrew Haley wrote: > On 01/11/17 16:24, Dmitry Chuyko wrote: >> As per Derek's suggestion I made private >> MacroAssembler::kernel_crc32_using_crc32(). Register naming became more >> clear, numeric results are the same. >> >> webrev: http://cr.openjdk.java.net/~dchuyko/8189176/webrev.01/ > It looks fine. One small thing to tidy up while you're working on it: > ORNW should be MOVN. MVN I suppose. It hasn't been introduced in assembler file, now implemented as ORN[W] using zero register, successfully decoded back by hsdis. Other usages are also updated. http://cr.openjdk.java.net/~dchuyko/8189176/webrev.02/ -Dmitry > > Thanks. > From aph at redhat.com Thu Nov 2 15:04:24 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 2 Nov 2017 15:04:24 +0000 Subject: [10] RFR: 8189176 - AARCH64: Improve _updateBytesCRC32 intrinsic In-Reply-To: References: <35073ed1-a326-5f4f-7809-56d6553ae083@redhat.com> Message-ID: <6cf8693d-df60-c53d-0618-eb73da0e387b@redhat.com> On 02/11/17 14:35, Dmitry Chuyko wrote: > MVN I suppose. It hasn't been introduced in assembler file, now > implemented as ORN[W] using zero register, successfully decoded back by > hsdis. Other usages are also updated. > > http://cr.openjdk.java.net/~dchuyko/8189176/webrev.02/ Thanks for doing this. It's not a big thing, but a worthy cleanup. OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Derek.White at cavium.com Thu Nov 2 15:05:34 2017 From: Derek.White at cavium.com (White, Derek) Date: Thu, 2 Nov 2017 15:05:34 +0000 Subject: [10] RFR: 8189176 - AARCH64: Improve _updateBytesCRC32 intrinsic In-Reply-To: <6cf8693d-df60-c53d-0618-eb73da0e387b@redhat.com> References: <35073ed1-a326-5f4f-7809-56d6553ae083@redhat.com> <6cf8693d-df60-c53d-0618-eb73da0e387b@redhat.com> Message-ID: Looks good to me. - Derek > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Andrew Haley > Sent: Thursday, November 02, 2017 11:04 AM > To: Dmitry Chuyko ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: [10] RFR: 8189176 - AARCH64: Improve _updateBytesCRC32 > intrinsic > > On 02/11/17 14:35, Dmitry Chuyko wrote: > > MVN I suppose. It hasn't been introduced in assembler file, now > > implemented as ORN[W] using zero register, successfully decoded back > > by hsdis. Other usages are also updated. > > > > http://cr.openjdk.java.net/~dchuyko/8189176/webrev.02/ > > Thanks for doing this. It's not a big thing, but a worthy cleanup. > OK. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Thu Nov 2 16:01:41 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 2 Nov 2017 16:01:41 +0000 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> Message-ID: Hi Jamsheed, seems like this lookup style is not used on all platforms. On PPC64, the test works with and without your fix. nm only shows: T Java_compiler_criticalnatives_LookUp_m1 T Java_compiler_criticalnatives_LookUp_m2 T Java_compiler_criticalnatives_LookUp_m3 T JavaCritical_compiler_criticalnatives_LookUp_m1 T JavaCritical_compiler_criticalnatives_LookUp_m2 T JavaCritical_compiler_criticalnatives_LookUp_m3 Anyway, the fix and the test look good to me. I agree with that it makes sense to run in on all platforms. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of jamsheed Sent: Dienstag, 31. Oktober 2017 20:38 To: hotspot-compiler-dev at openjdk.java.net Subject: Re: [10] JBS: 8167408: Invalid critical JNI function lookup Hi Dean, Thank you for the review, tested with a test case, previously it was not working for windows-x86, now it works. revised webrev with test case:http://cr.openjdk.java.net/~jcm/8167408/webrev.01/ Best regards, Jamsheed On Tuesday 31 October 2017 02:18 AM, dean.long at oracle.com wrote: > I think you need a native test for Windows x86 that defines > JavaCritical methods with various signatures (especially arrays) to > make sure this is working correctly. > > dl > > > On 10/30/17 9:45 AM, jamsheed wrote: >> Hi, >> >> request for review, >> >> jbs : https://bugs.openjdk.java.net/browse/JDK-8167408 >> >> webrev: http://cr.openjdk.java.net/~jcm/8167408/webrev.00/ >> >> (contributed by Ioannis Tsakpinis) >> >> desc: >> >> -- it starts with JavaCritical_ instead of Java_; >> -- it does not have extra JNIEnv* and jclass arguments; >> -- Java arrays are passed in two arguments: the first is an array >> length, and the second is a pointer to raw array data. That is, no >> need to call GetArrayElements and friends, you can instantly use a >> direct array pointer. >> >> updated arg_size calculation wrt above points. >> >> Best regards, >> >> Jamsheed >> > From tom.rodriguez at oracle.com Thu Nov 2 17:47:22 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 02 Nov 2017 10:47:22 -0700 Subject: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to jweak values In-Reply-To: <79532B9B-F7B4-41F4-9156-8B03B9D6D30B@oracle.com> References: <94B50A35-9898-47BA-8F20-A829FD7547AC@oracle.com> <59F99795.6090404@oracle.com> <33980406-F96C-434E-AAB7-949B39D46026@oracle.com> <111F6116-A1A4-4308-BAEC-D471F9E974B9@oracle.com> <79532B9B-F7B4-41F4-9156-8B03B9D6D30B@oracle.com> Message-ID: <59FB5A2A.3050407@oracle.com> Looks good to me. tom Doug Simon wrote: > >> On 2 Nov 2017, at 04:47, Kim Barrett wrote: >> >>> On Nov 1, 2017, at 5:10 PM, Doug Simon wrote: >>> >>> >>> >>>> On 1 Nov 2017, at 18:57, Kim Barrett wrote: >>>> >>>>> On Nov 1, 2017, at 5:44 AM, Erik ?sterlund wrote: >>>>> >>>>> Hi Kim, >>>>> >>>>> On 2017-11-01 06:03, Kim Barrett wrote: >>>>>>> On Oct 30, 2017, at 7:14 AM, Doug Simon wrote: >>>>> JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something? >>>> Does this nmethod pass get run during young collections? If not, then maybe you are right that it doesn?t matter. >>>> >>>> But I still think that a cleanup pass that is based on using weak references like this should just be properly ordered >>>> wrto weak reference processing, as it presumably already was. In which case the resolve and can_unload is >>>> effectively useless; either the jweak has been cleared and we won?t reach this clause, or the jweak has not been >>>> cleared because the referent is still live, in which case can_unload will always return false and there was no point >>>> in calling it. >>> I agree. As stated previously, my (defensive) code is based on assuming that nmethod unloading might happen before reference processing. If it never/rarely happens, then your suggested change is the right one. I did some extra testing and never saw it happen. Based on that, I'd like to adopt your solution. In the worst case, nmethod unloading will be delayed one full GC cycle if nmethod unloading precedes reference processing. >>> >>> I've created another rev based on this: >>> >>> http://cr.openjdk.java.net/~dnsimon/8188102_3 >>> >>> -Doug >> This looks good. >> >> ------------------------------------------------------------------------------ >> src/hotspot/share/runtime/jniHandles.cpp >> >> I'd like is_global_weak_cleared moved up a few lines, immediately >> following the specializations of resolve_jweak, which I think it is >> closely related to. >> >> I don't need another webrev for this. > > Will do. I updated the latest webrev in place. > >> ------------------------------------------------------------------------------ >> src/hotspot/share/code/nmethod.cpp >> >> 2934 char* nmethod::jvmci_installed_code_name(char* buf, size_t buflen) { >> 2935 if (!this->is_compiled_by_jvmci()) { >> 2936 return NULL; >> 2937 } >> 2938 oop installed_code = JNIHandles::resolve(_jvmci_installed_code); >> >> Are there any circumstances where it would be unfortunate to have >> getting the name keep alive the object? I was thinking logging. Or >> perhaps it's a feature that getting the name might artificially extend >> the lifetime? Looking at the callers, it doesn't seem like a problem >> right now. > > Right, this is only called from tracing or debugging code. > >> This is one of those places where a "peek" access (coming soon from >> the GC interface) might be appropriate. > > This potential for resolving a jweak keeping the referent alive is unfortunate but I'm guessing it's also unavoidable. > > Thanks once again for a very helpful review! > > -Doug From dmitry.chuyko at bell-sw.com Thu Nov 2 21:07:18 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 3 Nov 2017 00:07:18 +0300 Subject: [10] RFR (S): 8189177 - AARCH64: Improve _updateBytesCRC32C intrinsic In-Reply-To: <18544a56-5885-784f-b448-7f412861d916@bell-sw.com> References: <18544a56-5885-784f-b448-7f412861d916@bell-sw.com> Message-ID: Similar to CRC32 I added private MacroAssembler::kernel_crc32c_using_crc32c(). webrev: http://cr.openjdk.java.net/~dchuyko/8189177/webrev.01/ -Dmitry On 10/20/2017 08:45 PM, Dmitry Chuyko wrote: > Hello, > > Please review an improvement of CRC32C calculation on AArch64. It is > done pretty similar to a change for JDK-8189176 described in [1]. > > MacroAssembler::kernel_crc32c gets unused table registers. They can be > used to make neighbor loads and CRC calculations independent. Adding > prologue and epilogue for main by-64 loop makes it applicable starting > from len=128 so additional by-32 loop is added for smaller lengths. > > rfe: https://bugs.openjdk.java.net/browse/JDK-8189177 > webrev: http://cr.openjdk.java.net/~dchuyko/8189177/webrev.00/ > benchmark: > http://cr.openjdk.java.net/~dchuyko/8189177/crc32c/CRC32CBench.java > > Results for T88 and A53 [2] are similar to CRC32 change (good), but > again splitting pair loads may slow down other CPUs so measurements on > different HW are welcome. > > -Dmitry > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-October/027225.html > [2] > https://bugs.openjdk.java.net/browse/JDK-8189177?focusedCommentId=14124535&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14124535 > From vladimir.kozlov at oracle.com Thu Nov 2 22:03:37 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Nov 2017 15:03:37 -0700 Subject: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to jweak values In-Reply-To: <53561CBA-6032-46D1-A677-251872708A12@oracle.com> References: <94B50A35-9898-47BA-8F20-A829FD7547AC@oracle.com> <59F99795.6090404@oracle.com> <33980406-F96C-434E-AAB7-949B39D46026@oracle.com> <111F6116-A1A4-4308-BAEC-D471F9E974B9@oracle.com> <53561CBA-6032-46D1-A677-251872708A12@oracle.com> Message-ID: <9168e4cc-aac3-ac2b-2229-11b766be0a2e@oracle.com> Seems good to me. Thanks, Vladimir On 11/2/17 12:37 AM, Doug Simon wrote: > > >> On 2 Nov 2017, at 04:47, Kim Barrett wrote: >> >>> On Nov 1, 2017, at 5:10 PM, Doug Simon wrote: >>> >>> >>> >>>> On 1 Nov 2017, at 18:57, Kim Barrett wrote: >>>> >>>>> On Nov 1, 2017, at 5:44 AM, Erik ?sterlund wrote: >>>>> >>>>> Hi Kim, >>>>> >>>>> On 2017-11-01 06:03, Kim Barrett wrote: >>>>>>> On Oct 30, 2017, at 7:14 AM, Doug Simon wrote: >>>>> JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something? >>>> >>>> Does this nmethod pass get run during young collections? If not, then maybe you are right that it doesn?t matter. >>>> >>>> But I still think that a cleanup pass that is based on using weak references like this should just be properly ordered >>>> wrto weak reference processing, as it presumably already was. In which case the resolve and can_unload is >>>> effectively useless; either the jweak has been cleared and we won?t reach this clause, or the jweak has not been >>>> cleared because the referent is still live, in which case can_unload will always return false and there was no point >>>> in calling it. >>> >>> I agree. As stated previously, my (defensive) code is based on assuming that nmethod unloading might happen before reference processing. If it never/rarely happens, then your suggested change is the right one. I did some extra testing and never saw it happen. Based on that, I'd like to adopt your solution. In the worst case, nmethod unloading will be delayed one full GC cycle if nmethod unloading precedes reference processing. >>> >>> I've created another rev based on this: >>> >>> http://cr.openjdk.java.net/~dnsimon/8188102_3 >>> >>> -Doug >> >> This looks good. > > Can I please get sign off from someone in the compiler team. Thanks. > > -Doug > From dean.long at oracle.com Fri Nov 3 02:02:59 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 2 Nov 2017 19:02:59 -0700 Subject: 8u144 hotspot fails to reach safepoint due to compiler thread - VM frozen In-Reply-To: References: Message-ID: <5f39dfcf-64f9-7a9f-1ed3-c810eb6f1985@oracle.com> From a quick search, this sounds similar to 8085965.? I wonder if another circularity in the siblings list has been created somehow.? Can you check for that with gdb? dl On 10/31/17 11:08 AM, Vitaly Davidovich wrote: > Hi guys, > > I have some colleagues who appear to be running into > https://bugs.openjdk.java.net/browse/JDK-8059128 on Oracle JDK 8u144 > (Linux, x86-64).? Naturally, there's no reproducer but they've seen > this happen several times in the last couple of months. > > The symptom is the JVM becomes unresponsive - the application is not > servicing any traffic, and jstack doesn't work without the force > option. ?jstack output (with native frames) captured some time apart > shows the compiler thread either in Parse::do_all_blocks -> > do_one_block -> do_one_bytecode -> ... > InstanceKlass::has_finalizable_subclass -> > Dependencies::find_finalizable_subclass or > ... Dependencies::has_finalizable_subclass() -> Klass::next_sibling() > > I see that 8059128 was closed as Incomplete, but it does look like > there's a real issue here.? Has anyone looked into this further or has > any new thoughts/ideas? > > My understanding is the working theory is it's related to some data > race between class unloading and the compiler thread observing an > inconsistent (corrupt?) type hierarchy.? I see > https://bugs.openjdk.java.net/browse/JDK-8114823 is also noted as > possibly related - the app we're having trouble with is using G1, but > class unloading isn't disabled of course.? Is there some work around > to reduce the likelihood of having the compiler thread and GC cross > paths like this? > > Let me know if you need more info. > > Thanks From goetz.lindenmaier at sap.com Fri Nov 3 11:44:58 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 3 Nov 2017 11:44:58 +0000 Subject: RFR(L): 8189793: [s390]: Improve String compress/inflate by exploiting vector instructions In-Reply-To: <6F73CAE2-2FEC-4BC0-9F3A-FEE9748EB694@sap.com> References: <18ddb703d81a4a22bc97f134dd276eff@sap.com> <6F73CAE2-2FEC-4BC0-9F3A-FEE9748EB694@sap.com> Message-ID: <02fe90a2093144b6a2a1ec0020d9b88f@sap.com> Hi Lutz, I have been looking at your change. I think it's a good idea to match for constant string length. I did this for the ppc string intrinsics in the past. I remember that distribution of constant strings was quite uneven. StrIndexOf appeared with constant lengths a lot, StrEquals and StrComp didn't. Do you have any data on how often the new match rules match? Actually, if there is a constant string deflated, a platform independent optimization could compute that at compile time, but that's a different issue ... Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Freitag, 27. Oktober 2017 13:07 > To: Doerr, Martin ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(L): 8189793: [s390]: Improve String compress/inflate by > exploiting vector instructions > > Hi Martin, > > > > Thanks for reviewing my change! > > > > This is a preliminary response just to let you know I?m working on the > change. I?m putting a lot of effort in producing reliable performance > measurement data. Turns out this is not easy (to be more honest: almost > impossible). > > > > s390.ad: > > You are absolutely right, the sequence load_const/string_compress makes > no sense at all. But it does not hurt either ? I could not find one match in all > tests I ran. -> Match rule deleted. > > > > macroAssembler_s390: > > prefetch: did not see impact, neither positive nor negative. Artificial micro > benchmarks will not benefit (data is in cache anyway). More complex > benchmarks show measurement noise which covers the possible prefetch > benefit. -> prefetch deleted. > > Hardcoded vector registers: you are right. There are some design decisions > pending, e.g. how many vector scratch registers? > > Vperm instruction: using that is just another implementation variant that > could save the vn vector instruction. On the other hand, loading the index > vector is a (compared to vgmh) costly memory access. Given the fact that we > mostly deal with short strings, initialization effort is relevant. > > Code size vs. performance: the old, well known, often discussed tradeoff. > Starting from the existing implementation, I invested quite some time in > optimizing the (len <= 8) cases. With every refinement step I saw (or > believed to see (measurement noise)) some improvement ? or discarded it. > Is the overall improvement worth the larger code size? -> tradeoff, > discussion. > > > > Best Regards, > > Lutz > > > > > > > > On 25.10.2017, 21:08, "Doerr, Martin" > wrote: > > > > Hi Lutz, > > > > thanks for working on vector-based enhancements and for providing this > webrev. > > > > assembler_s390: > > -The changes in the assembler look good. > > > > s390.ad: > > -It doesn't make sense to load constant len to a register and generate > complex compare instructions for it and still to emit code for all cases. I > assume that e.g. the 4 characters cases usually have a constant length. If so, > much better code could be generated for them by omitting all the stuff > around the simple instructions. (ppc64.ad already contains nodes for > constant length of needle in indexOf rules.) > > > > macroAssembler_s390: > > -Are you sure the prefetch instructions improve performance? > > I remember that we had them in other String intrinsics but removed them > again as they showed absolutely no performance gain. > > -Comment: Using hardcoded vector registers is ok for now, but may need to > get changed e.g. when using them for C2's SuperWord optimization. > > -Comment: You could use the vperm instruction instead of vo+vn, but I'm ok > with the current implementation because loading a mask is much more > convenient than getting the permutation vector loaded (e.g. from constant > pool or pc relative). > > -So the new vector loop looks good to me. > > -In my opinion, the size of all the generated cases should be in relationship to > their performance benefit. > > As intrinsics are not like stubs and may get inlined often, I can't get rid of the > impression that generating so large code wastes valuable code cache space > with questionable performance gain in real world scenarios. > > > > Best regards, > > Martin > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Mittwoch, 25. Oktober 2017 12:02 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(L): 8189793: [s390]: Improve String compress/inflate by > exploiting vector instructions > > > > Dear all, > > > > I would like to request reviews for this s390-only enhancement: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189793 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8189793.00/index.html > > > > Vector instructions, which have been available on System z for a while (since > z13), promise noticeable performance improvements. This enhancement > improves the String Compress and String Inflate intrinsics by exploiting vector > instructions, when available. For long strings, up to 2x performance > improvement has been observed in micro-benchmarks. > > > > Special care was taken to preserve good performance for short strings. All > examined workloads showed a high ratio of short and very short strings. > > > > Thank you! > > Lutz > > > > > > > > > > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 (6227) 7-42834 > > From vitalyd at gmail.com Fri Nov 3 13:05:04 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 03 Nov 2017 13:05:04 +0000 Subject: 8u144 hotspot fails to reach safepoint due to compiler thread - VM frozen In-Reply-To: <5f39dfcf-64f9-7a9f-1ed3-c810eb6f1985@oracle.com> References: <5f39dfcf-64f9-7a9f-1ed3-c810eb6f1985@oracle.com> Message-ID: On Thu, Nov 2, 2017 at 10:03 PM wrote: > From a quick search, this sounds similar to 8085965. I wonder if > another circularity in the siblings list has been created somehow. Can > you check for that with gdb? Hi Dean, Yes it does sound like that bug, although that?s marked as fixed in 8u72. I guess the implication is that it?s not actually fixed or this is a different codepath/circumstance that ends up in the same blackhole. I?ll see if my colleagues can dig around in the core file. It?s a product build so not sure how easy it will be to make sense of it without debug symbols. Thanks > > > dl > > > On 10/31/17 11:08 AM, Vitaly Davidovich wrote: > > Hi guys, > > > > I have some colleagues who appear to be running into > > https://bugs.openjdk.java.net/browse/JDK-8059128 on Oracle JDK 8u144 > > (Linux, x86-64). Naturally, there's no reproducer but they've seen > > this happen several times in the last couple of months. > > > > The symptom is the JVM becomes unresponsive - the application is not > > servicing any traffic, and jstack doesn't work without the force > > option. jstack output (with native frames) captured some time apart > > shows the compiler thread either in Parse::do_all_blocks -> > > do_one_block -> do_one_bytecode -> ... > > InstanceKlass::has_finalizable_subclass -> > > Dependencies::find_finalizable_subclass or > > ... Dependencies::has_finalizable_subclass() -> Klass::next_sibling() > > > > I see that 8059128 was closed as Incomplete, but it does look like > > there's a real issue here. Has anyone looked into this further or has > > any new thoughts/ideas? > > > > My understanding is the working theory is it's related to some data > > race between class unloading and the compiler thread observing an > > inconsistent (corrupt?) type hierarchy. I see > > https://bugs.openjdk.java.net/browse/JDK-8114823 is also noted as > > possibly related - the app we're having trouble with is using G1, but > > class unloading isn't disabled of course. Is there some work around > > to reduce the likelihood of having the compiler thread and GC cross > > paths like this? > > > > Let me know if you need more info. > > > > Thanks > > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Fri Nov 3 14:55:26 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 3 Nov 2017 15:55:26 +0100 Subject: RFR: 8177397: [JVMCI] remove unnecessary synchronization Message-ID: <9F63DB61-7DA9-42CB-942A-449733416BC6@oracle.com> Please review this tiny change to remove some unnecessary synchronization. https://bugs.openjdk.java.net/browse/JDK-8177397 http://cr.openjdk.java.net/~dnsimon/8177397/ -Doug From tobias.hartmann at oracle.com Fri Nov 3 15:02:27 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 3 Nov 2017 16:02:27 +0100 Subject: RFR: 8177397: [JVMCI] remove unnecessary synchronization In-Reply-To: <9F63DB61-7DA9-42CB-942A-449733416BC6@oracle.com> References: <9F63DB61-7DA9-42CB-942A-449733416BC6@oracle.com> Message-ID: <76737a9e-eb38-5cb0-a990-c9158f5bf898@oracle.com> Hi Doug, looks good to me. Best regards, Tobias On 03.11.2017 15:55, Doug Simon wrote: > Please review this tiny change to remove some unnecessary synchronization. > > https://bugs.openjdk.java.net/browse/JDK-8177397 > http://cr.openjdk.java.net/~dnsimon/8177397/ > > -Doug > From jamsheed.c.m at oracle.com Fri Nov 3 15:06:58 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Fri, 3 Nov 2017 20:36:58 +0530 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> Message-ID: Hi Dean, David, Martin, Vladimir, incorporated most of the suggestions, let me know if this is ok! http://cr.openjdk.java.net/~jcm/8167408/webrev.02/ Best regards Jamsheed On Wednesday 01 November 2017 03:58 AM, Vladimir Ivanov wrote: > Jamsheed, nice test! > > 2 suggestions: > > ? (1) Enable the test on all platforms: though the bug is > platform-specific, it doesn't mean the test should be. I don't see any > platform-specific code there and it's beneficial to test other > platforms as well > > ? (2) Add some test cases with multiple array parameters. > > Otherwise, looks good. > > Best regards, > Vladimir Ivanov > > On 10/31/17 10:37 PM, jamsheed wrote: >> Hi Dean, >> >> Thank you for the review, >> >> tested with a test case, previously it was not working for >> windows-x86, now it works. >> >> revised webrev with test >> case:http://cr.openjdk.java.net/~jcm/8167408/webrev.01/ >> >> Best regards, >> >> Jamsheed >> >> >> On Tuesday 31 October 2017 02:18 AM, dean.long at oracle.com wrote: >>> I think you need a native test for Windows x86 that defines >>> JavaCritical methods with various signatures (especially arrays) to >>> make sure this is working correctly. >>> >>> dl >>> >>> >>> On 10/30/17 9:45 AM, jamsheed wrote: >>>> Hi, >>>> >>>> request for review, >>>> >>>> jbs : https://bugs.openjdk.java.net/browse/JDK-8167408 >>>> >>>> webrev: http://cr.openjdk.java.net/~jcm/8167408/webrev.00/ >>>> >>>> (contributed by Ioannis Tsakpinis) >>>> >>>> desc: >>>> >>>> -- it starts with JavaCritical_ instead of Java_; >>>> -- it does not have extra JNIEnv* and jclass arguments; >>>> -- Java arrays are passed in two arguments: the first is an array >>>> length, and the second is a pointer to raw array data. That is, no >>>> need to call GetArrayElements and friends, you can instantly use a >>>> direct array pointer. >>>> >>>> updated arg_size calculation wrt above points. >>>> >>>> Best regards, >>>> >>>> Jamsheed >>>> >>> >> From jamsheed.c.m at oracle.com Fri Nov 3 15:08:01 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Fri, 3 Nov 2017 20:38:01 +0530 Subject: [10] RFR: 8167409: Invalid value passed to critical JNI function In-Reply-To: References: Message-ID: <4f4ce7ab-c0ad-dbf7-e051-1a803cb2fdb9@oracle.com> Hi Dean, i have added a test case now, revised webrev: http://cr.openjdk.java.net/~jcm/8167409/webrev.01/ Best regards, Jamsheed On Monday 30 October 2017 10:15 PM, jamsheed wrote: > Hi, > > request for review, > > jbs: https://bugs.openjdk.java.net/browse/JDK-8167409 > > webrev: http://cr.openjdk.java.net/~jcm/8167409/webrev.00/ > > (contributed by Ioannis Tsakpinis) > > desc: the tmp? reg used to break the shuffling cycle (handled in > ComputeMoveOrder) > > is set to 64 bit. > > Best regards, > > Jamsheed > > From jamsheed.c.m at oracle.com Fri Nov 3 15:09:22 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Fri, 3 Nov 2017 20:39:22 +0530 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> Message-ID: <29d543eb-c93d-af7b-6b04-5806fb3e2e8c@oracle.com> Hi Martin, On Thursday 02 November 2017 09:31 PM, Doerr, Martin wrote: > Hi Jamsheed, > > seems like this lookup style is not used on all platforms. On PPC64, the test works with and without your fix. > nm only shows: > T Java_compiler_criticalnatives_LookUp_m1 > T Java_compiler_criticalnatives_LookUp_m2 > T Java_compiler_criticalnatives_LookUp_m3 > T JavaCritical_compiler_criticalnatives_LookUp_m1 > T JavaCritical_compiler_criticalnatives_LookUp_m2 > T JavaCritical_compiler_criticalnatives_LookUp_m3 Thank you for checking, > > Anyway, the fix and the test look good to me. I agree with that it makes sense to run in on all platforms. sure, i will make it to run on all platform. Best regards, Jamsheed > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of jamsheed > Sent: Dienstag, 31. Oktober 2017 20:38 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [10] JBS: 8167408: Invalid critical JNI function lookup > > Hi Dean, > > Thank you for the review, > > tested with a test case, previously it was not working for windows-x86, > now it works. > > revised webrev with test > case:http://cr.openjdk.java.net/~jcm/8167408/webrev.01/ > > Best regards, > > Jamsheed > > > On Tuesday 31 October 2017 02:18 AM, dean.long at oracle.com wrote: >> I think you need a native test for Windows x86 that defines >> JavaCritical methods with various signatures (especially arrays) to >> make sure this is working correctly. >> >> dl >> >> >> On 10/30/17 9:45 AM, jamsheed wrote: >>> Hi, >>> >>> request for review, >>> >>> jbs : https://bugs.openjdk.java.net/browse/JDK-8167408 >>> >>> webrev: http://cr.openjdk.java.net/~jcm/8167408/webrev.00/ >>> >>> (contributed by Ioannis Tsakpinis) >>> >>> desc: >>> >>> -- it starts with JavaCritical_ instead of Java_; >>> -- it does not have extra JNIEnv* and jclass arguments; >>> -- Java arrays are passed in two arguments: the first is an array >>> length, and the second is a pointer to raw array data. That is, no >>> need to call GetArrayElements and friends, you can instantly use a >>> direct array pointer. >>> >>> updated arg_size calculation wrt above points. >>> >>> Best regards, >>> >>> Jamsheed >>> From doug.simon at oracle.com Fri Nov 3 15:53:57 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 3 Nov 2017 16:53:57 +0100 Subject: RFR: 8177397: [JVMCI] remove unnecessary synchronization In-Reply-To: <76737a9e-eb38-5cb0-a990-c9158f5bf898@oracle.com> References: <9F63DB61-7DA9-42CB-942A-449733416BC6@oracle.com> <76737a9e-eb38-5cb0-a990-c9158f5bf898@oracle.com> Message-ID: > On 3 Nov 2017, at 16:02, Tobias Hartmann wrote: > > Hi Doug, > > looks good to me. Thanks for the review. -Doug > > Best regards, > Tobias > > On 03.11.2017 15:55, Doug Simon wrote: >> Please review this tiny change to remove some unnecessary synchronization. >> >> https://bugs.openjdk.java.net/browse/JDK-8177397 >> http://cr.openjdk.java.net/~dnsimon/8177397/ >> >> -Doug >> From doug.simon at oracle.com Fri Nov 3 15:55:40 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 3 Nov 2017 16:55:40 +0100 Subject: RFR: 8186478: [JVMCI] rename HotSpotResolvedJavaMethod#setNotInlineableOrCompileable Message-ID: <6529906E-BF3C-44DB-B19A-FD49F1C1088F@oracle.com> Please review this small change to fix the spelling of a method's name. https://bugs.openjdk.java.net/browse/JDK-8186478 http://cr.openjdk.java.net/~dnsimon/8186478 -Doug From lutz.schmidt at sap.com Fri Nov 3 16:45:39 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 3 Nov 2017 16:45:39 +0000 Subject: RFR(L): 8189793: [s390]: Improve String compress/inflate by exploiting vector instructions In-Reply-To: <02fe90a2093144b6a2a1ec0020d9b88f@sap.com> References: <18ddb703d81a4a22bc97f134dd276eff@sap.com> <6F73CAE2-2FEC-4BC0-9F3A-FEE9748EB694@sap.com> <02fe90a2093144b6a2a1ec0020d9b88f@sap.com> Message-ID: <7702F170-B574-4EF8-8B85-B366B507E7B0@sap.com> Hi Goetz, I agree. Knowing the string length greatly helps to optimize the generated code, both in terms of size and performance. There are no compress calls with constant length, though. Constant strings are stored compressed at compile time. Here are some counters I found when running (a subset of) the SPECjvm2008 suite: string_compress match count: 11 string_inflate match count: 171 string_inflate_const: len = 1: 10 matches len = 2: 2 matches len = 4: 3 matches len = 6: 9 matches len = 7: 3 matches len = 9: 4 matches len = 10: 5 matches len = 11: 15 matches len = 15: 1 matches len = 17: 1 matches len = 18: 2 matches len = 19: 2 matches len = 29: 1 matches len = 31: 1 matches These (rather few) matches handle a lot of compress/inflate operations: n #compress #inflate <16 673 Mio 2895 Mio <256 207 Mio 704 Mio <4096 0.7 Mio 1.8 Mio >=4096 1.1 Mio 0.3 Mio A short not on performance gains: I have done a lot of performance tests in different settings. With complex tests, like SPECjvm2008, the positive (or negative) effect of such low-level optimizations disappears in measurement noise. With a micro benchmark, just compressing and inflating a string, some effect is visible: My new, improved implementation of the intrinsics shows a slight performance advantage of 1..4% for short strings. Once the vector instructions kick in (at len >= 32), performance improves by 50..70% for string_compress and by 50..150% for string_inflate. Measurements show a high variance, despite testing was done on a system with dedicated cpu resources and with no concurrent load. BTW, there is a new webrev at http://cr.openjdk.java.net/~lucy/webrevs/8189793.01/index.html In addition to the changes mentioned below, it contains two minor, nevertheless important fixes to the compress intrinsic: 1) z_bru(skipShortcut); is changed to z_brh(skipShortcut); 2) Code is added after label ScalarShortcut to check for zero length strings. Regards, Lutz On 03.11.2017, 12:44, "Lindenmaier, Goetz" wrote: Hi Lutz, I have been looking at your change. I think it's a good idea to match for constant string length. I did this for the ppc string intrinsics in the past. I remember that distribution of constant strings was quite uneven. StrIndexOf appeared with constant lengths a lot, StrEquals and StrComp didn't. Do you have any data on how often the new match rules match? Actually, if there is a constant string deflated, a platform independent optimization could compute that at compile time, but that's a different issue ... Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Freitag, 27. Oktober 2017 13:07 > To: Doerr, Martin ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(L): 8189793: [s390]: Improve String compress/inflate by > exploiting vector instructions > > Hi Martin, > > > > Thanks for reviewing my change! > > > > This is a preliminary response just to let you know I?m working on the > change. I?m putting a lot of effort in producing reliable performance > measurement data. Turns out this is not easy (to be more honest: almost > impossible). > > > > s390.ad: > > You are absolutely right, the sequence load_const/string_compress makes > no sense at all. But it does not hurt either ? I could not find one match in all > tests I ran. -> Match rule deleted. > > > > macroAssembler_s390: > > prefetch: did not see impact, neither positive nor negative. Artificial micro > benchmarks will not benefit (data is in cache anyway). More complex > benchmarks show measurement noise which covers the possible prefetch > benefit. -> prefetch deleted. > > Hardcoded vector registers: you are right. There are some design decisions > pending, e.g. how many vector scratch registers? > > Vperm instruction: using that is just another implementation variant that > could save the vn vector instruction. On the other hand, loading the index > vector is a (compared to vgmh) costly memory access. Given the fact that we > mostly deal with short strings, initialization effort is relevant. > > Code size vs. performance: the old, well known, often discussed tradeoff. > Starting from the existing implementation, I invested quite some time in > optimizing the (len <= 8) cases. With every refinement step I saw (or > believed to see (measurement noise)) some improvement ? or discarded it. > Is the overall improvement worth the larger code size? -> tradeoff, > discussion. > > > > Best Regards, > > Lutz > > > > > > > > On 25.10.2017, 21:08, "Doerr, Martin" > wrote: > > > > Hi Lutz, > > > > thanks for working on vector-based enhancements and for providing this > webrev. > > > > assembler_s390: > > -The changes in the assembler look good. > > > > s390.ad: > > -It doesn't make sense to load constant len to a register and generate > complex compare instructions for it and still to emit code for all cases. I > assume that e.g. the 4 characters cases usually have a constant length. If so, > much better code could be generated for them by omitting all the stuff > around the simple instructions. (ppc64.ad already contains nodes for > constant length of needle in indexOf rules.) > > > > macroAssembler_s390: > > -Are you sure the prefetch instructions improve performance? > > I remember that we had them in other String intrinsics but removed them > again as they showed absolutely no performance gain. > > -Comment: Using hardcoded vector registers is ok for now, but may need to > get changed e.g. when using them for C2's SuperWord optimization. > > -Comment: You could use the vperm instruction instead of vo+vn, but I'm ok > with the current implementation because loading a mask is much more > convenient than getting the permutation vector loaded (e.g. from constant > pool or pc relative). > > -So the new vector loop looks good to me. > > -In my opinion, the size of all the generated cases should be in relationship to > their performance benefit. > > As intrinsics are not like stubs and may get inlined often, I can't get rid of the > impression that generating so large code wastes valuable code cache space > with questionable performance gain in real world scenarios. > > > > Best regards, > > Martin > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Mittwoch, 25. Oktober 2017 12:02 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(L): 8189793: [s390]: Improve String compress/inflate by > exploiting vector instructions > > > > Dear all, > > > > I would like to request reviews for this s390-only enhancement: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189793 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8189793.00/index.html > > > > Vector instructions, which have been available on System z for a while (since > z13), promise noticeable performance improvements. This enhancement > improves the String Compress and String Inflate intrinsics by exploiting vector > instructions, when available. For long strings, up to 2x performance > improvement has been observed in micro-benchmarks. > > > > Special care was taken to preserve good performance for short strings. All > examined workloads showed a high ratio of short and very short strings. > > > > Thank you! > > Lutz > > > > > > > > > > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 (6227) 7-42834 > > From dean.long at oracle.com Fri Nov 3 16:56:42 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 3 Nov 2017 09:56:42 -0700 Subject: 8u144 hotspot fails to reach safepoint due to compiler thread - VM frozen In-Reply-To: References: <5f39dfcf-64f9-7a9f-1ed3-c810eb6f1985@oracle.com> Message-ID: <6e0b34c7-177c-4148-20b8-d717a1bab55d@oracle.com> On 11/3/17 6:05 AM, Vitaly Davidovich wrote: > > On Thu, Nov 2, 2017 at 10:03 PM > wrote: > > ?From a quick search, this sounds similar to 8085965.? I wonder if > another circularity in the siblings list has been created > somehow.? Can > you check for that with gdb? > > Hi Dean, > > Yes it does sound like that bug, although that?s marked as fixed in > 8u72.? I guess the implication is that it?s not actually fixed or this > is a different codepath/circumstance that ends up in the same blackhole. > > I?ll see if my colleagues can dig around in the core file.? It?s a > product build so not sure how easy it will be to make sense of it > without debug symbols. > I'm not an expert with jhsdb/clhsdb/hsdb, but I believe it can attach to a core file and give you some information even with a product build. dl > Thanks > > > > dl > > > On 10/31/17 11:08 AM, Vitaly Davidovich wrote: > > Hi guys, > > > > I have some colleagues who appear to be running into > > https://bugs.openjdk.java.net/browse/JDK-8059128 on Oracle JDK 8u144 > > (Linux, x86-64).? Naturally, there's no reproducer but they've seen > > this happen several times in the last couple of months. > > > > The symptom is the JVM becomes unresponsive - the application is not > > servicing any traffic, and jstack doesn't work without the force > > option. ?jstack output (with native frames) captured some time apart > > shows the compiler thread either in Parse::do_all_blocks -> > > do_one_block -> do_one_bytecode -> ... > > InstanceKlass::has_finalizable_subclass -> > > Dependencies::find_finalizable_subclass or one> > > ... Dependencies::has_finalizable_subclass() -> > Klass::next_sibling() > > > > I see that 8059128 was closed as Incomplete, but it does look like > > there's a real issue here.? Has anyone looked into this further > or has > > any new thoughts/ideas? > > > > My understanding is the working theory is it's related to some data > > race between class unloading and the compiler thread observing an > > inconsistent (corrupt?) type hierarchy.? I see > > https://bugs.openjdk.java.net/browse/JDK-8114823 is also noted as > > possibly related - the app we're having trouble with is using > G1, but > > class unloading isn't disabled of course.? Is there some work around > > to reduce the likelihood of having the compiler thread and GC cross > > paths like this? > > > > Let me know if you need more info. > > > > Thanks > > -- > Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Fri Nov 3 17:36:32 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Fri, 3 Nov 2017 23:06:32 +0530 Subject: [10] RFR: 8152470: Add COMPILER2_OR_JVMCI definition Message-ID: Hi, request for review, jbs: https://bugs.openjdk.java.net/browse/JDK-8152470 webrev: http://cr.openjdk.java.net/~jcm/8152470/webrev.00/ desc: cleanup #if defined(COMPILER2) || INCLUDE_JVMCI changed to #if COMPILER2_OR_JVMC Best regards, Jamsheed From doug.simon at oracle.com Fri Nov 3 17:42:51 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 3 Nov 2017 18:42:51 +0100 Subject: RFR: 8187315: [JVMCI] remove unnecessary synchronization Message-ID: <58AEB8B2-8C7E-4DA8-AB54-81DBF0778D16@oracle.com> Please review this small change to fix a crash when using Graal in hosted-only mode. https://bugs.openjdk.java.net/browse/JDK-8187315 http://cr.openjdk.java.net/~dnsimon/8187315/ -Doug From dean.long at oracle.com Fri Nov 3 18:33:44 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 3 Nov 2017 11:33:44 -0700 Subject: RFR: 8187315: [JVMCI] remove unnecessary synchronization In-Reply-To: <58AEB8B2-8C7E-4DA8-AB54-81DBF0778D16@oracle.com> References: <58AEB8B2-8C7E-4DA8-AB54-81DBF0778D16@oracle.com> Message-ID: <1843e738-1cb9-9820-9288-9c9ec247d2cd@oracle.com> Looks reasonable.? Subject line is out of sync with bug title: [JVMCI] hosted use of JVMCI can crash VM under -Xint dl On 11/3/17 10:42 AM, Doug Simon wrote: > Please review this small change to fix a crash when using Graal in hosted-only mode. > > https://bugs.openjdk.java.net/browse/JDK-8187315 > http://cr.openjdk.java.net/~dnsimon/8187315/ > > -Doug From vladimir.kozlov at oracle.com Fri Nov 3 19:03:03 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 3 Nov 2017 12:03:03 -0700 Subject: RFR: 8186478: [JVMCI] rename HotSpotResolvedJavaMethod#setNotInlineableOrCompileable In-Reply-To: <6529906E-BF3C-44DB-B19A-FD49F1C1088F@oracle.com> References: <6529906E-BF3C-44DB-B19A-FD49F1C1088F@oracle.com> Message-ID: <81978da3-2d1c-ab74-6977-c4b76b89a134@oracle.com> Looks good. But why you need to rename it? There is no explanation in JBS. Please, add it. Thanks, Vladimir On 11/3/17 8:55 AM, Doug Simon wrote: > Please review this small change to fix the spelling of a method's name. > > https://bugs.openjdk.java.net/browse/JDK-8186478 > http://cr.openjdk.java.net/~dnsimon/8186478 > > -Doug > From vladimir.kozlov at oracle.com Fri Nov 3 19:07:38 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 3 Nov 2017 12:07:38 -0700 Subject: RFR: 8177397: [JVMCI] remove unnecessary synchronization In-Reply-To: <76737a9e-eb38-5cb0-a990-c9158f5bf898@oracle.com> References: <9F63DB61-7DA9-42CB-942A-449733416BC6@oracle.com> <76737a9e-eb38-5cb0-a990-c9158f5bf898@oracle.com> Message-ID: +1 Vladimir On 11/3/17 8:02 AM, Tobias Hartmann wrote: > Hi Doug, > > looks good to me. > > Best regards, > Tobias > > On 03.11.2017 15:55, Doug Simon wrote: >> Please review this tiny change to remove some unnecessary synchronization. >> >> https://bugs.openjdk.java.net/browse/JDK-8177397 >> http://cr.openjdk.java.net/~dnsimon/8177397/ >> >> -Doug >> From vladimir.kozlov at oracle.com Fri Nov 3 19:18:20 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 3 Nov 2017 12:18:20 -0700 Subject: RFR: 8187315: [JVMCI] hosted use of JVMCI can crash VM under -Xint In-Reply-To: <1843e738-1cb9-9820-9288-9c9ec247d2cd@oracle.com> References: <58AEB8B2-8C7E-4DA8-AB54-81DBF0778D16@oracle.com> <1843e738-1cb9-9820-9288-9c9ec247d2cd@oracle.com> Message-ID: Reviewed. Vladimir On 11/3/17 11:33 AM, dean.long at oracle.com wrote: > Looks reasonable.? Subject line is out of sync with bug title: [JVMCI] > hosted use of JVMCI can crash VM under -Xint > > dl > > > On 11/3/17 10:42 AM, Doug Simon wrote: >> Please review this small change to fix a crash when using Graal in >> hosted-only mode. >> >> https://bugs.openjdk.java.net/browse/JDK-8187315 >> http://cr.openjdk.java.net/~dnsimon/8187315/ >> >> -Doug > From dean.long at oracle.com Fri Nov 3 19:22:03 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 3 Nov 2017 12:22:03 -0700 Subject: [10] RFR: 8167409: Invalid value passed to critical JNI function In-Reply-To: <4f4ce7ab-c0ad-dbf7-e051-1a803cb2fdb9@oracle.com> References: <4f4ce7ab-c0ad-dbf7-e051-1a803cb2fdb9@oracle.com> Message-ID: <05f23773-b596-8657-6663-42226c2d8301@oracle.com> Looks good. dl On 11/3/17 8:08 AM, jamsheed wrote: > Hi Dean, > > i have added a test case now, > > revised webrev: http://cr.openjdk.java.net/~jcm/8167409/webrev.01/ > > Best regards, > > Jamsheed > > > On Monday 30 October 2017 10:15 PM, jamsheed wrote: >> Hi, >> >> request for review, >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8167409 >> >> webrev: http://cr.openjdk.java.net/~jcm/8167409/webrev.00/ >> >> (contributed by Ioannis Tsakpinis) >> >> desc: the tmp? reg used to break the shuffling cycle (handled in >> ComputeMoveOrder) >> >> is set to 64 bit. >> >> Best regards, >> >> Jamsheed >> >> > From dean.long at oracle.com Fri Nov 3 19:23:29 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 3 Nov 2017 12:23:29 -0700 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> Message-ID: <723aaed1-bcaa-f770-ad37-6b1105541eec@oracle.com> It looks good now. dl On 11/3/17 8:06 AM, jamsheed wrote: > Hi Dean, David, Martin, Vladimir, > > incorporated most of the suggestions, let me know if this is ok! > > http://cr.openjdk.java.net/~jcm/8167408/webrev.02/ > > Best regards > > Jamsheed > > On Wednesday 01 November 2017 03:58 AM, Vladimir Ivanov wrote: >> Jamsheed, nice test! >> >> 2 suggestions: >> >> ? (1) Enable the test on all platforms: though the bug is >> platform-specific, it doesn't mean the test should be. I don't see >> any platform-specific code there and it's beneficial to test other >> platforms as well >> >> ? (2) Add some test cases with multiple array parameters. >> >> Otherwise, looks good. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/31/17 10:37 PM, jamsheed wrote: >>> Hi Dean, >>> >>> Thank you for the review, >>> >>> tested with a test case, previously it was not working for >>> windows-x86, now it works. >>> >>> revised webrev with test >>> case:http://cr.openjdk.java.net/~jcm/8167408/webrev.01/ >>> >>> Best regards, >>> >>> Jamsheed >>> >>> >>> On Tuesday 31 October 2017 02:18 AM, dean.long at oracle.com wrote: >>>> I think you need a native test for Windows x86 that defines >>>> JavaCritical methods with various signatures (especially arrays) to >>>> make sure this is working correctly. >>>> >>>> dl >>>> >>>> >>>> On 10/30/17 9:45 AM, jamsheed wrote: >>>>> Hi, >>>>> >>>>> request for review, >>>>> >>>>> jbs : https://bugs.openjdk.java.net/browse/JDK-8167408 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jcm/8167408/webrev.00/ >>>>> >>>>> (contributed by Ioannis Tsakpinis) >>>>> >>>>> desc: >>>>> >>>>> -- it starts with JavaCritical_ instead of Java_; >>>>> -- it does not have extra JNIEnv* and jclass arguments; >>>>> -- Java arrays are passed in two arguments: the first is an array >>>>> length, and the second is a pointer to raw array data. That is, no >>>>> need to call GetArrayElements and friends, you can instantly use a >>>>> direct array pointer. >>>>> >>>>> updated arg_size calculation wrt above points. >>>>> >>>>> Best regards, >>>>> >>>>> Jamsheed >>>>> >>>> >>> > From doug.simon at oracle.com Fri Nov 3 21:01:19 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 3 Nov 2017 22:01:19 +0100 Subject: RFR: 8187315: [JVMCI] hosted use of JVMCI can crash VM under -Xint In-Reply-To: <1843e738-1cb9-9820-9288-9c9ec247d2cd@oracle.com> References: <58AEB8B2-8C7E-4DA8-AB54-81DBF0778D16@oracle.com> <1843e738-1cb9-9820-9288-9c9ec247d2cd@oracle.com> Message-ID: > On 3 Nov 2017, at 19:33, dean.long at oracle.com wrote: > > Looks reasonable. Thanks for the review. > Subject line is out of sync with bug title: [JVMCI] hosted use of JVMCI can crash VM under -Xint That's what I get for using a previous RFR email as a template! Sorry about that. -Doug > > dl > > > On 11/3/17 10:42 AM, Doug Simon wrote: >> Please review this small change to fix a crash when using Graal in hosted-only mode. >> >> https://bugs.openjdk.java.net/browse/JDK-8187315 >> http://cr.openjdk.java.net/~dnsimon/8187315/ >> >> -Doug > From doug.simon at oracle.com Fri Nov 3 21:11:24 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 3 Nov 2017 22:11:24 +0100 Subject: RFR: 8186478: [JVMCI] rename HotSpotResolvedJavaMethod#setNotInlineableOrCompileable In-Reply-To: <81978da3-2d1c-ab74-6977-c4b76b89a134@oracle.com> References: <6529906E-BF3C-44DB-B19A-FD49F1C1088F@oracle.com> <81978da3-2d1c-ab74-6977-c4b76b89a134@oracle.com> Message-ID: I added a justification to the bug which is copied below: This method should be renamed to setNotInlinableOrCompilable for better consistency with existing OpenJDK source. Grepping through the sources available from http://hg.openjdk.java.net/jdk10/hs: dsimon at kruger-4 ~/j/open> ag -i inlineable | grep -v setNotInlineableOrCompileable | wc -l 107 dsimon at kruger-4 ~/j/open> ag -i inlinable | grep -v setNotInlineableOrCompileable | wc -l 24 dsimon at kruger-4 ~/j/open> ag -i compileable | grep -v setNotInlineableOrCompileable | wc -l 3 dsimon at kruger-4 ~/j/open> ag -i compilable | grep -v setNotInlineableOrCompileable | wc -l 585 Based purely on these frequencies, we could rename to setNotInlineableOrCompilable but that looks internally inconsistent (why drop e from one word and not the other?). -Doug > On 3 Nov 2017, at 20:03, Vladimir Kozlov wrote: > > Looks good. > But why you need to rename it? There is no explanation in JBS. Please, add it. > > Thanks, > Vladimir > > On 11/3/17 8:55 AM, Doug Simon wrote: >> Please review this small change to fix the spelling of a method's name. >> https://bugs.openjdk.java.net/browse/JDK-8186478 >> http://cr.openjdk.java.net/~dnsimon/8186478 >> -Doug From vladimir.kozlov at oracle.com Fri Nov 3 22:24:34 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 3 Nov 2017 15:24:34 -0700 Subject: RFR: 8186478: [JVMCI] rename HotSpotResolvedJavaMethod#setNotInlineableOrCompileable In-Reply-To: References: <6529906E-BF3C-44DB-B19A-FD49F1C1088F@oracle.com> <81978da3-2d1c-ab74-6977-c4b76b89a134@oracle.com> Message-ID: <87a3bf8c-64fe-17bf-6d1e-a2968ef4ae40@oracle.com> I originally thought it is related to original changes JDK-8180487 and compatibility with jdk 9. But it looks like you simple fixed wording. Looks good. Thanks, Vladimir On 11/3/17 2:11 PM, Doug Simon wrote: > I added a justification to the bug which is copied below: > > This method should be renamed to setNotInlinableOrCompilable for better consistency with existing OpenJDK source. Grepping through the sources available from http://hg.openjdk.java.net/jdk10/hs: > > dsimon at kruger-4 ~/j/open> ag -i inlineable | grep -v setNotInlineableOrCompileable | wc -l > 107 > dsimon at kruger-4 ~/j/open> ag -i inlinable | grep -v setNotInlineableOrCompileable | wc -l > 24 > dsimon at kruger-4 ~/j/open> ag -i compileable | grep -v setNotInlineableOrCompileable | wc -l > 3 > dsimon at kruger-4 ~/j/open> ag -i compilable | grep -v setNotInlineableOrCompileable | wc -l > 585 > > Based purely on these frequencies, we could rename to setNotInlineableOrCompilable but that looks internally inconsistent (why drop e from one word and not the other?). > > -Doug > >> On 3 Nov 2017, at 20:03, Vladimir Kozlov wrote: >> >> Looks good. >> But why you need to rename it? There is no explanation in JBS. Please, add it. >> >> Thanks, >> Vladimir >> >> On 11/3/17 8:55 AM, Doug Simon wrote: >>> Please review this small change to fix the spelling of a method's name. >>> https://bugs.openjdk.java.net/browse/JDK-8186478 >>> http://cr.openjdk.java.net/~dnsimon/8186478 >>> -Doug > From chris.plummer at oracle.com Sat Nov 4 00:25:20 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 3 Nov 2017 17:25:20 -0700 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout Message-ID: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8059334 http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ The CR is closed, so I'll try to explain the issue here. The very short explanation is that the JVMTI test was enabling SINGLE STEP and doing a PopFrame, but the test method managed to get compiled and started executing compiled after the thread was put in "interp only" mode (which should never happen) and before the PopFrame was processed. The cause is a lack of a check for "interp only" mode in the OSR related compilation policy code. Details: The test is testing JVMTI PopFrame support. The test thread has a small method that sits in a tight loop. It will never exit. The main thread enables SINGLE STEP on the test thread, and then does a PopFrame on the test thread to force it out of the looping method. When the test failed due to a time out, I noticed it was still stuck in the small method, even though a PopFrame had been requested. Further, I noticed the method was compiled, so there was no chance the method would ever detect that it should do a PopFrame. Since "interp only" mode for SINGLE STEP had been enabled, the method should not be running compiled, so clearly something went wrong that allowed it to compile and execute. When SINGLE STEP is requested, JVMTI will deopt the topmost method (actually the top 2), put the thread in "interp only" mode, and then has checks to make sure the thread continues to execute interpreted. To avoid compilation when a back branch tries to trigger one, there is a check for "interp only" mode in SimpleThresholdPolicy::event(). If the thread is in "interp only" mode, it will prevent compilation. SimpleThresholdPolicy::event() is called (indirectly) by InterpreterRuntime::frequency_counter_overflow(), which is called from the interpreter when the back branch threshold is reached. After some debugging I noticed when the test timeout happens, "interp only" mode is not yet enabled when InterpreterRuntime::frequency_counter_overflow() is called, but is enabled by the time InterpreterRuntime::frequency_counter_overflow() has done the lookup of the nm. So there is a race here allowing the thread to begin execution in a compiled method even though "interp only" mode is enabled. I think the reason is because we safepoint during the compilation, and this allows a SINGLE STEP request to be processed, which enables "interp only" mode. I should add that initially I only saw this bug with -Xcomp, but eventually realized it was caused by disabling BackgroundCompilation. That makes it much more likely that a SINGLE STEP request will come in and be processed during the call to InterpreterRuntime::frequency_counter_overflow() (because it will block until the compilation completes). I believe for the fix it is enough just to add an "interp only" mode check in InterpreterRuntime::frequency_counter_overflow() after the nm lookup, and set it nm to NULL if we are now in "interp only" mode. If we are not in "interp only" mode at this point (and start executing the compiled method) it should not be possible to enter "interp only" mode until we reach a safepoint at some later time, and at that point the method will be properly deopt so it can execute interpreted. thanks, Chris From dean.long at oracle.com Sat Nov 4 04:44:20 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 3 Nov 2017 21:44:20 -0700 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> Message-ID: <901dc547-182d-155d-5340-b973731003e1@oracle.com> I'm not an expert in this area of code, but I'm wondering about Vladimir's comment about ciEnv::jvmti_state_changed() in the bug report.? With your fix, maybe we don't need to check ciEnv::jvmti_state_changed() (which doesn't seem to be enough by itself) and throw away the compiled result.? We could just keep it around so it can be used when "interp only" mode is switched off. dl On 11/3/17 5:25 PM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8059334 > http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ > > The CR is closed, so I'll try to explain the issue here. The very > short explanation is that the JVMTI test was enabling SINGLE STEP and > doing a PopFrame, but the test method managed to get compiled and > started executing compiled after the thread was put in "interp only" > mode (which should never happen) and before the PopFrame was > processed. The cause is a lack of a check for "interp only" mode in > the OSR related compilation policy code. > > Details: > > The test is testing JVMTI PopFrame support. The test thread has a > small method that sits in a tight loop. It will never exit. The main > thread enables SINGLE STEP on the test thread, and then does a > PopFrame on the test thread to force it out of the looping method. > When the test failed due to a time out, I noticed it was still stuck > in the small method, even though a PopFrame had been requested. > Further, I noticed the method was compiled, so there was no chance the > method would ever detect that it should do a PopFrame. Since "interp > only" mode for SINGLE STEP had been enabled, the method should not be > running compiled, so clearly something went wrong that allowed it to > compile and execute. > > When SINGLE STEP is requested, JVMTI will deopt the topmost method > (actually the top 2), put the thread in "interp only" mode, and then > has checks to make sure the thread continues to execute interpreted. > To avoid compilation when a back branch tries to trigger one, there is > a check for "interp only" mode in SimpleThresholdPolicy::event(). If > the thread is in "interp only" mode, it will prevent compilation. > SimpleThresholdPolicy::event() is called (indirectly) by > InterpreterRuntime::frequency_counter_overflow(), which is called from > the interpreter when the back branch threshold is reached. > > After some debugging I noticed when the test timeout happens, "interp > only" mode is not yet enabled when > InterpreterRuntime::frequency_counter_overflow() is called, but is > enabled by the time InterpreterRuntime::frequency_counter_overflow() > has done the lookup of the nm. So there is a race here allowing the > thread to begin execution in a compiled method even though "interp > only" mode is enabled. I think the reason is because we safepoint > during the compilation, and this allows a SINGLE STEP request to be > processed, which enables "interp only" mode. > > I should add that initially I only saw this bug with -Xcomp, but > eventually realized it was caused by disabling BackgroundCompilation. > That makes it much more likely that a SINGLE STEP request will come in > and be processed during the call to > InterpreterRuntime::frequency_counter_overflow() (because it will > block until the compilation completes). > > I believe for the fix it is enough just to add an "interp only" mode > check in InterpreterRuntime::frequency_counter_overflow() after the nm > lookup, and set it nm to NULL if we are now in "interp only" mode. If > we are not in "interp only" mode at this point (and start executing > the compiled method) it should not be possible to enter "interp only" > mode until we reach a safepoint at some later time, and at that point > the method will be properly deopt so it can execute interpreted. > > thanks, > > Chris > From jamsheed.c.m at oracle.com Sat Nov 4 08:15:10 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Sat, 4 Nov 2017 13:45:10 +0530 Subject: [10] RFR: 8167409: Invalid value passed to critical JNI function In-Reply-To: <05f23773-b596-8657-6663-42226c2d8301@oracle.com> References: <4f4ce7ab-c0ad-dbf7-e051-1a803cb2fdb9@oracle.com> <05f23773-b596-8657-6663-42226c2d8301@oracle.com> Message-ID: Thank you, Dean Best regards, Jamsheed On Saturday 04 November 2017 12:52 AM, dean.long at oracle.com wrote: > Looks good. > > dl > > > On 11/3/17 8:08 AM, jamsheed wrote: >> Hi Dean, >> >> i have added a test case now, >> >> revised webrev: http://cr.openjdk.java.net/~jcm/8167409/webrev.01/ >> >> Best regards, >> >> Jamsheed >> >> >> On Monday 30 October 2017 10:15 PM, jamsheed wrote: >>> Hi, >>> >>> request for review, >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8167409 >>> >>> webrev: http://cr.openjdk.java.net/~jcm/8167409/webrev.00/ >>> >>> (contributed by Ioannis Tsakpinis) >>> >>> desc: the tmp? reg used to break the shuffling cycle (handled in >>> ComputeMoveOrder) >>> >>> is set to 64 bit. >>> >>> Best regards, >>> >>> Jamsheed >>> >>> >> > From jamsheed.c.m at oracle.com Sat Nov 4 08:15:27 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Sat, 4 Nov 2017 13:45:27 +0530 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: <723aaed1-bcaa-f770-ad37-6b1105541eec@oracle.com> References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> <723aaed1-bcaa-f770-ad37-6b1105541eec@oracle.com> Message-ID: Thank you, Dean Best regards, Jamsheed On Saturday 04 November 2017 12:53 AM, dean.long at oracle.com wrote: > It looks good now. > > dl > > > On 11/3/17 8:06 AM, jamsheed wrote: >> Hi Dean, David, Martin, Vladimir, >> >> incorporated most of the suggestions, let me know if this is ok! >> >> http://cr.openjdk.java.net/~jcm/8167408/webrev.02/ >> >> Best regards >> >> Jamsheed >> >> On Wednesday 01 November 2017 03:58 AM, Vladimir Ivanov wrote: >>> Jamsheed, nice test! >>> >>> 2 suggestions: >>> >>> ? (1) Enable the test on all platforms: though the bug is >>> platform-specific, it doesn't mean the test should be. I don't see >>> any platform-specific code there and it's beneficial to test other >>> platforms as well >>> >>> ? (2) Add some test cases with multiple array parameters. >>> >>> Otherwise, looks good. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/31/17 10:37 PM, jamsheed wrote: >>>> Hi Dean, >>>> >>>> Thank you for the review, >>>> >>>> tested with a test case, previously it was not working for >>>> windows-x86, now it works. >>>> >>>> revised webrev with test >>>> case:http://cr.openjdk.java.net/~jcm/8167408/webrev.01/ >>>> >>>> Best regards, >>>> >>>> Jamsheed >>>> >>>> >>>> On Tuesday 31 October 2017 02:18 AM, dean.long at oracle.com wrote: >>>>> I think you need a native test for Windows x86 that defines >>>>> JavaCritical methods with various signatures (especially arrays) >>>>> to make sure this is working correctly. >>>>> >>>>> dl >>>>> >>>>> >>>>> On 10/30/17 9:45 AM, jamsheed wrote: >>>>>> Hi, >>>>>> >>>>>> request for review, >>>>>> >>>>>> jbs : https://bugs.openjdk.java.net/browse/JDK-8167408 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~jcm/8167408/webrev.00/ >>>>>> >>>>>> (contributed by Ioannis Tsakpinis) >>>>>> >>>>>> desc: >>>>>> >>>>>> -- it starts with JavaCritical_ instead of Java_; >>>>>> -- it does not have extra JNIEnv* and jclass arguments; >>>>>> -- Java arrays are passed in two arguments: the first is an array >>>>>> length, and the second is a pointer to raw array data. That is, >>>>>> no need to call GetArrayElements and friends, you can instantly >>>>>> use a direct array pointer. >>>>>> >>>>>> updated arg_size calculation wrt above points. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Jamsheed >>>>>> >>>>> >>>> >> > From dean.long at oracle.com Sat Nov 4 17:40:21 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sat, 4 Nov 2017 10:40:21 -0700 Subject: RFR(XL) 8190710: Update Graal Message-ID: https://bugs.openjdk.java.net/browse/JDK-8190710 http://cr.openjdk.java.net/~dlong/8190710/webrev/ This is a Graal update. Please see the JBS entry for the complete list of upstream changes included. I had to add new changes in these files to get it to build: make/CompileToolsHotspot.gmk src/hotspot/share/aot/aotCodeHeap.cpp src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java This update should also fix 8189828. dl From vladimir.kozlov at oracle.com Sun Nov 5 04:03:07 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 4 Nov 2017 21:03:07 -0700 Subject: RFR(XL) 8190710: Update Graal In-Reply-To: References: Message-ID: <67d2cb22-9c93-9556-7aff-f0765e5d0625@oracle.com> Good. Thanks, Vladimir On 11/4/17 10:40 AM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8190710 > http://cr.openjdk.java.net/~dlong/8190710/webrev/ > > This is a Graal update.? Please see the JBS entry for the complete list > of upstream changes included. > > I had to add new changes in these files to get it to build: > > make/CompileToolsHotspot.gmk > src/hotspot/share/aot/aotCodeHeap.cpp > src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java > > > This update should also fix 8189828. > > dl From dmitry.chuyko at bell-sw.com Sun Nov 5 15:54:57 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Sun, 5 Nov 2017 18:54:57 +0300 Subject: RFR (XXS): JDK-8190745 - AARCH64: fix for JDK-8189176 may break a build Message-ID: <68491c14-5b25-0966-4538-6739ae9f233d@bell-sw.com> Hello. I'm sorry, the webrev version of the fix for JDK-8189176 (aarch64) had missing semicolon in one of loop bindings. Please review a trivial fix, I'll also need a sponsorship for making a push. Details are at the bottom. -Dmitry bug: https://bugs.openjdk.java.net/browse/JDK-8190745 patch: diff -r d85284ccd1bd src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp??? Fri Nov 03 17:09:25 2017 -0700 +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp??? Sun Nov 05 18:16:48 2017 +0300 @@ -2942,7 +2942,7 @@ ?? BIND(CRC_less64); ???? adds(len, len, 128-32); ???? br(Assembler::GE, CRC_by32_loop); -? BIND(CRC_less32) +? BIND(CRC_less32); ???? adds(len, len, 32-4); ???? br(Assembler::GE, CRC_by4_loop); ???? adds(len, len, 4); From dmitry.samersoff at bell-sw.com Sun Nov 5 19:10:28 2017 From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff) Date: Sun, 5 Nov 2017 22:10:28 +0300 Subject: Fwd: RFR (XXS): JDK-8190745 - AARCH64: fix for JDK-8189176 may break a build In-Reply-To: <732ca0fa-205a-bb71-32db-77613d986a35@bell-sw.com> References: <68491c14-5b25-0966-4538-6739ae9f233d@bell-sw.com> <732ca0fa-205a-bb71-32db-77613d986a35@bell-sw.com> Message-ID: <41288013-25de-016d-67e9-ae14ac1523c7@bell-sw.com> Dmitry, The fix looks good to me. I'll sponsor the push as soon as the build finishes. -Dmitry On 11/05/2017 07:33 PM, Dmitry Chuyko wrote: > Hello. > > I'm sorry, the webrev version of the fix for JDK-8189176 (aarch64) had > missing semicolon in one of loop bindings. > Please review a trivial fix, I'll also need a sponsorship for making a > push. Details are at the bottom. > > -Dmitry > > bug: https://bugs.openjdk.java.net/browse/JDK-8190745 > patch: > > diff -r d85284ccd1bd src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp??? Fri Nov 03 > 17:09:25 2017 -0700 > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp??? Sun Nov 05 > 18:16:48 2017 +0300 > @@ -2942,7 +2942,7 @@ > ?? BIND(CRC_less64); > ???? adds(len, len, 128-32); > ???? br(Assembler::GE, CRC_by32_loop); > -? BIND(CRC_less32) > +? BIND(CRC_less32); > ???? adds(len, len, 32-4); > ???? br(Assembler::GE, CRC_by4_loop); > ???? adds(len, len, 4); > > > From martin.doerr at sap.com Mon Nov 6 10:48:49 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 6 Nov 2017 10:48:49 +0000 Subject: RFR(S): 8190781: ppc64 + s390: Fix CriticalJNINatives Message-ID: Hi, CriticalJNINatives are currently not working correctly on PPC64 and s390. Code which saves & restores int type values is missing. The s390 implementation needs 2 more minor fixes. Please see my webrev: http://cr.openjdk.java.net/~mdoerr/8190781_ppc64_s390_CritNatives/webrev.00/ I've also fixed an obvious copy&paste bug in PPC64 assembler in a currently unused instruction. My proposed change also switches off SuperwordUseVSX on PPC64 as discussed with Michihiro who is still working on it. Please review. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Mon Nov 6 10:54:13 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 Nov 2017 10:54:13 +0000 Subject: RFR(S): 8190781: ppc64 + s390: Fix CriticalJNINatives In-Reply-To: References: Message-ID: HI Martin, looks good, but please fix this comment to something meaningful before pushing: (at least I don't grok it :)) // Value is in an input register pass we must flush it to the stack Thanks, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 6. November 2017 11:49 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; Lindenmaier, Goetz > Subject: RFR(S): 8190781: ppc64 + s390: Fix CriticalJNINatives > > Hi, > > > > CriticalJNINatives are currently not working correctly on PPC64 and s390. > Code which saves & restores int type values is missing. > > The s390 implementation needs 2 more minor fixes. Please see my webrev: > > http://cr.openjdk.java.net/~mdoerr/8190781_ppc64_s390_CritNatives/webr > ev.00/ > brev.00/> > > > > I've also fixed an obvious copy&paste bug in PPC64 assembler in a currently > unused instruction. > > My proposed change also switches off SuperwordUseVSX on PPC64 as > discussed with Michihiro who is still working on it. > > > > Please review. > > > > Best regards, > > Martin > > From tobias.hartmann at oracle.com Mon Nov 6 11:22:11 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Nov 2017 12:22:11 +0100 Subject: RFR: 8186478: [JVMCI] rename HotSpotResolvedJavaMethod#setNotInlineableOrCompileable In-Reply-To: <6529906E-BF3C-44DB-B19A-FD49F1C1088F@oracle.com> References: <6529906E-BF3C-44DB-B19A-FD49F1C1088F@oracle.com> Message-ID: <2a8e9a59-bc48-c8bc-e6ea-66a550890ad6@oracle.com> Hi Doug, looks good to me. Best regards, Tobias On 03.11.2017 16:55, Doug Simon wrote: > Please review this small change to fix the spelling of a method's name. > > https://bugs.openjdk.java.net/browse/JDK-8186478 > http://cr.openjdk.java.net/~dnsimon/8186478 > > -Doug > From gilles.m.duboscq at oracle.com Mon Nov 6 14:40:21 2017 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Mon, 6 Nov 2017 15:40:21 +0100 Subject: RFR(S): 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a crash or exception when using EnableJVMCI but not UseJVMCICompiler Message-ID: <013a0b42-152c-1c6f-fe8b-f72aaae1b449@oracle.com> Please review the following fix for deoptimization when using +EnableJVMCI and -UseJVMCICompiler. In this mode there can still be methods compiled by JVMCI so the interpreter needs to support potential pending monitors. Bug: https://bugs.openjdk.java.net/browse/JDK-8182755 Webrev: http://cr.openjdk.java.net/~gdub/webrev-8182755/ Gilles From dean.long at oracle.com Mon Nov 6 16:46:36 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 6 Nov 2017 08:46:36 -0800 Subject: RFR(XL) 8190710: Update Graal In-Reply-To: <67d2cb22-9c93-9556-7aff-f0765e5d0625@oracle.com> References: <67d2cb22-9c93-9556-7aff-f0765e5d0625@oracle.com> Message-ID: <3b979ffe-9477-f82f-29f9-c867b04849d2@oracle.com> Thanks Vladimir. dl On 11/4/17 9:03 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 11/4/17 10:40 AM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8190710 >> http://cr.openjdk.java.net/~dlong/8190710/webrev/ >> >> This is a Graal update.? Please see the JBS entry for the complete >> list of upstream changes included. >> >> I had to add new changes in these files to get it to build: >> >> make/CompileToolsHotspot.gmk >> src/hotspot/share/aot/aotCodeHeap.cpp >> src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java >> >> >> This update should also fix 8189828. >> >> dl From vladimir.kozlov at oracle.com Mon Nov 6 16:53:57 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Nov 2017 08:53:57 -0800 Subject: RFR(S): 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a crash or exception when using EnableJVMCI but not UseJVMCICompiler In-Reply-To: <013a0b42-152c-1c6f-fe8b-f72aaae1b449@oracle.com> References: <013a0b42-152c-1c6f-fe8b-f72aaae1b449@oracle.com> Message-ID: Looks good. Thanks, Vladimir On 11/6/17 6:40 AM, Gilles Duboscq wrote: > Please review the following fix for deoptimization when using +EnableJVMCI and -UseJVMCICompiler. > In this mode there can still be methods compiled by JVMCI so the interpreter needs to support potential pending monitors. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8182755 > Webrev: http://cr.openjdk.java.net/~gdub/webrev-8182755/ > > Gilles > From martin.doerr at sap.com Mon Nov 6 17:19:01 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 6 Nov 2017 17:19:01 +0000 Subject: RFR(S): 8190781: ppc64 + s390: Fix CriticalJNINatives In-Reply-To: References: Message-ID: <474141db379b43ec952785501942e4dd@sap.com> Hi G?tz, thanks for the review. Pushed with improved comments. New tests were just pushed today, so it's good to have this one in, which is needed to get them working correctly. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 6. November 2017 11:54 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: RE: RFR(S): 8190781: ppc64 + s390: Fix CriticalJNINatives HI Martin, looks good, but please fix this comment to something meaningful before pushing: (at least I don't grok it :)) // Value is in an input register pass we must flush it to the stack Thanks, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 6. November 2017 11:49 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; Lindenmaier, Goetz > Subject: RFR(S): 8190781: ppc64 + s390: Fix CriticalJNINatives > > Hi, > > > > CriticalJNINatives are currently not working correctly on PPC64 and s390. > Code which saves & restores int type values is missing. > > The s390 implementation needs 2 more minor fixes. Please see my webrev: > > http://cr.openjdk.java.net/~mdoerr/8190781_ppc64_s390_CritNatives/webr > ev.00/ > brev.00/> > > > > I've also fixed an obvious copy&paste bug in PPC64 assembler in a currently > unused instruction. > > My proposed change also switches off SuperwordUseVSX on PPC64 as > discussed with Michihiro who is still working on it. > > > > Please review. > > > > Best regards, > > Martin > > From vladimir.kozlov at oracle.com Mon Nov 6 18:26:38 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Nov 2017 10:26:38 -0800 Subject: [10] RFR: 8152470: Add COMPILER2_OR_JVMCI definition In-Reply-To: References: Message-ID: Looks good. Thanks, Vladimir On 11/3/17 10:36 AM, jamsheed wrote: > Hi, > > request for review, > > jbs: https://bugs.openjdk.java.net/browse/JDK-8152470 > > webrev: http://cr.openjdk.java.net/~jcm/8152470/webrev.00/ > > desc: cleanup > > #if defined(COMPILER2) || INCLUDE_JVMCI changed to #if COMPILER2_OR_JVMC > > Best regards, > > Jamsheed > From vladimir.kozlov at oracle.com Mon Nov 6 18:42:21 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Nov 2017 10:42:21 -0800 Subject: RFR(S): 8186125: "DU iteration must converge quickly" assert in split if with unsafe accesses In-Reply-To: References: Message-ID: <1c9df7df-9455-9e75-4918-635f95ac712b@oracle.com> Can you explain (add comment) why it can be only CMove node?: if (use_c == blk1 || use_c == blk2) { + assert(use->is_CMove(), "unexpected node type"); Seems fine otherwise. I submitted testing. What did you run to catch this problem? Thanks, Vladimir On 10/30/17 10:02 AM, Roland Westrelin wrote: > > Anyone to review this fix? > > Roland. > >> http://cr.openjdk.java.net/~roland/8186125/webrev.00/ >> >> Split if is missing support for graph shapes with the Opaque4Node that >> was introduced for unsafe accesses by JDK-8176506. >> >> In the test case, the 2 Unsafe accesses share a single Opaque4Node >> before the if. When split if encounters the Cmp->Bol->Opaque4->If chain, >> it only tries to clone Cmp->Bol when it should clone Cmp->Bol->Opaque4 >> to make one copy for each If. >> >> Roland. From chris.plummer at oracle.com Mon Nov 6 18:56:43 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Nov 2017 10:56:43 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <901dc547-182d-155d-5340-b973731003e1@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <901dc547-182d-155d-5340-b973731003e1@oracle.com> Message-ID: <54b19b95-a682-9422-b430-d6ea59e287d9@oracle.com> Hi Dean, It looks like ciEnv::jvmti_state_changed() is used to support the JVMTI AddCapabilities() interface, which I believe typically a JVMTI agent uses to setup the available capabilities when the agent is first loaded (although capabilities can by changed afterwords also). So I don't see that code as being related to changing the thread to be changed to "interp only" mode. thanks, Chris On 11/3/17 9:44 PM, dean.long at oracle.com wrote: > I'm not an expert in this area of code, but I'm wondering about > Vladimir's comment about ciEnv::jvmti_state_changed() in the bug > report. With your fix, maybe we don't need to check > ciEnv::jvmti_state_changed() (which doesn't seem to be enough by > itself) and throw away the compiled result.? We could just keep it > around so it can be used when "interp only" mode is switched off. > > dl > > > On 11/3/17 5:25 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8059334 >> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ >> >> The CR is closed, so I'll try to explain the issue here. The very >> short explanation is that the JVMTI test was enabling SINGLE STEP and >> doing a PopFrame, but the test method managed to get compiled and >> started executing compiled after the thread was put in "interp only" >> mode (which should never happen) and before the PopFrame was >> processed. The cause is a lack of a check for "interp only" mode in >> the OSR related compilation policy code. >> >> Details: >> >> The test is testing JVMTI PopFrame support. The test thread has a >> small method that sits in a tight loop. It will never exit. The main >> thread enables SINGLE STEP on the test thread, and then does a >> PopFrame on the test thread to force it out of the looping method. >> When the test failed due to a time out, I noticed it was still stuck >> in the small method, even though a PopFrame had been requested. >> Further, I noticed the method was compiled, so there was no chance >> the method would ever detect that it should do a PopFrame. Since >> "interp only" mode for SINGLE STEP had been enabled, the method >> should not be running compiled, so clearly something went wrong that >> allowed it to compile and execute. >> >> When SINGLE STEP is requested, JVMTI will deopt the topmost method >> (actually the top 2), put the thread in "interp only" mode, and then >> has checks to make sure the thread continues to execute interpreted. >> To avoid compilation when a back branch tries to trigger one, there >> is a check for "interp only" mode in SimpleThresholdPolicy::event(). >> If the thread is in "interp only" mode, it will prevent compilation. >> SimpleThresholdPolicy::event() is called (indirectly) by >> InterpreterRuntime::frequency_counter_overflow(), which is called >> from the interpreter when the back branch threshold is reached. >> >> After some debugging I noticed when the test timeout happens, "interp >> only" mode is not yet enabled when >> InterpreterRuntime::frequency_counter_overflow() is called, but is >> enabled by the time InterpreterRuntime::frequency_counter_overflow() >> has done the lookup of the nm. So there is a race here allowing the >> thread to begin execution in a compiled method even though "interp >> only" mode is enabled. I think the reason is because we safepoint >> during the compilation, and this allows a SINGLE STEP request to be >> processed, which enables "interp only" mode. >> >> I should add that initially I only saw this bug with -Xcomp, but >> eventually realized it was caused by disabling BackgroundCompilation. >> That makes it much more likely that a SINGLE STEP request will come >> in and be processed during the call to >> InterpreterRuntime::frequency_counter_overflow() (because it will >> block until the compilation completes). >> >> I believe for the fix it is enough just to add an "interp only" mode >> check in InterpreterRuntime::frequency_counter_overflow() after the >> nm lookup, and set it nm to NULL if we are now in "interp only" mode. >> If we are not in "interp only" mode at this point (and start >> executing the compiled method) it should not be possible to enter >> "interp only" mode until we reach a safepoint at some later time, and >> at that point the method will be properly deopt so it can execute >> interpreted. >> >> thanks, >> >> Chris >> > From dean.long at oracle.com Mon Nov 6 19:14:37 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 6 Nov 2017 11:14:37 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <54b19b95-a682-9422-b430-d6ea59e287d9@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <901dc547-182d-155d-5340-b973731003e1@oracle.com> <54b19b95-a682-9422-b430-d6ea59e287d9@oracle.com> Message-ID: <7c91ed2f-4462-d890-c2aa-aea9526f6653@oracle.com> OK thanks. dl On 11/6/17 10:56 AM, Chris Plummer wrote: > Hi Dean, > > It looks like ciEnv::jvmti_state_changed() is used to support the > JVMTI AddCapabilities() interface, which I believe typically a JVMTI > agent uses to setup the available capabilities when the agent is first > loaded (although capabilities can by changed afterwords also). So I > don't see that code as being related to changing the thread to be > changed to "interp only" mode. > > thanks, > > Chris > > On 11/3/17 9:44 PM, dean.long at oracle.com wrote: >> I'm not an expert in this area of code, but I'm wondering about >> Vladimir's comment about ciEnv::jvmti_state_changed() in the bug >> report. With your fix, maybe we don't need to check >> ciEnv::jvmti_state_changed() (which doesn't seem to be enough by >> itself) and throw away the compiled result.? We could just keep it >> around so it can be used when "interp only" mode is switched off. >> >> dl >> >> >> On 11/3/17 5:25 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8059334 >>> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ >>> >>> The CR is closed, so I'll try to explain the issue here. The very >>> short explanation is that the JVMTI test was enabling SINGLE STEP >>> and doing a PopFrame, but the test method managed to get compiled >>> and started executing compiled after the thread was put in "interp >>> only" mode (which should never happen) and before the PopFrame was >>> processed. The cause is a lack of a check for "interp only" mode in >>> the OSR related compilation policy code. >>> >>> Details: >>> >>> The test is testing JVMTI PopFrame support. The test thread has a >>> small method that sits in a tight loop. It will never exit. The main >>> thread enables SINGLE STEP on the test thread, and then does a >>> PopFrame on the test thread to force it out of the looping method. >>> When the test failed due to a time out, I noticed it was still stuck >>> in the small method, even though a PopFrame had been requested. >>> Further, I noticed the method was compiled, so there was no chance >>> the method would ever detect that it should do a PopFrame. Since >>> "interp only" mode for SINGLE STEP had been enabled, the method >>> should not be running compiled, so clearly something went wrong that >>> allowed it to compile and execute. >>> >>> When SINGLE STEP is requested, JVMTI will deopt the topmost method >>> (actually the top 2), put the thread in "interp only" mode, and then >>> has checks to make sure the thread continues to execute interpreted. >>> To avoid compilation when a back branch tries to trigger one, there >>> is a check for "interp only" mode in SimpleThresholdPolicy::event(). >>> If the thread is in "interp only" mode, it will prevent compilation. >>> SimpleThresholdPolicy::event() is called (indirectly) by >>> InterpreterRuntime::frequency_counter_overflow(), which is called >>> from the interpreter when the back branch threshold is reached. >>> >>> After some debugging I noticed when the test timeout happens, >>> "interp only" mode is not yet enabled when >>> InterpreterRuntime::frequency_counter_overflow() is called, but is >>> enabled by the time InterpreterRuntime::frequency_counter_overflow() >>> has done the lookup of the nm. So there is a race here allowing the >>> thread to begin execution in a compiled method even though "interp >>> only" mode is enabled. I think the reason is because we safepoint >>> during the compilation, and this allows a SINGLE STEP request to be >>> processed, which enables "interp only" mode. >>> >>> I should add that initially I only saw this bug with -Xcomp, but >>> eventually realized it was caused by disabling >>> BackgroundCompilation. That makes it much more likely that a SINGLE >>> STEP request will come in and be processed during the call to >>> InterpreterRuntime::frequency_counter_overflow() (because it will >>> block until the compilation completes). >>> >>> I believe for the fix it is enough just to add an "interp only" mode >>> check in InterpreterRuntime::frequency_counter_overflow() after the >>> nm lookup, and set it nm to NULL if we are now in "interp only" >>> mode. If we are not in "interp only" mode at this point (and start >>> executing the compiled method) it should not be possible to enter >>> "interp only" mode until we reach a safepoint at some later time, >>> and at that point the method will be properly deopt so it can >>> execute interpreted. >>> >>> thanks, >>> >>> Chris >>> >> > > From daniel.daugherty at oracle.com Mon Nov 6 20:23:50 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Nov 2017 15:23:50 -0500 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> Message-ID: <304657a1-fe1a-100d-b155-3897d18e9770@oracle.com> On 11/3/17 8:25 PM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8059334 Wow! This bug was quite the adventure... > http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ src/hotspot/share/interpreter/interpreterRuntime.cpp ??? L924: ? if (thread->is_interp_only_mode()) { ??????? Perhaps: if (nm != NULL && thread->is_interp_only_mode()) { ??? I kept trying to decide whether your new check only needs to ? ? be inside the existing block: ? ? ? ? L913: ? if (branch_bcp != NULL && nm != NULL) { ??????? : ? ? ? ? L923?? } ? ? but I finally convinced myself that you want to check a non-NULL ? ? nm value in either branch_bcp code branch (NULL or non-NULL) so ??? where you put the fix is just fine. ? ? Of course, the usual question we have to ask in these kinds of ? ? races is what prevents the racy condition from asserting itself ? ? right after the fixed code location. Thanks for including your ? ? last sentence: > ??? If we are not in "interp only" mode at this point (and start executing > ??? the compiled method) it should not be possible to enter "interp only" > ??? mode until we reach a safepoint at some later time, and at that point > ??? the method will be properly deopt so it can execute interpreted. Nicely done bug hunt! Thumbs up! Dan > > The CR is closed, so I'll try to explain the issue here. The very > short explanation is that the JVMTI test was enabling SINGLE STEP and > doing a PopFrame, but the test method managed to get compiled and > started executing compiled after the thread was put in "interp only" > mode (which should never happen) and before the PopFrame was > processed. The cause is a lack of a check for "interp only" mode in > the OSR related compilation policy code. > > Details: > > The test is testing JVMTI PopFrame support. The test thread has a > small method that sits in a tight loop. It will never exit. The main > thread enables SINGLE STEP on the test thread, and then does a > PopFrame on the test thread to force it out of the looping method. > When the test failed due to a time out, I noticed it was still stuck > in the small method, even though a PopFrame had been requested. > Further, I noticed the method was compiled, so there was no chance the > method would ever detect that it should do a PopFrame. Since "interp > only" mode for SINGLE STEP had been enabled, the method should not be > running compiled, so clearly something went wrong that allowed it to > compile and execute. > > When SINGLE STEP is requested, JVMTI will deopt the topmost method > (actually the top 2), put the thread in "interp only" mode, and then > has checks to make sure the thread continues to execute interpreted. > To avoid compilation when a back branch tries to trigger one, there is > a check for "interp only" mode in SimpleThresholdPolicy::event(). If > the thread is in "interp only" mode, it will prevent compilation. > SimpleThresholdPolicy::event() is called (indirectly) by > InterpreterRuntime::frequency_counter_overflow(), which is called from > the interpreter when the back branch threshold is reached. > > After some debugging I noticed when the test timeout happens, "interp > only" mode is not yet enabled when > InterpreterRuntime::frequency_counter_overflow() is called, but is > enabled by the time InterpreterRuntime::frequency_counter_overflow() > has done the lookup of the nm. So there is a race here allowing the > thread to begin execution in a compiled method even though "interp > only" mode is enabled. I think the reason is because we safepoint > during the compilation, and this allows a SINGLE STEP request to be > processed, which enables "interp only" mode. > > I should add that initially I only saw this bug with -Xcomp, but > eventually realized it was caused by disabling BackgroundCompilation. > That makes it much more likely that a SINGLE STEP request will come in > and be processed during the call to > InterpreterRuntime::frequency_counter_overflow() (because it will > block until the compilation completes). > > I believe for the fix it is enough just to add an "interp only" mode > check in InterpreterRuntime::frequency_counter_overflow() after the nm > lookup, and set it nm to NULL if we are now in "interp only" mode. If > we are not in "interp only" mode at this point (and start executing > the compiled method) it should not be possible to enter "interp only" > mode until we reach a safepoint at some later time, and at that point > the method will be properly deopt so it can execute interpreted. > > thanks, > > Chris > From chris.plummer at oracle.com Mon Nov 6 20:33:43 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Nov 2017 12:33:43 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <304657a1-fe1a-100d-b155-3897d18e9770@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <304657a1-fe1a-100d-b155-3897d18e9770@oracle.com> Message-ID: Hi Dan, On 11/6/17 12:23 PM, Daniel D. Daugherty wrote: > On 11/3/17 8:25 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8059334 > > Wow! This bug was quite the adventure... I know how to pick 'em, huh? :) > > >> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ > > src/hotspot/share/interpreter/interpreterRuntime.cpp > ??? L924: ? if (thread->is_interp_only_mode()) { > ??????? Perhaps: if (nm != NULL && thread->is_interp_only_mode()) { Ok, I'll add the NULL check. > > ??? I kept trying to decide whether your new check only needs to > ? ? be inside the existing block: > > ? ? ? ? L913: ? if (branch_bcp != NULL && nm != NULL) { > ??????? : > ? ? ? ? L923?? } > > ? ? but I finally convinced myself that you want to check a non-NULL > ? ? nm value in either branch_bcp code branch (NULL or non-NULL) so > ??? where you put the fix is just fine. > > ? ? Of course, the usual question we have to ask in these kinds of > ? ? races is what prevents the racy condition from asserting itself > ? ? right after the fixed code location. Thanks for including your > ? ? last sentence: > >> ??? If we are not in "interp only" mode at this point (and start >> executing >> ??? the compiled method) it should not be possible to enter "interp >> only" >> ??? mode until we reach a safepoint at some later time, and at that >> point >> ??? the method will be properly deopt so it can execute interpreted. > > Nicely done bug hunt! > > Thumbs up! Thanks! Chris > > Dan > > >> >> The CR is closed, so I'll try to explain the issue here. The very >> short explanation is that the JVMTI test was enabling SINGLE STEP and >> doing a PopFrame, but the test method managed to get compiled and >> started executing compiled after the thread was put in "interp only" >> mode (which should never happen) and before the PopFrame was >> processed. The cause is a lack of a check for "interp only" mode in >> the OSR related compilation policy code. >> >> Details: >> >> The test is testing JVMTI PopFrame support. The test thread has a >> small method that sits in a tight loop. It will never exit. The main >> thread enables SINGLE STEP on the test thread, and then does a >> PopFrame on the test thread to force it out of the looping method. >> When the test failed due to a time out, I noticed it was still stuck >> in the small method, even though a PopFrame had been requested. >> Further, I noticed the method was compiled, so there was no chance >> the method would ever detect that it should do a PopFrame. Since >> "interp only" mode for SINGLE STEP had been enabled, the method >> should not be running compiled, so clearly something went wrong that >> allowed it to compile and execute. >> >> When SINGLE STEP is requested, JVMTI will deopt the topmost method >> (actually the top 2), put the thread in "interp only" mode, and then >> has checks to make sure the thread continues to execute interpreted. >> To avoid compilation when a back branch tries to trigger one, there >> is a check for "interp only" mode in SimpleThresholdPolicy::event(). >> If the thread is in "interp only" mode, it will prevent compilation. >> SimpleThresholdPolicy::event() is called (indirectly) by >> InterpreterRuntime::frequency_counter_overflow(), which is called >> from the interpreter when the back branch threshold is reached. >> >> After some debugging I noticed when the test timeout happens, "interp >> only" mode is not yet enabled when >> InterpreterRuntime::frequency_counter_overflow() is called, but is >> enabled by the time InterpreterRuntime::frequency_counter_overflow() >> has done the lookup of the nm. So there is a race here allowing the >> thread to begin execution in a compiled method even though "interp >> only" mode is enabled. I think the reason is because we safepoint >> during the compilation, and this allows a SINGLE STEP request to be >> processed, which enables "interp only" mode. >> >> I should add that initially I only saw this bug with -Xcomp, but >> eventually realized it was caused by disabling BackgroundCompilation. >> That makes it much more likely that a SINGLE STEP request will come >> in and be processed during the call to >> InterpreterRuntime::frequency_counter_overflow() (because it will >> block until the compilation completes). >> >> I believe for the fix it is enough just to add an "interp only" mode >> check in InterpreterRuntime::frequency_counter_overflow() after the >> nm lookup, and set it nm to NULL if we are now in "interp only" mode. >> If we are not in "interp only" mode at this point (and start >> executing the compiled method) it should not be possible to enter >> "interp only" mode until we reach a safepoint at some later time, and >> at that point the method will be properly deopt so it can execute >> interpreted. >> >> thanks, >> >> Chris >> > From daniel.daugherty at oracle.com Mon Nov 6 20:41:23 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Nov 2017 15:41:23 -0500 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <54b19b95-a682-9422-b430-d6ea59e287d9@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <901dc547-182d-155d-5340-b973731003e1@oracle.com> <54b19b95-a682-9422-b430-d6ea59e287d9@oracle.com> Message-ID: On 11/6/17 1:56 PM, Chris Plummer wrote: > Hi Dean, > > It looks like ciEnv::jvmti_state_changed() is used to support the > JVMTI AddCapabilities() interface, which I believe typically a JVMTI > agent uses to setup the available capabilities when the agent is first > loaded (although capabilities can by changed afterwords also). So I > don't see that code as being related to changing the thread to be > changed to "interp only" mode. Agreed. An agent enables a capability to indicate that it might want to use that capability/feature at some point during the agent's life. The compiler needs to know if an agent enabled specific capabilities because it may need to generate different code in order for specific features to work during compilation. The "interp only" mode state is set by the VM and is not directly managed by the agent. The agent may enable capabilities or events that cause "interp only" mode to be set and cleared, but it is not a mode that is directly managed by the agent. Put more simply: - The agent enables capabilities to indicate what it might want to do. - The "interp only" mode is set and cleared by the VM as the VM is ? actually doing stuff. Dan > > thanks, > > Chris > > On 11/3/17 9:44 PM, dean.long at oracle.com wrote: >> I'm not an expert in this area of code, but I'm wondering about >> Vladimir's comment about ciEnv::jvmti_state_changed() in the bug >> report. With your fix, maybe we don't need to check >> ciEnv::jvmti_state_changed() (which doesn't seem to be enough by >> itself) and throw away the compiled result.? We could just keep it >> around so it can be used when "interp only" mode is switched off. >> >> dl >> >> >> On 11/3/17 5:25 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8059334 >>> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ >>> >>> The CR is closed, so I'll try to explain the issue here. The very >>> short explanation is that the JVMTI test was enabling SINGLE STEP >>> and doing a PopFrame, but the test method managed to get compiled >>> and started executing compiled after the thread was put in "interp >>> only" mode (which should never happen) and before the PopFrame was >>> processed. The cause is a lack of a check for "interp only" mode in >>> the OSR related compilation policy code. >>> >>> Details: >>> >>> The test is testing JVMTI PopFrame support. The test thread has a >>> small method that sits in a tight loop. It will never exit. The main >>> thread enables SINGLE STEP on the test thread, and then does a >>> PopFrame on the test thread to force it out of the looping method. >>> When the test failed due to a time out, I noticed it was still stuck >>> in the small method, even though a PopFrame had been requested. >>> Further, I noticed the method was compiled, so there was no chance >>> the method would ever detect that it should do a PopFrame. Since >>> "interp only" mode for SINGLE STEP had been enabled, the method >>> should not be running compiled, so clearly something went wrong that >>> allowed it to compile and execute. >>> >>> When SINGLE STEP is requested, JVMTI will deopt the topmost method >>> (actually the top 2), put the thread in "interp only" mode, and then >>> has checks to make sure the thread continues to execute interpreted. >>> To avoid compilation when a back branch tries to trigger one, there >>> is a check for "interp only" mode in SimpleThresholdPolicy::event(). >>> If the thread is in "interp only" mode, it will prevent compilation. >>> SimpleThresholdPolicy::event() is called (indirectly) by >>> InterpreterRuntime::frequency_counter_overflow(), which is called >>> from the interpreter when the back branch threshold is reached. >>> >>> After some debugging I noticed when the test timeout happens, >>> "interp only" mode is not yet enabled when >>> InterpreterRuntime::frequency_counter_overflow() is called, but is >>> enabled by the time InterpreterRuntime::frequency_counter_overflow() >>> has done the lookup of the nm. So there is a race here allowing the >>> thread to begin execution in a compiled method even though "interp >>> only" mode is enabled. I think the reason is because we safepoint >>> during the compilation, and this allows a SINGLE STEP request to be >>> processed, which enables "interp only" mode. >>> >>> I should add that initially I only saw this bug with -Xcomp, but >>> eventually realized it was caused by disabling >>> BackgroundCompilation. That makes it much more likely that a SINGLE >>> STEP request will come in and be processed during the call to >>> InterpreterRuntime::frequency_counter_overflow() (because it will >>> block until the compilation completes). >>> >>> I believe for the fix it is enough just to add an "interp only" mode >>> check in InterpreterRuntime::frequency_counter_overflow() after the >>> nm lookup, and set it nm to NULL if we are now in "interp only" >>> mode. If we are not in "interp only" mode at this point (and start >>> executing the compiled method) it should not be possible to enter >>> "interp only" mode until we reach a safepoint at some later time, >>> and at that point the method will be properly deopt so it can >>> execute interpreted. >>> >>> thanks, >>> >>> Chris >>> >> > > From vladimir.kozlov at oracle.com Mon Nov 6 20:55:01 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Nov 2017 12:55:01 -0800 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> Message-ID: On 10/30/17 10:02 AM, Roland Westrelin wrote: > > Hi Vladimir, > >> Should we just make _loop_flags field type uint (32-bit) since we hit 16-bit limit? > > We don't hit the limit with this change. I have some other changes for > which I had to change _loop_flags to uint. That's where the int -> uint > tweaks are coming from. I can remove them if you like as they are not > required. Sorry for the confusion. Please, remove them. Changes are big already. > >> There is confusion (because you did not have enough bits?) about which loops are marked as >> strip_mined. I thought it is only inner loop but it looks like out (skeleton) loop also marked as >> such. I would suggest to mark them differently. > > The way it works currently is: > > Opcode() == Op_Loop && is_strip_mined() => outer loop > Opcode() == Op_CountedLoop && is_strip_mined() => inner loop Yes, I got it after 3rd read-through. It is not very obvious. > > The outer loop can't be transformed to a counted loop so that scheme > shouldn't break. Yes, it is correct code but it is hard to follow. > >> I was thinking may be we should create new Loop node subclass for outer loop. Then you don't need >> special flag for it and it will be obvious what they are in Ideal Graph. The same for outer loop end >> node. > > Ok. That sounds like it could clean up the code a bit. Do you want me to > look into that? Yes, please. > >> src/hotspot/share/opto/superword.cpp >> >> Where next change come from? >> >> + if (t2->Opcode() == Op_AddI && t2 == _lp->as_CountedLoop()->incr()) continue; // don't mess >> with the iv > > I saw a few cases where t2 is the increment of the CountedLoop > iv. SuperWord::opnd_positions_match() then swaps the edges of the AddI > and later CountedLoopEndNode::phi() fails because the edges of the iv's > AddI are not in the expected order anymore. Good. But why you need to check Opcode() too? In Counted loops it should be Int type. Thanks, Vladimir > > Roland. > From serguei.spitsyn at oracle.com Tue Nov 7 00:58:08 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Nov 2017 16:58:08 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> Message-ID: <4a20d856-08e9-1a17-c6d0-ad0d0d3396b5@oracle.com> Hi Chris, The fix looks good. I'm not that familiar with the compiler code to judge if this the best place to make this check. But, at least, it looks as such to me. Perhaps, it would be great if Vladimir could also look at it. But now pressure for this. Thanks, Serguei On 11/3/17 17:25, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8059334 > http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ > > The CR is closed, so I'll try to explain the issue here. The very > short explanation is that the JVMTI test was enabling SINGLE STEP and > doing a PopFrame, but the test method managed to get compiled and > started executing compiled after the thread was put in "interp only" > mode (which should never happen) and before the PopFrame was > processed. The cause is a lack of a check for "interp only" mode in > the OSR related compilation policy code. > > Details: > > The test is testing JVMTI PopFrame support. The test thread has a > small method that sits in a tight loop. It will never exit. The main > thread enables SINGLE STEP on the test thread, and then does a > PopFrame on the test thread to force it out of the looping method. > When the test failed due to a time out, I noticed it was still stuck > in the small method, even though a PopFrame had been requested. > Further, I noticed the method was compiled, so there was no chance the > method would ever detect that it should do a PopFrame. Since "interp > only" mode for SINGLE STEP had been enabled, the method should not be > running compiled, so clearly something went wrong that allowed it to > compile and execute. > > When SINGLE STEP is requested, JVMTI will deopt the topmost method > (actually the top 2), put the thread in "interp only" mode, and then > has checks to make sure the thread continues to execute interpreted. > To avoid compilation when a back branch tries to trigger one, there is > a check for "interp only" mode in SimpleThresholdPolicy::event(). If > the thread is in "interp only" mode, it will prevent compilation. > SimpleThresholdPolicy::event() is called (indirectly) by > InterpreterRuntime::frequency_counter_overflow(), which is called from > the interpreter when the back branch threshold is reached. > > After some debugging I noticed when the test timeout happens, "interp > only" mode is not yet enabled when > InterpreterRuntime::frequency_counter_overflow() is called, but is > enabled by the time InterpreterRuntime::frequency_counter_overflow() > has done the lookup of the nm. So there is a race here allowing the > thread to begin execution in a compiled method even though "interp > only" mode is enabled. I think the reason is because we safepoint > during the compilation, and this allows a SINGLE STEP request to be > processed, which enables "interp only" mode. > > I should add that initially I only saw this bug with -Xcomp, but > eventually realized it was caused by disabling BackgroundCompilation. > That makes it much more likely that a SINGLE STEP request will come in > and be processed during the call to > InterpreterRuntime::frequency_counter_overflow() (because it will > block until the compilation completes). > > I believe for the fix it is enough just to add an "interp only" mode > check in InterpreterRuntime::frequency_counter_overflow() after the nm > lookup, and set it nm to NULL if we are now in "interp only" mode. If > we are not in "interp only" mode at this point (and start executing > the compiled method) it should not be possible to enter "interp only" > mode until we reach a safepoint at some later time, and at that point > the method will be properly deopt so it can execute interpreted. > > thanks, > > Chris > From jamsheed.c.m at oracle.com Tue Nov 7 04:58:48 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Tue, 7 Nov 2017 10:28:48 +0530 Subject: [10] RFR: 8152470: Add COMPILER2_OR_JVMCI definition In-Reply-To: References: Message-ID: <2d857c4d-553a-68c8-511b-0e4dd74723e4@oracle.com> Thank you, Vladimir Best regards, Jamsheed On Monday 06 November 2017 11:56 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 11/3/17 10:36 AM, jamsheed wrote: >> Hi, >> >> request for review, >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8152470 >> >> webrev: http://cr.openjdk.java.net/~jcm/8152470/webrev.00/ >> >> desc: cleanup >> >> #if defined(COMPILER2) || INCLUDE_JVMCI changed to #if COMPILER2_OR_JVMC >> >> Best regards, >> >> Jamsheed >> From tobias.hartmann at oracle.com Tue Nov 7 12:04:49 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 7 Nov 2017 13:04:49 +0100 Subject: [10] RFR(S): 8190797: OSR compilation fails with "assert(__the_thread__->can_call_java()) failed: can not load classes with compiler thread" Message-ID: <9ab0bc1c-605f-7b28-57e9-c522b40ca4c1@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8190797 http://cr.openjdk.java.net/~thartmann/8190797/webrev.00/ When oop map creation fails, we try to throw a LinkageError to propagate the error message. If this happens in the compiler thread (for example, during OSR compilation), we fail because a compiler thread cannot initialize an exception object. I've fixed this by bailing out with a meaningful message in case !Thread::can_call_java(). Please note that even if we are able to instantiate an exception, we will still fail with ShouldNotReachHere because compute_map(TRAPS) is called with CATCH (see comments in the bug for a detailed explanation). This fix is not about changing this behavior but to fail with a meaningful error message during compilation. This should only happen if something is seriously broken (for example, incorrect bytecode with -noverify, see TestLinkageErrorInGenerateOopMap). In this case we would probably hit other issues as well if we would continue execution. Thanks, Tobias From christian.haeubl at oracle.com Tue Nov 7 13:08:49 2017 From: christian.haeubl at oracle.com (Christian Haeubl) Date: Tue, 7 Nov 2017 14:08:49 +0100 Subject: RFR: 8178048: [JVMCI] improve HotSpotResolvedJavaFieldImpl.hashCode() Message-ID: |Hi, Please review this small JVMCI change that decreases the probability of hashcode collisions.| || |https://bugs.openjdk.java.net/browse/JDK-8178048| |http://cr.openjdk.java.net/~chaeubl/8178048/webrev.001/| || |- Christian | -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Tue Nov 7 16:30:45 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 7 Nov 2017 19:30:45 +0300 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 11/3/17 6:06 PM, jamsheed wrote: > Hi Dean, David, Martin, Vladimir, > > incorporated most of the suggestions, let me know if this is ok! > > http://cr.openjdk.java.net/~jcm/8167408/webrev.02/ > > Best regards > > Jamsheed > > On Wednesday 01 November 2017 03:58 AM, Vladimir Ivanov wrote: >> Jamsheed, nice test! >> >> 2 suggestions: >> >> ? (1) Enable the test on all platforms: though the bug is >> platform-specific, it doesn't mean the test should be. I don't see any >> platform-specific code there and it's beneficial to test other >> platforms as well >> >> ? (2) Add some test cases with multiple array parameters. >> >> Otherwise, looks good. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/31/17 10:37 PM, jamsheed wrote: >>> Hi Dean, >>> >>> Thank you for the review, >>> >>> tested with a test case, previously it was not working for >>> windows-x86, now it works. >>> >>> revised webrev with test >>> case:http://cr.openjdk.java.net/~jcm/8167408/webrev.01/ >>> >>> Best regards, >>> >>> Jamsheed >>> >>> >>> On Tuesday 31 October 2017 02:18 AM, dean.long at oracle.com wrote: >>>> I think you need a native test for Windows x86 that defines >>>> JavaCritical methods with various signatures (especially arrays) to >>>> make sure this is working correctly. >>>> >>>> dl >>>> >>>> >>>> On 10/30/17 9:45 AM, jamsheed wrote: >>>>> Hi, >>>>> >>>>> request for review, >>>>> >>>>> jbs : https://bugs.openjdk.java.net/browse/JDK-8167408 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jcm/8167408/webrev.00/ >>>>> >>>>> (contributed by Ioannis Tsakpinis) >>>>> >>>>> desc: >>>>> >>>>> -- it starts with JavaCritical_ instead of Java_; >>>>> -- it does not have extra JNIEnv* and jclass arguments; >>>>> -- Java arrays are passed in two arguments: the first is an array >>>>> length, and the second is a pointer to raw array data. That is, no >>>>> need to call GetArrayElements and friends, you can instantly use a >>>>> direct array pointer. >>>>> >>>>> updated arg_size calculation wrt above points. >>>>> >>>>> Best regards, >>>>> >>>>> Jamsheed >>>>> >>>> >>> > From rwestrel at redhat.com Tue Nov 7 16:44:54 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 07 Nov 2017 17:44:54 +0100 Subject: RFR(S): 8186125: "DU iteration must converge quickly" assert in split if with unsafe accesses In-Reply-To: <1c9df7df-9455-9e75-4918-635f95ac712b@oracle.com> References: <1c9df7df-9455-9e75-4918-635f95ac712b@oracle.com> Message-ID: Thanks for reviewing this, Vladimir. > Can you explain (add comment) why it can be only CMove node?: > > if (use_c == blk1 || use_c == blk2) { > + assert(use->is_CMove(), "unexpected node type"); So either it's an If, a CMove or an Opaque1. That node is between the if that we are going to split and the Region right above we are going to split it through. It can't be an If because then there would be some control flow between the If to split and the Region which is impossible. It can't be an Opaque1 because there can't be any control flow between the If and the region (so no loop) and Opaque1 nodes are not commoned so even if they are loops in the if branches, they would each have an Opaque1 that should be assigned a control in the if branches. Roland. From rwestrel at redhat.com Tue Nov 7 16:49:38 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 07 Nov 2017 17:49:38 +0100 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> Message-ID: >>> src/hotspot/share/opto/superword.cpp >>> >>> Where next change come from? >>> >>> + if (t2->Opcode() == Op_AddI && t2 == _lp->as_CountedLoop()->incr()) continue; // don't mess >>> with the iv >> >> I saw a few cases where t2 is the increment of the CountedLoop >> iv. SuperWord::opnd_positions_match() then swaps the edges of the AddI >> and later CountedLoopEndNode::phi() fails because the edges of the iv's >> AddI are not in the expected order anymore. > > Good. But why you need to check Opcode() too? In Counted loops it should be Int type. It's not required for correctness but _lp->as_CountedLoop()->incr() is somewhat expensive because it has to follow several edges from the loop head to the AddI so t2->Opcode() == Op_AddI skips that call if it's obvious it's not needed. Roland. From vladimir.kozlov at oracle.com Tue Nov 7 17:14:51 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Nov 2017 09:14:51 -0800 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> Message-ID: <0fadaeb5-6eff-849e-e96a-a1eaedb209b8@oracle.com> On 11/7/17 8:49 AM, Roland Westrelin wrote: > >>>> src/hotspot/share/opto/superword.cpp >>>> >>>> Where next change come from? >>>> >>>> + if (t2->Opcode() == Op_AddI && t2 == _lp->as_CountedLoop()->incr()) continue; // don't mess >>>> with the iv >>> >>> I saw a few cases where t2 is the increment of the CountedLoop >>> iv. SuperWord::opnd_positions_match() then swaps the edges of the AddI >>> and later CountedLoopEndNode::phi() fails because the edges of the iv's >>> AddI are not in the expected order anymore. >> >> Good. But why you need to check Opcode() too? In Counted loops it should be Int type. > > It's not required for correctness but _lp->as_CountedLoop()->incr() is > somewhat expensive because it has to follow several edges from the loop > head to the AddI so t2->Opcode() == Op_AddI skips that call if it's > obvious it's not needed. Got it. I thought Opcode() will be more expensive since it is virtual but looking on other - it has a lot of checks. Thanks, Vladimir > > Roland. > From vladimir.kozlov at oracle.com Tue Nov 7 18:39:18 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Nov 2017 10:39:18 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <4a20d856-08e9-1a17-c6d0-ad0d0d3396b5@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <4a20d856-08e9-1a17-c6d0-ad0d0d3396b5@oracle.com> Message-ID: <36179db5-3a76-af68-773f-7a5d80370d4a@oracle.com> Looks good to me too. I assume you will add NULL check as Dan suggested. I thought that you may need to call nm->make_not_entrant() to deoptimize method. But on other hand you may still want to run compiled code in other threads. So your fix should is good for your problem. Thanks, Vladimir On 11/6/17 4:58 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > The fix looks good. > I'm not that familiar with the compiler code to judge if this the best place to make this check. > But, at least, it looks as such to me. > Perhaps, it would be great if Vladimir could also look at it. > But now pressure for this. > > Thanks, > Serguei > > > On 11/3/17 17:25, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8059334 >> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ >> >> The CR is closed, so I'll try to explain the issue here. The very short explanation is that the JVMTI test was >> enabling SINGLE STEP and doing a PopFrame, but the test method managed to get compiled and started executing compiled >> after the thread was put in "interp only" mode (which should never happen) and before the PopFrame was processed. The >> cause is a lack of a check for "interp only" mode in the OSR related compilation policy code. >> >> Details: >> >> The test is testing JVMTI PopFrame support. The test thread has a small method that sits in a tight loop. It will >> never exit. The main thread enables SINGLE STEP on the test thread, and then does a PopFrame on the test thread to >> force it out of the looping method. When the test failed due to a time out, I noticed it was still stuck in the small >> method, even though a PopFrame had been requested. Further, I noticed the method was compiled, so there was no chance >> the method would ever detect that it should do a PopFrame. Since "interp only" mode for SINGLE STEP had been enabled, >> the method should not be running compiled, so clearly something went wrong that allowed it to compile and execute. >> >> When SINGLE STEP is requested, JVMTI will deopt the topmost method (actually the top 2), put the thread in "interp >> only" mode, and then has checks to make sure the thread continues to execute interpreted. To avoid compilation when a >> back branch tries to trigger one, there is a check for "interp only" mode in SimpleThresholdPolicy::event(). If the >> thread is in "interp only" mode, it will prevent compilation. SimpleThresholdPolicy::event() is called (indirectly) by >> InterpreterRuntime::frequency_counter_overflow(), which is called from the interpreter when the back branch threshold >> is reached. >> >> After some debugging I noticed when the test timeout happens, "interp only" mode is not yet enabled when >> InterpreterRuntime::frequency_counter_overflow() is called, but is enabled by the time >> InterpreterRuntime::frequency_counter_overflow() has done the lookup of the nm. So there is a race here allowing the >> thread to begin execution in a compiled method even though "interp only" mode is enabled. I think the reason is >> because we safepoint during the compilation, and this allows a SINGLE STEP request to be processed, which enables >> "interp only" mode. >> >> I should add that initially I only saw this bug with -Xcomp, but eventually realized it was caused by disabling >> BackgroundCompilation. That makes it much more likely that a SINGLE STEP request will come in and be processed during >> the call to InterpreterRuntime::frequency_counter_overflow() (because it will block until the compilation completes). >> >> I believe for the fix it is enough just to add an "interp only" mode check in >> InterpreterRuntime::frequency_counter_overflow() after the nm lookup, and set it nm to NULL if we are now in "interp >> only" mode. If we are not in "interp only" mode at this point (and start executing the compiled method) it should not >> be possible to enter "interp only" mode until we reach a safepoint at some later time, and at that point the method >> will be properly deopt so it can execute interpreted. >> >> thanks, >> >> Chris >> > From vladimir.kozlov at oracle.com Tue Nov 7 18:49:23 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Nov 2017 10:49:23 -0800 Subject: RFR: 8178048: [JVMCI] improve HotSpotResolvedJavaFieldImpl.hashCode() In-Reply-To: References: Message-ID: Looks good. What testing was done? Thanks, Vladimir On 11/7/17 5:08 AM, Christian Haeubl wrote: > |Hi, > > Please review this small JVMCI change that decreases the probability of hashcode collisions.| > || > |https://bugs.openjdk.java.net/browse/JDK-8178048| > |http://cr.openjdk.java.net/~chaeubl/8178048/webrev.001/| > || > |- Christian > > | From vladimir.kozlov at oracle.com Tue Nov 7 18:56:36 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Nov 2017 10:56:36 -0800 Subject: [10] RFR(S): 8190797: OSR compilation fails with "assert(__the_thread__->can_call_java()) failed: can not load classes with compiler thread" In-Reply-To: <9ab0bc1c-605f-7b28-57e9-c522b40ca4c1@oracle.com> References: <9ab0bc1c-605f-7b28-57e9-c522b40ca4c1@oracle.com> Message-ID: <01dbd4cb-0683-a36d-5ee9-b4950e10c517@oracle.com> Looks good. Thanks, Vladimir On 11/7/17 4:04 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8190797 > http://cr.openjdk.java.net/~thartmann/8190797/webrev.00/ > > When oop map creation fails, we try to throw a LinkageError to propagate the error message. If this happens in the > compiler thread (for example, during OSR compilation), we fail because a compiler thread cannot initialize an exception > object. > > I've fixed this by bailing out with a meaningful message in case !Thread::can_call_java(). Please note that even if we > are able to instantiate an exception, we will still fail with ShouldNotReachHere because compute_map(TRAPS) is called > with CATCH (see comments in the bug for a detailed explanation). This fix is not about changing this behavior but to > fail with a meaningful error message during compilation. This should only happen if something is seriously broken (for > example, incorrect bytecode with -noverify, see TestLinkageErrorInGenerateOopMap). In this case we would probably hit > other issues as well if we would continue execution. > > Thanks, > Tobias > From chris.plummer at oracle.com Tue Nov 7 19:55:42 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 7 Nov 2017 11:55:42 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <36179db5-3a76-af68-773f-7a5d80370d4a@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <4a20d856-08e9-1a17-c6d0-ad0d0d3396b5@oracle.com> <36179db5-3a76-af68-773f-7a5d80370d4a@oracle.com> Message-ID: Hi Vladimir, I also considered calling nm->make_not_entrant(), but came to the same conclusion as you. thanks, Chris On 11/7/17 10:39 AM, Vladimir Kozlov wrote: > Looks good to me too. I assume you will add NULL check as Dan suggested. > > I thought that you may need to call nm->make_not_entrant() to > deoptimize method. But on other hand you may still want to run > compiled code in other threads. So your fix should is good for your > problem. > > Thanks, > Vladimir > > On 11/6/17 4:58 PM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> The fix looks good. >> I'm not that familiar with the compiler code to judge if this the >> best place to make this check. >> But, at least, it looks as such to me. >> Perhaps, it would be great if Vladimir could also look at it. >> But now pressure for this. >> >> Thanks, >> Serguei >> >> >> On 11/3/17 17:25, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8059334 >>> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ >>> >>> The CR is closed, so I'll try to explain the issue here. The very >>> short explanation is that the JVMTI test was enabling SINGLE STEP >>> and doing a PopFrame, but the test method managed to get compiled >>> and started executing compiled after the thread was put in "interp >>> only" mode (which should never happen) and before the PopFrame was >>> processed. The cause is a lack of a check for "interp only" mode in >>> the OSR related compilation policy code. >>> >>> Details: >>> >>> The test is testing JVMTI PopFrame support. The test thread has a >>> small method that sits in a tight loop. It will never exit. The main >>> thread enables SINGLE STEP on the test thread, and then does a >>> PopFrame on the test thread to force it out of the looping method. >>> When the test failed due to a time out, I noticed it was still stuck >>> in the small method, even though a PopFrame had been requested. >>> Further, I noticed the method was compiled, so there was no chance >>> the method would ever detect that it should do a PopFrame. Since >>> "interp only" mode for SINGLE STEP had been enabled, the method >>> should not be running compiled, so clearly something went wrong that >>> allowed it to compile and execute. >>> >>> When SINGLE STEP is requested, JVMTI will deopt the topmost method >>> (actually the top 2), put the thread in "interp only" mode, and then >>> has checks to make sure the thread continues to execute interpreted. >>> To avoid compilation when a back branch tries to trigger one, there >>> is a check for "interp only" mode in SimpleThresholdPolicy::event(). >>> If the thread is in "interp only" mode, it will prevent compilation. >>> SimpleThresholdPolicy::event() is called (indirectly) by >>> InterpreterRuntime::frequency_counter_overflow(), which is called >>> from the interpreter when the back branch threshold is reached. >>> >>> After some debugging I noticed when the test timeout happens, >>> "interp only" mode is not yet enabled when >>> InterpreterRuntime::frequency_counter_overflow() is called, but is >>> enabled by the time InterpreterRuntime::frequency_counter_overflow() >>> has done the lookup of the nm. So there is a race here allowing the >>> thread to begin execution in a compiled method even though "interp >>> only" mode is enabled. I think the reason is because we safepoint >>> during the compilation, and this allows a SINGLE STEP request to be >>> processed, which enables "interp only" mode. >>> >>> I should add that initially I only saw this bug with -Xcomp, but >>> eventually realized it was caused by disabling >>> BackgroundCompilation. That makes it much more likely that a SINGLE >>> STEP request will come in and be processed during the call to >>> InterpreterRuntime::frequency_counter_overflow() (because it will >>> block until the compilation completes). >>> >>> I believe for the fix it is enough just to add an "interp only" mode >>> check in InterpreterRuntime::frequency_counter_overflow() after the >>> nm lookup, and set it nm to NULL if we are now in "interp only" >>> mode. If we are not in "interp only" mode at this point (and start >>> executing the compiled method) it should not be possible to enter >>> "interp only" mode until we reach a safepoint at some later time, >>> and at that point the method will be properly deopt so it can >>> execute interpreted. >>> >>> thanks, >>> >>> Chris >>> >> From Derek.White at cavium.com Tue Nov 7 22:34:30 2017 From: Derek.White at cavium.com (White, Derek) Date: Tue, 7 Nov 2017 22:34:30 +0000 Subject: [10] RFR (S): 8189177 - AARCH64: Improve _updateBytesCRC32C intrinsic In-Reply-To: References: <18544a56-5885-784f-b448-7f412861d916@bell-sw.com> Message-ID: Hi Dmitry, This looks good! Thanks, - Derek > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Dmitry Chuyko > Sent: Thursday, November 02, 2017 5:07 PM > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [10] RFR (S): 8189177 - AARCH64: Improve _updateBytesCRC32C > intrinsic > > Similar to CRC32 I added private > MacroAssembler::kernel_crc32c_using_crc32c(). > > webrev: http://cr.openjdk.java.net/~dchuyko/8189177/webrev.01/ > > -Dmitry > > > On 10/20/2017 08:45 PM, Dmitry Chuyko wrote: > > Hello, > > > > Please review an improvement of CRC32C calculation on AArch64. It is > > done pretty similar to a change for JDK-8189176 described in [1]. > > > > MacroAssembler::kernel_crc32c gets unused table registers. They can be > > used to make neighbor loads and CRC calculations independent. Adding > > prologue and epilogue for main by-64 loop makes it applicable starting > > from len=128 so additional by-32 loop is added for smaller lengths. > > > > rfe: https://bugs.openjdk.java.net/browse/JDK-8189177 > > webrev: http://cr.openjdk.java.net/~dchuyko/8189177/webrev.00/ > > benchmark: > > http://cr.openjdk.java.net/~dchuyko/8189177/crc32c/CRC32CBench.java > > > > Results for T88 and A53 [2] are similar to CRC32 change (good), but > > again splitting pair loads may slow down other CPUs so measurements on > > different HW are welcome. > > > > -Dmitry > > > > [1] > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-Octob > > er/027225.html > > [2] > > https://bugs.openjdk.java.net/browse/JDK- > 8189177?focusedCommentId=1412 > > 4535&page=com.atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel#comment-14124535 > > From jamsheed.c.m at oracle.com Wed Nov 8 04:39:23 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Wed, 8 Nov 2017 10:09:23 +0530 Subject: [10] JBS: 8167408: Invalid critical JNI function lookup In-Reply-To: References: <34e7e1e6-09bd-a0c3-d3de-23a825474dbb@oracle.com> <2e195876-97cf-bc1f-5e3b-e19c5c5f240d@oracle.com> Message-ID: Thank you, Vladimir Ivanov Best regards, Jamsheed On Tuesday 07 November 2017 10:00 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 11/3/17 6:06 PM, jamsheed wrote: >> Hi Dean, David, Martin, Vladimir, >> >> incorporated most of the suggestions, let me know if this is ok! >> >> http://cr.openjdk.java.net/~jcm/8167408/webrev.02/ >> >> Best regards >> >> Jamsheed >> >> On Wednesday 01 November 2017 03:58 AM, Vladimir Ivanov wrote: >>> Jamsheed, nice test! >>> >>> 2 suggestions: >>> >>> ? (1) Enable the test on all platforms: though the bug is >>> platform-specific, it doesn't mean the test should be. I don't see >>> any platform-specific code there and it's beneficial to test other >>> platforms as well >>> >>> ? (2) Add some test cases with multiple array parameters. >>> >>> Otherwise, looks good. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/31/17 10:37 PM, jamsheed wrote: >>>> Hi Dean, >>>> >>>> Thank you for the review, >>>> >>>> tested with a test case, previously it was not working for >>>> windows-x86, now it works. >>>> >>>> revised webrev with test >>>> case:http://cr.openjdk.java.net/~jcm/8167408/webrev.01/ >>>> >>>> Best regards, >>>> >>>> Jamsheed >>>> >>>> >>>> On Tuesday 31 October 2017 02:18 AM, dean.long at oracle.com wrote: >>>>> I think you need a native test for Windows x86 that defines >>>>> JavaCritical methods with various signatures (especially arrays) >>>>> to make sure this is working correctly. >>>>> >>>>> dl >>>>> >>>>> >>>>> On 10/30/17 9:45 AM, jamsheed wrote: >>>>>> Hi, >>>>>> >>>>>> request for review, >>>>>> >>>>>> jbs : https://bugs.openjdk.java.net/browse/JDK-8167408 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~jcm/8167408/webrev.00/ >>>>>> >>>>>> (contributed by Ioannis Tsakpinis) >>>>>> >>>>>> desc: >>>>>> >>>>>> -- it starts with JavaCritical_ instead of Java_; >>>>>> -- it does not have extra JNIEnv* and jclass arguments; >>>>>> -- Java arrays are passed in two arguments: the first is an array >>>>>> length, and the second is a pointer to raw array data. That is, >>>>>> no need to call GetArrayElements and friends, you can instantly >>>>>> use a direct array pointer. >>>>>> >>>>>> updated arg_size calculation wrt above points. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Jamsheed >>>>>> >>>>> >>>> >> From tobias.hartmann at oracle.com Wed Nov 8 07:58:21 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 8 Nov 2017 08:58:21 +0100 Subject: [10] RFR(S): 8190797: OSR compilation fails with "assert(__the_thread__->can_call_java()) failed: can not load classes with compiler thread" In-Reply-To: <01dbd4cb-0683-a36d-5ee9-b4950e10c517@oracle.com> References: <9ab0bc1c-605f-7b28-57e9-c522b40ca4c1@oracle.com> <01dbd4cb-0683-a36d-5ee9-b4950e10c517@oracle.com> Message-ID: Hi Vladimir, thanks for the review! Best regards, Tobias On 07.11.2017 19:56, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 11/7/17 4:04 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8190797 >> http://cr.openjdk.java.net/~thartmann/8190797/webrev.00/ >> >> When oop map creation fails, we try to throw a LinkageError to propagate the error message. If this happens in the >> compiler thread (for example, during OSR compilation), we fail because a compiler thread cannot initialize an exception >> object. >> >> I've fixed this by bailing out with a meaningful message in case !Thread::can_call_java(). Please note that even if we >> are able to instantiate an exception, we will still fail with ShouldNotReachHere because compute_map(TRAPS) is called >> with CATCH (see comments in the bug for a detailed explanation). This fix is not about changing this behavior but to >> fail with a meaningful error message during compilation. This should only happen if something is seriously broken (for >> example, incorrect bytecode with -noverify, see TestLinkageErrorInGenerateOopMap). In this case we would probably hit >> other issues as well if we would continue execution. >> >> Thanks, >> Tobias >> From christian.haeubl at oracle.com Wed Nov 8 09:17:33 2017 From: christian.haeubl at oracle.com (Christian Haeubl) Date: Wed, 8 Nov 2017 10:17:33 +0100 Subject: RFR: 8178048: [JVMCI] improve HotSpotResolvedJavaFieldImpl.hashCode() In-Reply-To: References: Message-ID: Graal unit tests & Graal bootstrapping. Besides that, the same code change is also already active for a few month in the JDK 8 that is the foundation for GraalVM. - Christian Am 07.11.2017 um 19:49 schrieb Vladimir Kozlov: > Looks good. What testing was done? > > Thanks, > Vladimir > > On 11/7/17 5:08 AM, Christian Haeubl wrote: >> |Hi, >> >> Please review this small JVMCI change that decreases the probability >> of hashcode collisions.| >> || >> |https://bugs.openjdk.java.net/browse/JDK-8178048| >> |http://cr.openjdk.java.net/~chaeubl/8178048/webrev.001/| >> || >> |- Christian >> >> | From thomas.schatzl at oracle.com Wed Nov 8 13:07:05 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 08 Nov 2017 14:07:05 +0100 Subject: Low-Overhead Heap Profiling In-Reply-To: References: <1497366226.2829.109.camel@oracle.com> <1498215147.2741.34.camel@oracle.com> <044f8c75-72f3-79fd-af47-7ee875c071fd@oracle.com> <23f4e6f5-c94e-01f7-ef1d-5e328d4823c8@oracle.com> <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> Message-ID: <1510146425.3155.11.camel@oracle.com> Hi JC, sorry for the long wait. On Wed, 2017-11-01 at 10:46 -0700, JC Beyler wrote: > Dear all, > > Here is the next webrev: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a/ > > Incremental since the rebase: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14_14a/ > > (I'm still not too familiar with hg so I had to do a fresh rebase so > v14 is once the rebase was done and v14a integrates the changes > requested from Thomas). Yeah, there seem to be something missing in the incremental webrev, but thanks for the effort. > I have also inlined answers to Thomas' email: > > A few minor issues: > ? > > ? - in the declaration of CollectedHeap::sample_allocation, it > > would be nice if the fix_sample_rate parameter would be described - > > it takes a time to figure out what it's used for. I.e. in case an > > allocation goes beyond the sampling watermark, this value which > > represents the amount of overallocation is used to adjust the next > > sampling watermark to sample at the correct rate. > > Something like this - and if what I wrote is incorrect, there is > > even more reason to document it. > > Or maybe just renaming "fix_sample_rate" to something more > > descriptive - but I have no good idea about that. > > With lack of units in the type, it would also be nice to have the > > unit in the identifier name, as done elsewhere. > Thanks. Could you s/passed/past in that documentation? > Done for Robbin's issue and changed it to? > > ? - some (or most actually) of the new setters and getters in the > > ThreadLocalAllocBuffer class could be private I think. Also, we > > typically do not use "simple" getters that just return a member in > > the class where they are defined. > > I removed all that were not used that I could see (not used outside > the class) moved the ones that are not simple to private if they > could be. I think it's a bit weird because now some of the setting of > the tlab internal data is using methods, others are directly setting. > Let me know what you think. That's fine with me. You need to start somewhere I guess. > > ? - ThreadLocalAllocBuffer::pick_next_sample() - I recommend making > > the first check an assert - it seems that it is only useful to call > > this with heap monitoring enabled, as is done right now. > > Longer conversation below about this, It cannot be an assert (I could > remove the test altogether though). I looked at the description, and you are right. I missed that. Keep it as is. :) > > - HeapMonitoring::next_random() - the different names for the > > constants use different formatting. Preferable (to me) is > > UpperCamelCase, but at least make them uniform. > > > > I think done the way you wanted! In heapMonitoring.hpp:50-53 the constants still have different format? ? > > ? > > ? - not really convinced that it is a good idea to not somehow > > guard > > StartHeapSampling() and StopHeapSampling() against being called by > > multiple threads. > > > > I added another mutex for the start/stop so that way it will protect > from that. > Thanks! > ? > > Otherwise looks okay from what I can see. Still okay. I do not need a re-review for the changes suggested in this email. > > Awesome, what do you think I still need for this before going to the > next step (which is what by the way? :)). I think: - look through the JEP if it is still current and fix the descriptions if required - add a link to the latest webrev to the JEP as comment - if not done already, file CSRs [0] for - the new flag - JVMTI changes (I think, not sure actually) - find a sponsor from Oracle to do some internal work (pushing, and before that there is iirc still some background work related to JEPs that can only be done by Oracle, mostly shepherding :/). I talked to Robbin about this, and he offered to help you with that. Thanks, Thomas [0] https://wiki.openjdk.java.net/display/csr/Main From rwestrel at redhat.com Wed Nov 8 15:05:50 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 08 Nov 2017 16:05:50 +0100 Subject: RFR(S): 8190375: Java Crash in JavaBug.formatPos(I)Ljava/lang/String Message-ID: http://cr.openjdk.java.net/~roland/8190375/webrev.00/ Bounds of a counted loop iv can't be reliably determined from the init/limit bounds if the exit condition is "not equal". TestCountedLoopBadIVRange.test1() is an example of that. On first execution of the inner loop the loop runs from j = 0 to j = 4 but on second execution, j = 10 on entry so exit condition j != 5 never triggers and the test in the loop is the one that exits the loop. Current logic sets j to be in [0, 10[ which is incorrect. The fix simply skips the logic that set the value of the Phi iv if the exit condition is "not equal". If init < limit for instance, the existing logic is correct but in that case, when the counted loop is created, the exit test is changed to a greater or less than test. Roland. From daniel.daugherty at oracle.com Wed Nov 8 17:49:43 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Nov 2017 12:49:43 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: Message-ID: <543b5bd6-1f5e-37df-d4fc-199b4e67fca3@oracle.com> Greetings, This code review from Stefan Karlsson was originally posted on an Oracle internal alias that we use for discussing HotSpot SMR development issues. That subject was: "Thread-SMR (8167108)(JDK10): CR round 0 changes". I did not have time to address Stefan's review before I went on vacation and Stefan graciously allowed me to defer his review to the OpenJDK review. With Stefan's permission, I'm replying to his code review on the OpenJDK aliases that we're using for the JDK-8167108 code review. On 10/6/17 1:19 PM, Stefan Karlsson wrote: > Hi Dan, > > Great that this is getting done! Thanks! It has been an adventure for all three primary contributors... > Erik already mentioned the file so I think that's on track, and that's > what I was most concerned about. > > > I have not been involved in the review of this patch at all, but now > that I've been looking at it I have a few comments. I hope you don't > mind. I don't want them to block the open review request, but at the > same time I'd like to share my opinion and have it weighted in for the > future of this code. > > 1) ThreadsListHandle allows a safepoint to block and allow GCs to run > and restructure objects and metadata, iff the ThreadsListHandle is > nested. This forced me to review all usages of ThreadsListHandle in > great detail to visually verify that it didn't break the surrounding code. > > If ThreadsListHandle didn't ever block for safepoints, I wouldn't have > had to care about that aspect when reading and reviewing the code. > This also means that we in the future runs the risk of someone > accidentally adding a nested ThreadsListHandle somewhere where they > don't expect a safepoint to happen. We included the following to automatically sanity check the placement of the ThreadsListHandle: src/hotspot/share/runtime/thread.cpp: 3596 ThreadsList *Threads::acquire_stable_list(Thread *self, bool is_ThreadsListSetter) { 3597?? assert(self != NULL, "sanity check"); 3598?? // acquire_stable_list_nested_path() will grab the Threads_lock 3599?? // so let's make sure the ThreadsListHandle is in a safe place. 3600?? // ThreadsListSetter cannot make this check on this code path. 3601?? debug_only(if (!is_ThreadsListSetter && StrictSafepointChecks) self->check_for_valid_safepoint_state(/* potential_vm_operation */ false);) So each ThreadsListHandle location is checked for being a valid safepoint state. We tested this idea with our work on JvmtiEnv::GetThreadLocalStorage(). GetThreadLocalStorage() is called from the 'in native' state so we cannot place a common ThreadsListHandle for all code paths because it would fail the assertion when called with 'thread == NULL', i.e., the thread is operating on itself. Update: Erik is going to explore a lock free solution for the nesting algorithm. That will likely mean that a ThreadsListHandle will not require placement in a safepoint safe location... > If the lock protecting the threads list could be taken with > no_safepoint_check, then the described problem above would completely > vanish. Unfortunately, we can't acquire the Threads_lock with > no_safepoint_check. A solution to this would be to introduced a > low-rank (rank == access) lock, say ThreadsList_lock, and always take > it with no_safepoint_check. The problem with switching locks is that we are protecting the scanning phase of the SMR algorithm with the Threads_lock so we would have to switch that lock also. I believe we use the Threads_lock with the scanning because we're using closures... Of course, Erik or Robbin should probably jump in here... :-) Update: Erik is going to explore a lock-free solution for the nesting algorithm. > That solution would also solve a potential lock-rank problem, we have > that ThreadsListHandle can't be used if a higher-rank lock is held. So far we haven't run into that problem and we think that the check_for_valid_safepoint_state() will catch that if the code should evolve to introduce one. Update: Erik is going to explore a lock-free solution for the nesting algorithm. > 2) The following one-liner: > - for (JavaThread* t = Threads::first(); t; t = t->next()) { > has been converted to a five-liner: > > + { > + ThreadsListHandle tlh; > + JavaThreadIterator jti(tlh.list()); > + for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { > ... + } I find that unfortunate, and would prefer if this was > rewritten. For example: for (JavaThreadIterator jti; JavaThread* t = > jit.next();) { jti will implicitly hold the ThreadListHandle on the > stack. I know that the implicit conversion of pointer to bool is > non-conventional in the HotSpot code, but in this case I prefer that > over five lines of extra noise in the GC code. Coleen made a similar comment in her OpenJDK review: > Hi,? From my initial look at this, I really like new interface for > walking the threads list, except every instance but 2 uses of > JavaThreadIterator has a preceding ThreadsListHandle declaration. > > +? ThreadsListHandle tlh; > +? JavaThreadIterator jti(tlh.list()); > > > Could there be a wrapper that embeds the ThreadsListHandle, like: > > class JavaThreadsListIterator { > ??? ThreadsListHandle _tlh; > ... > } Yup a definite code noise problem. We originally didn't have an iterator and used direct thread_at(foo) calls so we had a pretty close correspondence between the old for-loop and the new for-loop. Early reviewers asked for an iterator abstraction so we modeled JavaThreadIterator after other existing iterators in the JVM/TI area... (Yes, Dan stayed pretty close to "home" here...) There are places where we still need the existing JavaThreadIterator because a ThreadsList is passed down a call stack... So we've added a JavaThreadIteratorWithHandle class. Here's an example of the noisy code in the GC area: src/hotspot/share/gc/g1/dirtyCardQueue.cpp: @@ -319,8 +320,12 @@ ?? clear(); ?? // Since abandon is done only at safepoints, we can safely manipulate ?? // these queues. -? for (JavaThread* t = Threads::first(); t; t = t->next()) { -??? t->dirty_card_queue().reset(); +? { +??? ThreadsListHandle tlh; +??? JavaThreadIterator jti(tlh.list()); +??? for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { +????? t->dirty_card_queue().reset(); +??? } ?? } ?? shared_dirty_card_queue()->reset(); ?} Here's an example of the revised code in the GC area: src/hotspot/share/gc/g1/dirtyCardQueue.cpp: @@ -319,7 +320,7 @@ ?? clear(); ?? // Since abandon is done only at safepoints, we can safely manipulate ?? // these queues. -? for (JavaThread* t = Threads::first(); t; t = t->next()) { +? for (JavaThreadIteratorWithHandle jtiwh; JavaThread *t = jtiwh.next(); ) { ???? t->dirty_card_queue().reset(); ?? } ?? shared_dirty_card_queue()->reset(); This is definitely much less noisy and I'm hoping I don't catch too much grief for the implied boolean usage... > 3) cv_internal_thread_to_JavaThread Has one return value and two > output parameter. It forces the callers to setup stack lock variables > for the two new variables. --- Used to be --- > - oop java_thread = JNIHandles::resolve_non_null(jthread); > java_lang_Thread::set_priority(java_thread, (ThreadPriority)prio); - > JavaThread* thr = java_lang_Thread::thread(java_thread); - if (thr != > NULL) { // Thread not yet started; priority pushed down when it is - > Thread::set_priority(thr, (ThreadPriority)prio); > --- Now is --- > + oop java_thread = NULL; + JavaThread* receiver = NULL; + bool > is_alive = tlh.cv_internal_thread_to_JavaThread(jthread, &receiver, > &java_thread); java_lang_Thread::set_priority(java_thread, > (ThreadPriority)prio); + + if (is_alive) { + // jthread refers to a > live JavaThread. + Thread::set_priority(receiver, > (ThreadPriority)prio); --- Maybe could be --- > oop java_thread = JNIHandles::resolve_non_null(jthread); > java_lang_Thread::set_priority(java_thread, (ThreadPriority)prio); > JavaThread* thr = tlh.cv_internal_thread_to_JavaThread(java_thread); > if (thr != NULL) { // Thread not yet started; priority pushed down > when it is Thread::set_priority(thr, (ThreadPriority)prio); I don't > see the need to for the extra complexity of the two output parameters. > The return value is always true when thr is non-null, and always false > when thr is null. There are three cv_*_to_JavaThread() functions and we had to craft them very, very carefully to avoid changing some of the subtle semantics at the original call sites. If you carefully examine the output parameters and return value usages at all of the call sites, you'll see that each was added to fit some existing semantic that we didn't want to risk changing. Of course, not all of the call sites need all of the special behaviors individually, but they do as a union. In short, compatibility and risk management led us here. > But the usage of cv_internal_thread_to_JavaThread is contained within > the Runtime code, so my opinion should probably not weigh as much as > other's opinions. :) We definitely agree this is a mess, but not one we're willing to risk changing at this time. Dan has made the observation that the JVM_* entry points, like Y2K code, shows a variety of different coding patterns, each with different (potential) issues... Thanks for being flexible on accepting cv_internal_thread_to_JavaThread() as is for now! > 4) I'd prefer if abbreviations where expanded, so that the casual > reader would immediately understood the code. For example: t_list -> > thread_list cv_internal_thread_to_JavaThread -> > internal_thread_to_JavaThread We've had requests to shorten names, spell out names, use different names, etc. It seems that no one is going to be happy with all of the names we used in this code. Our guidelines: - use the same consistently, e.g., t_list for ThreadsLists - use a name that doesn't show up in an existing grep (if possible) We hope you don't mind, but we're not planning to make any more name changes... > 5) This macro and the jesting is pretty bad. Yup! > I complained about it to Erik, and then he confessed that he wrote it :D > +// Possibly the ugliest for loop the world has seen. C++ does not > allow +// multiple types in the declaration section of the for loop. > In this case +// we are only dealing with pointers and hence can cast > them. It looks ugly +// but macros are ugly and therefore it's fine to > make things absurdly ugly. +#define DO_JAVA_THREADS(LIST, X) \ + for > (JavaThread *MACRO_scan_interval = > (JavaThread*)(uintptr_t)PrefetchScanIntervalInBytes, \ + *MACRO_list = > (JavaThread*)(LIST), \ + **MACRO_end = > ((JavaThread**)((ThreadsList*)MACRO_list)->threads()) + > ((ThreadsList*)MACRO_list)->length(), \ + **MACRO_current_p = > (JavaThread**)((ThreadsList*)MACRO_list)->threads(), \ + *X = > (JavaThread*)prefetch_and_load_ptr((void**)MACRO_current_p, > (intx)MACRO_scan_interval); \ + MACRO_current_p != MACRO_end; \ + > MACRO_current_p++, \ + X = > (JavaThread*)prefetch_and_load_ptr((void**)MACRO_current_p, > (intx)MACRO_scan_interval)) + This can be rewritten without all these > cast, and minimal usage of the macros expansions: struct > JavaThreadPrefetchedIterator { ThreadList* _list; JavaThread** _end; > JavaThread** _current; JavaThreadIteror(ThreadList* list) : > _list(list), _end(list->threads() + list->length()), > _current(list->threads()) {} JavaThread* current() { return > context._current != context._end ?? > prefetch_and_load_ptr(context._current, PrefetchScanIntervalInBytes) > ?: NULL) // ^ prefetch would be rewritten to return JavaThread* and > not void* } void next() { _current++; }; #define DO_JAVA_THREADS(LIST, > X) \ for (JavaThreadPrefetchedIterator iter(LIST); JavaThread* X = > iter.current(); iter.next()) (I did some changes to the code above and > haven't compiled this exact version) Erik hasn't chimed in on this comment so I (Dan) am not planning to try to resolve this comment in this round. Update: Erik is planning to look at cleaning up the ugly macro... > 6) I think it would be nice if the SMR stuff in thread.hpp were > encapsulated into an class instead of added directly to Thread and > Threads. I sort-of expected the SMR variables to be moved to > threadSMR.hpp. For example: > class Threads: AllStatic { friend class VMStructs; private: + // Safe > Memory Reclamation (SMR) support: + static Monitor* _smr_delete_lock; > + // The '_cnt', '_max' and '_times" fields are enabled via + // > -XX:+EnableThreadSMRStatistics: + static uint > _smr_delete_lock_wait_cnt; + static uint _smr_delete_lock_wait_max; + > static volatile int _smr_delete_notify; + static volatile jint > _smr_deleted_thread_cnt; + static volatile jint > _smr_deleted_thread_time_max; + static volatile jint > _smr_deleted_thread_times; + static ThreadsList* volatile > _smr_java_thread_list; + static ThreadsList* > get_smr_java_thread_list() { + return > (ThreadsList*)OrderAccess::load_ptr_acquire((void* > volatile*)&_smr_java_thread_list); + } + static ThreadsList* > xchg_smr_java_thread_list(ThreadsList* new_list) { + return > (ThreadsList*)Atomic::xchg_ptr((void*)new_list, (volatile > void*)&_smr_java_thread_list); + } + static long > _smr_java_thread_list_alloc_cnt; + static long > _smr_java_thread_list_free_cnt; + static uint > _smr_java_thread_list_max; + static uint _smr_nested_thread_list_max; > + static volatile jint _smr_tlh_cnt; + static volatile jint > _smr_tlh_time_max; + static volatile jint _smr_tlh_times; + static > ThreadsList* _smr_to_delete_list; + static uint > _smr_to_delete_list_cnt; + static uint _smr_to_delete_list_max; Could > be: class Threads: AllStatic { friend class VMStructs; private: // > Safe Memory Reclamation (SMR) support: SMRSupport _smr_support; And > SMRSupport could be moved to threadSMR.hpp. I haven't read all the > code in detail, so I'm not sure if this is feasible or not, but my > gut-feeling says that it would be worth testing. The above is just an > example, and the rest of the code could probably be encapsulated and > moved as well. We already moved all of the SMR stuff that was "easy" to move based on your earlier comment. (Of course, doing that move introduced a number of compilation complications, but that's just Dan complaining :-)) We don't really want to try this migration at this time since we're still hoping to get this code into 18.3. (Also Dan doesn't see the value in moving the SMR fields... Threads is already an eclectic static class so why does SMR have to encapsulate when no other project did so?) > 7) Currently, threadSMR.hpp "only" contains the ThreadList. Unless, > you move the SMR stuff into threadSMR.hpp, maybe it should be renamed > to threadsList.hpp? Maybe it does make sense to have both > threadSMR.hpp and threadsList.hpp? We're planning to stick with the threadSMR.hpp and threadSMR.cpp file names. Currently they contain the more standalone pieces of thread SMR (more than just ThreadsList) so we're planning to keep those names. Thanks for the detailed review!! Dan, Erik and Robbin > Cheers and thanks! StefanK -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Nov 8 17:53:22 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Nov 2017 12:53:22 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <2b180329-9cf3-d83b-133b-ddd5d33b4f1f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <2b180329-9cf3-d83b-133b-ddd5d33b4f1f@oracle.com> Message-ID: <10022dbf-74a6-5b38-265e-079ebaad22c8@oracle.com> Added back the other three OpenJDK aliases being used for this review... Coleen, thanks for chiming in on this review thread. Sorry for the delay in responding... I was on vacation... On 10/11/17 11:32 AM, coleen.phillimore at oracle.com wrote: > > Hi,? From my initial look at this, I really like new interface for > walking the threads list, except every instance but 2 uses of > JavaThreadIterator has a preceding ThreadsListHandle declaration. > > +? ThreadsListHandle tlh; > +? JavaThreadIterator jti(tlh.list()); > > > Could there be a wrapper that embeds the ThreadsListHandle, like: > > class JavaThreadsListIterator { > ??? ThreadsListHandle _tlh; > ... > } This issue has been addressed as part of my response to Stefan K's code review comments. I quoted the above comment in that reply so it should be easy to find that resolution... Dan > > Thanks, > Coleen > > On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> We have a (eXtra Large) fix for the following bug: >> >> 8167108 inconsistent handling of SR_lock can lead to crashes >> https://bugs.openjdk.java.net/browse/JDK-8167108 >> >> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >> Hazard Pointers to manage JavaThread lifecycle. >> >> Here's a PDF for the internal wiki that we've been using to describe >> and track the work on this project: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >> >> >> Dan has noticed that the indenting is wrong in some of the code quotes >> in the PDF that are not present in the internal wiki. We don't have a >> solution for that problem yet. >> >> Here's the webrev for current JDK10 version of this fix: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >> >> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >> testing, additional stress testing on Dan's Solaris X64 server, and >> additional testing on Erik and Robbin's machines. >> >> We welcome comments, suggestions and feedback. >> >> Daniel Daugherty >> Erik Osterlund >> Robbin Ehn > From daniel.daugherty at oracle.com Wed Nov 8 18:05:57 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Nov 2017 13:05:57 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> Message-ID: Greetings, Resolving one of the code review comments (from both Stefan K and Coleen) on jdk10-04-full required quite a few changes so it is being done as a standalone patch and corresponding webrevs: Here's the mq comment for the change: ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use ??? JavaThreadIteratorWithHandle. Here is the full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ And here is the delta webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: > Greetings, > > We have a (eXtra Large) fix for the following bug: > > 8167108 inconsistent handling of SR_lock can lead to crashes > https://bugs.openjdk.java.net/browse/JDK-8167108 > > This fix adds a Safe Memory Reclamation (SMR) mechanism based on > Hazard Pointers to manage JavaThread lifecycle. > > Here's a PDF for the internal wiki that we've been using to describe > and track the work on this project: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf > > > Dan has noticed that the indenting is wrong in some of the code quotes > in the PDF that are not present in the internal wiki. We don't have a > solution for that problem yet. > > Here's the webrev for current JDK10 version of this fix: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full > > This fix has been run through many rounds of JPRT and Mach5 tier[2-5] > testing, additional stress testing on Dan's Solaris X64 server, and > additional testing on Erik and Robbin's machines. > > We welcome comments, suggestions and feedback. > > Daniel Daugherty > Erik Osterlund > Robbin Ehn > From vladimir.kozlov at oracle.com Wed Nov 8 18:27:17 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 8 Nov 2017 10:27:17 -0800 Subject: RFR: 8178048: [JVMCI] improve HotSpotResolvedJavaFieldImpl.hashCode() In-Reply-To: References: Message-ID: <8b977de2-7da1-bdbe-6bf2-827fa1c099b4@oracle.com> Good. Thank you. Vladimir On 11/8/17 1:17 AM, Christian Haeubl wrote: > Graal unit tests & Graal bootstrapping. Besides that, the same code change is also already active for a few month in the > JDK 8 that is the foundation for GraalVM. > > - Christian > > > Am 07.11.2017 um 19:49 schrieb Vladimir Kozlov: >> Looks good. What testing was done? >> >> Thanks, >> Vladimir >> >> On 11/7/17 5:08 AM, Christian Haeubl wrote: >>> |Hi, >>> >>> Please review this small JVMCI change that decreases the probability of hashcode collisions.| >>> || >>> |https://bugs.openjdk.java.net/browse/JDK-8178048| >>> |http://cr.openjdk.java.net/~chaeubl/8178048/webrev.001/| >>> || >>> |- Christian >>> >>> | > From daniel.daugherty at oracle.com Wed Nov 8 23:09:41 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Nov 2017 18:09:41 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> Message-ID: <1c0edbe2-1b9c-dc7e-c610-4ea053831790@oracle.com> The jdk10-05-full bits have passed JPRT testing (hs-tier1 testing) and hs-tier[2-5] testing via Mach 5. No unexpected test failures. Dan On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: > Greetings, > > Resolving one of the code review comments (from both Stefan K and Coleen) > on jdk10-04-full required quite a few changes so it is being done as a > standalone patch and corresponding webrevs: > > Here's the mq comment for the change: > > ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use > ??? JavaThreadIteratorWithHandle. > > Here is the full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ > > And here is the delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> We have a (eXtra Large) fix for the following bug: >> >> 8167108 inconsistent handling of SR_lock can lead to crashes >> https://bugs.openjdk.java.net/browse/JDK-8167108 >> >> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >> Hazard Pointers to manage JavaThread lifecycle. >> >> Here's a PDF for the internal wiki that we've been using to describe >> and track the work on this project: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >> >> >> Dan has noticed that the indenting is wrong in some of the code quotes >> in the PDF that are not present in the internal wiki. We don't have a >> solution for that problem yet. >> >> Here's the webrev for current JDK10 version of this fix: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >> >> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >> testing, additional stress testing on Dan's Solaris X64 server, and >> additional testing on Erik and Robbin's machines. >> >> We welcome comments, suggestions and feedback. >> >> Daniel Daugherty >> Erik Osterlund >> Robbin Ehn >> > > From rwestrel at redhat.com Thu Nov 9 14:56:41 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 09 Nov 2017 15:56:41 +0100 Subject: RFR(S): 8186125: "DU iteration must converge quickly" assert in split if with unsafe accesses In-Reply-To: <1c9df7df-9455-9e75-4918-635f95ac712b@oracle.com> References: <1c9df7df-9455-9e75-4918-635f95ac712b@oracle.com> Message-ID: > What did you run to catch this problem? Forgot to answer that question: I think it was with the lucene test suite. Roland. From vladimir.kozlov at oracle.com Thu Nov 9 20:40:10 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 9 Nov 2017 12:40:10 -0800 Subject: RFR(S): 8186125: "DU iteration must converge quickly" assert in split if with unsafe accesses In-Reply-To: References: <1c9df7df-9455-9e75-4918-635f95ac712b@oracle.com> Message-ID: <7278ed0a-a571-a3df-749c-b1121e3bc011@oracle.com> Thanks. I will add it to bug report. Tests passed I will push changes. Vladimir On 11/9/17 6:56 AM, Roland Westrelin wrote: > >> What did you run to catch this problem? > > Forgot to answer that question: I think it was with the lucene test > suite. > > Roland. > From tobias.hartmann at oracle.com Fri Nov 10 08:35:52 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 10 Nov 2017 09:35:52 +0100 Subject: [10] RFR(S): 8190797: OSR compilation fails with "assert(__the_thread__->can_call_java()) failed: can not load classes with compiler thread" In-Reply-To: References: <9ab0bc1c-605f-7b28-57e9-c522b40ca4c1@oracle.com> <01dbd4cb-0683-a36d-5ee9-b4950e10c517@oracle.com> Message-ID: <34b31a7b-aacf-c12c-85b2-2a917d6ffa42@oracle.com> Hi, could I please get a second review from the runtime team? Thanks, Tobias On 08.11.2017 08:58, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > Best regards, > Tobias > > On 07.11.2017 19:56, Vladimir Kozlov wrote: >> Looks good. >> >> Thanks, >> Vladimir >> >> On 11/7/17 4:04 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8190797 >>> http://cr.openjdk.java.net/~thartmann/8190797/webrev.00/ >>> >>> When oop map creation fails, we try to throw a LinkageError to propagate the error message. If this happens in the >>> compiler thread (for example, during OSR compilation), we fail because a compiler thread cannot initialize an exception >>> object. >>> >>> I've fixed this by bailing out with a meaningful message in case !Thread::can_call_java(). Please note that even if we >>> are able to instantiate an exception, we will still fail with ShouldNotReachHere because compute_map(TRAPS) is called >>> with CATCH (see comments in the bug for a detailed explanation). This fix is not about changing this behavior but to >>> fail with a meaningful error message during compilation. This should only happen if something is seriously broken (for >>> example, incorrect bytecode with -noverify, see TestLinkageErrorInGenerateOopMap). In this case we would probably hit >>> other issues as well if we would continue execution. >>> >>> Thanks, >>> Tobias >>> From tobias.hartmann at oracle.com Fri Nov 10 11:49:59 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 10 Nov 2017 12:49:59 +0100 Subject: RFR(S): 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a crash or exception when using EnableJVMCI but not UseJVMCICompiler In-Reply-To: <013a0b42-152c-1c6f-fe8b-f72aaae1b449@oracle.com> References: <013a0b42-152c-1c6f-fe8b-f72aaae1b449@oracle.com> Message-ID: Hi Gilles, looks good to me as well. Thanks, Tobias On 06.11.2017 15:40, Gilles Duboscq wrote: > Please review the following fix for deoptimization when using +EnableJVMCI and -UseJVMCICompiler. > In this mode there can still be methods compiled by JVMCI so the interpreter needs to support potential pending monitors. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8182755 > Webrev: http://cr.openjdk.java.net/~gdub/webrev-8182755/ > > Gilles > From david.holmes at oracle.com Fri Nov 10 12:00:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Nov 2017 22:00:21 +1000 Subject: [10] RFR(S): 8190797: OSR compilation fails with "assert(__the_thread__->can_call_java()) failed: can not load classes with compiler thread" In-Reply-To: <34b31a7b-aacf-c12c-85b2-2a917d6ffa42@oracle.com> References: <9ab0bc1c-605f-7b28-57e9-c522b40ca4c1@oracle.com> <01dbd4cb-0683-a36d-5ee9-b4950e10c517@oracle.com> <34b31a7b-aacf-c12c-85b2-2a917d6ffa42@oracle.com> Message-ID: <44af395f-5614-778a-63e4-e122af6300a7@oracle.com> On 10/11/2017 6:35 PM, Tobias Hartmann wrote: > Hi, > > could I please get a second review from the runtime team? Reviewed. Thanks, David PS. Never knew that -noverify existed as an alias for -Xverify:none :) > Thanks, > Tobias > > On 08.11.2017 08:58, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> Best regards, >> Tobias >> >> On 07.11.2017 19:56, Vladimir Kozlov wrote: >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/7/17 4:04 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> https://bugs.openjdk.java.net/browse/JDK-8190797 >>>> http://cr.openjdk.java.net/~thartmann/8190797/webrev.00/ >>>> >>>> When oop map creation fails, we try to throw a LinkageError to propagate the error message. If this happens in the >>>> compiler thread (for example, during OSR compilation), we fail because a compiler thread cannot initialize an exception >>>> object. >>>> >>>> I've fixed this by bailing out with a meaningful message in case !Thread::can_call_java(). Please note that even if we >>>> are able to instantiate an exception, we will still fail with ShouldNotReachHere because compute_map(TRAPS) is called >>>> with CATCH (see comments in the bug for a detailed explanation). This fix is not about changing this behavior but to >>>> fail with a meaningful error message during compilation. This should only happen if something is seriously broken (for >>>> example, incorrect bytecode with -noverify, see TestLinkageErrorInGenerateOopMap). In this case we would probably hit >>>> other issues as well if we would continue execution. >>>> >>>> Thanks, >>>> Tobias >>>> From tobias.hartmann at oracle.com Fri Nov 10 12:08:24 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 10 Nov 2017 13:08:24 +0100 Subject: [10] RFR(S): 8190797: OSR compilation fails with "assert(__the_thread__->can_call_java()) failed: can not load classes with compiler thread" In-Reply-To: <44af395f-5614-778a-63e4-e122af6300a7@oracle.com> References: <9ab0bc1c-605f-7b28-57e9-c522b40ca4c1@oracle.com> <01dbd4cb-0683-a36d-5ee9-b4950e10c517@oracle.com> <34b31a7b-aacf-c12c-85b2-2a917d6ffa42@oracle.com> <44af395f-5614-778a-63e4-e122af6300a7@oracle.com> Message-ID: Hi David, On 10.11.2017 13:00, David Holmes wrote: > Reviewed. Thank you! Best regards, Tobias From nils.eliasson at oracle.com Fri Nov 10 12:57:42 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 10 Nov 2017 13:57:42 +0100 Subject: RFR(XS): 8160548: Inconsistent inlining behavior with CompileOnly Message-ID: Hi, This patch fixes a problem with inconsistent inlining behavior when using CompileCommand compileonly flag. InlineTree::check_can_parse(ciMethod* callee) checks the callee->can_be_compiled(), which is a wrapper of ciMethod _is_c1_compilable/_is_c2_compilable boolean fields. Those fields are set 1) by Compilecommands that prohibit compilation (compileonly and exclude) at first compilation, or 2) by a compiler when a method is failing compilation. Because of this, a method may be inlinable before it is has been compiled itself, but not after. This can cause unexpected problems in test that rely on compilecommands for inlining and compilation decisions. But... there are two sides too this: 1) It is incorrect since a method may still be inlined even though it shouldn't be compiled. 2) It is correct, because we don't want to inline methods that failed an earlier compilation. In this patch I have settled with solving problem description (1) while noting that it may cause some extra compilations that bailout because of (2), but will still function correctly. Bug: https://bugs.openjdk.java.net/browse/JDK-8160548 Webrev: http://cr.openjdk.java.net/~neliasso/8160548/webrev.01/ Please review, Nils Eliasson From nils.eliasson at oracle.com Fri Nov 10 13:31:31 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 10 Nov 2017 14:31:31 +0100 Subject: RFR(XS): 8065838: compiler/relocations/TestPrintRelocations.java times out after 1920 seconds Message-ID: Hi, Please review this quick fix of test that unnecessarily consumes far to much resources. This test combines the use of -XX:+PrintRelocation and -Xcomp which causes more than 600.000 lines of output even with an empty main method. My quick fix is to exclude most methods for compilation. Adding "-XX:CompileCommand=compileonly,java.lang.String*::*" reduces the output to ~15.000 lines, and compilations from 3440 to 170, while we still can be certain that at selection of methods are compiled at all compilation levels. The execution time is reduced from 18 to 1 second on my workstation. Bug: https://bugs.openjdk.java.net/browse/JDK-8065838 Webrev: http://cr.openjdk.java.net/~neliasso/8065838/webrev.01/ Regards, Nils Eliasson From tobias.hartmann at oracle.com Fri Nov 10 13:38:50 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 10 Nov 2017 14:38:50 +0100 Subject: RFR(XS): 8065838: compiler/relocations/TestPrintRelocations.java times out after 1920 seconds In-Reply-To: References: Message-ID: <85f50509-1b04-4503-4f49-2fd79240883c@oracle.com> Hi Nils, this looks good to me! Best regards, Tobias On 10.11.2017 14:31, Nils Eliasson wrote: > Hi, > > Please review this quick fix of test that unnecessarily consumes far to much resources. > > This test combines the use of -XX:+PrintRelocation and -Xcomp which causes more than 600.000 lines of output even with > an empty main method. > > My quick fix is to exclude most methods for compilation. Adding "-XX:CompileCommand=compileonly,java.lang.String*::*" > reduces the output to ~15.000 lines, and compilations from 3440 to 170, while we still can be certain that at selection > of methods are compiled at all compilation levels. The execution time is reduced from 18 to 1 second on my workstation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065838 > > Webrev: http://cr.openjdk.java.net/~neliasso/8065838/webrev.01/ > > Regards, > > Nils Eliasson > From tobias.hartmann at oracle.com Fri Nov 10 13:43:39 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 10 Nov 2017 14:43:39 +0100 Subject: RFR(XS): 8160548: Inconsistent inlining behavior with CompileOnly In-Reply-To: References: Message-ID: <5a556461-5013-f22b-d792-325edb847e41@oracle.com> Hi Nils, this looks reasonable to me. Best regards, Tobias On 10.11.2017 13:57, Nils Eliasson wrote: > Hi, > > This patch fixes a problem with inconsistent inlining behavior when using CompileCommand compileonly flag. > > InlineTree::check_can_parse(ciMethod* callee) checks the callee->can_be_compiled(), which is a wrapper of ciMethod > _is_c1_compilable/_is_c2_compilable boolean fields. Those fields are set 1) by Compilecommands that prohibit compilation > (compileonly and exclude) at first compilation, or 2) by a compiler when a method is failing compilation. > > Because of this, a method may be inlinable before it is has been compiled itself, but not after. This can cause > unexpected problems in test that rely on compilecommands for inlining and compilation decisions. > > But... there are two sides too this: > > 1) It is incorrect since a method may still be inlined even though it shouldn't be compiled. > > 2) It is correct, because we don't want to inline methods that failed an earlier compilation. > > In this patch I have settled with solving problem description (1) while noting that it may cause some extra compilations > that bailout because of (2), but will still function correctly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160548 > > Webrev: http://cr.openjdk.java.net/~neliasso/8160548/webrev.01/ > > Please review, > > Nils Eliasson > > From dmitrij.pochepko at bell-sw.com Fri Nov 10 14:19:00 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 10 Nov 2017 17:19:00 +0300 Subject: [aarch64-port-dev ] [10] RFR: 8187472 - AARCH64: array_equals intrinsic doesn't use prefetch for large arrays In-Reply-To: <47181509391125@web22j.yandex.ru> References: <99ecb097-c382-47a0-48db-be85310c1d9d@bell-sw.com> <8e14d691-8edd-27fd-4687-4f1971daf2ea@redhat.com> <8144c663-ea6b-8d21-384b-baeb79f596c4@bell-sw.com> <47fb00b1-c51a-03d8-83f8-9c7cbd436f74@redhat.com> <47181509391125@web22j.yandex.ru> Message-ID: Hi, please take a look at merged simd/non-simd version. I've set ergonomics to use non-simd version on ThunderX, because simd is about 15% slower there. R-Pi shows about the same results for both versions. webrev: http://cr.openjdk.java.net/~dpochepk/8187472/webrev.02/ Thanks, Dmitrij On 30.10.2017 22:18, dmitrij.pochepko at bell-sw.com wrote: > > ok, I'll create a merged version before sending this to review. Thanks > for the feedback! > > 21:06, 30 ??????? 2017 ?., Andrew Haley : > > On 30/10/17 18:03, Dmitrij Pochepko wrote: > > ?I am hesitant if it is best to do this, or keep a single, > simple, and > ?fastest version for now for this intrinsic, and get back to > it when SVE > ?becomes widely available. > > ?What do you think? > > > Do it now, or we'll have merge problems later. > > ?Note that other intrinsics that are in the works will use SIMD. > > > OK, thanks. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > > -- > ?????????? ?? ?????????? ?????????? ??????.????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.eliasson at oracle.com Fri Nov 10 14:20:45 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 10 Nov 2017 15:20:45 +0100 Subject: RFR(XS): 8160548: Inconsistent inlining behavior with CompileOnly In-Reply-To: <5a556461-5013-f22b-d792-325edb847e41@oracle.com> References: <5a556461-5013-f22b-d792-325edb847e41@oracle.com> Message-ID: <020f4ba8-0cd3-4645-92d3-1eaae970ef36@oracle.com> Thank you Tobias, I might add that in the future we might want to split ciMethod::_is_c*_compilable into separate fields for compilations bailouts and compile command exclusions. I'll add the test results to the bug when they are complete. Regards, Nils Eliasson On 2017-11-10 14:43, Tobias Hartmann wrote: > Hi Nils, > > this looks reasonable to me. > > Best regards, > Tobias > > On 10.11.2017 13:57, Nils Eliasson wrote: >> Hi, >> >> This patch fixes a problem with inconsistent inlining behavior when using CompileCommand compileonly flag. >> >> InlineTree::check_can_parse(ciMethod* callee) checks the callee->can_be_compiled(), which is a wrapper of ciMethod >> _is_c1_compilable/_is_c2_compilable boolean fields. Those fields are set 1) by Compilecommands that prohibit compilation >> (compileonly and exclude) at first compilation, or 2) by a compiler when a method is failing compilation. >> >> Because of this, a method may be inlinable before it is has been compiled itself, but not after. This can cause >> unexpected problems in test that rely on compilecommands for inlining and compilation decisions. >> >> But... there are two sides too this: >> >> 1) It is incorrect since a method may still be inlined even though it shouldn't be compiled. >> >> 2) It is correct, because we don't want to inline methods that failed an earlier compilation. >> >> In this patch I have settled with solving problem description (1) while noting that it may cause some extra compilations >> that bailout because of (2), but will still function correctly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8160548 >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8160548/webrev.01/ >> >> Please review, >> >> Nils Eliasson >> >> From nils.eliasson at oracle.com Fri Nov 10 14:21:24 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 10 Nov 2017 15:21:24 +0100 Subject: RFR(XS): 8065838: compiler/relocations/TestPrintRelocations.java times out after 1920 seconds In-Reply-To: <85f50509-1b04-4503-4f49-2fd79240883c@oracle.com> References: <85f50509-1b04-4503-4f49-2fd79240883c@oracle.com> Message-ID: <39cbb0eb-65fc-ad89-c581-d7c5ec3ece22@oracle.com> Thank you Tobias! // Nils On 2017-11-10 14:38, Tobias Hartmann wrote: > Hi Nils, > > this looks good to me! > > Best regards, > Tobias > > On 10.11.2017 14:31, Nils Eliasson wrote: >> Hi, >> >> Please review this quick fix of test that unnecessarily consumes far to much resources. >> >> This test combines the use of -XX:+PrintRelocation and -Xcomp which causes more than 600.000 lines of output even with >> an empty main method. >> >> My quick fix is to exclude most methods for compilation. Adding "-XX:CompileCommand=compileonly,java.lang.String*::*" >> reduces the output to ~15.000 lines, and compilations from 3440 to 170, while we still can be certain that at selection >> of methods are compiled at all compilation levels. The execution time is reduced from 18 to 1 second on my workstation. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065838 >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8065838/webrev.01/ >> >> Regards, >> >> Nils Eliasson >> From aph at redhat.com Fri Nov 10 14:28:23 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Nov 2017 14:28:23 +0000 Subject: [aarch64-port-dev ] [10] RFR: 8187472 - AARCH64: array_equals intrinsic doesn't use prefetch for large arrays In-Reply-To: References: <99ecb097-c382-47a0-48db-be85310c1d9d@bell-sw.com> <8e14d691-8edd-27fd-4687-4f1971daf2ea@redhat.com> <8144c663-ea6b-8d21-384b-baeb79f596c4@bell-sw.com> <47fb00b1-c51a-03d8-83f8-9c7cbd436f74@redhat.com> <47181509391125@web22j.yandex.ru> Message-ID: On 10/11/17 14:19, Dmitrij Pochepko wrote: > please take a look at merged simd/non-simd version. + if (UseSIMDForArrayEquals) { + __ ld1(v0, v1, v2, v3, __ T2D, Address(__ post(a1, 64))); + __ ld1(v4, v5, v6, v7, __ T2D, Address(__ post(a2, 64))); Is this post-increment correct? It should be a multiple of wordSize. Also, the indentation in generate_large_array_equals is wrong. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Fri Nov 10 14:52:40 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 10 Nov 2017 17:52:40 +0300 Subject: [aarch64-port-dev ] [10] RFR: 8187472 - AARCH64: array_equals intrinsic doesn't use prefetch for large arrays In-Reply-To: References: <99ecb097-c382-47a0-48db-be85310c1d9d@bell-sw.com> <8e14d691-8edd-27fd-4687-4f1971daf2ea@redhat.com> <8144c663-ea6b-8d21-384b-baeb79f596c4@bell-sw.com> <47fb00b1-c51a-03d8-83f8-9c7cbd436f74@redhat.com> <47181509391125@web22j.yandex.ru> Message-ID: On 10.11.2017 17:28, Andrew Haley wrote: > On 10/11/17 14:19, Dmitrij Pochepko wrote: > >> please take a look at merged simd/non-simd version. > + if (UseSIMDForArrayEquals) { > + __ ld1(v0, v1, v2, v3, __ T2D, Address(__ post(a1, 64))); > + __ ld1(v4, v5, v6, v7, __ T2D, Address(__ post(a2, 64))); > > Is this post-increment correct? It should be a multiple of wordSize. It's correct, since we're loading 4x128-bit registers, which is 64 bytes. But I've changed it to "4 * 2 * wordSize", which has the same value. > > Also, the indentation in generate_large_array_equals is wrong. > Thank you for noticing it. Please take a look at http://cr.openjdk.java.net/~dpochepk/8187472/webrev.03/ Thanks, Dmitrij From dean.long at oracle.com Fri Nov 10 20:38:39 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 10 Nov 2017 12:38:39 -0800 Subject: RFR(XS): 8065838: compiler/relocations/TestPrintRelocations.java times out after 1920 seconds In-Reply-To: References: Message-ID: <80b02548-8aa9-0b3d-d39e-d1dc362a7942@oracle.com> As a followup RFE, what if we had something like -XX:CompileCommand=eagercompile,java.lang.String*::* that could be used instead of -Xcomp? It would be like -Xcomp for methods matching the filter.? But unlike -Xcomp+compileonly, it would allow other hot methods to be compiled as needed, instead of forcing them to be interpreted. dl On 11/10/17 5:31 AM, Nils Eliasson wrote: > Hi, > > Please review this quick fix of test that unnecessarily consumes far > to much resources. > > This test combines the use of -XX:+PrintRelocation and -Xcomp which > causes more than 600.000 lines of output even with an empty main method. > > My quick fix is to exclude most methods for compilation. Adding > "-XX:CompileCommand=compileonly,java.lang.String*::*" reduces the > output to ~15.000 lines, and compilations from 3440 to 170, while we > still can be certain that at selection of methods are compiled at all > compilation levels. The execution time is reduced from 18 to 1 second > on my workstation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065838 > > Webrev: http://cr.openjdk.java.net/~neliasso/8065838/webrev.01/ > > Regards, > > Nils Eliasson > From vladimir.kozlov at oracle.com Sat Nov 11 05:52:32 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Nov 2017 21:52:32 -0800 Subject: RFR(XS): 8065838: compiler/relocations/TestPrintRelocations.java times out after 1920 seconds In-Reply-To: <85f50509-1b04-4503-4f49-2fd79240883c@oracle.com> References: <85f50509-1b04-4503-4f49-2fd79240883c@oracle.com> Message-ID: <16e928d0-e3ad-520f-c6a1-865aeef969ae@oracle.com> +1 Thanks, Vladimir On 11/10/17 5:38 AM, Tobias Hartmann wrote: > Hi Nils, > > this looks good to me! > > Best regards, > Tobias > > On 10.11.2017 14:31, Nils Eliasson wrote: >> Hi, >> >> Please review this quick fix of test that unnecessarily consumes far to much resources. >> >> This test combines the use of -XX:+PrintRelocation and -Xcomp which causes more than 600.000 lines of output even with >> an empty main method. >> >> My quick fix is to exclude most methods for compilation. Adding "-XX:CompileCommand=compileonly,java.lang.String*::*" >> reduces the output to ~15.000 lines, and compilations from 3440 to 170, while we still can be certain that at selection >> of methods are compiled at all compilation levels. The execution time is reduced from 18 to 1 second on my workstation. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065838 >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8065838/webrev.01/ >> >> Regards, >> >> Nils Eliasson >> From dmitry.samersoff at bell-sw.com Sun Nov 12 17:35:08 2017 From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff) Date: Sun, 12 Nov 2017 20:35:08 +0300 Subject: [10] RFR (S): 8189177 - AARCH64: Improve _updateBytesCRC32C intrinsic In-Reply-To: References: <18544a56-5885-784f-b448-7f412861d916@bell-sw.com> Message-ID: <933b7886-2459-3572-3996-33ff026b8eea@bell-sw.com> Dmitry, Looks good to me. -Dmitry On 11/08/2017 01:34 AM, White, Derek wrote: > Hi Dmitry, > > This looks good! > > Thanks, > > - Derek > >> -----Original Message----- >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >> bounces at openjdk.java.net] On Behalf Of Dmitry Chuyko >> Sent: Thursday, November 02, 2017 5:07 PM >> To: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: [10] RFR (S): 8189177 - AARCH64: Improve _updateBytesCRC32C >> intrinsic >> >> Similar to CRC32 I added private >> MacroAssembler::kernel_crc32c_using_crc32c(). >> >> webrev: http://cr.openjdk.java.net/~dchuyko/8189177/webrev.01/ >> >> -Dmitry >> >> >> On 10/20/2017 08:45 PM, Dmitry Chuyko wrote: >>> Hello, >>> >>> Please review an improvement of CRC32C calculation on AArch64. It is >>> done pretty similar to a change for JDK-8189176 described in [1]. >>> >>> MacroAssembler::kernel_crc32c gets unused table registers. They can be >>> used to make neighbor loads and CRC calculations independent. Adding >>> prologue and epilogue for main by-64 loop makes it applicable starting >>> from len=128 so additional by-32 loop is added for smaller lengths. >>> >>> rfe: https://bugs.openjdk.java.net/browse/JDK-8189177 >>> webrev: http://cr.openjdk.java.net/~dchuyko/8189177/webrev.00/ >>> benchmark: >>> http://cr.openjdk.java.net/~dchuyko/8189177/crc32c/CRC32CBench.java >>> >>> Results for T88 and A53 [2] are similar to CRC32 change (good), but >>> again splitting pair loads may slow down other CPUs so measurements on >>> different HW are welcome. >>> >>> -Dmitry >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-Octob >>> er/027225.html >>> [2] >>> https://bugs.openjdk.java.net/browse/JDK- >> 8189177?focusedCommentId=1412 >>> 4535&page=com.atlassian.jira.plugin.system.issuetabpanels:comment- >> tabpanel#comment-14124535 >>> > From rahul.v.raghavan at oracle.com Mon Nov 13 08:59:19 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 13 Nov 2017 14:29:19 +0530 Subject: [10] RFR: 8182037: wrong ResourceMark in Method::print_short_name() Message-ID: <98a5b61b-d971-6b13-6ec1-cbd65ea091aa@oracle.com> Hi, Request help reviewing proposed fix for 8182037. jbs - https://bugs.openjdk.java.net/browse/JDK-8182037 webrev.01 - http://cr.openjdk.java.net/~rraghavan/8182037/webrev.01/ Notes / jbs extract - -- "void Method::print_short_name(outputStream* st) { ResourceMark rm; breaks if st is not tty and buffer grows under the ResourceMark" -- "All the printing functions that take an outputStream could potentially have this problem. The caller should have the ResourceMark." -- "All but a couple of the calls to method->print_short_name() are in compiler code, so reassigning to the compiler." -- To fix the issue - Removed ResourceMark from following printing functions - Method::print_short_name(outputStream* st) Method::print_name(outputStream* st) Method::print_on(outputStream* st) - checked usages of above functions and added ResourceMark to the callers. (Mach5 testing in progress) So can this be the correct fix? please tell if I missed some point here. Thanks, Rahul From goetz.lindenmaier at sap.com Mon Nov 13 11:48:22 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 Nov 2017 11:48:22 +0000 Subject: RFR(L): 8189793: [s390]: Improve String compress/inflate by exploiting vector instructions In-Reply-To: <7702F170-B574-4EF8-8B85-B366B507E7B0@sap.com> References: <18ddb703d81a4a22bc97f134dd276eff@sap.com> <6F73CAE2-2FEC-4BC0-9F3A-FEE9748EB694@sap.com> <02fe90a2093144b6a2a1ec0020d9b88f@sap.com> <7702F170-B574-4EF8-8B85-B366B507E7B0@sap.com> Message-ID: <2f718b251d5d4a5bac81dc85eb0644ed@sap.com> Hi Lutz, thanks for the numbers and for the two fixes. Change looks good now. The numbers indicate that deflation of constant strings at compile time would make sense, as well as optimizing compress for large strings. (if jvm2008 is representative, but I assume it's good enough). Best regards, Goetz. > -----Original Message----- > From: Schmidt, Lutz > Sent: Freitag, 3. November 2017 17:46 > To: Lindenmaier, Goetz ; Doerr, Martin > ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(L): 8189793: [s390]: Improve String compress/inflate by > exploiting vector instructions > > Hi Goetz, > > I agree. Knowing the string length greatly helps to optimize the generated > code, both in terms of size and performance. There are no compress calls > with constant length, though. Constant strings are stored compressed at > compile time. > > Here are some counters I found when running (a subset of) the SPECjvm2008 > suite: > string_compress match count: 11 > string_inflate match count: 171 > string_inflate_const: > len = 1: 10 matches > len = 2: 2 matches > len = 4: 3 matches > len = 6: 9 matches > len = 7: 3 matches > len = 9: 4 matches > len = 10: 5 matches > len = 11: 15 matches > len = 15: 1 matches > len = 17: 1 matches > len = 18: 2 matches > len = 19: 2 matches > len = 29: 1 matches > len = 31: 1 matches > > These (rather few) matches handle a lot of compress/inflate operations: > n #compress #inflate > <16 673 Mio 2895 Mio > <256 207 Mio 704 Mio > <4096 0.7 Mio 1.8 Mio > >=4096 1.1 Mio 0.3 Mio > > > A short not on performance gains: > I have done a lot of performance tests in different settings. With complex > tests, like SPECjvm2008, the positive (or negative) effect of such low-level > optimizations disappears in measurement noise. With a micro benchmark, > just compressing and inflating a string, some effect is visible: > > My new, improved implementation of the intrinsics shows a slight > performance advantage of 1..4% for short strings. Once the vector > instructions kick in (at len >= 32), performance improves by 50..70% for > string_compress and by 50..150% for string_inflate. Measurements show a > high variance, despite testing was done on a system with dedicated cpu > resources and with no concurrent load. > > BTW, there is a new webrev at > http://cr.openjdk.java.net/~lucy/webrevs/8189793.01/index.html > > In addition to the changes mentioned below, it contains two minor, > nevertheless important fixes to the compress intrinsic: > 1) z_bru(skipShortcut); is changed to z_brh(skipShortcut); > 2) Code is added after label ScalarShortcut to check for zero length strings. > > Regards, > Lutz > > > > > On 03.11.2017, 12:44, "Lindenmaier, Goetz" > wrote: > > Hi Lutz, > > I have been looking at your change. I think it's a good idea to match > for constant string length. I did this for the ppc string intrinsics in the > past. > I remember that distribution of constant strings was quite uneven. > StrIndexOf appeared with constant lengths a lot, StrEquals and StrComp > didn't. > > Do you have any data on how often the new match rules match? > > Actually, if there is a constant string deflated, a platform independent > optimization could compute that at compile time, but that's a different > issue ... > > Best regards, > Goetz. > > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > > Sent: Freitag, 27. Oktober 2017 13:07 > > To: Doerr, Martin ; hotspot-compiler- > > dev at openjdk.java.net > > Subject: Re: RFR(L): 8189793: [s390]: Improve String compress/inflate by > > exploiting vector instructions > > > > Hi Martin, > > > > > > > > Thanks for reviewing my change! > > > > > > > > This is a preliminary response just to let you know I?m working on the > > change. I?m putting a lot of effort in producing reliable performance > > measurement data. Turns out this is not easy (to be more honest: almost > > impossible). > > > > > > > > s390.ad: > > > > You are absolutely right, the sequence load_const/string_compress > makes > > no sense at all. But it does not hurt either ? I could not find one match in > all > > tests I ran. -> Match rule deleted. > > > > > > > > macroAssembler_s390: > > > > prefetch: did not see impact, neither positive nor negative. Artificial > micro > > benchmarks will not benefit (data is in cache anyway). More complex > > benchmarks show measurement noise which covers the possible > prefetch > > benefit. -> prefetch deleted. > > > > Hardcoded vector registers: you are right. There are some design > decisions > > pending, e.g. how many vector scratch registers? > > > > Vperm instruction: using that is just another implementation variant that > > could save the vn vector instruction. On the other hand, loading the > index > > vector is a (compared to vgmh) costly memory access. Given the fact that > we > > mostly deal with short strings, initialization effort is relevant. > > > > Code size vs. performance: the old, well known, often discussed > tradeoff. > > Starting from the existing implementation, I invested quite some time in > > optimizing the (len <= 8) cases. With every refinement step I saw (or > > believed to see (measurement noise)) some improvement ? or > discarded it. > > Is the overall improvement worth the larger code size? -> tradeoff, > > discussion. > > > > > > > > Best Regards, > > > > Lutz > > > > > > > > > > > > > > > > On 25.10.2017, 21:08, "Doerr, Martin" > > wrote: > > > > > > > > Hi Lutz, > > > > > > > > thanks for working on vector-based enhancements and for providing this > > webrev. > > > > > > > > assembler_s390: > > > > -The changes in the assembler look good. > > > > > > > > s390.ad: > > > > -It doesn't make sense to load constant len to a register and generate > > complex compare instructions for it and still to emit code for all cases. I > > assume that e.g. the 4 characters cases usually have a constant length. If > so, > > much better code could be generated for them by omitting all the stuff > > around the simple instructions. (ppc64.ad already contains nodes for > > constant length of needle in indexOf rules.) > > > > > > > > macroAssembler_s390: > > > > -Are you sure the prefetch instructions improve performance? > > > > I remember that we had them in other String intrinsics but removed > them > > again as they showed absolutely no performance gain. > > > > -Comment: Using hardcoded vector registers is ok for now, but may need > to > > get changed e.g. when using them for C2's SuperWord optimization. > > > > -Comment: You could use the vperm instruction instead of vo+vn, but I'm > ok > > with the current implementation because loading a mask is much more > > convenient than getting the permutation vector loaded (e.g. from > constant > > pool or pc relative). > > > > -So the new vector loop looks good to me. > > > > -In my opinion, the size of all the generated cases should be in > relationship to > > their performance benefit. > > > > As intrinsics are not like stubs and may get inlined often, I can't get rid of > the > > impression that generating so large code wastes valuable code cache > space > > with questionable performance gain in real world scenarios. > > > > > > > > Best regards, > > > > Martin > > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > > Sent: Mittwoch, 25. Oktober 2017 12:02 > > To: hotspot-compiler-dev at openjdk.java.net > > Subject: RFR(L): 8189793: [s390]: Improve String compress/inflate by > > exploiting vector instructions > > > > > > > > Dear all, > > > > > > > > I would like to request reviews for this s390-only enhancement: > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189793 > > > > Webrev: > http://cr.openjdk.java.net/~lucy/webrevs/8189793.00/index.html > > > > > > > > Vector instructions, which have been available on System z for a while > (since > > z13), promise noticeable performance improvements. This enhancement > > improves the String Compress and String Inflate intrinsics by exploiting > vector > > instructions, when available. For long strings, up to 2x performance > > improvement has been observed in micro-benchmarks. > > > > > > > > Special care was taken to preserve good performance for short strings. > All > > examined workloads showed a high ratio of short and very short strings. > > > > > > > > Thank you! > > > > Lutz > > > > > > > > > > > > > > > > > > > > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 (6227) 7-42834 > > > > > > From lutz.schmidt at sap.com Mon Nov 13 11:52:58 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 13 Nov 2017 11:52:58 +0000 Subject: RFR(L): 8189793: [s390]: Improve String compress/inflate by exploiting vector instructions In-Reply-To: <2f718b251d5d4a5bac81dc85eb0644ed@sap.com> References: <18ddb703d81a4a22bc97f134dd276eff@sap.com> <6F73CAE2-2FEC-4BC0-9F3A-FEE9748EB694@sap.com> <02fe90a2093144b6a2a1ec0020d9b88f@sap.com> <7702F170-B574-4EF8-8B85-B366B507E7B0@sap.com> <2f718b251d5d4a5bac81dc85eb0644ed@sap.com> Message-ID: <53479CC5-02DF-4161-9CEE-161D9BECDD0C@sap.com> Thank you, Goetz! Best Regards, Lutz On 13.11.2017, 12:48, "Lindenmaier, Goetz" wrote: Hi Lutz, thanks for the numbers and for the two fixes. Change looks good now. The numbers indicate that deflation of constant strings at compile time would make sense, as well as optimizing compress for large strings. (if jvm2008 is representative, but I assume it's good enough). Best regards, Goetz. > -----Original Message----- > From: Schmidt, Lutz > Sent: Freitag, 3. November 2017 17:46 > To: Lindenmaier, Goetz ; Doerr, Martin > ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(L): 8189793: [s390]: Improve String compress/inflate by > exploiting vector instructions > > Hi Goetz, > > I agree. Knowing the string length greatly helps to optimize the generated > code, both in terms of size and performance. There are no compress calls > with constant length, though. Constant strings are stored compressed at > compile time. > > Here are some counters I found when running (a subset of) the SPECjvm2008 > suite: > string_compress match count: 11 > string_inflate match count: 171 > string_inflate_const: > len = 1: 10 matches > len = 2: 2 matches > len = 4: 3 matches > len = 6: 9 matches > len = 7: 3 matches > len = 9: 4 matches > len = 10: 5 matches > len = 11: 15 matches > len = 15: 1 matches > len = 17: 1 matches > len = 18: 2 matches > len = 19: 2 matches > len = 29: 1 matches > len = 31: 1 matches > > These (rather few) matches handle a lot of compress/inflate operations: > n #compress #inflate > <16 673 Mio 2895 Mio > <256 207 Mio 704 Mio > <4096 0.7 Mio 1.8 Mio > >=4096 1.1 Mio 0.3 Mio > > > A short not on performance gains: > I have done a lot of performance tests in different settings. With complex > tests, like SPECjvm2008, the positive (or negative) effect of such low-level > optimizations disappears in measurement noise. With a micro benchmark, > just compressing and inflating a string, some effect is visible: > > My new, improved implementation of the intrinsics shows a slight > performance advantage of 1..4% for short strings. Once the vector > instructions kick in (at len >= 32), performance improves by 50..70% for > string_compress and by 50..150% for string_inflate. Measurements show a > high variance, despite testing was done on a system with dedicated cpu > resources and with no concurrent load. > > BTW, there is a new webrev at > http://cr.openjdk.java.net/~lucy/webrevs/8189793.01/index.html > > In addition to the changes mentioned below, it contains two minor, > nevertheless important fixes to the compress intrinsic: > 1) z_bru(skipShortcut); is changed to z_brh(skipShortcut); > 2) Code is added after label ScalarShortcut to check for zero length strings. > > Regards, > Lutz > > > > > On 03.11.2017, 12:44, "Lindenmaier, Goetz" > wrote: > > Hi Lutz, > > I have been looking at your change. I think it's a good idea to match > for constant string length. I did this for the ppc string intrinsics in the > past. > I remember that distribution of constant strings was quite uneven. > StrIndexOf appeared with constant lengths a lot, StrEquals and StrComp > didn't. > > Do you have any data on how often the new match rules match? > > Actually, if there is a constant string deflated, a platform independent > optimization could compute that at compile time, but that's a different > issue ... > > Best regards, > Goetz. > > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > > Sent: Freitag, 27. Oktober 2017 13:07 > > To: Doerr, Martin ; hotspot-compiler- > > dev at openjdk.java.net > > Subject: Re: RFR(L): 8189793: [s390]: Improve String compress/inflate by > > exploiting vector instructions > > > > Hi Martin, > > > > > > > > Thanks for reviewing my change! > > > > > > > > This is a preliminary response just to let you know I?m working on the > > change. I?m putting a lot of effort in producing reliable performance > > measurement data. Turns out this is not easy (to be more honest: almost > > impossible). > > > > > > > > s390.ad: > > > > You are absolutely right, the sequence load_const/string_compress > makes > > no sense at all. But it does not hurt either ? I could not find one match in > all > > tests I ran. -> Match rule deleted. > > > > > > > > macroAssembler_s390: > > > > prefetch: did not see impact, neither positive nor negative. Artificial > micro > > benchmarks will not benefit (data is in cache anyway). More complex > > benchmarks show measurement noise which covers the possible > prefetch > > benefit. -> prefetch deleted. > > > > Hardcoded vector registers: you are right. There are some design > decisions > > pending, e.g. how many vector scratch registers? > > > > Vperm instruction: using that is just another implementation variant that > > could save the vn vector instruction. On the other hand, loading the > index > > vector is a (compared to vgmh) costly memory access. Given the fact that > we > > mostly deal with short strings, initialization effort is relevant. > > > > Code size vs. performance: the old, well known, often discussed > tradeoff. > > Starting from the existing implementation, I invested quite some time in > > optimizing the (len <= 8) cases. With every refinement step I saw (or > > believed to see (measurement noise)) some improvement ? or > discarded it. > > Is the overall improvement worth the larger code size? -> tradeoff, > > discussion. > > > > > > > > Best Regards, > > > > Lutz > > > > > > > > > > > > > > > > On 25.10.2017, 21:08, "Doerr, Martin" > > wrote: > > > > > > > > Hi Lutz, > > > > > > > > thanks for working on vector-based enhancements and for providing this > > webrev. > > > > > > > > assembler_s390: > > > > -The changes in the assembler look good. > > > > > > > > s390.ad: > > > > -It doesn't make sense to load constant len to a register and generate > > complex compare instructions for it and still to emit code for all cases. I > > assume that e.g. the 4 characters cases usually have a constant length. If > so, > > much better code could be generated for them by omitting all the stuff > > around the simple instructions. (ppc64.ad already contains nodes for > > constant length of needle in indexOf rules.) > > > > > > > > macroAssembler_s390: > > > > -Are you sure the prefetch instructions improve performance? > > > > I remember that we had them in other String intrinsics but removed > them > > again as they showed absolutely no performance gain. > > > > -Comment: Using hardcoded vector registers is ok for now, but may need > to > > get changed e.g. when using them for C2's SuperWord optimization. > > > > -Comment: You could use the vperm instruction instead of vo+vn, but I'm > ok > > with the current implementation because loading a mask is much more > > convenient than getting the permutation vector loaded (e.g. from > constant > > pool or pc relative). > > > > -So the new vector loop looks good to me. > > > > -In my opinion, the size of all the generated cases should be in > relationship to > > their performance benefit. > > > > As intrinsics are not like stubs and may get inlined often, I can't get rid of > the > > impression that generating so large code wastes valuable code cache > space > > with questionable performance gain in real world scenarios. > > > > > > > > Best regards, > > > > Martin > > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > > Sent: Mittwoch, 25. Oktober 2017 12:02 > > To: hotspot-compiler-dev at openjdk.java.net > > Subject: RFR(L): 8189793: [s390]: Improve String compress/inflate by > > exploiting vector instructions > > > > > > > > Dear all, > > > > > > > > I would like to request reviews for this s390-only enhancement: > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189793 > > > > Webrev: > http://cr.openjdk.java.net/~lucy/webrevs/8189793.00/index.html > > > > > > > > Vector instructions, which have been available on System z for a while > (since > > z13), promise noticeable performance improvements. This enhancement > > improves the String Compress and String Inflate intrinsics by exploiting > vector > > instructions, when available. For long strings, up to 2x performance > > improvement has been observed in micro-benchmarks. > > > > > > > > Special care was taken to preserve good performance for short strings. > All > > examined workloads showed a high ratio of short and very short strings. > > > > > > > > Thank you! > > > > Lutz > > > > > > > > > > > > > > > > > > > > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 (6227) 7-42834 > > > > > > From matcdac at gmail.com Mon Nov 13 15:27:14 2017 From: matcdac at gmail.com (Prakhar Makhija) Date: Mon, 13 Nov 2017 20:57:14 +0530 Subject: Require some insight regarding Objects Message-ID: *json* {"subCategory":"European","bornLocation":"Pondicherry","name":"Goldi Heathers","someSocialStatus":"Active","prefferedCategory":"Within City","dateOfBeingBorn":"16/11/1987","interestedActivity":"Business","personalEarnings":500000.0,"matchfulDesiredEarnings":1000000.0,"identificationNumber":"X582TQ0170TF47002UTD087X74","prefferedClass":"Private","addressState":"Andaman and Nicobar Islands","someAddress":"House Number 143, Near Pie Beach, Port Blair, Andaman and Nicobar Islands, India - 744101","interestedActivityCode":72681.0,"emailId":"munchymuffin at gmail.com"} *class definition* public class MyClass { private String identificationNumber; private String name; private String someAddress; private String addressState; private String bornLocation; private String someSocialStatus; private String prefferedClass; private String prefferedCategory; private String subCategory; private String dateOfBeingBorn; private String interestedActivity; private Double interestedActivityCode; private Double personalEarnings; private Double matchfulDesiredEarnings; private String emailId; // getters & setters // constructors } *code block* import com.fasterxml.jackson.databind.ObjectMapper; ObjectMapper objectMapper = new ObjectMapper(); MyClass myClassObj = objectMapper.readValue(currentLine.getBytes(), MyClass.class); *topic* Likewise having 1.5 million json files Total size which they are occupying on disk is 940 Mega Bytes My first doubt is when I load all these json, to make objects out of them, will they occupy the same space in the memory? My second doubt is about what is going on internally in the JVM's memory, when I am making 1.5 million objects of MyClass. Lets pick one identifier 'identificationNumber', it has 20 characters. So just this field 'identificationNumber' is going to occupy 40 bytes only, or (40 * 1,500,000) = 60,000,000 bytes = 57.22 MB ???? PS : I am not aware which mailing list should be concerned with this kind of query, could you direct me to them, if you are not aware of what I am asking. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Mon Nov 13 16:50:06 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 13 Nov 2017 11:50:06 -0500 Subject: RFR(S): 8190375: Java Crash in JavaBug.formatPos(I)Ljava/lang/String In-Reply-To: References: Message-ID: <66412d2b-a33f-b315-0094-6751fc5940b1@oracle.com> Hi Roland, looks good to me! I'm running some pre-integration testing. Best regards, Tobias On 08.11.2017 10:05, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8190375/webrev.00/ > > Bounds of a counted loop iv can't be reliably determined from the > init/limit bounds if the exit condition is "not > equal". TestCountedLoopBadIVRange.test1() is an example of that. On > first execution of the inner loop the loop runs from j = 0 to j = 4 but > on second execution, j = 10 on entry so exit condition j != 5 never > triggers and the test in the loop is the one that exits the > loop. Current logic sets j to be in [0, 10[ which is incorrect. > > The fix simply skips the logic that set the value of the Phi iv if the > exit condition is "not equal". If init < limit for instance, the existing logic > is correct but in that case, when the counted loop is created, the exit > test is changed to a greater or less than test. > > Roland. > From daniel.daugherty at oracle.com Mon Nov 13 17:30:57 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 13 Nov 2017 12:30:57 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> Message-ID: <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> Greetings, I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. Here are the updated webrevs: Here's the mq comment for the change: ? Rebase to 2017.10.25 PIT snapshot. Here is the full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ And here is the delta webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ I ran the above bits throught Mach5 tier[1-5] testing over the holiday weekend. Didn't see any issues in a quick look. Going to take a closer look today. We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: > Greetings, > > Resolving one of the code review comments (from both Stefan K and Coleen) > on jdk10-04-full required quite a few changes so it is being done as a > standalone patch and corresponding webrevs: > > Here's the mq comment for the change: > > ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use > ??? JavaThreadIteratorWithHandle. > > Here is the full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ > > And here is the delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> We have a (eXtra Large) fix for the following bug: >> >> 8167108 inconsistent handling of SR_lock can lead to crashes >> https://bugs.openjdk.java.net/browse/JDK-8167108 >> >> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >> Hazard Pointers to manage JavaThread lifecycle. >> >> Here's a PDF for the internal wiki that we've been using to describe >> and track the work on this project: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >> >> >> Dan has noticed that the indenting is wrong in some of the code quotes >> in the PDF that are not present in the internal wiki. We don't have a >> solution for that problem yet. >> >> Here's the webrev for current JDK10 version of this fix: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >> >> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >> testing, additional stress testing on Dan's Solaris X64 server, and >> additional testing on Erik and Robbin's machines. >> >> We welcome comments, suggestions and feedback. >> >> Daniel Daugherty >> Erik Osterlund >> Robbin Ehn >> > > From martin.doerr at sap.com Mon Nov 13 17:31:50 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 13 Nov 2017 17:31:50 +0000 Subject: RFR(S): 8190375: Java Crash in JavaBug.formatPos(I)Ljava/lang/String In-Reply-To: <66412d2b-a33f-b315-0094-6751fc5940b1@oracle.com> References: <66412d2b-a33f-b315-0094-6751fc5940b1@oracle.com> Message-ID: <9cce658cb0dc440f894ca968573d6f34@sap.com> Hi Roland, we have just debugged the same problem. Your fix looks good. I've tested it with my very simple stand-alone test (see below). Without your fix, we get an ArrayIndexOutOfBoundsException. With this fix, it runs correctly. Thanks for fixing. Best regards, Martin TestLoopLimit.java: // run with -Xbatch -XX:CompileCommand=dontinline,TestLoopLimit::write TestLoopLimit public class TestLoopLimit{ static byte[] bytes = new byte[4]; static int idx = 0; static void write(byte b) { bytes[idx++] = b; } static void test_loop(int size) { for (int align = size % 4; align != 0 && align != 4; align++) { write((byte)'-'); } } static final int loop_cnt = 10000; public static void main(String args[]){ for (int x = 0; x < loop_cnt; x++) { idx = 0; test_loop(x); } System.out.println("Test passed. Final idx: " + idx); } } -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Tobias Hartmann Sent: Montag, 13. November 2017 17:50 To: Roland Westrelin ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(S): 8190375: Java Crash in JavaBug.formatPos(I)Ljava/lang/String Hi Roland, looks good to me! I'm running some pre-integration testing. Best regards, Tobias On 08.11.2017 10:05, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8190375/webrev.00/ > > Bounds of a counted loop iv can't be reliably determined from the > init/limit bounds if the exit condition is "not > equal". TestCountedLoopBadIVRange.test1() is an example of that. On > first execution of the inner loop the loop runs from j = 0 to j = 4 but > on second execution, j = 10 on entry so exit condition j != 5 never > triggers and the test in the loop is the one that exits the > loop. Current logic sets j to be in [0, 10[ which is incorrect. > > The fix simply skips the logic that set the value of the Phi iv if the > exit condition is "not equal". If init < limit for instance, the existing logic > is correct but in that case, when the counted loop is created, the exit > test is changed to a greater or less than test. > > Roland. > From dean.long at oracle.com Mon Nov 13 17:32:09 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 13 Nov 2017 09:32:09 -0800 Subject: RFR(S) 8190817: deopt special-case for _return_register_finalizer is confusing and leads to bugs Message-ID: <480ed17b-fae1-8db4-1d12-3319be262d3d@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8190817 http://cr.openjdk.java.net/~dlong/8190817/webrev/ This fix replaces the problematic use of _normal_table.entry(Bytecodes::_return).entry(vtos) as a deoptimization entry point with a proper deopt entry point returned by deopt_reexecute_return_entry().? This is needed to handle the situation where compiled code is calling register_finalizer() and gets deoptimized. I also noticed that we generate duplicate entry points unnecessarily, so I cleaned that up at the same time. aarch64/ppc64/s390 folks, please check that compiler/runtime/Test8168712.java still passes. dl From kevin.walls at oracle.com Mon Nov 13 18:08:27 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 13 Nov 2017 18:08:27 +0000 Subject: RFR(8u): 8038636, 8055008, 8156137: SIGSEGV in ReceiverTypeData::clean_weak_klass_links ...and 8057570. Message-ID: Hi, I'd like to get a hotspot review of these backports from 9 to 8u.? This is mainly runtime territory but some of the history is from the compiler side. webrev: http://cr.openjdk.java.net/~kevinw/8055008.8156137/webrev.00/ The one we need is: 8156137: SIGSEGV in ReceiverTypeData::clean_weak_klass_links jbs: https://bugs.openjdk.java.net/browse/JDK-8156137 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/882e8cda60b3 The 9 changeset is short, just changing klass.cpp, but not possible in 8 without additional work, so... 1. 8038636: speculative traps break when classes are redefined https://bugs.openjdk.java.net/browse/JDK-8038636 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a7784ddacbef 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-April/013948.html (in 9 since April 2014) That one imports cleanly into 8u. 2. With that imported, we need: 8055008:Clean up code that saves the previous versions of redefined classes https://bugs.openjdk.java.net/browse/JDK-8055008 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e3fb51ae8d7d This is the change to stop using PreviousVersionNode and get an InstanceKlass* from previous_versions(). My webrev: http://cr.openjdk.java.net/~kevinw/8055008.8156137/webrev.00/ ...is 8055008 and 8156137 in 8u. The klass.cpp change here is 8156137.? The rest is 8055008, so I can commit them separately. 8156137 doesn't have its own test, but I have found if you get this area wrong, the test runtime/RedefineObject crashes. Notes: For 8055008 there was a change in src/share/vm/classfile/classLoaderData.cpp which is already in 8u. src/share/vm/classfile/metadataOnStackMark.cpp: +MetadataOnStackMark::MetadataOnStackMark(bool has_redefined_a_class) { The change is to stop using JvmtiExport::has_redefined_a_class() here which is already in 8u at this point, but the param is already there with a different name, so renamed as per 8055008. universe.cpp: had a change in 8055008 but following that there was: 8057570: RedefineClasses() tests fail assert(((Metadata*)obj)->is_valid()) failed: obj is valid https://bugs.openjdk.java.net/browse/JDK-8057570 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/479ed4234a9d ..this puts back a few lines in nmethod.cpp which 8055008 removed: + // Call function Method*, not embedded in these other places. + if (_method != NULL) f(_method); ..and in universe.cpp: + // Make the dependent methods not entrant (in VM_Deoptimize they are made zombies) + CodeCache::make_marked_nmethods_not_entrant(); ..and removes: CodeCache::make_marked_nmethods_zombies(); My webrev takes these into account. Then there are 8038636's two follow-on bugs which I'd like to follow-up in a separate thread. 8039960 is a test change 8040237: nsk/jvmti/RetransformClasses/retransform001 crashed the VM on all platforms when run with with -server -Xcomp https://bugs.openjdk.java.net/browse/JDK-8040237 Thanks! Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwestrel at redhat.com Mon Nov 13 18:51:11 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 13 Nov 2017 13:51:11 -0500 Subject: RFR(S): 8186125: "DU iteration must converge quickly" assert in split if with unsafe accesses In-Reply-To: <7278ed0a-a571-a3df-749c-b1121e3bc011@oracle.com> References: <1c9df7df-9455-9e75-4918-635f95ac712b@oracle.com> <7278ed0a-a571-a3df-749c-b1121e3bc011@oracle.com> Message-ID: > Thanks. I will add it to bug report. > Tests passed I will push changes. Thanks you for taking care of that? Roland. From rwestrel at redhat.com Mon Nov 13 19:17:04 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 13 Nov 2017 14:17:04 -0500 Subject: RFR(S): 8190375: Java Crash in JavaBug.formatPos(I)Ljava/lang/String In-Reply-To: <66412d2b-a33f-b315-0094-6751fc5940b1@oracle.com> References: <66412d2b-a33f-b315-0094-6751fc5940b1@oracle.com> Message-ID: Hi Tobias, > looks good to me! > > I'm running some pre-integration testing. Thanks for the review and testing. Roland. From rwestrel at redhat.com Mon Nov 13 19:25:19 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 13 Nov 2017 14:25:19 -0500 Subject: RFR(S): 8190375: Java Crash in JavaBug.formatPos(I)Ljava/lang/String In-Reply-To: <9cce658cb0dc440f894ca968573d6f34@sap.com> References: <66412d2b-a33f-b315-0094-6751fc5940b1@oracle.com> <9cce658cb0dc440f894ca968573d6f34@sap.com> Message-ID: Hi Martin, > we have just debugged the same problem. Your fix looks good. I've tested it with my very simple stand-alone test (see below). > Without your fix, we get an ArrayIndexOutOfBoundsException. With this fix, it runs correctly. Thanks for fixing. Thanks for verifying the fix. Roland. From tobias.hartmann at oracle.com Mon Nov 13 19:55:48 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 13 Nov 2017 14:55:48 -0500 Subject: RFR(S): 8190375: Java Crash in JavaBug.formatPos(I)Ljava/lang/String In-Reply-To: References: <66412d2b-a33f-b315-0094-6751fc5940b1@oracle.com> Message-ID: Hi Roland, all tests passed. Pushed. Best regards, Tobias On 13.11.2017 14:17, Roland Westrelin wrote: > > Hi Tobias, > >> looks good to me! >> >> I'm running some pre-integration testing. > > Thanks for the review and testing. > > Roland. > From shade at redhat.com Tue Nov 14 14:16:51 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Nov 2017 15:16:51 +0100 Subject: C1 code installation and JNIHandle::deleted_handle() oop Message-ID: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> Hi, In some of our aggressive test configurations for Shenandoah, we sometimes see the following failure: http://cr.openjdk.java.net/~shade/shenandoah/c1-race-fail-hs_err.log It seems to happen when C1 code installation is happening during Full GC. The actual failure is caused by touching the JNIHandles::deleted_handle() oop in JNIHandles::guard_value() during JNIHandles::resolve() against the constant oop handle when we are recording the debugging information for C1-generated Java call: http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 The C1 thread is in _thread_in_native state, and so the runtime thinks the thread is at safepoint, but the thread touches the deleted_handle oop(). When Shenandoah dives into Full GC and moves that object at the same time, everything crashes and burns. Is C1 (and any other compiler thread) supposed to transit to _vm_state when touching the naked oops, and thus coordinate with safepoints? I see VM_ENTRY_MARK all over ci* that seems to transit there before accessing the heap. Does that mean we need the same everywhere around JNIHandles::resolve too? Or is there some other mechanism that is supposed to get compiler threads to coordinate with GC? Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From jamsheed.c.m at oracle.com Tue Nov 14 05:10:59 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Tue, 14 Nov 2017 10:40:59 +0530 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR Message-ID: Hi, request for review, jbs: https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) changes equivalent to JDK-4454115 is done for windows. 2) added guard to multiple value access sites, Unsafe_CopyMemory0, Unsafe_SetMemory0 and Unsafe_CopySwapMemory0. 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed thread->thread_state() == _thread_in_vm checks from signal handler Best regards, Jamsheed -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at redhat.com Tue Nov 14 15:02:25 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Nov 2017 16:02:25 +0100 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> Message-ID: When the compiler thread is _in_native state, it doesn't stop for safepoints, e.g. GC. This means it must not touch naked oops, otherwise the GC may move away the oop under our feet. Seems like this is what happens here. I am not sure what granularity VM_ENTRY_MARK are usually done. My feeling is that it should be somewhere around LIR_Assembler::emit_code(BlockList*) ? Roman > Hi, > > In some of our aggressive test configurations for Shenandoah, we sometimes see the following failure: > http://cr.openjdk.java.net/~shade/shenandoah/c1-race-fail-hs_err.log > > It seems to happen when C1 code installation is happening during Full GC. > > The actual failure is caused by touching the JNIHandles::deleted_handle() oop in > JNIHandles::guard_value() during JNIHandles::resolve() against the constant oop handle when we are > recording the debugging information for C1-generated Java call: > http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 > > The C1 thread is in _thread_in_native state, and so the runtime thinks the thread is at safepoint, > but the thread touches the deleted_handle oop(). When Shenandoah dives into Full GC and moves that > object at the same time, everything crashes and burns. > > Is C1 (and any other compiler thread) supposed to transit to _vm_state when touching the naked oops, > and thus coordinate with safepoints? I see VM_ENTRY_MARK all over ci* that seems to transit there > before accessing the heap. Does that mean we need the same everywhere around JNIHandles::resolve too? > > Or is there some other mechanism that is supposed to get compiler threads to coordinate with GC? > > Thanks, > -Aleksey > From vladimir.x.ivanov at oracle.com Tue Nov 14 15:36:10 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Nov 2017 18:36:10 +0300 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> Message-ID: <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> Aleksey, I agree with your & Roman analysis: compilers shouldn't touch naked oops unless the thread is in _thread_in_vm mode. Looking at the crash log, the problematic code is under assert: void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { assert(JNIHandles::resolve(value()) == NULL || Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), "Should be in heap"); stream->write_int(CONSTANT_OOP_CODE); stream->write_handle(value()); } So, the proper fix would be to make the verification code more robust. Best regards, Vladimir Ivanov On 11/14/17 5:16 PM, Aleksey Shipilev wrote: > Hi, > > In some of our aggressive test configurations for Shenandoah, we sometimes see the following failure: > http://cr.openjdk.java.net/~shade/shenandoah/c1-race-fail-hs_err.log > > It seems to happen when C1 code installation is happening during Full GC. > > The actual failure is caused by touching the JNIHandles::deleted_handle() oop in > JNIHandles::guard_value() during JNIHandles::resolve() against the constant oop handle when we are > recording the debugging information for C1-generated Java call: > http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 > > The C1 thread is in _thread_in_native state, and so the runtime thinks the thread is at safepoint, > but the thread touches the deleted_handle oop(). When Shenandoah dives into Full GC and moves that > object at the same time, everything crashes and burns. > > Is C1 (and any other compiler thread) supposed to transit to _vm_state when touching the naked oops, > and thus coordinate with safepoints? I see VM_ENTRY_MARK all over ci* that seems to transit there > before accessing the heap. Does that mean we need the same everywhere around JNIHandles::resolve too? > > Or is there some other mechanism that is supposed to get compiler threads to coordinate with GC? > > Thanks, > -Aleksey > From rkennke at redhat.com Tue Nov 14 15:45:53 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Nov 2017 16:45:53 +0100 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> Message-ID: <4D5DC152-B7B2-4E89-81B9-D9A291E943E0@redhat.com> The code below the assert also unwraps the oop and does lookups with it. I'm not on my computer but I can dig out the relevant parts when I'm back at work... Roman Am 14. November 2017 16:36:10 MEZ schrieb Vladimir Ivanov : >Aleksey, > >I agree with your & Roman analysis: compilers shouldn't touch naked >oops >unless the thread is in _thread_in_vm mode. > >Looking at the crash log, the problematic code is under assert: > >void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { > assert(JNIHandles::resolve(value()) == NULL || > Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), > "Should be in heap"); > stream->write_int(CONSTANT_OOP_CODE); > stream->write_handle(value()); >} > >So, the proper fix would be to make the verification code more robust. > >Best regards, >Vladimir Ivanov > >On 11/14/17 5:16 PM, Aleksey Shipilev wrote: >> Hi, >> >> In some of our aggressive test configurations for Shenandoah, we >sometimes see the following failure: >> >http://cr.openjdk.java.net/~shade/shenandoah/c1-race-fail-hs_err.log >> >> It seems to happen when C1 code installation is happening during Full >GC. >> >> The actual failure is caused by touching the >JNIHandles::deleted_handle() oop in >> JNIHandles::guard_value() during JNIHandles::resolve() against the >constant oop handle when we are >> recording the debugging information for C1-generated Java call: >> >http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 >> >> The C1 thread is in _thread_in_native state, and so the runtime >thinks the thread is at safepoint, >> but the thread touches the deleted_handle oop(). When Shenandoah >dives into Full GC and moves that >> object at the same time, everything crashes and burns. >> >> Is C1 (and any other compiler thread) supposed to transit to >_vm_state when touching the naked oops, >> and thus coordinate with safepoints? I see VM_ENTRY_MARK all over ci* >that seems to transit there >> before accessing the heap. Does that mean we need the same everywhere >around JNIHandles::resolve too? >> >> Or is there some other mechanism that is supposed to get compiler >threads to coordinate with GC? >> >> Thanks, >> -Aleksey >> -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Tue Nov 14 16:04:50 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Nov 2017 19:04:50 +0300 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <4D5DC152-B7B2-4E89-81B9-D9A291E943E0@redhat.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <4D5DC152-B7B2-4E89-81B9-D9A291E943E0@redhat.com> Message-ID: Thanks, now I see that as well: OopRecorder::find_index() can delegate to ObjectLookup::find_index() which does resolve the handle w/o transitioning to VM. But I don't believe you hit that path: ObjectLookup was added as part of JVMCI and is guarded by a flag (deduplicate) which is turned on only for JVMCI. Anyway, I'll file a bug to investigate ObjectLookup::find_index(). Best regards, Vladimir Ivanov On 11/14/17 6:45 PM, Roman Kennke wrote: > The code below the assert also unwraps the oop and does lookups with it. > I'm not on my computer but I can dig out the relevant parts when I'm > back at work... > > Roman > > > Am 14. November 2017 16:36:10 MEZ schrieb Vladimir Ivanov > : > > Aleksey, > > I agree with your & Roman analysis: compilers shouldn't touch naked oops > unless the thread is in _thread_in_vm mode. > > Looking at the crash log, the problematic code is under assert: > > void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { > assert(JNIHandles::resolve(value()) == NULL || > Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), > "Should be in heap"); > stream->write_int(CONSTANT_OOP_CODE); > stream->write_handle(value()); > } > > So, the proper fix would be to make the verification code more robust. > > Best regards, > Vladimir Ivanov > > On 11/14/17 5:16 PM, Aleksey Shipilev wrote: > > Hi, > > In some of our aggressive test configurations for Shenandoah, we > sometimes see the following failure: > http://cr.openjdk.java.net/~shade/shenandoah/c1-race-fail-hs_err.log > > It seems to happen when C1 code installation is happening during > Full GC. > > The actual failure is caused by touching the > JNIHandles::deleted_handle() oop in > JNIHandles::guard_value() during JNIHandles::resolve() against > the constant oop handle when we are > recording the debugging information for C1-generated Java call: > http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 > > The C1 thread is in _thread_in_native state, and so the runtime > thinks the thread is at safepoint, > but the thread touches the deleted_handle oop(). When Shenandoah > dives into Full GC and moves that > object at the same time, everything crashes and burns. > > Is C1 (and any other compiler thread) supposed to transit to > _vm_state when touching the naked oops, > and thus coordinate with safepoints? I see VM_ENTRY_MARK all > over ci* that seems to transit there > before accessing the heap. Does that mean we need the same > everywhere around JNIHandles::resolve too? > > Or is there some other mechanism that is supposed to get > compiler threads to coordinate with GC? > > Thanks, > -Aleksey > > > -- > Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From shade at redhat.com Tue Nov 14 16:08:18 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Nov 2017 17:08:18 +0100 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> Message-ID: <6cb75d25-11c7-a199-8aa9-ce769252c031@redhat.com> On 11/14/2017 04:36 PM, Vladimir Ivanov wrote: > Aleksey, > > I agree with your & Roman analysis: compilers shouldn't touch naked oops unless the thread is in > _thread_in_vm mode. > > Looking at the crash log, the problematic code is under assert: > > void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { > ? assert(JNIHandles::resolve(value()) == NULL || > ???????? Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), > ???????? "Should be in heap"); > ? stream->write_int(CONSTANT_OOP_CODE); > ? stream->write_handle(value()); > } > > So, the proper fix would be to make the verification code more robust. Actually, in Shenandoah case, the failure is here (it is obscured by inlining, but visible in slowdebug): http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 ... "== deleted_handle()" or "!= deleted_handle()". So fortifying assert code does not help, the bug is touching the oop in improper thread state. Nightmarish scenario would be to fail "!="/"==" check because the deleted_handle oop had been already updated, but the actual handle value did not. The similar thing happens after we write the oop into the debug stream: it is not handelize-d anymore, and so opaque for GC, and thus has all the chance to be garbled by the time GC finishes. Having these two thoughts in mind, I think we have to consider _thread_in_vm on that C1 path. But where exactly? Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.x.ivanov at oracle.com Tue Nov 14 16:09:42 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Nov 2017 19:09:42 +0300 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <4D5DC152-B7B2-4E89-81B9-D9A291E943E0@redhat.com> Message-ID: <2b13e9a6-7fba-86b1-82ac-b6c13af10fb8@oracle.com> > Anyway, I'll file a bug to investigate ObjectLookup::find_index(). FTR it shouldn't be a problem for JVMCI since transition to VM happens as part of the call into VM (see jvmciCompilerToVM.cpp & C2V_VMENTRY macro). Best regards, Vladimir Ivanov > On 11/14/17 6:45 PM, Roman Kennke wrote: >> The code below the assert also unwraps the oop and does lookups with >> it. I'm not on my computer but I can dig out the relevant parts when >> I'm back at work... >> >> Roman >> >> >> Am 14. November 2017 16:36:10 MEZ schrieb Vladimir Ivanov >> : >> >> ??? Aleksey, >> >> ??? I agree with your & Roman analysis: compilers shouldn't touch >> naked oops >> ??? unless the thread is in _thread_in_vm mode. >> >> ??? Looking at the crash log, the problematic code is under assert: >> >> ??? void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { >> ??????? assert(JNIHandles::resolve(value()) == NULL || >> >> Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), >> ?????????????? "Should be in heap"); >> ??????? stream->write_int(CONSTANT_OOP_CODE); >> ??????? stream->write_handle(value()); >> ??? } >> >> ??? So, the proper fix would be to make the verification code more >> robust. >> >> ??? Best regards, >> ??? Vladimir Ivanov >> >> ??? On 11/14/17 5:16 PM, Aleksey Shipilev wrote: >> >> ??????? Hi, >> >> ??????? In some of our aggressive test configurations for Shenandoah, we >> ??????? sometimes see the following failure: >> >> http://cr.openjdk.java.net/~shade/shenandoah/c1-race-fail-hs_err.log >> >> ??????? It seems to happen when C1 code installation is happening during >> ??????? Full GC. >> >> ??????? The actual failure is caused by touching the >> ??????? JNIHandles::deleted_handle() oop in >> ??????? JNIHandles::guard_value() during JNIHandles::resolve() against >> ??????? the constant oop handle when we are >> ??????? recording the debugging information for C1-generated Java call: >> >> http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 >> >> >> ??????? The C1 thread is in _thread_in_native state, and so the runtime >> ??????? thinks the thread is at safepoint, >> ??????? but the thread touches the deleted_handle oop(). When Shenandoah >> ??????? dives into Full GC and moves that >> ??????? object at the same time, everything crashes and burns. >> >> ??????? Is C1 (and any other compiler thread) supposed to transit to >> ??????? _vm_state when touching the naked oops, >> ??????? and thus coordinate with safepoints? I see VM_ENTRY_MARK all >> ??????? over ci* that seems to transit there >> ??????? before accessing the heap. Does that mean we need the same >> ??????? everywhere around JNIHandles::resolve too? >> >> ??????? Or is there some other mechanism that is supposed to get >> ??????? compiler threads to coordinate with GC? >> >> ??????? Thanks, >> ??????? -Aleksey >> >> >> -- >> Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From vladimir.x.ivanov at oracle.com Tue Nov 14 16:23:07 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Nov 2017 19:23:07 +0300 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <6cb75d25-11c7-a199-8aa9-ce769252c031@redhat.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <6cb75d25-11c7-a199-8aa9-ce769252c031@redhat.com> Message-ID: <28cf279a-93ca-2902-7f1b-ad44e3ccd69d@oracle.com> >> Looking at the crash log, the problematic code is under assert: >> >> void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { >> ? assert(JNIHandles::resolve(value()) == NULL || >> ???????? Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), >> ???????? "Should be in heap"); >> ? stream->write_int(CONSTANT_OOP_CODE); >> ? stream->write_handle(value()); >> } >> >> So, the proper fix would be to make the verification code more robust. > > Actually, in Shenandoah case, the failure is here (it is obscured by inlining, but visible in > slowdebug): > http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 > > ... "== deleted_handle()" or "!= deleted_handle()". So fortifying assert code does not help, the bug > is touching the oop in improper thread state. Nightmarish scenario would be to fail "!="/"==" check > because the deleted_handle oop had been already updated, but the actual handle value did not. > The similar thing happens after we write the oop into the debug stream: it is not handelize-d > anymore, and so opaque for GC, and thus has all the chance to be garbled by the time GC finishes. I don't follow you. Can you point to the code you are talking about? ConstantOopWriteValue::write_on() writes the _handle_ and not the naked oop [1]. I still believe the assert is the only problem here. If it's valuable to keep it, then it should perform all necessary precautions itself before accessing the oop. The assert is a relatively recent addition. It was added as part of PermGen removal and most likely the fact it isn't executed in VM was overlooked. Best regards, Vladimir Ivanov [1] void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { ... stream->write_handle(value()); ... class ConstantOopWriteValue: public ScopeValue { private: jobject _value; public: jobject value() const { return _value; } ... void DebugInfoWriteStream::write_handle(jobject h) { write_int(recorder()->oop_recorder()->find_index(h)); } Best regards, Vladimir Ivanov > Having these two thoughts in mind, I think we have to consider _thread_in_vm on that C1 path. But > where exactly? > > Thanks, > -Aleksey > From shade at redhat.com Tue Nov 14 16:37:05 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Nov 2017 17:37:05 +0100 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <28cf279a-93ca-2902-7f1b-ad44e3ccd69d@oracle.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <6cb75d25-11c7-a199-8aa9-ce769252c031@redhat.com> <28cf279a-93ca-2902-7f1b-ad44e3ccd69d@oracle.com> Message-ID: <98013a00-48ad-86d9-b2d4-90f3a2df074d@redhat.com> On 11/14/2017 05:23 PM, Vladimir Ivanov wrote: >> Actually, in Shenandoah case, the failure is here (it is obscured by inlining, but visible in >> slowdebug): >> ?? http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 >> >> ... "== deleted_handle()" or "!= deleted_handle()". So fortifying assert code does not help, the bug >> is touching the oop in improper thread state. Nightmarish scenario would be to fail "!="/"==" check >> because the deleted_handle oop had been already updated, but the actual handle value did not. > See this line: http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l224 } else if ((value == badJNIHandle) || (value == deleted_handle())) { value = NULL; } return value; If we ever get in that code during the GC, we might get the deleted_handle() updated by GC code (because it is a root via JNIHandles), but the $value may be not updated, and still point to old location. Then "value == deleted_handle()" fails, and we return broken oop from guard_value. Notice this code is not under the assert. It seems to me the symptom of larger problem: touching naked oops is seldom reliable, if the thread is inconsistent state. It does not seem right to fix asserts, because the real trouble is touching that oop on product paths. It appears to work for other GCs, but for Shenandoah this failure is observable, because its barriers touch heap through the oops. >> The similar thing happens after we write the oop into the debug stream: it is not handelize-d >> anymore, and so opaque for GC, and thus has all the chance to be garbled by the time GC finishes. > > I don't follow you. Can you point to the code you are talking about? > ConstantOopWriteValue::write_on() writes the _handle_ and not the naked oop [1]. Right, this part I overlooked. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From lutz.schmidt at sap.com Tue Nov 14 16:45:34 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 14 Nov 2017 16:45:34 +0000 Subject: RFR(L): 8189793: [s390]: Improve String compress/inflate by exploiting vector instructions In-Reply-To: <53479CC5-02DF-4161-9CEE-161D9BECDD0C@sap.com> References: <18ddb703d81a4a22bc97f134dd276eff@sap.com> <6F73CAE2-2FEC-4BC0-9F3A-FEE9748EB694@sap.com> <02fe90a2093144b6a2a1ec0020d9b88f@sap.com> <7702F170-B574-4EF8-8B85-B366B507E7B0@sap.com> <2f718b251d5d4a5bac81dc85eb0644ed@sap.com> <53479CC5-02DF-4161-9CEE-161D9BECDD0C@sap.com> Message-ID: Hi all, Following the request from Martin, I have disabled the ?special case handling? for very short strings. That sacrifices some possible performance advantage for generated code size. Please find the new, updated webrev here: http://cr.openjdk.java.net/~lucy/webrevs/8189793.02/index.html Thanks and best regards, Lutz On 13.11.2017, 12:52, "hotspot-compiler-dev on behalf of Schmidt, Lutz" wrote: Thank you, Goetz! Best Regards, Lutz On 13.11.2017, 12:48, "Lindenmaier, Goetz" wrote: Hi Lutz, thanks for the numbers and for the two fixes. Change looks good now. The numbers indicate that deflation of constant strings at compile time would make sense, as well as optimizing compress for large strings. (if jvm2008 is representative, but I assume it's good enough). Best regards, Goetz. > -----Original Message----- > From: Schmidt, Lutz > Sent: Freitag, 3. November 2017 17:46 > To: Lindenmaier, Goetz ; Doerr, Martin > ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(L): 8189793: [s390]: Improve String compress/inflate by > exploiting vector instructions > > Hi Goetz, > > I agree. Knowing the string length greatly helps to optimize the generated > code, both in terms of size and performance. There are no compress calls > with constant length, though. Constant strings are stored compressed at > compile time. > > Here are some counters I found when running (a subset of) the SPECjvm2008 > suite: > string_compress match count: 11 > string_inflate match count: 171 > string_inflate_const: > len = 1: 10 matches > len = 2: 2 matches > len = 4: 3 matches > len = 6: 9 matches > len = 7: 3 matches > len = 9: 4 matches > len = 10: 5 matches > len = 11: 15 matches > len = 15: 1 matches > len = 17: 1 matches > len = 18: 2 matches > len = 19: 2 matches > len = 29: 1 matches > len = 31: 1 matches > > These (rather few) matches handle a lot of compress/inflate operations: > n #compress #inflate > <16 673 Mio 2895 Mio > <256 207 Mio 704 Mio > <4096 0.7 Mio 1.8 Mio > >=4096 1.1 Mio 0.3 Mio > > > A short not on performance gains: > I have done a lot of performance tests in different settings. With complex > tests, like SPECjvm2008, the positive (or negative) effect of such low-level > optimizations disappears in measurement noise. With a micro benchmark, > just compressing and inflating a string, some effect is visible: > > My new, improved implementation of the intrinsics shows a slight > performance advantage of 1..4% for short strings. Once the vector > instructions kick in (at len >= 32), performance improves by 50..70% for > string_compress and by 50..150% for string_inflate. Measurements show a > high variance, despite testing was done on a system with dedicated cpu > resources and with no concurrent load. > > BTW, there is a new webrev at > http://cr.openjdk.java.net/~lucy/webrevs/8189793.01/index.html > > In addition to the changes mentioned below, it contains two minor, > nevertheless important fixes to the compress intrinsic: > 1) z_bru(skipShortcut); is changed to z_brh(skipShortcut); > 2) Code is added after label ScalarShortcut to check for zero length strings. > > Regards, > Lutz > > > > > On 03.11.2017, 12:44, "Lindenmaier, Goetz" > wrote: > > Hi Lutz, > > I have been looking at your change. I think it's a good idea to match > for constant string length. I did this for the ppc string intrinsics in the > past. > I remember that distribution of constant strings was quite uneven. > StrIndexOf appeared with constant lengths a lot, StrEquals and StrComp > didn't. > > Do you have any data on how often the new match rules match? > > Actually, if there is a constant string deflated, a platform independent > optimization could compute that at compile time, but that's a different > issue ... > > Best regards, > Goetz. > > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > > Sent: Freitag, 27. Oktober 2017 13:07 > > To: Doerr, Martin ; hotspot-compiler- > > dev at openjdk.java.net > > Subject: Re: RFR(L): 8189793: [s390]: Improve String compress/inflate by > > exploiting vector instructions > > > > Hi Martin, > > > > > > > > Thanks for reviewing my change! > > > > > > > > This is a preliminary response just to let you know I?m working on the > > change. I?m putting a lot of effort in producing reliable performance > > measurement data. Turns out this is not easy (to be more honest: almost > > impossible). > > > > > > > > s390.ad: > > > > You are absolutely right, the sequence load_const/string_compress > makes > > no sense at all. But it does not hurt either ? I could not find one match in > all > > tests I ran. -> Match rule deleted. > > > > > > > > macroAssembler_s390: > > > > prefetch: did not see impact, neither positive nor negative. Artificial > micro > > benchmarks will not benefit (data is in cache anyway). More complex > > benchmarks show measurement noise which covers the possible > prefetch > > benefit. -> prefetch deleted. > > > > Hardcoded vector registers: you are right. There are some design > decisions > > pending, e.g. how many vector scratch registers? > > > > Vperm instruction: using that is just another implementation variant that > > could save the vn vector instruction. On the other hand, loading the > index > > vector is a (compared to vgmh) costly memory access. Given the fact that > we > > mostly deal with short strings, initialization effort is relevant. > > > > Code size vs. performance: the old, well known, often discussed > tradeoff. > > Starting from the existing implementation, I invested quite some time in > > optimizing the (len <= 8) cases. With every refinement step I saw (or > > believed to see (measurement noise)) some improvement ? or > discarded it. > > Is the overall improvement worth the larger code size? -> tradeoff, > > discussion. > > > > > > > > Best Regards, > > > > Lutz > > > > > > > > > > > > > > > > On 25.10.2017, 21:08, "Doerr, Martin" > > wrote: > > > > > > > > Hi Lutz, > > > > > > > > thanks for working on vector-based enhancements and for providing this > > webrev. > > > > > > > > assembler_s390: > > > > -The changes in the assembler look good. > > > > > > > > s390.ad: > > > > -It doesn't make sense to load constant len to a register and generate > > complex compare instructions for it and still to emit code for all cases. I > > assume that e.g. the 4 characters cases usually have a constant length. If > so, > > much better code could be generated for them by omitting all the stuff > > around the simple instructions. (ppc64.ad already contains nodes for > > constant length of needle in indexOf rules.) > > > > > > > > macroAssembler_s390: > > > > -Are you sure the prefetch instructions improve performance? > > > > I remember that we had them in other String intrinsics but removed > them > > again as they showed absolutely no performance gain. > > > > -Comment: Using hardcoded vector registers is ok for now, but may need > to > > get changed e.g. when using them for C2's SuperWord optimization. > > > > -Comment: You could use the vperm instruction instead of vo+vn, but I'm > ok > > with the current implementation because loading a mask is much more > > convenient than getting the permutation vector loaded (e.g. from > constant > > pool or pc relative). > > > > -So the new vector loop looks good to me. > > > > -In my opinion, the size of all the generated cases should be in > relationship to > > their performance benefit. > > > > As intrinsics are not like stubs and may get inlined often, I can't get rid of > the > > impression that generating so large code wastes valuable code cache > space > > with questionable performance gain in real world scenarios. > > > > > > > > Best regards, > > > > Martin > > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > > Sent: Mittwoch, 25. Oktober 2017 12:02 > > To: hotspot-compiler-dev at openjdk.java.net > > Subject: RFR(L): 8189793: [s390]: Improve String compress/inflate by > > exploiting vector instructions > > > > > > > > Dear all, > > > > > > > > I would like to request reviews for this s390-only enhancement: > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189793 > > > > Webrev: > http://cr.openjdk.java.net/~lucy/webrevs/8189793.00/index.html > > > > > > > > Vector instructions, which have been available on System z for a while > (since > > z13), promise noticeable performance improvements. This enhancement > > improves the String Compress and String Inflate intrinsics by exploiting > vector > > instructions, when available. For long strings, up to 2x performance > > improvement has been observed in micro-benchmarks. > > > > > > > > Special care was taken to preserve good performance for short strings. > All > > examined workloads showed a high ratio of short and very short strings. > > > > > > > > Thank you! > > > > Lutz > > > > > > > > > > > > > > > > > > > > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 (6227) 7-42834 > > > > > > From rkennke at redhat.com Tue Nov 14 17:00:23 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Nov 2017 18:00:23 +0100 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <4D5DC152-B7B2-4E89-81B9-D9A291E943E0@redhat.com> Message-ID: <320433c9-5ce2-0426-0de8-8b135acaf85f@redhat.com> Am 14.11.2017 um 17:04 schrieb Vladimir Ivanov: > Thanks, now I see that as well: OopRecorder::find_index() can delegate > to ObjectLookup::find_index() which does resolve the handle w/o > transitioning to VM. > > But I don't believe you hit that path: ObjectLookup was added as part > of JVMCI and is guarded by a flag (deduplicate) which is turned on > only for JVMCI. Ah ok. Didn't know that. However, as Aleksey pointed out, we hit JNIHandles::resolve() in product path, JVMCI or not, and this touches the naked oop by comparing it with another oop. This doesn't sound like a reliable thing to do. This simple change seems to fix it: https://paste.fedoraproject.org/paste/poQ5caTCuN6jHSGbK1n0iQ Doing more testing... Roman > Anyway, I'll file a bug to investigate ObjectLookup::find_index(). > > Best regards, > Vladimir Ivanov > > On 11/14/17 6:45 PM, Roman Kennke wrote: >> The code below the assert also unwraps the oop and does lookups with >> it. I'm not on my computer but I can dig out the relevant parts when >> I'm back at work... >> >> Roman >> >> >> Am 14. November 2017 16:36:10 MEZ schrieb Vladimir Ivanov >> : >> >> ??? Aleksey, >> >> ??? I agree with your & Roman analysis: compilers shouldn't touch >> naked oops >> ??? unless the thread is in _thread_in_vm mode. >> >> ??? Looking at the crash log, the problematic code is under assert: >> >> ??? void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { >> ??????? assert(JNIHandles::resolve(value()) == NULL || >> Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), >> ?????????????? "Should be in heap"); >> ??????? stream->write_int(CONSTANT_OOP_CODE); >> ??????? stream->write_handle(value()); >> ??? } >> >> ??? So, the proper fix would be to make the verification code more >> robust. >> >> ??? Best regards, >> ??? Vladimir Ivanov >> >> ??? On 11/14/17 5:16 PM, Aleksey Shipilev wrote: >> >> ??????? Hi, >> >> ??????? In some of our aggressive test configurations for Shenandoah, we >> ??????? sometimes see the following failure: >> http://cr.openjdk.java.net/~shade/shenandoah/c1-race-fail-hs_err.log >> >> ??????? It seems to happen when C1 code installation is happening during >> ??????? Full GC. >> >> ??????? The actual failure is caused by touching the >> ??????? JNIHandles::deleted_handle() oop in >> ??????? JNIHandles::guard_value() during JNIHandles::resolve() against >> ??????? the constant oop handle when we are >> ??????? recording the debugging information for C1-generated Java call: >> http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 >> >> ??????? The C1 thread is in _thread_in_native state, and so the runtime >> ??????? thinks the thread is at safepoint, >> ??????? but the thread touches the deleted_handle oop(). When Shenandoah >> ??????? dives into Full GC and moves that >> ??????? object at the same time, everything crashes and burns. >> >> ??????? Is C1 (and any other compiler thread) supposed to transit to >> ??????? _vm_state when touching the naked oops, >> ??????? and thus coordinate with safepoints? I see VM_ENTRY_MARK all >> ??????? over ci* that seems to transit there >> ??????? before accessing the heap. Does that mean we need the same >> ??????? everywhere around JNIHandles::resolve too? >> >> ??????? Or is there some other mechanism that is supposed to get >> ??????? compiler threads to coordinate with GC? >> >> ??????? Thanks, >> ??????? -Aleksey >> >> >> -- >> Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From shade at redhat.com Tue Nov 14 17:04:12 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Nov 2017 18:04:12 +0100 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <98013a00-48ad-86d9-b2d4-90f3a2df074d@redhat.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <6cb75d25-11c7-a199-8aa9-ce769252c031@redhat.com> <28cf279a-93ca-2902-7f1b-ad44e3ccd69d@oracle.com> <98013a00-48ad-86d9-b2d4-90f3a2df074d@redhat.com> Message-ID: On 11/14/2017 05:37 PM, Aleksey Shipilev wrote: > On 11/14/2017 05:23 PM, Vladimir Ivanov wrote: >>> Actually, in Shenandoah case, the failure is here (it is obscured by inlining, but visible in >>> slowdebug): >>> ?? http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 >>> >>> ... "== deleted_handle()" or "!= deleted_handle()". So fortifying assert code does not help, the bug >>> is touching the oop in improper thread state. Nightmarish scenario would be to fail "!="/"==" check >>> because the deleted_handle oop had been already updated, but the actual handle value did not. >> > > See this line: > http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l224 > > } else if ((value == badJNIHandle) || (value == deleted_handle())) { > value = NULL; > } > return value; > > If we ever get in that code during the GC, we might get the deleted_handle() updated by GC code > (because it is a root via JNIHandles), but the $value may be not updated, and still point to old > location. Then "value == deleted_handle()" fails, and we return broken oop from guard_value. Notice > this code is not under the assert. > > It seems to me the symptom of larger problem: touching naked oops is seldom reliable, if the thread > is inconsistent state. It does not seem right to fix asserts, because the real trouble is touching > that oop on product paths. It appears to work for other GCs, but for Shenandoah this failure is > observable, because its barriers touch heap through the oops. FTR, this is the minimal change that makes Shenandoah pass the stress tests: $ hg diff diff -r ac4d369eac91 src/hotspot/share/code/debugInfo.cpp --- a/src/hotspot/share/code/debugInfo.cpp Tue Nov 14 12:27:52 2017 +0100 +++ b/src/hotspot/share/code/debugInfo.cpp Tue Nov 14 17:54:44 2017 +0100 @@ -209,6 +209,7 @@ // ConstantOopWriteValue void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { + VM_ENTRY_MARK; assert(JNIHandles::resolve(value()) == NULL || Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), "Should be in heap"); And this is the change that avoids the Shenandoah crash (because it does not do read barriers on value and deleted_handle()), but still is subject to GC-compiler race explained above: $ hg diff diff -r ac4d369eac91 src/hotspot/share/runtime/jniHandles.hpp --- a/src/hotspot/share/runtime/jniHandles.hpp Tue Nov 14 12:27:52 2017 +0100 +++ b/src/hotspot/share/runtime/jniHandles.hpp Tue Nov 14 17:58:22 2017 +0100 @@ -219,8 +219,8 @@ inline oop JNIHandles::guard_value(oop value) { if (!external_guard) { assert(!oopDesc::unsafe_equals(value, badJNIHandle), "Pointing to zapped jni handle area"); - assert(!oopDesc::equals(value, deleted_handle()), "Used a deleted global handle"); - } else if (oopDesc::unsafe_equals(value, badJNIHandle) || oopDesc::equals(value, deleted_handle())) { + assert(!oopDesc::unsafe_equals(value, deleted_handle()), "Used a deleted global handle"); + } else if (oopDesc::unsafe_equals(value, badJNIHandle) || oopDesc::unsafe_equals(value, deleted_handle())) { value = NULL; } return value; Neither feels like a proper fix. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.x.ivanov at oracle.com Tue Nov 14 17:21:46 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Nov 2017 20:21:46 +0300 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <320433c9-5ce2-0426-0de8-8b135acaf85f@redhat.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <4D5DC152-B7B2-4E89-81B9-D9A291E943E0@redhat.com> <320433c9-5ce2-0426-0de8-8b135acaf85f@redhat.com> Message-ID: <769ad8d4-0d8b-d2c0-d586-a823a1d61ef6@oracle.com> On 11/14/17 8:00 PM, Roman Kennke wrote: > Am 14.11.2017 um 17:04 schrieb Vladimir Ivanov: >> Thanks, now I see that as well: OopRecorder::find_index() can delegate >> to ObjectLookup::find_index() which does resolve the handle w/o >> transitioning to VM. >> >> But I don't believe you hit that path: ObjectLookup was added as part >> of JVMCI and is guarded by a flag (deduplicate) which is turned on >> only for JVMCI. > Ah ok. Didn't know that. > > However, as Aleksey pointed out, we hit JNIHandles::resolve() in product > path, JVMCI or not, and this touches the naked oop by comparing it with > another oop. This doesn't sound like a reliable thing to do. Can you double-check you observe the crash with product binaries as well? My current understanding is that it happens only with debug builds. Best regards, Vladimir Ivanov > This simple change seems to fix it: > https://paste.fedoraproject.org/paste/poQ5caTCuN6jHSGbK1n0iQ > > Doing more testing... > > Roman > >> Anyway, I'll file a bug to investigate ObjectLookup::find_index(). >> >> Best regards, >> Vladimir Ivanov >> >> On 11/14/17 6:45 PM, Roman Kennke wrote: >>> The code below the assert also unwraps the oop and does lookups with >>> it. I'm not on my computer but I can dig out the relevant parts when >>> I'm back at work... >>> >>> Roman >>> >>> >>> Am 14. November 2017 16:36:10 MEZ schrieb Vladimir Ivanov >>> : >>> >>> ??? Aleksey, >>> >>> ??? I agree with your & Roman analysis: compilers shouldn't touch >>> naked oops >>> ??? unless the thread is in _thread_in_vm mode. >>> >>> ??? Looking at the crash log, the problematic code is under assert: >>> >>> ??? void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { >>> ??????? assert(JNIHandles::resolve(value()) == NULL || >>> Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), >>> ?????????????? "Should be in heap"); >>> ??????? stream->write_int(CONSTANT_OOP_CODE); >>> ??????? stream->write_handle(value()); >>> ??? } >>> >>> ??? So, the proper fix would be to make the verification code more >>> robust. >>> >>> ??? Best regards, >>> ??? Vladimir Ivanov >>> >>> ??? On 11/14/17 5:16 PM, Aleksey Shipilev wrote: >>> >>> ??????? Hi, >>> >>> ??????? In some of our aggressive test configurations for Shenandoah, we >>> ??????? sometimes see the following failure: >>> http://cr.openjdk.java.net/~shade/shenandoah/c1-race-fail-hs_err.log >>> >>> ??????? It seems to happen when C1 code installation is happening during >>> ??????? Full GC. >>> >>> ??????? The actual failure is caused by touching the >>> ??????? JNIHandles::deleted_handle() oop in >>> ??????? JNIHandles::guard_value() during JNIHandles::resolve() against >>> ??????? the constant oop handle when we are >>> ??????? recording the debugging information for C1-generated Java call: >>> http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 >>> >>> >>> ??????? The C1 thread is in _thread_in_native state, and so the runtime >>> ??????? thinks the thread is at safepoint, >>> ??????? but the thread touches the deleted_handle oop(). When Shenandoah >>> ??????? dives into Full GC and moves that >>> ??????? object at the same time, everything crashes and burns. >>> >>> ??????? Is C1 (and any other compiler thread) supposed to transit to >>> ??????? _vm_state when touching the naked oops, >>> ??????? and thus coordinate with safepoints? I see VM_ENTRY_MARK all >>> ??????? over ci* that seems to transit there >>> ??????? before accessing the heap. Does that mean we need the same >>> ??????? everywhere around JNIHandles::resolve too? >>> >>> ??????? Or is there some other mechanism that is supposed to get >>> ??????? compiler threads to coordinate with GC? >>> >>> ??????? Thanks, >>> ??????? -Aleksey >>> >>> >>> -- >>> Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. > > From rkennke at redhat.com Tue Nov 14 17:26:35 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Nov 2017 18:26:35 +0100 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <320433c9-5ce2-0426-0de8-8b135acaf85f@redhat.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <4D5DC152-B7B2-4E89-81B9-D9A291E943E0@redhat.com> <320433c9-5ce2-0426-0de8-8b135acaf85f@redhat.com> Message-ID: Am 14.11.2017 um 18:00 schrieb Roman Kennke: > Am 14.11.2017 um 17:04 schrieb Vladimir Ivanov: >> Thanks, now I see that as well: OopRecorder::find_index() can >> delegate to ObjectLookup::find_index() which does resolve the handle >> w/o transitioning to VM. >> >> But I don't believe you hit that path: ObjectLookup was added as part >> of JVMCI and is guarded by a flag (deduplicate) which is turned on >> only for JVMCI. > Ah ok. Didn't know that. > > However, as Aleksey pointed out, we hit JNIHandles::resolve() in > product path, JVMCI or not, and this touches the naked oop by > comparing it with another oop. This doesn't sound like a reliable > thing to do. Scratch that. Looking at the code paths again, this doesn't seem to be true. I.e. we hit JNIHandles::resolve() only in assert and ObjectLookup (I trust you that it's only JVMCI). Not sure if it can be robust to compare oops in assert paths. It sure is a race and doesn't feel very well. I wonder if we should introduce a CollectedHeap::is_in_or_null(jobject) method, and let the GC figure it out. It might actually have a way to check it (simple address range check) without sending the thread to VM state. Roman > > This simple change seems to fix it: > https://paste.fedoraproject.org/paste/poQ5caTCuN6jHSGbK1n0iQ > > Doing more testing... > > Roman > >> Anyway, I'll file a bug to investigate ObjectLookup::find_index(). >> >> Best regards, >> Vladimir Ivanov >> >> On 11/14/17 6:45 PM, Roman Kennke wrote: >>> The code below the assert also unwraps the oop and does lookups with >>> it. I'm not on my computer but I can dig out the relevant parts when >>> I'm back at work... >>> >>> Roman >>> >>> >>> Am 14. November 2017 16:36:10 MEZ schrieb Vladimir Ivanov >>> : >>> >>> ??? Aleksey, >>> >>> ??? I agree with your & Roman analysis: compilers shouldn't touch >>> naked oops >>> ??? unless the thread is in _thread_in_vm mode. >>> >>> ??? Looking at the crash log, the problematic code is under assert: >>> >>> ??? void ConstantOopWriteValue::write_on(DebugInfoWriteStream* >>> stream) { >>> ??????? assert(JNIHandles::resolve(value()) == NULL || >>> Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), >>> ?????????????? "Should be in heap"); >>> ??????? stream->write_int(CONSTANT_OOP_CODE); >>> ??????? stream->write_handle(value()); >>> ??? } >>> >>> ??? So, the proper fix would be to make the verification code more >>> robust. >>> >>> ??? Best regards, >>> ??? Vladimir Ivanov >>> >>> ??? On 11/14/17 5:16 PM, Aleksey Shipilev wrote: >>> >>> ??????? Hi, >>> >>> ??????? In some of our aggressive test configurations for >>> Shenandoah, we >>> ??????? sometimes see the following failure: >>> http://cr.openjdk.java.net/~shade/shenandoah/c1-race-fail-hs_err.log >>> >>> ??????? It seems to happen when C1 code installation is happening >>> during >>> ??????? Full GC. >>> >>> ??????? The actual failure is caused by touching the >>> ??????? JNIHandles::deleted_handle() oop in >>> ??????? JNIHandles::guard_value() during JNIHandles::resolve() against >>> ??????? the constant oop handle when we are >>> ??????? recording the debugging information for C1-generated Java call: >>> http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 >>> >>> >>> ??????? The C1 thread is in _thread_in_native state, and so the runtime >>> ??????? thinks the thread is at safepoint, >>> ??????? but the thread touches the deleted_handle oop(). When >>> Shenandoah >>> ??????? dives into Full GC and moves that >>> ??????? object at the same time, everything crashes and burns. >>> >>> ??????? Is C1 (and any other compiler thread) supposed to transit to >>> ??????? _vm_state when touching the naked oops, >>> ??????? and thus coordinate with safepoints? I see VM_ENTRY_MARK all >>> ??????? over ci* that seems to transit there >>> ??????? before accessing the heap. Does that mean we need the same >>> ??????? everywhere around JNIHandles::resolve too? >>> >>> ??????? Or is there some other mechanism that is supposed to get >>> ??????? compiler threads to coordinate with GC? >>> >>> ??????? Thanks, >>> ??????? -Aleksey >>> >>> >>> -- >>> Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. > > From shade at redhat.com Tue Nov 14 18:18:26 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Nov 2017 19:18:26 +0100 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <6cb75d25-11c7-a199-8aa9-ce769252c031@redhat.com> <28cf279a-93ca-2902-7f1b-ad44e3ccd69d@oracle.com> <98013a00-48ad-86d9-b2d4-90f3a2df074d@redhat.com> Message-ID: <12f7d3e9-5fea-eaa6-565c-cdf06058bbe5@redhat.com> On 11/14/2017 06:04 PM, Aleksey Shipilev wrote: > On 11/14/2017 05:37 PM, Aleksey Shipilev wrote: >> On 11/14/2017 05:23 PM, Vladimir Ivanov wrote: >>>> Actually, in Shenandoah case, the failure is here (it is obscured by inlining, but visible in >>>> slowdebug): >>>> ?? http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 >>>> >>>> ... "== deleted_handle()" or "!= deleted_handle()". So fortifying assert code does not help, the bug >>>> is touching the oop in improper thread state. Nightmarish scenario would be to fail "!="/"==" check >>>> because the deleted_handle oop had been already updated, but the actual handle value did not. >>> >> >> See this line: >> http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l224 >> >> } else if ((value == badJNIHandle) || (value == deleted_handle())) { >> value = NULL; >> } >> return value; >> >> If we ever get in that code during the GC, we might get the deleted_handle() updated by GC code >> (because it is a root via JNIHandles), but the $value may be not updated, and still point to old >> location. Then "value == deleted_handle()" fails, and we return broken oop from guard_value. Notice >> this code is not under the assert. >> >> It seems to me the symptom of larger problem: touching naked oops is seldom reliable, if the thread >> is inconsistent state. It does not seem right to fix asserts, because the real trouble is touching >> that oop on product paths. It appears to work for other GCs, but for Shenandoah this failure is >> observable, because its barriers touch heap through the oops. > > FTR, this is the minimal change that makes Shenandoah pass the stress tests: > > $ hg diff > diff -r ac4d369eac91 src/hotspot/share/code/debugInfo.cpp > --- a/src/hotspot/share/code/debugInfo.cpp Tue Nov 14 12:27:52 2017 +0100 > +++ b/src/hotspot/share/code/debugInfo.cpp Tue Nov 14 17:54:44 2017 +0100 > @@ -209,6 +209,7 @@ > // ConstantOopWriteValue > > void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { > + VM_ENTRY_MARK; > assert(JNIHandles::resolve(value()) == NULL || > Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), > "Should be in heap"); > > Neither feels like a proper fix. Well, VM_ENTRY_MARK is a decent enough workaround, so we are flying with that: http://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-November/004296.html Happy to pick up the proper fix, if this is not the one. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dean.long at oracle.com Tue Nov 14 18:27:52 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 14 Nov 2017 10:27:52 -0800 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: References: Message-ID: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> Adding runtime alias... comments inlined below. On 11/13/17 9:10 PM, jamsheed wrote: > Hi, request for review, jbs: > https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: > http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) > changes equivalent to JDK-4454115 is done for windows. It looks like "nm" can be uninitialized if "in_java" is false. > 2) added guard to multiple value access sites, Unsafe_CopyMemory0, > Unsafe_SetMemory0 and Unsafe_CopySwapMemory0. Can you narrow the scope of the unsafe access using something like GuardUnsafeAccess, instead of marking the whole function as doing unsafe access? There are some risks with trying to? abort a copy function. First, won't we get multiple exceptions until we finally hit the end of the range?? What if the bad range is very large? Second, what if the loop is using auto-increment instructions? Skipping to the next instruction would mean we loop forever if the increment never happens. I think if we are going to safely abort copy functions then we need to register them as a kind of CodeBlob that has a special abort entry point or exception handler we can redirect to, or maybe pop the whole frame and return. Is there really a problem with these copy functions?? I'm wondering why Mikael did not identify these as a problem in 8154592. > 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed > thread->thread_state() == _thread_in_vm checks from signal handler How about adding a check for _thread_in_native instead of removing the check entirely? dl > Best regards, Jamsheed > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Tue Nov 14 18:33:27 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Nov 2017 21:33:27 +0300 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <12f7d3e9-5fea-eaa6-565c-cdf06058bbe5@redhat.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <6cb75d25-11c7-a199-8aa9-ce769252c031@redhat.com> <28cf279a-93ca-2902-7f1b-ad44e3ccd69d@oracle.com> <98013a00-48ad-86d9-b2d4-90f3a2df074d@redhat.com> <12f7d3e9-5fea-eaa6-565c-cdf06058bbe5@redhat.com> Message-ID: FYI just filed JDK-8191227 [1]. Thanks for the report! Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8191227 On 11/14/17 9:18 PM, Aleksey Shipilev wrote: > On 11/14/2017 06:04 PM, Aleksey Shipilev wrote: >> On 11/14/2017 05:37 PM, Aleksey Shipilev wrote: >>> On 11/14/2017 05:23 PM, Vladimir Ivanov wrote: >>>>> Actually, in Shenandoah case, the failure is here (it is obscured by inlining, but visible in >>>>> slowdebug): >>>>> ?? http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 >>>>> >>>>> ... "== deleted_handle()" or "!= deleted_handle()". So fortifying assert code does not help, the bug >>>>> is touching the oop in improper thread state. Nightmarish scenario would be to fail "!="/"==" check >>>>> because the deleted_handle oop had been already updated, but the actual handle value did not. >>>> >>> >>> See this line: >>> http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l224 >>> >>> } else if ((value == badJNIHandle) || (value == deleted_handle())) { >>> value = NULL; >>> } >>> return value; >>> >>> If we ever get in that code during the GC, we might get the deleted_handle() updated by GC code >>> (because it is a root via JNIHandles), but the $value may be not updated, and still point to old >>> location. Then "value == deleted_handle()" fails, and we return broken oop from guard_value. Notice >>> this code is not under the assert. >>> >>> It seems to me the symptom of larger problem: touching naked oops is seldom reliable, if the thread >>> is inconsistent state. It does not seem right to fix asserts, because the real trouble is touching >>> that oop on product paths. It appears to work for other GCs, but for Shenandoah this failure is >>> observable, because its barriers touch heap through the oops. >> >> FTR, this is the minimal change that makes Shenandoah pass the stress tests: >> >> $ hg diff >> diff -r ac4d369eac91 src/hotspot/share/code/debugInfo.cpp >> --- a/src/hotspot/share/code/debugInfo.cpp Tue Nov 14 12:27:52 2017 +0100 >> +++ b/src/hotspot/share/code/debugInfo.cpp Tue Nov 14 17:54:44 2017 +0100 >> @@ -209,6 +209,7 @@ >> // ConstantOopWriteValue >> >> void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) { >> + VM_ENTRY_MARK; >> assert(JNIHandles::resolve(value()) == NULL || >> Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), >> "Should be in heap"); >> >> Neither feels like a proper fix. > > Well, VM_ENTRY_MARK is a decent enough workaround, so we are flying with that: > http://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-November/004296.html > > Happy to pick up the proper fix, if this is not the one. > > -Aleksey > From vladimir.x.ivanov at oracle.com Tue Nov 14 18:38:33 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Nov 2017 21:38:33 +0300 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <4D5DC152-B7B2-4E89-81B9-D9A291E943E0@redhat.com> <320433c9-5ce2-0426-0de8-8b135acaf85f@redhat.com> Message-ID: >> However, as Aleksey pointed out, we hit JNIHandles::resolve() in >> product path, JVMCI or not, and this touches the naked oop by >> comparing it with another oop. This doesn't sound like a reliable >> thing to do. > Scratch that. Looking at the code paths again, this doesn't seem to be > true. I.e. we hit JNIHandles::resolve() only in assert and ObjectLookup > (I trust you that it's only JVMCI). Not sure if it can be robust to > compare oops in assert paths. It sure is a race and doesn't feel very well. > > I wonder if we should introduce a CollectedHeap::is_in_or_null(jobject) > method, and let the GC figure it out. It might actually have a way to > check it (simple address range check) without sending the thread to VM > state. Yes, the assert just sanity checks that the handlized oop points into the heap. Depending on the complexity of the check, I'd consider the following options: * dedicated CollectedHeap::is_in_or_null(jobject) * ThreadInVMfromNative under #ifdef ASSERT (or factored out) * completely remove the assert Best regards, Vladimir Ivanov >> >> This simple change seems to fix it: >> https://paste.fedoraproject.org/paste/poQ5caTCuN6jHSGbK1n0iQ >> >> Doing more testing... >> >> Roman >> >>> Anyway, I'll file a bug to investigate ObjectLookup::find_index(). >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/14/17 6:45 PM, Roman Kennke wrote: >>>> The code below the assert also unwraps the oop and does lookups with >>>> it. I'm not on my computer but I can dig out the relevant parts when >>>> I'm back at work... >>>> >>>> Roman >>>> >>>> >>>> Am 14. November 2017 16:36:10 MEZ schrieb Vladimir Ivanov >>>> : >>>> >>>> ??? Aleksey, >>>> >>>> ??? I agree with your & Roman analysis: compilers shouldn't touch >>>> naked oops >>>> ??? unless the thread is in _thread_in_vm mode. >>>> >>>> ??? Looking at the crash log, the problematic code is under assert: >>>> >>>> ??? void ConstantOopWriteValue::write_on(DebugInfoWriteStream* >>>> stream) { >>>> ??????? assert(JNIHandles::resolve(value()) == NULL || >>>> Universe::heap()->is_in_reserved(JNIHandles::resolve(value())), >>>> ?????????????? "Should be in heap"); >>>> ??????? stream->write_int(CONSTANT_OOP_CODE); >>>> ??????? stream->write_handle(value()); >>>> ??? } >>>> >>>> ??? So, the proper fix would be to make the verification code more >>>> robust. >>>> >>>> ??? Best regards, >>>> ??? Vladimir Ivanov >>>> >>>> ??? On 11/14/17 5:16 PM, Aleksey Shipilev wrote: >>>> >>>> ??????? Hi, >>>> >>>> ??????? In some of our aggressive test configurations for >>>> Shenandoah, we >>>> ??????? sometimes see the following failure: >>>> http://cr.openjdk.java.net/~shade/shenandoah/c1-race-fail-hs_err.log >>>> >>>> ??????? It seems to happen when C1 code installation is happening >>>> during >>>> ??????? Full GC. >>>> >>>> ??????? The actual failure is caused by touching the >>>> ??????? JNIHandles::deleted_handle() oop in >>>> ??????? JNIHandles::guard_value() during JNIHandles::resolve() against >>>> ??????? the constant oop handle when we are >>>> ??????? recording the debugging information for C1-generated Java call: >>>> http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220 >>>> >>>> >>>> ??????? The C1 thread is in _thread_in_native state, and so the runtime >>>> ??????? thinks the thread is at safepoint, >>>> ??????? but the thread touches the deleted_handle oop(). When >>>> Shenandoah >>>> ??????? dives into Full GC and moves that >>>> ??????? object at the same time, everything crashes and burns. >>>> >>>> ??????? Is C1 (and any other compiler thread) supposed to transit to >>>> ??????? _vm_state when touching the naked oops, >>>> ??????? and thus coordinate with safepoints? I see VM_ENTRY_MARK all >>>> ??????? over ci* that seems to transit there >>>> ??????? before accessing the heap. Does that mean we need the same >>>> ??????? everywhere around JNIHandles::resolve too? >>>> >>>> ??????? Or is there some other mechanism that is supposed to get >>>> ??????? compiler threads to coordinate with GC? >>>> >>>> ??????? Thanks, >>>> ??????? -Aleksey >>>> >>>> >>>> -- >>>> Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. >> >> > From jamsheed.c.m at oracle.com Tue Nov 14 19:32:02 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Wed, 15 Nov 2017 01:02:02 +0530 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> References: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> Message-ID: <200961d9-f62d-ab2c-f0fe-eb2892c52440@oracle.com> Hi Dean, Thank you for the feedback, On Tuesday 14 November 2017 11:57 PM, dean.long at oracle.com wrote: > Adding runtime alias... > > comments inlined below. > > > On 11/13/17 9:10 PM, jamsheed wrote: > >> Hi, request for review, jbs: >> https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: >> http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) >> changes equivalent to JDK-4454115 is done for windows. > > It looks like "nm" can be uninitialized if "in_java" is false. that was a miss, thank you for pointing that. > >> 2) added guard to multiple value access sites, Unsafe_CopyMemory0, >> Unsafe_SetMemory0 and Unsafe_CopySwapMemory0. > > Can you narrow the scope of the unsafe access using something like > GuardUnsafeAccess, instead of marking the whole function as doing > unsafe access? can do that, but i don't find an issue with putting guard for the whole function. > > There are some risks with trying to? abort a copy function. > > First, won't we get multiple exceptions until we finally hit the end > of the range?? What if the bad range is very large? we may get multiple exception, and we may reach safepoint a bit late, this should be case in compiled code too, where we use intrinsics > > Second, what if the loop is using auto-increment instructions? > Skipping to the next instruction would mean we loop forever if the > increment never happens. we move to next instruction, so will exit loop, no backward branching right ? > > I think if we are going to safely abort copy functions then we need to > register them as a kind of CodeBlob that has a special abort entry > point or exception handler we can redirect to, or maybe pop the whole > frame and return. > > Is there really a problem with these copy functions?? I'm wondering > why Mikael did not identify these as a problem in 8154592. > >> 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed >> thread->thread_state() == _thread_in_vm checks from signal handler > > How about adding a check for _thread_in_native instead of removing the > check entirely? ok i will add that. Best regards, Jamsheed > > dl > >> Best regards, Jamsheed >> > From rkennke at redhat.com Tue Nov 14 19:46:48 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Nov 2017 20:46:48 +0100 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <4D5DC152-B7B2-4E89-81B9-D9A291E943E0@redhat.com> <320433c9-5ce2-0426-0de8-8b135acaf85f@redhat.com> Message-ID: <43de40fc-a585-3096-6a67-5e8e7e64ad68@redhat.com> Am 14.11.2017 um 19:38 schrieb Vladimir Ivanov: >>> However, as Aleksey pointed out, we hit JNIHandles::resolve() in >>> product path, JVMCI or not, and this touches the naked oop by >>> comparing it with another oop. This doesn't sound like a reliable >>> thing to do. >> Scratch that. Looking at the code paths again, this doesn't seem to >> be true. I.e. we hit JNIHandles::resolve() only in assert and >> ObjectLookup (I trust you that it's only JVMCI). Not sure if it can >> be robust to compare oops in assert paths. It sure is a race and >> doesn't feel very well. >> >> I wonder if we should introduce a >> CollectedHeap::is_in_or_null(jobject) method, and let the GC figure >> it out. It might actually have a way to check it (simple address >> range check) without sending the thread to VM state. > > Yes, the assert just sanity checks that the handlized oop points into > the heap. > > Depending on the complexity of the check, I'd consider the following > options: > ? * dedicated CollectedHeap::is_in_or_null(jobject) This would require some sort of JNIHandles::resolve_raw() or similar, that bypasses the checks. I don't really like it. > ? * ThreadInVMfromNative under #ifdef ASSERT (or factored out) Different safepointing behaviour in release vs. debug build? Don't know... > ? * completely remove the assert Maybe. The root of the evil is still that we're accessing the naked oop while potentially at a safepoint (and oops moving around). You already established that JVMCI doesn't have the problem because it's already transitioned into VM. Why not make the other compilers consistent? I.e. transition into VM (VM_ENTRY_MARK) before going into the same code path. >From the looks of it, code paths start to be shared between JVMCI and others starting around DebugInformationRecorder::create_scope_values(GrowableArray*), i.e. the VM_ENTRY_MARK could be placed around that in, e.g., void CodeEmitInfo::record_debug_info(DebugInformationRecorder* recorder, int pc_offset) { ? // record the safepoint before recording the debug info for enclosing scopes ? VM_ENTRY_MARK; ? recorder->add_safepoint(pc_offset, _oop_map->deep_copy()); ? _scope_debug_info->record_debug_info(recorder, pc_offset, true/*topmost*/, _is_method_handle_invoke); ? recorder->end_safepoint(pc_offset); } Although similarities between this code and related code in JVMCI would suggest to place the VM_ENTRY_MARK even higher in the call stack. WDYT? Roman From jamsheed.c.m at oracle.com Tue Nov 14 19:58:11 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Wed, 15 Nov 2017 01:28:11 +0530 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: <200961d9-f62d-ab2c-f0fe-eb2892c52440@oracle.com> References: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> <200961d9-f62d-ab2c-f0fe-eb2892c52440@oracle.com> Message-ID: <8feaa96f-50cb-daa3-3e4d-6f4b0b255c3c@oracle.com> sorry, we do loop, even for autoincrement case only if both from and to are invalid we may loop for ever, i didn't assume that case Best regards, Jamsheed On Wednesday 15 November 2017 01:02 AM, jamsheed wrote: > Second, what if the loop is using auto-increment instructions? > Skipping to the next instruction would mean we loop forever if the > increment never happens. From jamsheed.c.m at oracle.com Tue Nov 14 20:23:18 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Wed, 15 Nov 2017 01:53:18 +0530 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: <8feaa96f-50cb-daa3-3e4d-6f4b0b255c3c@oracle.com> References: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> <200961d9-f62d-ab2c-f0fe-eb2892c52440@oracle.com> <8feaa96f-50cb-daa3-3e4d-6f4b0b255c3c@oracle.com> Message-ID: only problem i see in autoincrement is in? unsafe.setMemory(base, size, (byte) 0), may be i will skip this case. and maintain same implementation for copy and copyswap, as i assume autoincrement? for count wouldn't happen in single instruction for these two case. Best regards, Jamsheed On Wednesday 15 November 2017 01:28 AM, jamsheed wrote: > sorry, we do loop, even for autoincrement case only if both from and > to are invalid we may loop for ever, i didn't assume that case > > Best regards, > > Jamsheed > > > On Wednesday 15 November 2017 01:02 AM, jamsheed wrote: >> Second, what if the loop is using auto-increment instructions? >> Skipping to the next instruction would mean we loop forever if the >> increment never happens. > From jamsheed.c.m at oracle.com Tue Nov 14 21:11:08 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Wed, 15 Nov 2017 02:41:08 +0530 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> References: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> Message-ID: <2c16f1ff-57fc-9fed-2290-7e3a99c6a741@oracle.com> Hi Dean, revised webrev: http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ i agree to the comment that it is potentially unsafe to assume the implementation, and count can be in autoincrement mode. so with this bug i would like to deal with only the single value access error handling. revised webrev: http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ Best regards, Jamsheed On Tuesday 14 November 2017 11:57 PM, dean.long at oracle.com wrote: > Adding runtime alias... > > comments inlined below. > > > On 11/13/17 9:10 PM, jamsheed wrote: > >> Hi, request for review, jbs: >> https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: >> http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) >> changes equivalent to JDK-4454115 is done for windows. > > It looks like "nm" can be uninitialized if "in_java" is false. > >> 2) added guard to multiple value access sites, Unsafe_CopyMemory0, >> Unsafe_SetMemory0 and Unsafe_CopySwapMemory0. > > Can you narrow the scope of the unsafe access using something like > GuardUnsafeAccess, instead of marking the whole function as doing > unsafe access? > > There are some risks with trying to? abort a copy function. > > First, won't we get multiple exceptions until we finally hit the end > of the range?? What if the bad range is very large? > > Second, what if the loop is using auto-increment instructions? > Skipping to the next instruction would mean we loop forever if the > increment never happens. > > I think if we are going to safely abort copy functions then we need to > register them as a kind of CodeBlob that has a special abort entry > point or exception handler we can redirect to, or maybe pop the whole > frame and return. > > Is there really a problem with these copy functions?? I'm wondering > why Mikael did not identify these as a problem in 8154592. > >> 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed >> thread->thread_state() == _thread_in_vm checks from signal handler > > How about adding a check for _thread_in_native instead of removing the > check entirely? > > dl > >> Best regards, Jamsheed >> > From david.holmes at oracle.com Tue Nov 14 21:15:36 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Nov 2017 07:15:36 +1000 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> References: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> Message-ID: On 15/11/2017 4:27 AM, dean.long at oracle.com wrote: > Adding runtime alias... Thanks Dean! > comments inlined below. > > > On 11/13/17 9:10 PM, jamsheed wrote: > >> Hi, request for review, jbs: >> https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: >> http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) >> changes equivalent to JDK-4454115 is done for windows. > > It looks like "nm" can be uninitialized if "in_java" is false. > >> 2) added guard to multiple value access sites, Unsafe_CopyMemory0, >> Unsafe_SetMemory0 and Unsafe_CopySwapMemory0. > > Can you narrow the scope of the unsafe access using something like > GuardUnsafeAccess, instead of marking the whole function as doing unsafe > access? I tend to agree with this suggestion. The unsafe region should be as narrow as possible. > There are some risks with trying to? abort a copy function. > > First, won't we get multiple exceptions until we finally hit the end of > the range?? What if the bad range is very large? > > Second, what if the loop is using auto-increment instructions? Skipping > to the next instruction would mean we loop forever if the increment > never happens. > > I think if we are going to safely abort copy functions then we need to > register them as a kind of CodeBlob that has a special abort entry point > or exception handler we can redirect to, or maybe pop the whole frame > and return. Jamsheed and I has some discussions on this on IM last week. I also flagged the multiple exceptions as potentially problematic. I'm not sure how things will behave if we trigger hundreds of faults in succession - nor how long it will take. Aborting the whole loop, or frame, seems preferable but I don't know how you would do that. > Is there really a problem with these copy functions?? I'm wondering why > Mikael did not identify these as a problem in 8154592. Good question. :) It seems quite obvious to me that if a single load/store needs protection then bulk load/store would also need protection. And Jamsheeds tests confirmed that. Cheers, David >> 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed >> thread->thread_state() == _thread_in_vm checks from signal handler > > How about adding a check for _thread_in_native instead of removing the > check entirely? > > dl > >> Best regards, Jamsheed >> > From david.holmes at oracle.com Tue Nov 14 21:18:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Nov 2017 07:18:18 +1000 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: <2c16f1ff-57fc-9fed-2290-7e3a99c6a741@oracle.com> References: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> <2c16f1ff-57fc-9fed-2290-7e3a99c6a741@oracle.com> Message-ID: On 15/11/2017 7:11 AM, jamsheed wrote: > Hi Dean, > > revised webrev: > > http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ > > i agree to the comment that it is potentially unsafe to assume the > implementation, and count can be in autoincrement mode. so with this bug > i would like to deal with only the single value access error handling. > > revised webrev: http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ Okay so now this just brings to windows what currently exists on the other platforms - right? Seems reasonable for now. Longer term we should look at the bulk operation problem. Thanks, David > Best regards, > > Jamsheed > > > > On Tuesday 14 November 2017 11:57 PM, dean.long at oracle.com wrote: >> Adding runtime alias... >> >> comments inlined below. >> >> >> On 11/13/17 9:10 PM, jamsheed wrote: >> >>> Hi, request for review, jbs: >>> https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: >>> http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) >>> changes equivalent to JDK-4454115 is done for windows. >> >> It looks like "nm" can be uninitialized if "in_java" is false. >> >>> 2) added guard to multiple value access sites, Unsafe_CopyMemory0, >>> Unsafe_SetMemory0 and Unsafe_CopySwapMemory0. >> >> Can you narrow the scope of the unsafe access using something like >> GuardUnsafeAccess, instead of marking the whole function as doing >> unsafe access? >> >> There are some risks with trying to? abort a copy function. >> >> First, won't we get multiple exceptions until we finally hit the end >> of the range?? What if the bad range is very large? >> >> Second, what if the loop is using auto-increment instructions? >> Skipping to the next instruction would mean we loop forever if the >> increment never happens. >> >> I think if we are going to safely abort copy functions then we need to >> register them as a kind of CodeBlob that has a special abort entry >> point or exception handler we can redirect to, or maybe pop the whole >> frame and return. >> >> Is there really a problem with these copy functions?? I'm wondering >> why Mikael did not identify these as a problem in 8154592. >> >>> 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed >>> thread->thread_state() == _thread_in_vm checks from signal handler >> >> How about adding a check for _thread_in_native instead of removing the >> check entirely? >> >> dl >> >>> Best regards, Jamsheed >>> >> > From jamsheed.c.m at oracle.com Tue Nov 14 21:23:55 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Wed, 15 Nov 2017 02:53:55 +0530 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: <2c16f1ff-57fc-9fed-2290-7e3a99c6a741@oracle.com> References: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> <2c16f1ff-57fc-9fed-2290-7e3a99c6a741@oracle.com> Message-ID: Hi David, Hope you too agree here. Best regards, Jamsheed On Wednesday 15 November 2017 02:41 AM, jamsheed wrote: > Hi Dean, > > revised webrev: > > http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ > > i agree to the comment that it is potentially unsafe to assume the > implementation, and count can be in autoincrement mode. so with this > bug i would like to deal with only > > the single value access error handling. > > revised webrev: http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ > > Best regards, > > Jamsheed > > > > On Tuesday 14 November 2017 11:57 PM, dean.long at oracle.com wrote: >> Adding runtime alias... >> >> comments inlined below. >> >> >> On 11/13/17 9:10 PM, jamsheed wrote: >> >>> Hi, request for review, jbs: >>> https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: >>> http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) >>> changes equivalent to JDK-4454115 is done for windows. >> >> It looks like "nm" can be uninitialized if "in_java" is false. >> >>> 2) added guard to multiple value access sites, Unsafe_CopyMemory0, >>> Unsafe_SetMemory0 and Unsafe_CopySwapMemory0. >> >> Can you narrow the scope of the unsafe access using something like >> GuardUnsafeAccess, instead of marking the whole function as doing >> unsafe access? >> >> There are some risks with trying to? abort a copy function. >> >> First, won't we get multiple exceptions until we finally hit the end >> of the range?? What if the bad range is very large? >> >> Second, what if the loop is using auto-increment instructions? >> Skipping to the next instruction would mean we loop forever if the >> increment never happens. >> >> I think if we are going to safely abort copy functions then we need >> to register them as a kind of CodeBlob that has a special abort entry >> point or exception handler we can redirect to, or maybe pop the whole >> frame and return. >> >> Is there really a problem with these copy functions?? I'm wondering >> why Mikael did not identify these as a problem in 8154592. >> >>> 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed >>> thread->thread_state() == _thread_in_vm checks from signal handler >> >> How about adding a check for _thread_in_native instead of removing >> the check entirely? >> >> dl >> >>> Best regards, Jamsheed >>> >> > From jamsheed.c.m at oracle.com Tue Nov 14 21:26:53 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Wed, 15 Nov 2017 02:56:53 +0530 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: References: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> <2c16f1ff-57fc-9fed-2290-7e3a99c6a741@oracle.com> Message-ID: <41491f82-94fd-57d8-d6da-677443762f32@oracle.com> Hi David, On Wednesday 15 November 2017 02:48 AM, David Holmes wrote: > On 15/11/2017 7:11 AM, jamsheed wrote: >> Hi Dean, >> >> revised webrev: >> >> http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ >> >> i agree to the comment that it is potentially unsafe to assume the >> implementation, and count can be in autoincrement mode. so with this >> bug i would like to deal with only the single value access error >> handling. >> >> revised webrev: http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ > > Okay so now this just brings to windows what currently exists on the > other platforms - right? Yes, > > Seems reasonable for now. Longer term we should look at the bulk > operation problem. Sure, Best regards, Jamsheed > > Thanks, > David > >> Best regards, >> >> Jamsheed >> >> >> >> On Tuesday 14 November 2017 11:57 PM, dean.long at oracle.com wrote: >>> Adding runtime alias... >>> >>> comments inlined below. >>> >>> >>> On 11/13/17 9:10 PM, jamsheed wrote: >>> >>>> Hi, request for review, jbs: >>>> https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: >>>> http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) >>>> changes equivalent to JDK-4454115 is done for windows. >>> >>> It looks like "nm" can be uninitialized if "in_java" is false. >>> >>>> 2) added guard to multiple value access sites, Unsafe_CopyMemory0, >>>> Unsafe_SetMemory0 and Unsafe_CopySwapMemory0. >>> >>> Can you narrow the scope of the unsafe access using something like >>> GuardUnsafeAccess, instead of marking the whole function as doing >>> unsafe access? >>> >>> There are some risks with trying to? abort a copy function. >>> >>> First, won't we get multiple exceptions until we finally hit the end >>> of the range?? What if the bad range is very large? >>> >>> Second, what if the loop is using auto-increment instructions? >>> Skipping to the next instruction would mean we loop forever if the >>> increment never happens. >>> >>> I think if we are going to safely abort copy functions then we need >>> to register them as a kind of CodeBlob that has a special abort >>> entry point or exception handler we can redirect to, or maybe pop >>> the whole frame and return. >>> >>> Is there really a problem with these copy functions?? I'm wondering >>> why Mikael did not identify these as a problem in 8154592. >>> >>>> 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed >>>> thread->thread_state() == _thread_in_vm checks from signal handler >>> >>> How about adding a check for _thread_in_native instead of removing >>> the check entirely? >>> >>> dl >>> >>>> Best regards, Jamsheed >>>> >>> >> From daniel.daugherty at oracle.com Tue Nov 14 21:48:42 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Nov 2017 16:48:42 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> Message-ID: <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> Greetings, I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. (Yes, we're playing chase-the-repo...) Here is the updated full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ Unlike the previous rebase, there were no changes required to the open code to get the rebased bits to build so there is no delta webrev. These bits have been run through JPRT and I've submitted the usual Mach5 tier[1-5] test run... We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: > Greetings, > > I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. > > Here are the updated webrevs: > > Here's the mq comment for the change: > > ? Rebase to 2017.10.25 PIT snapshot. > > Here is the full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ > > And here is the delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ > > I ran the above bits throught Mach5 tier[1-5] testing over the holiday > weekend. Didn't see any issues in a quick look. Going to take a closer > look today. > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Resolving one of the code review comments (from both Stefan K and >> Coleen) >> on jdk10-04-full required quite a few changes so it is being done as a >> standalone patch and corresponding webrevs: >> >> Here's the mq comment for the change: >> >> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >> ??? JavaThreadIteratorWithHandle. >> >> Here is the full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >> >> And here is the delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> We have a (eXtra Large) fix for the following bug: >>> >>> 8167108 inconsistent handling of SR_lock can lead to crashes >>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>> >>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>> Hazard Pointers to manage JavaThread lifecycle. >>> >>> Here's a PDF for the internal wiki that we've been using to describe >>> and track the work on this project: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>> >>> >>> Dan has noticed that the indenting is wrong in some of the code quotes >>> in the PDF that are not present in the internal wiki. We don't have a >>> solution for that problem yet. >>> >>> Here's the webrev for current JDK10 version of this fix: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>> >>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>> testing, additional stress testing on Dan's Solaris X64 server, and >>> additional testing on Erik and Robbin's machines. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Daniel Daugherty >>> Erik Osterlund >>> Robbin Ehn >>> >> >> > > From Derek.White at cavium.com Tue Nov 14 22:14:59 2017 From: Derek.White at cavium.com (White, Derek) Date: Tue, 14 Nov 2017 22:14:59 +0000 Subject: RFR (XS): 8188221 - AARCH64: Return type profiling is not performed from aarch64 interpreter In-Reply-To: <122214a9-e4e3-5765-fdca-10f73f79bf2a@bell-sw.com> References: <1de74a72-ec83-9fed-ffc8-091af58de457@bell-sw.com> <122214a9-e4e3-5765-fdca-10f73f79bf2a@bell-sw.com> Message-ID: Hi Dmitry, This looks good. Thanks, - Derek > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Dmitry Chuyko > Sent: Tuesday, October 10, 2017 11:14 AM > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (XS): 8188221 - AARCH64: Return type profiling is not > performed from aarch64 interpreter > > --- old/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp > 2017-10-02 09:10:20.917960334 +0000 > +++ > new/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp > 2017-10-02 09:10:20.293932959 +0000 > @@ -414,6 +414,14 @@ > ?? __ restore_constant_pool_cache(); > ?? __ get_method(rmethod); > > +? if (state == atos) { > +??? Register obj = r0; > +??? Register mdp = r1; > +??? Register tmp = r2; > +??? __ ldr(mdp, Address(rmethod, Method::method_data_offset())); > +??? __ profile_return_type(mdp, obj, tmp); > +? } > + > ?? // Pop N words from the stack > ?? __ get_cache_and_index_at_bcp(r1, r2, 1, index_size); > ?? __ ldr(r1, Address(r1, ConstantPoolCache::base_offset() + > ConstantPoolCacheEntry::flags_offset())); > > > On 10/10/2017 05:54 PM, Dmitry Chuyko wrote: > > Hello, > > > > TestArrayCopyNoInitDeopt jtreg test (JDK-8072016) fails in > > -XX:-TieredCompilation mode because return type is not profiled in > > interpreter. > > Please review the fix, it adds profiling for aarch64 similar to how > > it's implemented for other cpus. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8188221 > > patch: jdk10.patch attached > > > > -Dmitry From dean.long at oracle.com Tue Nov 14 22:38:34 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 14 Nov 2017 14:38:34 -0800 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: <2c16f1ff-57fc-9fed-2290-7e3a99c6a741@oracle.com> References: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> <2c16f1ff-57fc-9fed-2290-7e3a99c6a741@oracle.com> Message-ID: <43f85d9a-89fd-0ecf-2c18-c8c10ce466f5@oracle.com> This version looks good.? If you wanted you could also do the following: CompiledMethod* nm = NULL; JavaThread* thread = (JavaThread*)t; if (in_java) { CodeBlob* cb= CodeCache::find_blob_unsafe(pc); because "cb" is only used in that inner block. dl On 11/14/17 1:11 PM, jamsheed wrote: > Hi Dean, > > revised webrev: > > http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ > > i agree to the comment that it is potentially unsafe to assume the > implementation, and count can be in autoincrement mode. so with this > bug i would like to deal with only > > the single value access error handling. > > revised webrev: http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ > > Best regards, > > Jamsheed > > > > On Tuesday 14 November 2017 11:57 PM, dean.long at oracle.com wrote: >> Adding runtime alias... >> >> comments inlined below. >> >> >> On 11/13/17 9:10 PM, jamsheed wrote: >> >>> Hi, request for review, jbs: >>> https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: >>> http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) >>> changes equivalent to JDK-4454115 is done for windows. >> >> It looks like "nm" can be uninitialized if "in_java" is false. >> >>> 2) added guard to multiple value access sites, Unsafe_CopyMemory0, >>> Unsafe_SetMemory0 and Unsafe_CopySwapMemory0. >> >> Can you narrow the scope of the unsafe access using something like >> GuardUnsafeAccess, instead of marking the whole function as doing >> unsafe access? >> >> There are some risks with trying to? abort a copy function. >> >> First, won't we get multiple exceptions until we finally hit the end >> of the range?? What if the bad range is very large? >> >> Second, what if the loop is using auto-increment instructions? >> Skipping to the next instruction would mean we loop forever if the >> increment never happens. >> >> I think if we are going to safely abort copy functions then we need >> to register them as a kind of CodeBlob that has a special abort entry >> point or exception handler we can redirect to, or maybe pop the whole >> frame and return. >> >> Is there really a problem with these copy functions?? I'm wondering >> why Mikael did not identify these as a problem in 8154592. >> >>> 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed >>> thread->thread_state() == _thread_in_vm checks from signal handler >> >> How about adding a check for _thread_in_native instead of removing >> the check entirely? >> >> dl >> >>> Best regards, Jamsheed >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Wed Nov 15 03:30:22 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Wed, 15 Nov 2017 09:00:22 +0530 Subject: [10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR In-Reply-To: <43f85d9a-89fd-0ecf-2c18-c8c10ce466f5@oracle.com> References: <05a52b8b-8a14-83c1-f1b3-5798de2d8af8@oracle.com> <2c16f1ff-57fc-9fed-2290-7e3a99c6a741@oracle.com> <43f85d9a-89fd-0ecf-2c18-c8c10ce466f5@oracle.com> Message-ID: <12e5f50a-d59d-e6ce-b04e-d3c34298658c@oracle.com> Thank you, Dean, David for review, created a new CR for tracking bulk access failure graceful handling https://bugs.openjdk.java.net/browse/JDK-8191278 On Wednesday 15 November 2017 04:08 AM, dean.long at oracle.com wrote: > > This version looks good.? If you wanted you could also do the following: > > CompiledMethod* nm = NULL; > JavaThread* thread = (JavaThread*)t; > if (in_java) { > CodeBlob* cb= CodeCache::find_blob_unsafe(pc); > > because "cb" is only used in that inner block. Ok Best regards, Jamsheed > > dl > > On 11/14/17 1:11 PM, jamsheed wrote: >> Hi Dean, >> >> revised webrev: >> >> http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ >> >> i agree to the comment that it is potentially unsafe to assume the >> implementation, and count can be in autoincrement mode. so with this >> bug i would like to deal with only >> >> the single value access error handling. >> >> revised webrev: http://cr.openjdk.java.net/~jcm/6415680/webrev.01/ >> >> Best regards, >> >> Jamsheed >> >> >> >> On Tuesday 14 November 2017 11:57 PM, dean.long at oracle.com wrote: >>> Adding runtime alias... >>> >>> comments inlined below. >>> >>> >>> On 11/13/17 9:10 PM, jamsheed wrote: >>> >>>> Hi, request for review, jbs: >>>> https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: >>>> http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) >>>> changes equivalent to JDK-4454115 is done for windows. >>> >>> It looks like "nm" can be uninitialized if "in_java" is false. >>> >>>> 2) added guard to multiple value access sites, Unsafe_CopyMemory0, >>>> Unsafe_SetMemory0 and Unsafe_CopySwapMemory0. >>> >>> Can you narrow the scope of the unsafe access using something like >>> GuardUnsafeAccess, instead of marking the whole function as doing >>> unsafe access? >>> >>> There are some risks with trying to? abort a copy function. >>> >>> First, won't we get multiple exceptions until we finally hit the end >>> of the range?? What if the bad range is very large? >>> >>> Second, what if the loop is using auto-increment instructions? >>> Skipping to the next instruction would mean we loop forever if the >>> increment never happens. >>> >>> I think if we are going to safely abort copy functions then we need >>> to register them as a kind of CodeBlob that has a special abort >>> entry point or exception handler we can redirect to, or maybe pop >>> the whole frame and return. >>> >>> Is there really a problem with these copy functions?? I'm wondering >>> why Mikael did not identify these as a problem in 8154592. >>> >>>> 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed >>>> thread->thread_state() == _thread_in_vm checks from signal handler >>> >>> How about adding a check for _thread_in_native instead of removing >>> the check entirely? >>> >>> dl >>> >>>> Best regards, Jamsheed >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ningsheng.jian at linaro.org Wed Nov 15 08:34:35 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Wed, 15 Nov 2017 16:34:35 +0800 Subject: [aarch64-port-dev ] [10] RFR: 8187472 - AARCH64: array_equals intrinsic doesn't use prefetch for large arrays In-Reply-To: References: <99ecb097-c382-47a0-48db-be85310c1d9d@bell-sw.com> <8e14d691-8edd-27fd-4687-4f1971daf2ea@redhat.com> <8144c663-ea6b-8d21-384b-baeb79f596c4@bell-sw.com> <47fb00b1-c51a-03d8-83f8-9c7cbd436f74@redhat.com> <47181509391125@web22j.yandex.ru> Message-ID: Hi Dmitrij, I can see regressions on some hardware with your patch. Could you please try the micro-benchmark below on your systems? http://people.linaro.org/~ningsheng.jian/test/StringOps.java $ java -jar ./target/benchmarks.jar "StringEqualsLarge" -wi 10 -f 3 -i 10 Seems that your patch affects the inlining. Thanks, Ningsheng On 10 November 2017 at 22:52, Dmitrij Pochepko wrote: > > > On 10.11.2017 17:28, Andrew Haley wrote: >> >> On 10/11/17 14:19, Dmitrij Pochepko wrote: >> >>> please take a look at merged simd/non-simd version. >> >> + if (UseSIMDForArrayEquals) { >> + __ ld1(v0, v1, v2, v3, __ T2D, Address(__ post(a1, 64))); >> + __ ld1(v4, v5, v6, v7, __ T2D, Address(__ post(a2, 64))); >> >> Is this post-increment correct? It should be a multiple of wordSize. > > It's correct, since we're loading 4x128-bit registers, which is 64 bytes. > But I've changed it to "4 * 2 * wordSize", which has the same value. >> >> >> Also, the indentation in generate_large_array_equals is wrong. >> > Thank you for noticing it. > > Please take a look at > http://cr.openjdk.java.net/~dpochepk/8187472/webrev.03/ > > > Thanks, > Dmitrij From rahul.v.raghavan at oracle.com Wed Nov 15 09:09:34 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 15 Nov 2017 14:39:34 +0530 Subject: [10] RFR: 8182037: wrong ResourceMark in Method::print_short_name() In-Reply-To: <98a5b61b-d971-6b13-6ec1-cbd65ea091aa@oracle.com> References: <98a5b61b-d971-6b13-6ec1-cbd65ea091aa@oracle.com> Message-ID: <44755a5e-5438-4b7f-ffd7-45caa22dc1ad@oracle.com> Hi, Please hold the review of 8182037-webrev.01 submitted earlier. Got failures in Mach5 testing. Working to fix the issues and will submit revised webrev. Thanks, Rahul On Monday 13 November 2017 02:29 PM, Rahul Raghavan wrote: > Hi, > > Request help reviewing proposed fix for 8182037. > > jbs - https://bugs.openjdk.java.net/browse/JDK-8182037 > > webrev.01 - http://cr.openjdk.java.net/~rraghavan/8182037/webrev.01/ > > > Notes / jbs extract - > > -- "void Method::print_short_name(outputStream* st) { > ???? ResourceMark rm; > breaks if st is not tty and buffer grows under the ResourceMark" > > -- "All the printing functions that take an outputStream could > potentially have this problem. > The caller should have the ResourceMark." > > -- "All but a couple of the calls to method->print_short_name() > are in compiler code, so reassigning to the compiler." > > > > -- To fix the issue > - Removed ResourceMark from following printing functions - > ??? Method::print_short_name(outputStream* st) > ??? Method::print_name(outputStream* st) > ??? Method::print_on(outputStream* st) > - checked usages of above functions and added ResourceMark to the callers. > > > (Mach5 testing in progress) > So can this be the correct fix? please tell if I missed some point here. > > > Thanks, > Rahul From aph at redhat.com Wed Nov 15 10:34:21 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Nov 2017 10:34:21 +0000 Subject: [aarch64-port-dev ] [10] RFR: 8187472 - AARCH64: array_equals intrinsic doesn't use prefetch for large arrays In-Reply-To: References: <99ecb097-c382-47a0-48db-be85310c1d9d@bell-sw.com> <8e14d691-8edd-27fd-4687-4f1971daf2ea@redhat.com> <8144c663-ea6b-8d21-384b-baeb79f596c4@bell-sw.com> <47fb00b1-c51a-03d8-83f8-9c7cbd436f74@redhat.com> <47181509391125@web22j.yandex.ru> Message-ID: <4a63bc1b-cb90-90dc-a1f8-4d4d03527f3c@redhat.com> On 15/11/17 08:34, Ningsheng Jian wrote: > Hi Dmitrij, > > I can see regressions on some hardware with your patch. > > Could you please try the micro-benchmark below on your systems? > > http://people.linaro.org/~ningsheng.jian/test/StringOps.java > > $ java -jar ./target/benchmarks.jar "StringEqualsLarge" -wi 10 -f 3 -i 10 > > Seems that your patch affects the inlining. Before the patch: StringOps.jmhTimeStringEqualsIgnoreCaseLarge avgt 10 2984.638 ? 12.899 ns/op StringOps.jmhTimeStringEqualsIgnoreCaseSmall avgt 10 319.434 ? 0.434 ns/op StringOps.jmhTimeStringEqualsLarge avgt 10 146.122 ? 0.638 ns/op StringOps.jmhTimeStringEqualsSmall avgt 10 45.998 ? 0.444 ns/op After: Mode Cnt Score Error Units StringOps.jmhTimeStringEqualsIgnoreCaseLarge avgt 10 2982.222 ? 3.683 ns/op StringOps.jmhTimeStringEqualsIgnoreCaseSmall avgt 10 319.671 ? 0.902 ns/op StringOps.jmhTimeStringEqualsLarge avgt 10 1137.348 ? 1.088 ns/op StringOps.jmhTimeStringEqualsSmall avgt 10 194.698 ? 0.857 ns/op Gosh. I think that's a very bad patch. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Nov 15 12:16:40 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Nov 2017 12:16:40 +0000 Subject: [aarch64-port-dev ] [10] RFR: 8187472 - AARCH64: array_equals intrinsic doesn't use prefetch for large arrays In-Reply-To: <4a63bc1b-cb90-90dc-a1f8-4d4d03527f3c@redhat.com> References: <99ecb097-c382-47a0-48db-be85310c1d9d@bell-sw.com> <8e14d691-8edd-27fd-4687-4f1971daf2ea@redhat.com> <8144c663-ea6b-8d21-384b-baeb79f596c4@bell-sw.com> <47fb00b1-c51a-03d8-83f8-9c7cbd436f74@redhat.com> <47181509391125@web22j.yandex.ru> <4a63bc1b-cb90-90dc-a1f8-4d4d03527f3c@redhat.com> Message-ID: On 15/11/17 10:34, Andrew Haley wrote: > Gosh. I think that's a very bad patch. In fact it's even worse than I thought. It causes crashes in testing. Nobody seems to have noticed that the .ad file is wrong. Note this: instruct string_equalsL(iRegP_R1 str1, iRegP_R3 str2, iRegI_R4 cnt, iRegI_R0 result, rFlagsReg cr) instruct array_equalsB(iRegP_R1 ary1, iRegP_R2 ary2, iRegI_R0 result, iRegP_R4 tmp, rFlagsReg cr) Spot the difference? str2 is in R3, ary2 is in R2. That means you can't call the same stub from both of these patterns. If you're adding a stub call you must assert that the passed registers are correct. Add the assertions, fix the register usage, and test it properly, both with and without UseSIMDForArrayEquals. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.x.ivanov at oracle.com Wed Nov 15 14:55:44 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Nov 2017 17:55:44 +0300 Subject: C1 code installation and JNIHandle::deleted_handle() oop In-Reply-To: <43de40fc-a585-3096-6a67-5e8e7e64ad68@redhat.com> References: <319f089c-1cc8-e494-bf11-79b284165085@redhat.com> <13318115-87c4-74bd-c323-a4f1d45646d9@oracle.com> <4D5DC152-B7B2-4E89-81B9-D9A291E943E0@redhat.com> <320433c9-5ce2-0426-0de8-8b135acaf85f@redhat.com> <43de40fc-a585-3096-6a67-5e8e7e64ad68@redhat.com> Message-ID: > The root of the evil is still that we're accessing the naked oop while > potentially at a safepoint (and oops moving around). You already > established that JVMCI doesn't have the problem because it's already > transitioned into VM. Why not make the other compilers consistent? I.e. > transition into VM (VM_ENTRY_MARK) before going into the same code path. > From the looks of it, code paths start to be shared between JVMCI and > others starting around > DebugInformationRecorder::create_scope_values(GrowableArray*), > i.e. the VM_ENTRY_MARK could be placed around that in, e.g., > > void CodeEmitInfo::record_debug_info(DebugInformationRecorder* recorder, > int pc_offset) { > ? // record the safepoint before recording the debug info for enclosing > scopes > ? VM_ENTRY_MARK; > ? recorder->add_safepoint(pc_offset, _oop_map->deep_copy()); > ? _scope_debug_info->record_debug_info(recorder, pc_offset, > true/*topmost*/, _is_method_handle_invoke); > ? recorder->end_safepoint(pc_offset); > } > > Although similarities between this code and related code in JVMCI would > suggest to place the VM_ENTRY_MARK even higher in the call stack. > > WDYT? (JVMCI is a different story, so leaving it aside for now.) IMO the problem in ConstantOopWriteValue::write_on() doesn't justify such change. The problematic assert does something very unusual for existing compilers in the JVM and adjusting product code to fix that doesn't feel right. Compiler threads were deliberately designed as JavaThreads running in native state to reduce interference with other parts of the JVM. Compiler interface (CI) encapsulates interactions with runtime and compilers code base is mostly free of handles & naked oops. In other words, compilers were written in a way to minimize the risk of accessing naked oops w/o proper coordination with the rest of runtime. So, instead of precausiously putting VM_ENTRY_MARKs here and there, I'd prefer to see additional verification code to catch such problems in newly introduced code. IMO the lack of such functionality was the main reason why the bug slipped through testing. Best regards, Vladimir Ivanov From stuart.monteith at linaro.org Wed Nov 15 16:57:14 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 15 Nov 2017 16:57:14 +0000 Subject: [aarch64-port-dev] RFR 8191338: aarch64: fails to build after 8189745 Message-ID: https://bugs.openjdk.java.net/browse/JDK-8191338 http://cr.openjdk.java.net/~smonteith/8191338/webrev/ This fixes an issue whereby on aarch64 platforms without CRC32 instructions, a relative branch to NULL was being generated, which is out of reach. This is causing my builds on APM X-Gene 1's to fail. BR, Stuart From aph at redhat.com Wed Nov 15 17:17:00 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Nov 2017 17:17:00 +0000 Subject: [aarch64-port-dev ] [aarch64-port-dev] RFR 8191338: aarch64: fails to build after 8189745 In-Reply-To: References: Message-ID: On 15/11/17 16:57, Stuart Monteith wrote: > https://bugs.openjdk.java.net/browse/JDK-8191338 > http://cr.openjdk.java.net/~smonteith/8191338/webrev/ > > This fixes an issue whereby on aarch64 platforms without CRC32 > instructions, a relative branch to NULL was being generated, which is > out of reach. This is causing my builds on APM X-Gene 1's to fail. OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Derek.White at cavium.com Wed Nov 15 17:28:10 2017 From: Derek.White at cavium.com (White, Derek) Date: Wed, 15 Nov 2017 17:28:10 +0000 Subject: [aarch64-port-dev ] [aarch64-port-dev] RFR 8191338: aarch64: fails to build after 8189745 In-Reply-To: References: Message-ID: Hi Stuart, Yes the fix looks good. I had to stare at it for a while to see the difference, but it's an important one! Sorry I missed this in the original review. - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Stuart Monteith > Sent: Wednesday, November 15, 2017 11:57 AM > To: aarch64-port-dev ; hotspot- > compiler-dev at openjdk.java.net compiler dev at openjdk.java.net> > Subject: [aarch64-port-dev ] [aarch64-port-dev] RFR 8191338: aarch64: fails > to build after 8189745 > > https://bugs.openjdk.java.net/browse/JDK-8191338 > http://cr.openjdk.java.net/~smonteith/8191338/webrev/ > > This fixes an issue whereby on aarch64 platforms without CRC32 > instructions, a relative branch to NULL was being generated, which is out of > reach. This is causing my builds on APM X-Gene 1's to fail. > > > BR, > Stuart From dmitry.chuyko at bell-sw.com Wed Nov 15 19:38:34 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 15 Nov 2017 22:38:34 +0300 Subject: [aarch64-port-dev ] [aarch64-port-dev] RFR 8191338: aarch64: fails to build after 8189745 In-Reply-To: References: Message-ID: Stuart, thanks a lot! I missed that. -Dmitry > 15 ????. 2017 ?., ? 20:28, White, Derek ???????(?): > > Hi Stuart, > > Yes the fix looks good. I had to stare at it for a while to see the difference, but it's an important one! Sorry I missed this in the original review. > > - Derek > >> -----Original Message----- >> From: aarch64-port-dev [mailto:aarch64-port-dev- >> bounces at openjdk.java.net] On Behalf Of Stuart Monteith >> Sent: Wednesday, November 15, 2017 11:57 AM >> To: aarch64-port-dev ; hotspot- >> compiler-dev at openjdk.java.net compiler > dev at openjdk.java.net> >> Subject: [aarch64-port-dev ] [aarch64-port-dev] RFR 8191338: aarch64: fails >> to build after 8189745 >> >> https://bugs.openjdk.java.net/browse/JDK-8191338 >> http://cr.openjdk.java.net/~smonteith/8191338/webrev/ >> >> This fixes an issue whereby on aarch64 platforms without CRC32 >> instructions, a relative branch to NULL was being generated, which is out of >> reach. This is causing my builds on APM X-Gene 1's to fail. >> >> >> BR, >> Stuart From daniel.daugherty at oracle.com Wed Nov 15 20:32:13 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Nov 2017 15:32:13 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> Message-ID: <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> Greetings, Robbin rebased the project last night/this morning to merge with Thread Local Handshakes (TLH) and also picked up additional changesets up thru: > Changeset: fa736014cf28 > Author: cjplummer > Date: 2017-11-14 18:08 -0800 > URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 > > 8191049: Add alternate version of pns() that is callable from within hotspot source > Summary: added pns2() to debug.cpp > Reviewed-by: stuefe, gthornbr This is the first time we've rebased the project to bits that are this fresh (< 12 hours old at rebase time). We've done this because we think we're done with this project and are in the final review-change-retest cycle(s)... In other words, we're not planning on making any more major changes for this project... :-) *** Time for code reviewers to chime in on this thread! *** Here is the updated full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ Here's is the delta webrev from the 2017.11.10 rebase: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ Dan has submitted the bits for the usual Mach5 tier[1-5] testing (and the new baseline also)... We're expecting this round to be a little noisier than usual because we did not rebase on a PIT snapshot so the new baseline has not been through Jesper's usual care-and-feeding of integration_blockers, etc. We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: > Greetings, > > I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. > (Yes, we're playing chase-the-repo...) > > Here is the updated full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ > > Unlike the previous rebase, there were no changes required to the > open code to get the rebased bits to build so there is no delta > webrev. > > These bits have been run through JPRT and I've submitted the usual > Mach5 tier[1-5] test run... > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >> >> Here are the updated webrevs: >> >> Here's the mq comment for the change: >> >> ? Rebase to 2017.10.25 PIT snapshot. >> >> Here is the full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >> >> And here is the delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >> >> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >> weekend. Didn't see any issues in a quick look. Going to take a closer >> look today. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Resolving one of the code review comments (from both Stefan K and >>> Coleen) >>> on jdk10-04-full required quite a few changes so it is being done as a >>> standalone patch and corresponding webrevs: >>> >>> Here's the mq comment for the change: >>> >>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>> ??? JavaThreadIteratorWithHandle. >>> >>> Here is the full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>> >>> And here is the delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> We have a (eXtra Large) fix for the following bug: >>>> >>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>> >>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>> Hazard Pointers to manage JavaThread lifecycle. >>>> >>>> Here's a PDF for the internal wiki that we've been using to describe >>>> and track the work on this project: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>> >>>> >>>> Dan has noticed that the indenting is wrong in some of the code quotes >>>> in the PDF that are not present in the internal wiki. We don't have a >>>> solution for that problem yet. >>>> >>>> Here's the webrev for current JDK10 version of this fix: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>> >>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>> additional testing on Erik and Robbin's machines. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Daniel Daugherty >>>> Erik Osterlund >>>> Robbin Ehn >>>> >>> >>> >> >> > > From dmitrij.pochepko at bell-sw.com Wed Nov 15 21:31:26 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 16 Nov 2017 00:31:26 +0300 Subject: [aarch64-port-dev ] [10] RFR: 8187472 - AARCH64: array_equals intrinsic doesn't use prefetch for large arrays In-Reply-To: References: <99ecb097-c382-47a0-48db-be85310c1d9d@bell-sw.com> <8e14d691-8edd-27fd-4687-4f1971daf2ea@redhat.com> <8144c663-ea6b-8d21-384b-baeb79f596c4@bell-sw.com> <47fb00b1-c51a-03d8-83f8-9c7cbd436f74@redhat.com> <47181509391125@web22j.yandex.ru> <4a63bc1b-cb90-90dc-a1f8-4d4d03527f3c@redhat.com> Message-ID: <1a6bbd9f-d3be-bec6-5e18-bc8cf365ea43@bell-sw.com> Hi, Ningsheng, Andrew, thank you for looking into in. Your pre-review of this patch helps a lot. I was originally focused on Arrays::equals, without paying too much attention to String::equals, so, haven't found these issues. The cause of this slowdown was a small bug Andrew mentioned on first webrev(iRegP/iRegI change). webrev.03 you were using has leftover of this problem (http://cr.openjdk.java.net/~dpochepk/8187472/webrev.03/src/hotspot/cpu/aarch64/aarch64.ad.udiff.html). And it caused this intrinsic to be ignored by matcher, so, no intrinsic was used at all. I changed back iRegP to iRegI and it fixed slowdown. I also changed R3 to R2 to keep 2nd string in .ad file to fix 2nd problem Andrew found and it seems to work fine. new webrev (only .ad file was changed): http://cr.openjdk.java.net/~dpochepk/8187472/webrev.04/ Ningsheng's benchmark numbers for this patch on ThunderX: Before: Benchmark?????????????????????????? Mode? Cnt??? Score?? Error Units StringOps.jmhTimeStringEqualsLarge? avgt?? 10? 235.631 ? 0.054 ns/op After: Benchmark?????????????????????????? Mode? Cnt??? Score?? Error Units StringOps.jmhTimeStringEqualsLarge? avgt?? 10? 216.660 ? 0.304 ns/op I still have to test this patch a bit more to be sure no other problems appears. Thanks, Dmitrij On 15.11.2017 15:16, Andrew Haley wrote: > On 15/11/17 10:34, Andrew Haley wrote: >> Gosh. I think that's a very bad patch. > In fact it's even worse than I thought. It causes crashes in testing. > Nobody seems to have noticed that the .ad file is wrong. > > Note this: > > instruct string_equalsL(iRegP_R1 str1, iRegP_R3 str2, iRegI_R4 cnt, > iRegI_R0 result, rFlagsReg cr) > > instruct array_equalsB(iRegP_R1 ary1, iRegP_R2 ary2, iRegI_R0 result, > iRegP_R4 tmp, rFlagsReg cr) > > Spot the difference? str2 is in R3, ary2 is in R2. That means you > can't call the same stub from both of these patterns. > > If you're adding a stub call you must assert that the passed registers > are correct. Add the assertions, fix the register usage, and test it > properly, both with and without UseSIMDForArrayEquals. > From ningsheng.jian at linaro.org Thu Nov 16 09:49:51 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Thu, 16 Nov 2017 17:49:51 +0800 Subject: [aarch64-port-dev ] [10] RFR: 8187472 - AARCH64: array_equals intrinsic doesn't use prefetch for large arrays In-Reply-To: <1a6bbd9f-d3be-bec6-5e18-bc8cf365ea43@bell-sw.com> References: <99ecb097-c382-47a0-48db-be85310c1d9d@bell-sw.com> <8e14d691-8edd-27fd-4687-4f1971daf2ea@redhat.com> <8144c663-ea6b-8d21-384b-baeb79f596c4@bell-sw.com> <47fb00b1-c51a-03d8-83f8-9c7cbd436f74@redhat.com> <47181509391125@web22j.yandex.ru> <4a63bc1b-cb90-90dc-a1f8-4d4d03527f3c@redhat.com> <1a6bbd9f-d3be-bec6-5e18-bc8cf365ea43@bell-sw.com> Message-ID: Hi Dmitrij, Your code below (T2D) in stubGenerator_aarch64.cpp will trigger assertion in assembler on debug build. 3935 __ eor(v0, __ T2D, v0, v4); 3936 __ eor(v1, __ T2D, v1, v5); I ran your benchmarks in some platforms. Will share the benchmark data to you in a separate mail. Thanks, Ningsheng On 16 November 2017 at 05:31, Dmitrij Pochepko wrote: > Hi, > > Ningsheng, Andrew, > > thank you for looking into in. Your pre-review of this patch helps a lot. I > was originally focused on Arrays::equals, without paying too much attention > to String::equals, so, haven't found these issues. > > > The cause of this slowdown was a small bug Andrew mentioned on first > webrev(iRegP/iRegI change). webrev.03 you were using has leftover of this > problem > (http://cr.openjdk.java.net/~dpochepk/8187472/webrev.03/src/hotspot/cpu/aarch64/aarch64.ad.udiff.html). > And it caused this intrinsic to be ignored by matcher, so, no intrinsic was > used at all. > > > I changed back iRegP to iRegI and it fixed slowdown. I also changed R3 to R2 > to keep 2nd string in .ad file to fix 2nd problem Andrew found and it seems > to work fine. > > new webrev (only .ad file was changed): > http://cr.openjdk.java.net/~dpochepk/8187472/webrev.04/ > > > > Ningsheng's benchmark numbers for this patch on ThunderX: > > > Before: > > Benchmark Mode Cnt Score Error Units > StringOps.jmhTimeStringEqualsLarge avgt 10 235.631 ? 0.054 ns/op > > > After: > > Benchmark Mode Cnt Score Error Units > StringOps.jmhTimeStringEqualsLarge avgt 10 216.660 ? 0.304 ns/op > > > I still have to test this patch a bit more to be sure no other problems > appears. > > > Thanks, > > Dmitrij > > > > On 15.11.2017 15:16, Andrew Haley wrote: >> >> On 15/11/17 10:34, Andrew Haley wrote: >>> >>> Gosh. I think that's a very bad patch. >> >> In fact it's even worse than I thought. It causes crashes in testing. >> Nobody seems to have noticed that the .ad file is wrong. >> >> Note this: >> >> instruct string_equalsL(iRegP_R1 str1, iRegP_R3 str2, iRegI_R4 cnt, >> iRegI_R0 result, rFlagsReg cr) >> >> instruct array_equalsB(iRegP_R1 ary1, iRegP_R2 ary2, iRegI_R0 result, >> iRegP_R4 tmp, rFlagsReg cr) >> >> Spot the difference? str2 is in R3, ary2 is in R2. That means you >> can't call the same stub from both of these patterns. >> >> If you're adding a stub call you must assert that the passed registers >> are correct. Add the assertions, fix the register usage, and test it >> properly, both with and without UseSIMDForArrayEquals. >> > From mark.reinhold at oracle.com Thu Nov 16 16:47:22 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Nov 2017 08:47:22 -0800 (PST) Subject: JEP 315: Improve Aarch64 Intrinsics Message-ID: <20171116164722.4BD5EFDD36@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/315 - Mark From igor.veresov at oracle.com Thu Nov 16 19:08:09 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 16 Nov 2017 11:08:09 -0800 Subject: RFR (S) 8043070: nmethod::verify_interrupt_point() shouldn't enter safepoint Message-ID: <229F1CC5-7CFE-4752-8A8B-2D5ABABC76E1@oracle.com> The problems here is that the sweeper can transition a newly created nmethod to not_entrant state before it?s installed. This breaks the logic in nmethod::verify_interrupt_point() called at the end of the installation process. As a result locks might be taken in that can safepoint and safepoints are forbidden during the method install. The solution is to introduce an new nmethod state: not_installed. The goal is to be able to prevent certain things like sweeping or parts of the verification happening during the nmethod installation. The change passed the failing test and the internal mach5 pre-intergration testing. Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8043070 Note, this also fixes: https://bugs.openjdk.java.net/browse/JDK-8028001 Thanks! igor From dean.long at oracle.com Thu Nov 16 23:30:27 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 16 Nov 2017 15:30:27 -0800 Subject: RFR (S) 8043070: nmethod::verify_interrupt_point() shouldn't enter safepoint In-Reply-To: <229F1CC5-7CFE-4752-8A8B-2D5ABABC76E1@oracle.com> References: <229F1CC5-7CFE-4752-8A8B-2D5ABABC76E1@oracle.com> Message-ID: Hi Igor.? The changes look good.? Thanks for not changing the values for the other states.? It would have broken AOT :-) Are there any situations where make_in_use() might need a compiler/memory barrier? I was thinking about an alternative approach, at least for this case.? We could have NoSafepointVerififer always set _thread->_allow_safepoint_count (right now it doesn't for product builds), then verify_interrupt_point() could check that flag before taking the path that can safepoint.? Or how about just using nmethodLocker as suggested in 8028001?? Or does having a new state help solve other problems? dl On 11/16/17 11:08 AM, Igor Veresov wrote: > The problems here is that the sweeper can transition a newly created nmethod to not_entrant state before it?s installed. This breaks the logic in nmethod::verify_interrupt_point() called at the end of the installation process. As a result locks might be taken in that can safepoint and safepoints are forbidden during the method install. > > The solution is to introduce an new nmethod state: not_installed. The goal is to be able to prevent certain things like sweeping or parts of the verification happening during the nmethod installation. > > The change passed the failing test and the internal mach5 pre-intergration testing. > > Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8043070 > > Note, this also fixes: https://bugs.openjdk.java.net/browse/JDK-8028001 > > Thanks! > igor From igor.veresov at oracle.com Fri Nov 17 02:32:27 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 16 Nov 2017 18:32:27 -0800 Subject: RFR (S) 8043070: nmethod::verify_interrupt_point() shouldn't enter safepoint In-Reply-To: References: <229F1CC5-7CFE-4752-8A8B-2D5ABABC76E1@oracle.com> Message-ID: <89481363-8F68-433F-9D34-B6D3A7B04777@oracle.com> > On Nov 16, 2017, at 3:30 PM, dean.long at oracle.com wrote: > > Hi Igor. The changes look good. Thanks! > Thanks for not changing the values for the other states. It would have broken AOT :-) Yes, we?d like in_use to be 0 so it could be in BSS, right? > > Are there any situations where make_in_use() might need a compiler/memory barrier? > I don?t think so, is_in_use() actually returns true for not_installed (now it?s _state <= in_use). So as far as other threads are concerned nothing changed. There is an exotic possibility that the initial store of not_installed might be reordered with the store of in_use on non-TSO, but there is a mutex unlock between those, so I?m not really concerned about that. Are you thinking about any other scenarios? > I was thinking about an alternative approach, at least for this case. We could have NoSafepointVerififer always set _thread->_allow_safepoint_count (right now it doesn't for product builds), then verify_interrupt_point() could check that flag before taking the path that can safepoint. Or how about just using nmethodLocker as suggested in 8028001? Or does having a new state help solve other problems? nmethodLocker approach seemed less tidy because I?d have to lock in nmethod::nmethod() and unlock in ciEnv::register_method(). We could probably introduce sort of an nmethodHandle that we?d return from new_nmethod() but then we?d have to do reference counting of sorts. Anyway, it felt like an additional state is less trouble. igor > > dl > > > On 11/16/17 11:08 AM, Igor Veresov wrote: >> The problems here is that the sweeper can transition a newly created nmethod to not_entrant state before it?s installed. This breaks the logic in nmethod::verify_interrupt_point() called at the end of the installation process. As a result locks might be taken in that can safepoint and safepoints are forbidden during the method install. >> >> The solution is to introduce an new nmethod state: not_installed. The goal is to be able to prevent certain things like sweeping or parts of the verification happening during the nmethod installation. >> >> The change passed the failing test and the internal mach5 pre-intergration testing. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070 >> >> Note, this also fixes: https://bugs.openjdk.java.net/browse/JDK-8028001 >> >> Thanks! >> igor > From dean.long at oracle.com Fri Nov 17 05:42:38 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 16 Nov 2017 21:42:38 -0800 Subject: RFR (S) 8043070: nmethod::verify_interrupt_point() shouldn't enter safepoint In-Reply-To: <89481363-8F68-433F-9D34-B6D3A7B04777@oracle.com> References: <229F1CC5-7CFE-4752-8A8B-2D5ABABC76E1@oracle.com> <89481363-8F68-433F-9D34-B6D3A7B04777@oracle.com> Message-ID: <4d367fa6-7d3b-0962-c65d-882663a9f5d8@oracle.com> On 11/16/17 6:32 PM, Igor Veresov wrote: > >> On Nov 16, 2017, at 3:30 PM, dean.long at oracle.com wrote: >> >> Hi Igor. The changes look good. > Thanks! > >> Thanks for not changing the values for the other states. It would have broken AOT :-) > Yes, we?d like in_use to be 0 so it could be in BSS, right? > And because we compare against 0 right now: ??? 3440:?????? 48 8b 05 39 bb 21 00??? mov 0x21bb39(%rip),%rax??????? # 21ef80 ??? 3447:?????? 48 85 c0??????????????? test?? %rax,%rax ??? 344a:?????? 0f 85 20 b1 00 00?????? jne??? e570 >> Are there any situations where make_in_use() might need a compiler/memory barrier? >> > I don?t think so, is_in_use() actually returns true for not_installed (now it?s _state <= in_use). So as far as other threads are concerned nothing changed. > There is an exotic possibility that the initial store of not_installed might be reordered with the store of in_use on non-TSO, but there is a mutex unlock between those, so I?m not really concerned about that. > Are you thinking about any other scenarios? I was thinking about make_in_use() happening before the verify() call, but that would mean an invalid optimization by a broken C++ compiler, right? >> I was thinking about an alternative approach, at least for this case. We could have NoSafepointVerififer always set _thread->_allow_safepoint_count (right now it doesn't for product builds), then verify_interrupt_point() could check that flag before taking the path that can safepoint. Or how about just using nmethodLocker as suggested in 8028001? Or does having a new state help solve other problems? > nmethodLocker approach seemed less tidy because I?d have to lock in nmethod::nmethod() and unlock in ciEnv::register_method(). > We could probably introduce sort of an nmethodHandle that we?d return from new_nmethod() but then we?d have to do reference counting of sorts. Anyway, it felt like an additional state is less trouble. OK, a new state does look like less trouble than nmethodLocker or nmethodHandle. dl > igor > >> dl >> >> >> On 11/16/17 11:08 AM, Igor Veresov wrote: >>> The problems here is that the sweeper can transition a newly created nmethod to not_entrant state before it?s installed. This breaks the logic in nmethod::verify_interrupt_point() called at the end of the installation process. As a result locks might be taken in that can safepoint and safepoints are forbidden during the method install. >>> >>> The solution is to introduce an new nmethod state: not_installed. The goal is to be able to prevent certain things like sweeping or parts of the verification happening during the nmethod installation. >>> >>> The change passed the failing test and the internal mach5 pre-intergration testing. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070 >>> >>> Note, this also fixes: https://bugs.openjdk.java.net/browse/JDK-8028001 >>> >>> Thanks! >>> igor From igor.veresov at oracle.com Fri Nov 17 08:52:12 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 17 Nov 2017 00:52:12 -0800 Subject: RFR (S) 8043070: nmethod::verify_interrupt_point() shouldn't enter safepoint In-Reply-To: <4d367fa6-7d3b-0962-c65d-882663a9f5d8@oracle.com> References: <229F1CC5-7CFE-4752-8A8B-2D5ABABC76E1@oracle.com> <89481363-8F68-433F-9D34-B6D3A7B04777@oracle.com> <4d367fa6-7d3b-0962-c65d-882663a9f5d8@oracle.com> Message-ID: > On Nov 16, 2017, at 9:42 PM, dean.long at oracle.com wrote: > > On 11/16/17 6:32 PM, Igor Veresov wrote: > >> >>> On Nov 16, 2017, at 3:30 PM, dean.long at oracle.com wrote: >>> >>> Hi Igor. The changes look good. >> Thanks! >> >>> Thanks for not changing the values for the other states. It would have broken AOT :-) >> Yes, we?d like in_use to be 0 so it could be in BSS, right? >> > > And because we compare against 0 right now: > > 3440: 48 8b 05 39 bb 21 00 mov 0x21bb39(%rip),%rax # 21ef80 > 3447: 48 85 c0 test %rax,%rax > 344a: 0f 85 20 b1 00 00 jne e570 Good point, yes. > >>> Are there any situations where make_in_use() might need a compiler/memory barrier? >>> >> I don?t think so, is_in_use() actually returns true for not_installed (now it?s _state <= in_use). So as far as other threads are concerned nothing changed. >> There is an exotic possibility that the initial store of not_installed might be reordered with the store of in_use on non-TSO, but there is a mutex unlock between those, so I?m not really concerned about that. >> Are you thinking about any other scenarios? > > I was thinking about make_in_use() happening before the verify() call, but that would mean an invalid optimization by a broken C++ compiler, right? Yes, I think that would mean it doesn?t track memory effects correctly. No reordering should happen from the point of view of the same thread. >>> I was thinking about an alternative approach, at least for this case. We could have NoSafepointVerififer always set _thread->_allow_safepoint_count (right now it doesn't for product builds), then verify_interrupt_point() could check that flag before taking the path that can safepoint. Or how about just using nmethodLocker as suggested in 8028001? Or does having a new state help solve other problems? >> nmethodLocker approach seemed less tidy because I?d have to lock in nmethod::nmethod() and unlock in ciEnv::register_method(). >> We could probably introduce sort of an nmethodHandle that we?d return from new_nmethod() but then we?d have to do reference counting of sorts. Anyway, it felt like an additional state is less trouble. > > OK, a new state does look like less trouble than nmethodLocker or nmethodHandle. igor > > dl > >> igor >> >>> dl >>> >>> >>> On 11/16/17 11:08 AM, Igor Veresov wrote: >>>> The problems here is that the sweeper can transition a newly created nmethod to not_entrant state before it?s installed. This breaks the logic in nmethod::verify_interrupt_point() called at the end of the installation process. As a result locks might be taken in that can safepoint and safepoints are forbidden during the method install. >>>> >>>> The solution is to introduce an new nmethod state: not_installed. The goal is to be able to prevent certain things like sweeping or parts of the verification happening during the nmethod installation. >>>> >>>> The change passed the failing test and the internal mach5 pre-intergration testing. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070 >>>> >>>> Note, this also fixes: https://bugs.openjdk.java.net/browse/JDK-8028001 >>>> >>>> Thanks! >>>> igor > From dmitrij.pochepko at bell-sw.com Fri Nov 17 19:15:43 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 17 Nov 2017 22:15:43 +0300 Subject: RFR(S) 8190817: deopt special-case for _return_register_finalizer is confusing and leads to bugs In-Reply-To: <480ed17b-fae1-8db4-1d12-3319be262d3d@oracle.com> References: <480ed17b-fae1-8db4-1d12-3319be262d3d@oracle.com> Message-ID: Hi, I've built clean fastdebug build with this patch and run compiler/runtime/Test8168712.java on AArch64 (ThunderX) and it passed. Please note that this test can't be run on AArch64 by default because of @requires tag. I had to update this tag first. Btw: I wonder if it should be also updated as a part of this patch? I also took a look at Aarch64-specific change and it looks good to me(not a Reviewer). Thanks, Dmitrij On 13.11.2017 20:32, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8190817 > > http://cr.openjdk.java.net/~dlong/8190817/webrev/ > > This fix replaces the problematic use of > _normal_table.entry(Bytecodes::_return).entry(vtos) as a > deoptimization entry point with a proper deopt entry point returned by > deopt_reexecute_return_entry().? This is needed to handle the > situation where compiled code is calling register_finalizer() and gets > deoptimized. > > I also noticed that we generate duplicate entry points unnecessarily, > so I cleaned that up at the same time. > > aarch64/ppc64/s390 folks, please check that > compiler/runtime/Test8168712.java still passes. > > dl > From dean.long at oracle.com Fri Nov 17 20:01:05 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 17 Nov 2017 12:01:05 -0800 Subject: RFR(S) 8190817: deopt special-case for _return_register_finalizer is confusing and leads to bugs In-Reply-To: References: <480ed17b-fae1-8db4-1d12-3319be262d3d@oracle.com> Message-ID: <48b1c46e-8eab-8232-3213-044fe59a462b@oracle.com> Thanks Dmitrij!? I have updated the test as well.? Good suggestion. dl http://cr.openjdk.java.net/~dlong/8190817/webrev.1/ On 11/17/17 11:15 AM, Dmitrij Pochepko wrote: > Hi, > > I've built clean fastdebug build with this patch and run > compiler/runtime/Test8168712.java on AArch64 (ThunderX) and it passed. > > Please note that this test can't be run on AArch64 by default because > of @requires tag. I had to update this tag first. Btw: I wonder if it > should be also updated as a part of this patch? > > > I also took a look at Aarch64-specific change and it looks good to > me(not a Reviewer). > > > Thanks, > > Dmitrij > > > On 13.11.2017 20:32, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8190817 >> >> http://cr.openjdk.java.net/~dlong/8190817/webrev/ >> >> This fix replaces the problematic use of >> _normal_table.entry(Bytecodes::_return).entry(vtos) as a >> deoptimization entry point with a proper deopt entry point returned >> by deopt_reexecute_return_entry().? This is needed to handle the >> situation where compiled code is calling register_finalizer() and >> gets deoptimized. >> >> I also noticed that we generate duplicate entry points unnecessarily, >> so I cleaned that up at the same time. >> >> aarch64/ppc64/s390 folks, please check that >> compiler/runtime/Test8168712.java still passes. >> >> dl >> > From razvan.a.lupusoru at intel.com Fri Nov 17 21:10:28 2017 From: razvan.a.lupusoru at intel.com (Lupusoru, Razvan A) Date: Fri, 17 Nov 2017 21:10:28 +0000 Subject: RFR 8190800: Support for vectorization of sqrt float Message-ID: <48D92A70936F7946BE99F3FF5ECB6461D8DDF561@ORSMSX113.amr.corp.intel.com> Hello, The vectorizer cannot currently handle vectorization of sqrt for floats even though there is packed single precision sqrt instruction supported in AVX. The following patch rectifies the situation by adding a new C2 node for floating point version of Sqrt and its vectorized version, along with assembler support for it. https://bugs.openjdk.java.net/browse/JDK-8190800 The proposed solution can be found here: http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_sqrtf_02/ Please let me know if you have any questions or concerns. --Razvan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Fri Nov 17 21:35:49 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 17 Nov 2017 13:35:49 -0800 (PST) Subject: JEP 317: Experimental Java-Based JIT Compiler Message-ID: <20171117213549.24536FE344@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/317 - Mark From jacekt at dug.com Sat Nov 18 00:03:14 2017 From: jacekt at dug.com (Jacek Tomaka) Date: Sat, 18 Nov 2017 08:03:14 +0800 Subject: RFR 8190800: Support for vectorization of sqrt float In-Reply-To: <48D92A70936F7946BE99F3FF5ECB6461D8DDF561@ORSMSX113.amr.corp.intel.com> References: <48D92A70936F7946BE99F3FF5ECB6461D8DDF561@ORSMSX113.amr.corp.intel.com> Message-ID: Hi Razvan, Thank you for making this patch available. I have a few questions regarding your changes: 1. Would it make sense to get rid of match(Set dst (ConvD2F (SqrtD (ConvF2D src)))); for other platforms as well(and just use match(Set dst (SqrtF src));), now that ConvD2FNode::Ideal does similar job? 2. What would be situations where instruct vsqrt2F_reg and instruct vsqrt2F_mem would be used? Isn't AVX only >128 bit? 3. In subnode.hpp i think the comment should mention float not double. It is +// square root a double currently. Regards. Jacek Tomaka -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan.a.lupusoru at intel.com Sat Nov 18 00:34:13 2017 From: razvan.a.lupusoru at intel.com (Lupusoru, Razvan A) Date: Sat, 18 Nov 2017 00:34:13 +0000 Subject: RFR 8190800: Support for vectorization of sqrt float In-Reply-To: References: <48D92A70936F7946BE99F3FF5ECB6461D8DDF561@ORSMSX113.amr.corp.intel.com> Message-ID: <48D92A70936F7946BE99F3FF5ECB6461D8DDF6F0@ORSMSX113.amr.corp.intel.com> Hi Jacek, You are very welcome and it is nice we had same idea for implementation :) Regarding your questions: 1) I did not want to change other architecture .ad files because I do not have the means to test them. Because of that, you will see that the Ideal conversion restricts conversion to SqrtF node only for architectures that have a Matcher entry. Namely all non-x86 architectures will work exact same way as before - this ensures I did not break anything for them. 2) It appears that it is general convention in the .ad file that all ?packed? combinations are supported. Thus, you will find many places where 2F is a supported combination. That is because the vectorizer may decide (unlikely) that it should pack only 2 floats. The AVX instruction will apply transform on all 4 lanes (when 128 bit), but the caller of that .ad entry will only look at the resulting 2 relevant float lanes (as reflected by dst being vecD). I have ensured now that all 2F entries use vecD. 3) You are right - that is a copy/paste error. It should say ?float? instead of ?double?. I have uploaded a fixed webrev here: http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_sqrtf_03/ Thanks, Razvan From: Jacek Tomaka [mailto:jacekt at dug.com] Sent: Friday, November 17, 2017 4:03 PM To: Lupusoru, Razvan A Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR 8190800: Support for vectorization of sqrt float Hi Razvan, Thank you for making this patch available. I have a few questions regarding your changes: 1. Would it make sense to get rid of match(Set dst (ConvD2F (SqrtD (ConvF2D src)))); for other platforms as well(and just use match(Set dst (SqrtF src));), now that ConvD2FNode::Ideal does similar job? 2. What would be situations where instruct vsqrt2F_reg and instruct vsqrt2F_mem would be used? Isn't AVX only >128 bit? 3. In subnode.hpp i think the comment should mention float not double. It is +// square root a double currently. Regards. Jacek Tomaka -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Sun Nov 19 01:49:43 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 18 Nov 2017 20:49:43 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> Message-ID: <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Greetings, Testing of the last round of changes revealed a hang in one of the new TLH tests. Robbin has fixed the hang, updated the existing TLH test, and added another TLH test for good measure. Here is the updated full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ Here is the updated delta webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are no unexpected failures. We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: > Greetings, > > Robbin rebased the project last night/this morning to merge with Thread > Local Handshakes (TLH) and also picked up additional changesets up thru: > >> Changeset: fa736014cf28 >> Author:??? cjplummer >> Date:????? 2017-11-14 18:08 -0800 >> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >> >> 8191049: Add alternate version of pns() that is callable from within >> hotspot source >> Summary: added pns2() to debug.cpp >> Reviewed-by: stuefe, gthornbr > > This is the first time we've rebased the project to bits that are this > fresh (< 12 hours old at rebase time). We've done this because we think > we're done with this project and are in the final review-change-retest > cycle(s)... In other words, we're not planning on making any more major > changes for this project... :-) > > *** Time for code reviewers to chime in on this thread! *** > > Here is the updated full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ > > Here's is the delta webrev from the 2017.11.10 rebase: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ > > Dan has submitted the bits for the usual Mach5 tier[1-5] testing > (and the new baseline also)... > > We're expecting this round to be a little noisier than usual because > we did not rebase on a PIT snapshot so the new baseline has not been > through Jesper's usual care-and-feeding of integration_blockers, etc. > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >> (Yes, we're playing chase-the-repo...) >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >> >> Unlike the previous rebase, there were no changes required to the >> open code to get the rebased bits to build so there is no delta >> webrev. >> >> These bits have been run through JPRT and I've submitted the usual >> Mach5 tier[1-5] test run... >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>> >>> Here are the updated webrevs: >>> >>> Here's the mq comment for the change: >>> >>> ? Rebase to 2017.10.25 PIT snapshot. >>> >>> Here is the full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>> >>> And here is the delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>> >>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>> weekend. Didn't see any issues in a quick look. Going to take a closer >>> look today. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Resolving one of the code review comments (from both Stefan K and >>>> Coleen) >>>> on jdk10-04-full required quite a few changes so it is being done as a >>>> standalone patch and corresponding webrevs: >>>> >>>> Here's the mq comment for the change: >>>> >>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>> ??? JavaThreadIteratorWithHandle. >>>> >>>> Here is the full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>> >>>> And here is the delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> We have a (eXtra Large) fix for the following bug: >>>>> >>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>> >>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>> >>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>> and track the work on this project: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>> >>>>> >>>>> Dan has noticed that the indenting is wrong in some of the code >>>>> quotes >>>>> in the PDF that are not present in the internal wiki. We don't have a >>>>> solution for that problem yet. >>>>> >>>>> Here's the webrev for current JDK10 version of this fix: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>> >>>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>> additional testing on Erik and Robbin's machines. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Daniel Daugherty >>>>> Erik Osterlund >>>>> Robbin Ehn >>>>> >>>> >>>> >>> >>> >> >> > > From david.holmes at oracle.com Mon Nov 20 05:51:06 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Nov 2017 15:51:06 +1000 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Message-ID: <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> Hi Dan, Figured I'd better cast an eye over this again before it gets pushed :) Only one thing (repeated many times) jumped out at me and apologies if this has already been debated back and forth. I missed the exchange where the for loop iteration was rewritten into this unusual form: for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = jtiwh.next(); ) { On first reading I expect most people would mistake the control expression for the iteration-expression due to the next(). I didn't even know the control expression could introduce a local variable! I find this really hard to read stylistically and far too cute/clever for its own good. It also violates the style rules regarding implicit boolean checks. I know Stefan proposed this as he did not like the alternate (in a few places): + { + ThreadsListHandle tlh; + JavaThreadIterator jti(tlh.list()); + for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { ... + } but it seems to me the iterator code has evolved since then and only a couple of places need a distinct TLH separate from the actual iterator object. So I'm more in favour of the more classic for-loop, with the iterator declared before the loop. Or even convert to while loops, as this iterator seems more suited to that. Other than that just a couple of comments on variable type choices, and a few typos spotted below. Thanks, David --- src/hotspot/share/runtime/globals.hpp 2476 diagnostic(bool, EnableThreadSMRExtraValidityChecks, true, \ 2477 "Enable Thread SMR extra validity checks") \ 2478 \ 2479 diagnostic(bool, EnableThreadSMRStatistics, true, \ 2480 "Enable Thread SMR Statistics") \ Indent of strings is off by 3 spaces. --- src/hotspot/share/runtime/handshake.cpp 140 // There is assumption in code that Threads_lock should be lock 200 // There is assumption in code that Threads_lock should be lock lock -> locked 146 // handshake_process_by_vmthread will check the semaphore for us again Needs period at end. 148 // should be okey since the new thread will not have an operation. okey -> okay 151 // We can't warn here is since the thread do cancel_handshake after it have been removed I think: // We can't warn here since the thread does cancel_handshake after it has been removed 152 // from ThreadsList. So we should just keep looping here until while below return negative. from -> from the Needs period at end. 204 // A new thread on the ThreadsList will not have an operation. Change period to comma, and ... 205 // Hence is skipped in handshake_process_by_vmthread. Hence is -> hence it is --- src/hotspot/share/runtime/thread.cpp 1482 // dcubed - Looks like the Threads_lock is for stable access 1483 // to _jvmci_old_thread_counters and _jvmci_counters. Does this comment need revisiting? 3451 volatile jint ... Why are you using jint for field types here? (Surprised Coleen hasn't spotted them! ;-) ). 3456 long Threads::_smr_java_thread_list_alloc_cnt = 1; 3457 long Threads::_smr_java_thread_list_free_cnt = 0; long? If you really want 64-bit counters here you won't get them on Windows with that declaration. If you really want variable sized counters I suggest uintptr_t; otherwise uint64_t. ---- On 19/11/2017 11:49 AM, Daniel D. Daugherty wrote: > Greetings, > > Testing of the last round of changes revealed a hang in one of the new > TLH tests. Robbin has fixed the hang, updated the existing TLH test, and > added another TLH test for good measure. > > Here is the updated full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ > > Here is the updated delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ > > Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are > no unexpected failures. > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Robbin rebased the project last night/this morning to merge with Thread >> Local Handshakes (TLH) and also picked up additional changesets up thru: >> >>> Changeset: fa736014cf28 >>> Author:??? cjplummer >>> Date:????? 2017-11-14 18:08 -0800 >>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>> >>> 8191049: Add alternate version of pns() that is callable from within >>> hotspot source >>> Summary: added pns2() to debug.cpp >>> Reviewed-by: stuefe, gthornbr >> >> This is the first time we've rebased the project to bits that are this >> fresh (< 12 hours old at rebase time). We've done this because we think >> we're done with this project and are in the final review-change-retest >> cycle(s)... In other words, we're not planning on making any more major >> changes for this project... :-) >> >> *** Time for code reviewers to chime in on this thread! *** >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >> >> Here's is the delta webrev from the 2017.11.10 rebase: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >> >> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >> (and the new baseline also)... >> >> We're expecting this round to be a little noisier than usual because >> we did not rebase on a PIT snapshot so the new baseline has not been >> through Jesper's usual care-and-feeding of integration_blockers, etc. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>> (Yes, we're playing chase-the-repo...) >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>> >>> Unlike the previous rebase, there were no changes required to the >>> open code to get the rebased bits to build so there is no delta >>> webrev. >>> >>> These bits have been run through JPRT and I've submitted the usual >>> Mach5 tier[1-5] test run... >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>> >>>> Here are the updated webrevs: >>>> >>>> Here's the mq comment for the change: >>>> >>>> ? Rebase to 2017.10.25 PIT snapshot. >>>> >>>> Here is the full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>> >>>> And here is the delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>> >>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>> look today. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Resolving one of the code review comments (from both Stefan K and >>>>> Coleen) >>>>> on jdk10-04-full required quite a few changes so it is being done as a >>>>> standalone patch and corresponding webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>> ??? JavaThreadIteratorWithHandle. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> We have a (eXtra Large) fix for the following bug: >>>>>> >>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>> >>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>> >>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>> and track the work on this project: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>> >>>>>> >>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>> quotes >>>>>> in the PDF that are not present in the internal wiki. We don't have a >>>>>> solution for that problem yet. >>>>>> >>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>> >>>>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>> additional testing on Erik and Robbin's machines. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Daniel Daugherty >>>>>> Erik Osterlund >>>>>> Robbin Ehn >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > From tobias.hartmann at oracle.com Mon Nov 20 08:22:33 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 20 Nov 2017 09:22:33 +0100 Subject: [10] RFR(S): 8179026: Remove explicit code cache options processing Message-ID: Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8179026 http://cr.openjdk.java.net/~thartmann/8179026/webrev.00/ I've removed the explicit processing of -XX:CodeCacheExpansionSize, -XX:NonNMethodCodeHeapSize, -XX:ProfiledCodeHeapSize and -XX:NonProfiledCodeHeapSize because generic option processing already supports memory values. I've also added a lower bound of vm_page_size() to all of them except the non-profiled and the profiled size because these can be 0. The actual checking is done in codeCache.cpp. All tests pass. Thanks, Tobias From rwestrel at redhat.com Mon Nov 20 10:27:16 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 20 Nov 2017 11:27:16 +0100 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> Message-ID: > I was thinking may be we should create new Loop node subclass for outer loop. Then you don't need > special flag for it and it will be obvious what they are in Ideal Graph. The same for outer loop end > node. Here is a new webrev with new node types for the outer loop: http://cr.openjdk.java.net/~roland/8186027/webrev.02/ Roland. From rwestrel at redhat.com Mon Nov 20 14:10:47 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 20 Nov 2017 15:10:47 +0100 Subject: RFR(XS): 8191153: assert(u_ctrl != blk1 && u_ctrl != blk2) failed: won't converge Message-ID: http://cr.openjdk.java.net/~roland/8191153/webrev.00/ The assert that I added with 8186125 is too strong. It assumes that Cmp and its uses are being cloned down but it's not always the case. When the TestSplitIfPinnedCMove::test() from the test case is compiled, line 63 becomes a CMoveP which is pinned and the if line 66 can then be split through phi. For that to happen, the CMoveP must first be moved out of the way: it can be split up but the CmpI that feeds into the CMoveP has more than one use. A first pass through PhaseIdealLoop::split_up() causes the CmpI->Bol->CMoveP chain to be cloned and a second call to PhaseIdealLoop::split_up() splits the CmpI up. The assert fires on the first call but it's too strong because we're not splitting the CmpI->Bol->CMoveP chain down. Roland. From stuart.monteith at linaro.org Mon Nov 20 14:12:22 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 20 Nov 2017 14:12:22 +0000 Subject: [aarch64-port-dev ] [aarch64-port-dev] RFR 8191338: aarch64: fails to build after 8189745 In-Reply-To: References: Message-ID: Hi, I've put the changeset here: http://cr.openjdk.java.net/~smonteith/8191338/8191338.changeset BR, Stuart On 15 November 2017 at 19:38, Dmitry Chuyko wrote: > Stuart, thanks a lot! I missed that. > > -Dmitry > >> 15 ????. 2017 ?., ? 20:28, White, Derek ???????(?): >> >> Hi Stuart, >> >> Yes the fix looks good. I had to stare at it for a while to see the difference, but it's an important one! Sorry I missed this in the original review. >> >> - Derek >> >>> -----Original Message----- >>> From: aarch64-port-dev [mailto:aarch64-port-dev- >>> bounces at openjdk.java.net] On Behalf Of Stuart Monteith >>> Sent: Wednesday, November 15, 2017 11:57 AM >>> To: aarch64-port-dev ; hotspot- >>> compiler-dev at openjdk.java.net compiler >> dev at openjdk.java.net> >>> Subject: [aarch64-port-dev ] [aarch64-port-dev] RFR 8191338: aarch64: fails >>> to build after 8189745 >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191338 >>> http://cr.openjdk.java.net/~smonteith/8191338/webrev/ >>> >>> This fixes an issue whereby on aarch64 platforms without CRC32 >>> instructions, a relative branch to NULL was being generated, which is out of >>> reach. This is causing my builds on APM X-Gene 1's to fail. >>> >>> >>> BR, >>> Stuart > From dmitrij.pochepko at bell-sw.com Mon Nov 20 15:57:25 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 20 Nov 2017 18:57:25 +0300 Subject: [aarch64-port-dev ] [aarch64-port-dev] RFR 8191338: aarch64: fails to build after 8189745 In-Reply-To: References: Message-ID: <4ff9bba2-afaa-6cb0-4bd7-91effb7fb1de@bell-sw.com> I've pushed it. Thanks, Dmitrij On 20.11.2017 17:12, Stuart Monteith wrote: > Hi, > I've put the changeset here: > http://cr.openjdk.java.net/~smonteith/8191338/8191338.changeset > > BR, > Stuart > > On 15 November 2017 at 19:38, Dmitry Chuyko wrote: >> Stuart, thanks a lot! I missed that. >> >> -Dmitry >> >>> 15 ????. 2017 ?., ? 20:28, White, Derek ???????(?): >>> >>> Hi Stuart, >>> >>> Yes the fix looks good. I had to stare at it for a while to see the difference, but it's an important one! Sorry I missed this in the original review. >>> >>> - Derek >>> >>>> -----Original Message----- >>>> From: aarch64-port-dev [mailto:aarch64-port-dev- >>>> bounces at openjdk.java.net] On Behalf Of Stuart Monteith >>>> Sent: Wednesday, November 15, 2017 11:57 AM >>>> To: aarch64-port-dev ; hotspot- >>>> compiler-dev at openjdk.java.net compiler >>> dev at openjdk.java.net> >>>> Subject: [aarch64-port-dev ] [aarch64-port-dev] RFR 8191338: aarch64: fails >>>> to build after 8189745 >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8191338 >>>> http://cr.openjdk.java.net/~smonteith/8191338/webrev/ >>>> >>>> This fixes an issue whereby on aarch64 platforms without CRC32 >>>> instructions, a relative branch to NULL was being generated, which is out of >>>> reach. This is causing my builds on APM X-Gene 1's to fail. >>>> >>>> >>>> BR, >>>> Stuart From vladimir.x.ivanov at oracle.com Mon Nov 20 17:36:14 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 20 Nov 2017 20:36:14 +0300 Subject: RFR 8190800: Support for vectorization of sqrt float In-Reply-To: <48D92A70936F7946BE99F3FF5ECB6461D8DDF561@ORSMSX113.amr.corp.intel.com> References: <48D92A70936F7946BE99F3FF5ECB6461D8DDF561@ORSMSX113.amr.corp.intel.com> Message-ID: <5c9e54c0-cd07-e68f-852b-448239b5f47f@oracle.com> Looks good. I'll sponsor the change. Best regards, Vladimir Ivanov On 11/18/17 12:10 AM, Lupusoru, Razvan A wrote: > Hello, > > The vectorizer cannot currently handle vectorization of sqrt for floats > even though there is packed single precision sqrt instruction supported > in AVX. The following patch rectifies the situation by adding a new C2 > node for floating point version of Sqrt and its vectorized version, > along with assembler support for it. > > https://bugs.openjdk.java.net/browse/JDK-8190800 > > The proposed solution can be found here: > > http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_sqrtf_02/ > > Please let me know if you have any questions or concerns. > > --Razvan > From eric.caspole at oracle.com Mon Nov 20 22:43:59 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Mon, 20 Nov 2017 17:43:59 -0500 Subject: RFR (XS):8191615 : LogCompilation can show bytes Message-ID: <3a9650cd-7a66-583f-008b-97f8645c50a5@oracle.com> Hi everybody, While using the LogCompilation tool, I noticed it would be a bit better to show the bytes size of the method being compiled as this info is now available in the log. I think this might be an oversight that the tool was never updated as the +LogCompilation output got better over time. http://cr.openjdk.java.net/~ecaspole/JDK-8191615/webrev/ JBS: https://bugs.openjdk.java.net/browse/JDK-8191615 Thanks, Eric From vladimir.x.ivanov at oracle.com Mon Nov 20 23:06:59 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 21 Nov 2017 02:06:59 +0300 Subject: RFR (XS):8191615 : LogCompilation can show bytes In-Reply-To: <3a9650cd-7a66-583f-008b-97f8645c50a5@oracle.com> References: <3a9650cd-7a66-583f-008b-97f8645c50a5@oracle.com> Message-ID: <9678f625-4fa1-e749-a7c5-f491d34c8b5c@oracle.com> Looks good. Best regards, Vladimir Ivanov On 11/21/17 1:43 AM, Eric Caspole wrote: > Hi everybody, > While using the LogCompilation tool, I noticed it would be a bit better > to show the bytes size of the method being compiled as this info is now > available in the log. I think this might be an oversight that the tool > was never updated as the +LogCompilation output got better over time. > > http://cr.openjdk.java.net/~ecaspole/JDK-8191615/webrev/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8191615 > > Thanks, > Eric From dean.long at oracle.com Tue Nov 21 00:36:55 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 20 Nov 2017 16:36:55 -0800 Subject: RFR(S) 8190817: deopt special-case for _return_register_finalizer is confusing and leads to bugs In-Reply-To: <48b1c46e-8eab-8232-3213-044fe59a462b@oracle.com> References: <480ed17b-fae1-8db4-1d12-3319be262d3d@oracle.com> <48b1c46e-8eab-8232-3213-044fe59a462b@oracle.com> Message-ID: <44cf3764-38d6-7ac1-7bf0-d65bf113afc7@oracle.com> Ping.? I still need a Reviewer to look at this. dl On 11/17/17 12:01 PM, dean.long at oracle.com wrote: > Thanks Dmitrij!? I have updated the test as well.? Good suggestion. > > dl > > http://cr.openjdk.java.net/~dlong/8190817/webrev.1/ > > > On 11/17/17 11:15 AM, Dmitrij Pochepko wrote: >> Hi, >> >> I've built clean fastdebug build with this patch and run >> compiler/runtime/Test8168712.java on AArch64 (ThunderX) and it passed. >> >> Please note that this test can't be run on AArch64 by default because >> of @requires tag. I had to update this tag first. Btw: I wonder if it >> should be also updated as a part of this patch? >> >> >> I also took a look at Aarch64-specific change and it looks good to >> me(not a Reviewer). >> >> >> Thanks, >> >> Dmitrij >> >> >> On 13.11.2017 20:32, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8190817 >>> >>> http://cr.openjdk.java.net/~dlong/8190817/webrev/ >>> >>> This fix replaces the problematic use of >>> _normal_table.entry(Bytecodes::_return).entry(vtos) as a >>> deoptimization entry point with a proper deopt entry point returned >>> by deopt_reexecute_return_entry().? This is needed to handle the >>> situation where compiled code is calling register_finalizer() and >>> gets deoptimized. >>> >>> I also noticed that we generate duplicate entry points >>> unnecessarily, so I cleaned that up at the same time. >>> >>> aarch64/ppc64/s390 folks, please check that >>> compiler/runtime/Test8168712.java still passes. >>> >>> dl >>> >> > From daniel.daugherty at oracle.com Tue Nov 21 01:50:29 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 20 Nov 2017 20:50:29 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> Message-ID: <92d1f572-a745-6f2b-1b5f-e68a1d252bab@oracle.com> On 11/20/17 12:51 AM, David Holmes wrote: > Hi Dan, > > Figured I'd better cast an eye over this again before it gets pushed :) Thanks for reviewing again!! > Only one thing (repeated many times) jumped out at me and apologies if > this has already been debated back and forth. I missed the exchange > where the for loop iteration was rewritten into this unusual form: > > for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = > jtiwh.next(); ) { > > On first reading I expect most people would mistake the control > expression for the iteration-expression due to the next(). I didn't > even know the control expression could introduce a local variable! I > find this really hard to read stylistically and far too cute/clever > for its own good. It also violates the style rules regarding implicit > boolean checks. > > I know Stefan proposed this as he did not like the alternate (in a few > places): > > +? { > +??? ThreadsListHandle tlh; > +??? JavaThreadIterator jti(tlh.list()); > +??? for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { > ... > +? } > > but it seems to me the iterator code has evolved since then and only a > couple of places need a distinct TLH separate from the actual iterator > object. So I'm more in favour of the more classic for-loop, with the > iterator declared before the loop. Or even convert to while loops, as > this iterator seems more suited to that. Actually both Coleen and Stefan had a problem with how much additional code was added to support an iterator model. In some cases we went from 1-line to 3-lines and in some cases we went from 1-line to 5-lines. For Coleen, she wanted 2 of the new lines compressed into 1 new line by using an iterator with an embedded ThreadsListHandle. Stefan wanted us to try and get back to 1-line where possible. The advantages of the new style are: - 1-line to 1-line in all but a few cases - automatic limited scope of the embedded ThreadsListHandle so we were ? able to remove extra braces that were added earlier in most cases The disadvantages of the new style are: - it is an unusual for-loop style (in HotSpot) - it breaks HotSpot's style rule about implied booleans Stefan K is pretty adamant that the original iterator version where we go from 1-line to 3-lines or 1-line to 5-lines is not acceptable for GC code. The compiler guys haven't chimed in on this debate so I'm guessing they don't have a strong opinion either way. One thing that we don't want to do is have different styles for the different teams. So I had to make a judgement call on whether I thought Runtime could live with Stefan's idea. Originally I wasn't fond of it either and breaking the implied boolean style rule is a problem for me (I post that comment a lot in my code reviews). However, I have to say that I'm a lot happier about the compactness of the code and the fact that limited ThreadsListHandle scope comes for 'free' in most cases. We're planning to keep the new iterator style for the following reasons: - smaller change footprint - consistent style used for all of the teams - limited ThreadsListHandle scope comes for free in most cases We're hoping that you can live with this decision (for now) and maybe even grow to like it in the future. :-) > Other than that just a couple of comments on variable type choices, > and a few typos spotted below. Replies embedded below. > > Thanks, > David > --- > > src/hotspot/share/runtime/globals.hpp > > 2476?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, true, > ??????? \ > 2477?????????? "Enable Thread SMR extra validity checks") \ > 2478 ??????? \ > 2479?? diagnostic(bool, EnableThreadSMRStatistics, true, ??????? \ > 2480?????????? "Enable Thread SMR Statistics") ??????? \ > > Indent of strings is off by? 3 spaces. Fixed. > --- > > src/hotspot/share/runtime/handshake.cpp > > ?140?????? // There is assumption in code that Threads_lock should be > lock > ?200?????? // There is assumption in code that Threads_lock should be > lock > > lock -> locked Fixed. > 146???????? // handshake_process_by_vmthread will check the semaphore > for us again > > Needs period at end. Fixed. > 148???????? // should be okey since the new thread will not have an > operation. > > okey -> okay Fixed. > 151???????? // We can't warn here is since the thread do > cancel_handshake after it have been removed > > I think: > > // We can't warn here since the thread does cancel_handshake after it > has been removed Fixed. > 152???????? // from ThreadsList. So we should just keep looping here > until while below return negative. > > from -> from the > > Needs period at end. Fixed both. > > ?204???????????? // A new thread on the ThreadsList will not have an > operation. > > Change period to comma, and ... Fixed. > 205???????????? // Hence is skipped in handshake_process_by_vmthread. > > Hence is -> hence it is Fixed. > --- > > src/hotspot/share/runtime/thread.cpp > > 1482???? // dcubed - Looks like the Threads_lock is for stable access > 1483???? // to _jvmci_old_thread_counters and _jvmci_counters. > > Does this comment need revisiting? We've been trying to decide what to do about this comment. We'll be filing a follow up bug for the Compiler team to take another look at how _jvmci_old_thread_counters and _jvmci_counters are protected. Threads_lock is a big hammer and there should be a less expensive solution. Once that bug gets filed, this comment can go away. > 3451 volatile jint ... > > Why are you using jint for field types here? (Surprised Coleen hasn't > spotted them! ;-) ). volatile jint???????? Threads::_smr_delete_notify = 0; volatile jint???????? Threads::_smr_deleted_thread_cnt = 0; volatile jint???????? Threads::_smr_deleted_thread_time_max = 0; volatile jint???????? Threads::_smr_deleted_thread_times = 0; : volatile jint???????? Threads::_smr_tlh_cnt = 0; volatile jint???????? Threads::_smr_tlh_time_max = 0; volatile jint???????? Threads::_smr_tlh_times = 0; _smr_delete_notify is a "flag" that indicates when an _smr_delete_lock notify() operation is needed. It counts up and down and should be a fairly small number. _smr_deleted_thread_cnt counts the number of Threads that have been deleted over the life of the VM. It's an always increasing number so it's size depends on how long the VM has been running. _smr_deleted_thread_time_max is the maximum time in millis it has taken to delete a thread. This field was originally a jlong, but IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have just been Atomic::add() that was not happy) _smr_deleted_thread_times accumulates the time in millis that it has taken to delete threads. It's an always increasing number so it's size depends on how long the VM has been running. This field was originally a jlong, but IIRC the Atomic::add() code was not happy on ARM... (might have just been Atomic::cmpxchg() that was not happy) _smr_tlh_cnt counts the number of ThreadsListHandles that have been deleted over the life of the VM. It's an always increasing number so it's size depends on how long the VM has been running. _smr_tlh_time_max is the maximum time in millis it has taken to delete a ThreadsListHandle. This field was originally a jlong, but IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have just been Atomic::add() that was not happy) _smr_tlh_times? accumulates the time in millis that it has taken to delete ThreadsListHandles. It's an always increasing number so it's size depends on how long the VM has been running.? This field was originally a jlong, but IIRC the Atomic::add() code was not happy on ARM... (might have just been Atomic::cmpxchg() that was not happy) It just dawned on me that I'm not sure whether you think the 'jint' fields should be larger or smaller or the same size but a different type... :-) The fact that I had to write so much to explain what these fields are for and how they're used indicates I need more comments. See below... > 3456 long Threads::_smr_java_thread_list_alloc_cnt = 1; > 3457 long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; > > long? If you really want 64-bit counters here you won't get them on > Windows with that declaration. If you really want variable sized > counters I suggest uintptr_t; otherwise uint64_t. long????????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; _smr_java_thread_list_alloc_cnt counts the number of ThreadsLists that have been allocated over the life of the VM. It's an always increasing number so it's size depends on how long the VM has been running and how many Threads have been created and destroyed. _smr_java_thread_list_free_cnt counts the number of ThreadsLists that have been freed over the life of the VM. It's an always increasing number so it's size depends on how long the VM has been running and how many Threads have been created and destroyed. I can't remember why we chose 'long' and I agree it's not a good choice for Win*. Okay so it dawns on me that we haven't written down a description for the various new '_cnt', '_max' and '_times" fields so I'm adding these comments to thread.hpp: ?private: ? // Safe Memory Reclamation (SMR) support: ? static Monitor*????????????? _smr_delete_lock; ? // The '_cnt', '_max' and '_times" fields are enabled via ? // -XX:+EnableThreadSMRStatistics: ?????????????????????????????? // # of parallel threads in _smr_delete_lock->wait(). ? static uint????????????????? _smr_delete_lock_wait_cnt; ?????????????????????????????? // Max # of parallel threads in _smr_delete_lock->wait(). ? static uint????????????????? _smr_delete_lock_wait_max; ?????????????????????????????? // Flag to indicate when an _smr_delete_lock->notify() is needed. ? static volatile uint???????? _smr_delete_notify; ?????????????????????????????? // # of threads deleted over VM lifetime. ? static volatile uint???????? _smr_deleted_thread_cnt; ?????????????????????????????? // Max time in millis to delete a thread. ? static volatile uint???????? _smr_deleted_thread_time_max; ?????????????????????????????? // Cumulative time in millis to delete threads. ? static volatile uint???????? _smr_deleted_thread_times; ? static ThreadsList* volatile _smr_java_thread_list; ? static ThreadsList*????????? get_smr_java_thread_list(); ? static ThreadsList* xchg_smr_java_thread_list(ThreadsList* new_list); ?????????????????????????????? // # of ThreadsLists allocated over VM lifetime. ? static uint64_t????????????? _smr_java_thread_list_alloc_cnt; ?????????????????????????????? // # of ThreadsLists freed over VM lifetime. ? static uint64_t????????????? _smr_java_thread_list_free_cnt; ?????????????????????????????? // Max size ThreadsList allocated. ? static uint????????????????? _smr_java_thread_list_max; ?????????????????????????????? // Max # of nested ThreadsLists for a thread. ? static uint????????????????? _smr_nested_thread_list_max; ?????????????????????????????? // # of ThreadsListHandles deleted over VM lifetime. ? static volatile uint???????? _smr_tlh_cnt; ?????????????????????????????? // Max time in millis to delete a ThreadsListHandle. ? static volatile jint???????? _smr_tlh_time_max; ?????????????????????????????? // Cumulative time in millis to delete ThreadsListHandles. ? static volatile jint???????? _smr_tlh_times; ? static ThreadsList*????????? _smr_to_delete_list; ?????????????????????????????? // # of parallel ThreadsLists on the to-delete list. ? static uint????????????????? _smr_to_delete_list_cnt; ?????????????????????????????? // Max # of parallel ThreadsLists on the to-delete list. ? static uint????????????????? _smr_to_delete_list_max; I've also gone through all the new '_cnt', '_max' and '_times" fields in thread.cpp and added an impl note to explain the choice of type: // Safe Memory Reclamation (SMR) support: Monitor*????????????? Threads::_smr_delete_lock = ????????????????????????? new Monitor(Monitor::special, "smr_delete_lock", ????????????????????????????????????? false /* allow_vm_block */, Monitor::_safepoint_check_never); // The '_cnt', '_max' and '_times" fields are enabled via // -XX:+EnableThreadSMRStatistics: ????????????????????? // # of parallel threads in _smr_delete_lock->wait(). ????????????????????? // Impl note: Hard to imagine > 64K waiting threads so ????????????????????? // this could be 16-bit, but there is no nice 16-bit ????????????????????? // _FORMAT support. uint????????????????? Threads::_smr_delete_lock_wait_cnt = 0; ????????????????????? // Max # of parallel threads in _smr_delete_lock->wait(). ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. uint????????????????? Threads::_smr_delete_lock_wait_max = 0; ????????????????????? // Flag to indicate when an _smr_delete_lock->notify() is needed. ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. volatile uint???????? Threads::_smr_delete_notify = 0; ????????????????????? // # of threads deleted over VM lifetime. ????????????????????? // Impl note: Atomically incremented over VM lifetime so ????????????????????? // use unsigned for more range. Unsigned 64-bit would ????????????????????? // be more future proof, but 64-bit atomic inc isn't ????????????????????? // available everywhere (or is it?). volatile uint???????? Threads::_smr_deleted_thread_cnt = 0; ????????????????????? // Max time in millis to delete a thread. ????????????????????? // Impl note: 16-bit might be too small on an overloaded ????????????????????? // machine. Use unsigned since this is a time value. Set ????????????????????? // via Atomic::cmpxchg() in a loop for correctness. volatile uint???????? Threads::_smr_deleted_thread_time_max = 0; ????????????????????? // Cumulative time in millis to delete threads. ????????????????????? // Impl note: Atomically added to over VM lifetime so use ????????????????????? // unsigned for more range. Unsigned 64-bit would be more ????????????????????? // future proof, but 64-bit atomic inc isn't available ????????????????????? // everywhere (or is it?). volatile uint???????? Threads::_smr_deleted_thread_times = 0; ThreadsList* volatile Threads::_smr_java_thread_list = new ThreadsList(0); ????????????????????? // # of ThreadsLists allocated over VM lifetime. ????????????????????? // Impl note: We allocate a new ThreadsList for every ????????????????????? // thread create and every thread delete so we need a ????????????????????? // bigger type than the _smr_deleted_thread_cnt field. uint64_t????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; ????????????????????? // # of ThreadsLists freed over VM lifetime. ????????????????????? // Impl note: See _smr_java_thread_list_alloc_cnt note. uint64_t????????????? Threads::_smr_java_thread_list_free_cnt = 0; ????????????????????? // Max size ThreadsList allocated. ????????????????????? // Impl note: Max # of threads alive at one time should ????????????????????? // fit in unsigned 32-bit. uint????????????????? Threads::_smr_java_thread_list_max = 0; ????????????????????? // Max # of nested ThreadsLists for a thread. ????????????????????? // Impl note: Hard to imagine > 64K nested ThreadsLists ????????????????????? // so his could be 16-bit, but there is no nice 16-bit ????????????????????? // _FORMAT support. uint????????????????? Threads::_smr_nested_thread_list_max = 0; ????????????????????? // # of ThreadsListHandles deleted over VM lifetime. ????????????????????? // Impl note: Atomically incremented over VM lifetime so ????????????????????? // use unsigned for more range. There will be fewer ????????????????????? // ThreadsListHandles than threads so unsigned 32-bit ????????????????????? // should be fine. volatile uint???????? Threads::_smr_tlh_cnt = 0; ????????????????????? // Max time in millis to delete a ThreadsListHandle. ????????????????????? // Impl note: 16-bit might be too small on an overloaded ????????????????????? // machine. Use unsigned since this is a time value. Set ????????????????????? // via Atomic::cmpxchg() in a loop for correctness. volatile uint???????? Threads::_smr_tlh_time_max = 0; ????????????????????? // Cumulative time in millis to delete ThreadsListHandles. ????????????????????? // Impl note: Atomically added to over VM lifetime so use ????????????????????? // unsigned for more range. Unsigned 64-bit would be more ????????????????????? // future proof, but 64-bit atomic inc isn't available ????????????????????? // everywhere (or is it?). volatile uint???????? Threads::_smr_tlh_times = 0; ThreadsList*????????? Threads::_smr_to_delete_list = NULL; ????????????????????? // # of parallel ThreadsLists on the to-delete list. ????????????????????? // Impl note: Hard to imagine > 64K ThreadsLists needing ????????????????????? // to be deleted so this could be 16-bit, but there is no ????????????????????? // nice 16-bit _FORMAT support. uint????????????????? Threads::_smr_to_delete_list_cnt = 0; ????????????????????? // Max # of parallel ThreadsLists on the to-delete list. ????????????????????? // Impl note: See _smr_to_delete_list_cnt note. uint????????????????? Threads::_smr_to_delete_list_max = 0; Yikes! With the additional comments, the additions to thread.hpp and thread.cpp grew by a bunch... I've done a test build build on my Mac with these changes and I'm about to kick off a Mach5 tier1 job... Dan > > ---- > > On 19/11/2017 11:49 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Testing of the last round of changes revealed a hang in one of the new >> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >> added another TLH test for good measure. >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >> >> Here is the updated delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >> >> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >> no unexpected failures. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Robbin rebased the project last night/this morning to merge with Thread >>> Local Handshakes (TLH) and also picked up additional changesets up >>> thru: >>> >>>> Changeset: fa736014cf28 >>>> Author:??? cjplummer >>>> Date:????? 2017-11-14 18:08 -0800 >>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>> >>>> 8191049: Add alternate version of pns() that is callable from >>>> within hotspot source >>>> Summary: added pns2() to debug.cpp >>>> Reviewed-by: stuefe, gthornbr >>> >>> This is the first time we've rebased the project to bits that are this >>> fresh (< 12 hours old at rebase time). We've done this because we think >>> we're done with this project and are in the final review-change-retest >>> cycle(s)... In other words, we're not planning on making any more major >>> changes for this project... :-) >>> >>> *** Time for code reviewers to chime in on this thread! *** >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>> >>> Here's is the delta webrev from the 2017.11.10 rebase: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>> (and the new baseline also)... >>> >>> We're expecting this round to be a little noisier than usual because >>> we did not rebase on a PIT snapshot so the new baseline has not been >>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>> (Yes, we're playing chase-the-repo...) >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>> >>>> Unlike the previous rebase, there were no changes required to the >>>> open code to get the rebased bits to build so there is no delta >>>> webrev. >>>> >>>> These bits have been run through JPRT and I've submitted the usual >>>> Mach5 tier[1-5] test run... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>> >>>>> Here are the updated webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>> >>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>> holiday >>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>> closer >>>>> look today. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Resolving one of the code review comments (from both Stefan K and >>>>>> Coleen) >>>>>> on jdk10-04-full required quite a few changes so it is being done >>>>>> as a >>>>>> standalone patch and corresponding webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to >>>>>> use >>>>>> ??? JavaThreadIteratorWithHandle. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>> >>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>> >>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>> >>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>> describe >>>>>>> and track the work on this project: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>> >>>>>>> >>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>> quotes >>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>> have a >>>>>>> solution for that problem yet. >>>>>>> >>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>> >>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>> tier[2-5] >>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>> additional testing on Erik and Robbin's machines. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Daniel Daugherty >>>>>>> Erik Osterlund >>>>>>> Robbin Ehn >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> From david.holmes at oracle.com Tue Nov 21 02:13:40 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Nov 2017 12:13:40 +1000 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <92d1f572-a745-6f2b-1b5f-e68a1d252bab@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> <92d1f572-a745-6f2b-1b5f-e68a1d252bab@oracle.com> Message-ID: Hi Dan, Just to be clear my comment about use of jint's was not about expected size but the fact you were using a j-type instead of a C++ type when the field is not a Java field. (Coleen has been on a crusade to remove j-types from where they don't belong - and they were removed from the Atomic API as part of that recent templatization effort.) No further comments. :) Thanks, David On 21/11/2017 11:50 AM, Daniel D. Daugherty wrote: > On 11/20/17 12:51 AM, David Holmes wrote: >> Hi Dan, >> >> Figured I'd better cast an eye over this again before it gets pushed :) > > Thanks for reviewing again!! > > >> Only one thing (repeated many times) jumped out at me and apologies if >> this has already been debated back and forth. I missed the exchange >> where the for loop iteration was rewritten into this unusual form: >> >> for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = >> jtiwh.next(); ) { >> >> On first reading I expect most people would mistake the control >> expression for the iteration-expression due to the next(). I didn't >> even know the control expression could introduce a local variable! I >> find this really hard to read stylistically and far too cute/clever >> for its own good. It also violates the style rules regarding implicit >> boolean checks. >> >> I know Stefan proposed this as he did not like the alternate (in a few >> places): >> >> +? { >> +??? ThreadsListHandle tlh; >> +??? JavaThreadIterator jti(tlh.list()); >> +??? for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { >> ... >> +? } >> >> but it seems to me the iterator code has evolved since then and only a >> couple of places need a distinct TLH separate from the actual iterator >> object. So I'm more in favour of the more classic for-loop, with the >> iterator declared before the loop. Or even convert to while loops, as >> this iterator seems more suited to that. > > Actually both Coleen and Stefan had a problem with how much additional > code was added to support an iterator model. In some cases we went from > 1-line to 3-lines and in some cases we went from 1-line to 5-lines. For > Coleen, she wanted 2 of the new lines compressed into 1 new line by using > an iterator with an embedded ThreadsListHandle. Stefan wanted us to try > and get back to 1-line where possible. > > The advantages of the new style are: > > - 1-line to 1-line in all but a few cases > - automatic limited scope of the embedded ThreadsListHandle so we were > ? able to remove extra braces that were added earlier in most cases > > The disadvantages of the new style are: > > - it is an unusual for-loop style (in HotSpot) > - it breaks HotSpot's style rule about implied booleans > > > Stefan K is pretty adamant that the original iterator version where we > go from 1-line to 3-lines or 1-line to 5-lines is not acceptable for GC > code. The compiler guys haven't chimed in on this debate so I'm guessing > they don't have a strong opinion either way. One thing that we don't want > to do is have different styles for the different teams. > > So I had to make a judgement call on whether I thought Runtime could live > with Stefan's idea. Originally I wasn't fond of it either and breaking the > implied boolean style rule is a problem for me (I post that comment a lot > in my code reviews). However, I have to say that I'm a lot happier about > the compactness of the code and the fact that limited ThreadsListHandle > scope comes for 'free' in most cases. > > We're planning to keep the new iterator style for the following reasons: > > - smaller change footprint > - consistent style used for all of the teams > - limited ThreadsListHandle scope comes for free in most cases > > We're hoping that you can live with this decision (for now) and maybe > even grow to like it in the future. :-) > > >> Other than that just a couple of comments on variable type choices, >> and a few typos spotted below. > > Replies embedded below. > > >> >> Thanks, >> David >> --- >> >> src/hotspot/share/runtime/globals.hpp >> >> 2476?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, true, >> ??????? \ >> 2477?????????? "Enable Thread SMR extra validity checks") \ >> 2478 ??????? \ >> 2479?? diagnostic(bool, EnableThreadSMRStatistics, true, ??????? \ >> 2480?????????? "Enable Thread SMR Statistics") ??????? \ >> >> Indent of strings is off by? 3 spaces. > > Fixed. > > >> --- >> >> src/hotspot/share/runtime/handshake.cpp >> >> ?140?????? // There is assumption in code that Threads_lock should be >> lock >> ?200?????? // There is assumption in code that Threads_lock should be >> lock >> >> lock -> locked > > Fixed. > > >> 146???????? // handshake_process_by_vmthread will check the semaphore >> for us again >> >> Needs period at end. > > Fixed. > > >> 148???????? // should be okey since the new thread will not have an >> operation. >> >> okey -> okay > > Fixed. > > >> 151???????? // We can't warn here is since the thread do >> cancel_handshake after it have been removed >> >> I think: >> >> // We can't warn here since the thread does cancel_handshake after it >> has been removed > > Fixed. > > >> 152???????? // from ThreadsList. So we should just keep looping here >> until while below return negative. >> >> from -> from the >> >> Needs period at end. > > Fixed both. > > >> >> ?204???????????? // A new thread on the ThreadsList will not have an >> operation. >> >> Change period to comma, and ... > > Fixed. > > >> 205???????????? // Hence is skipped in handshake_process_by_vmthread. >> >> Hence is -> hence it is > > Fixed. > > >> --- >> >> src/hotspot/share/runtime/thread.cpp >> >> 1482???? // dcubed - Looks like the Threads_lock is for stable access >> 1483???? // to _jvmci_old_thread_counters and _jvmci_counters. >> >> Does this comment need revisiting? > > We've been trying to decide what to do about this comment. We'll be > filing a follow up bug for the Compiler team to take another look at > how _jvmci_old_thread_counters and _jvmci_counters are protected. > Threads_lock is a big hammer and there should be a less expensive > solution. Once that bug gets filed, this comment can go away. > > >> 3451 volatile jint ... >> >> Why are you using jint for field types here? (Surprised Coleen hasn't >> spotted them! ;-) ). > > volatile jint???????? Threads::_smr_delete_notify = 0; > volatile jint???????? Threads::_smr_deleted_thread_cnt = 0; > volatile jint???????? Threads::_smr_deleted_thread_time_max = 0; > volatile jint???????? Threads::_smr_deleted_thread_times = 0; > : > volatile jint???????? Threads::_smr_tlh_cnt = 0; > volatile jint???????? Threads::_smr_tlh_time_max = 0; > volatile jint???????? Threads::_smr_tlh_times = 0; > > _smr_delete_notify is a "flag" that indicates when an _smr_delete_lock > notify() operation is needed. It counts up and down and should be a fairly > small number. > > _smr_deleted_thread_cnt counts the number of Threads that have been > deleted over the life of the VM. It's an always increasing number so > it's size depends on how long the VM has been running. > > _smr_deleted_thread_time_max is the maximum time in millis it has > taken to delete a thread. This field was originally a jlong, but > IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have > just been Atomic::add() that was not happy) > > _smr_deleted_thread_times accumulates the time in millis that it > has taken to delete threads. It's an always increasing number so > it's size depends on how long the VM has been running. This field > was originally a jlong, but IIRC the Atomic::add() code was not > happy on ARM... (might have just been Atomic::cmpxchg() that was > not happy) > > _smr_tlh_cnt counts the number of ThreadsListHandles that have been > deleted over the life of the VM. It's an always increasing number so > it's size depends on how long the VM has been running. > > _smr_tlh_time_max is the maximum time in millis it has taken to > delete a ThreadsListHandle. This field was originally a jlong, but > IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have > just been Atomic::add() that was not happy) > > _smr_tlh_times? accumulates the time in millis that it has taken to > delete ThreadsListHandles. It's an always increasing number so > it's size depends on how long the VM has been running.? This field > was originally a jlong, but IIRC the Atomic::add() code was not > happy on ARM... (might have just been Atomic::cmpxchg() that was > not happy) > > > It just dawned on me that I'm not sure whether you think the 'jint' > fields should be larger or smaller or the same size but a different > type... :-) > > The fact that I had to write so much to explain what these fields > are for and how they're used indicates I need more comments. See > below... > > >> 3456 long Threads::_smr_java_thread_list_alloc_cnt = 1; >> 3457 long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; >> >> long? If you really want 64-bit counters here you won't get them on >> Windows with that declaration. If you really want variable sized >> counters I suggest uintptr_t; otherwise uint64_t. > > long????????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; > long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; > > _smr_java_thread_list_alloc_cnt counts the number of ThreadsLists that > have been allocated over the life of the VM. It's an always increasing > number so it's size depends on how long the VM has been running and how > many Threads have been created and destroyed. > > _smr_java_thread_list_free_cnt counts the number of ThreadsLists that > have been freed over the life of the VM. It's an always increasing > number so it's size depends on how long the VM has been running and how > many Threads have been created and destroyed. > > I can't remember why we chose 'long' and I agree it's not a good choice > for Win*. > > > Okay so it dawns on me that we haven't written down a description for > the various new '_cnt', '_max' and '_times" fields so I'm adding these > comments to thread.hpp: > > ?private: > ? // Safe Memory Reclamation (SMR) support: > ? static Monitor*????????????? _smr_delete_lock; > ? // The '_cnt', '_max' and '_times" fields are enabled via > ? // -XX:+EnableThreadSMRStatistics: > ?????????????????????????????? // # of parallel threads in > _smr_delete_lock->wait(). > ? static uint????????????????? _smr_delete_lock_wait_cnt; > ?????????????????????????????? // Max # of parallel threads in > _smr_delete_lock->wait(). > ? static uint????????????????? _smr_delete_lock_wait_max; > ?????????????????????????????? // Flag to indicate when an > _smr_delete_lock->notify() is needed. > ? static volatile uint???????? _smr_delete_notify; > ?????????????????????????????? // # of threads deleted over VM lifetime. > ? static volatile uint???????? _smr_deleted_thread_cnt; > ?????????????????????????????? // Max time in millis to delete a thread. > ? static volatile uint???????? _smr_deleted_thread_time_max; > ?????????????????????????????? // Cumulative time in millis to delete > threads. > ? static volatile uint???????? _smr_deleted_thread_times; > ? static ThreadsList* volatile _smr_java_thread_list; > ? static ThreadsList*????????? get_smr_java_thread_list(); > ? static ThreadsList* xchg_smr_java_thread_list(ThreadsList* new_list); > ?????????????????????????????? // # of ThreadsLists allocated over VM > lifetime. > ? static uint64_t????????????? _smr_java_thread_list_alloc_cnt; > ?????????????????????????????? // # of ThreadsLists freed over VM > lifetime. > ? static uint64_t????????????? _smr_java_thread_list_free_cnt; > ?????????????????????????????? // Max size ThreadsList allocated. > ? static uint????????????????? _smr_java_thread_list_max; > ?????????????????????????????? // Max # of nested ThreadsLists for a > thread. > ? static uint????????????????? _smr_nested_thread_list_max; > ?????????????????????????????? // # of ThreadsListHandles deleted over > VM lifetime. > ? static volatile uint???????? _smr_tlh_cnt; > ?????????????????????????????? // Max time in millis to delete a > ThreadsListHandle. > ? static volatile jint???????? _smr_tlh_time_max; > ?????????????????????????????? // Cumulative time in millis to delete > ThreadsListHandles. > ? static volatile jint???????? _smr_tlh_times; > ? static ThreadsList*????????? _smr_to_delete_list; > ?????????????????????????????? // # of parallel ThreadsLists on the > to-delete list. > ? static uint????????????????? _smr_to_delete_list_cnt; > ?????????????????????????????? // Max # of parallel ThreadsLists on the > to-delete list. > ? static uint????????????????? _smr_to_delete_list_max; > > > I've also gone through all the new '_cnt', '_max' and '_times" fields > in thread.cpp and added an impl note to explain the choice of type: > > // Safe Memory Reclamation (SMR) support: > Monitor*????????????? Threads::_smr_delete_lock = > ????????????????????????? new Monitor(Monitor::special, "smr_delete_lock", > ????????????????????????????????????? false /* allow_vm_block */, > Monitor::_safepoint_check_never); > // The '_cnt', '_max' and '_times" fields are enabled via > // -XX:+EnableThreadSMRStatistics: > ????????????????????? // # of parallel threads in > _smr_delete_lock->wait(). > ????????????????????? // Impl note: Hard to imagine > 64K waiting > threads so > ????????????????????? // this could be 16-bit, but there is no nice 16-bit > ????????????????????? // _FORMAT support. > uint????????????????? Threads::_smr_delete_lock_wait_cnt = 0; > ????????????????????? // Max # of parallel threads in > _smr_delete_lock->wait(). > ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. > uint????????????????? Threads::_smr_delete_lock_wait_max = 0; > ????????????????????? // Flag to indicate when an > _smr_delete_lock->notify() is needed. > ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. > volatile uint???????? Threads::_smr_delete_notify = 0; > ????????????????????? // # of threads deleted over VM lifetime. > ????????????????????? // Impl note: Atomically incremented over VM > lifetime so > ????????????????????? // use unsigned for more range. Unsigned 64-bit > would > ????????????????????? // be more future proof, but 64-bit atomic inc isn't > ????????????????????? // available everywhere (or is it?). > volatile uint???????? Threads::_smr_deleted_thread_cnt = 0; > ????????????????????? // Max time in millis to delete a thread. > ????????????????????? // Impl note: 16-bit might be too small on an > overloaded > ????????????????????? // machine. Use unsigned since this is a time > value. Set > ????????????????????? // via Atomic::cmpxchg() in a loop for correctness. > volatile uint???????? Threads::_smr_deleted_thread_time_max = 0; > ????????????????????? // Cumulative time in millis to delete threads. > ????????????????????? // Impl note: Atomically added to over VM > lifetime so use > ????????????????????? // unsigned for more range. Unsigned 64-bit would > be more > ????????????????????? // future proof, but 64-bit atomic inc isn't > available > ????????????????????? // everywhere (or is it?). > volatile uint???????? Threads::_smr_deleted_thread_times = 0; > ThreadsList* volatile Threads::_smr_java_thread_list = new ThreadsList(0); > ????????????????????? // # of ThreadsLists allocated over VM lifetime. > ????????????????????? // Impl note: We allocate a new ThreadsList for > every > ????????????????????? // thread create and every thread delete so we > need a > ????????????????????? // bigger type than the _smr_deleted_thread_cnt > field. > uint64_t????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; > ????????????????????? // # of ThreadsLists freed over VM lifetime. > ????????????????????? // Impl note: See _smr_java_thread_list_alloc_cnt > note. > uint64_t????????????? Threads::_smr_java_thread_list_free_cnt = 0; > ????????????????????? // Max size ThreadsList allocated. > ????????????????????? // Impl note: Max # of threads alive at one time > should > ????????????????????? // fit in unsigned 32-bit. > uint????????????????? Threads::_smr_java_thread_list_max = 0; > ????????????????????? // Max # of nested ThreadsLists for a thread. > ????????????????????? // Impl note: Hard to imagine > 64K nested > ThreadsLists > ????????????????????? // so his could be 16-bit, but there is no nice > 16-bit > ????????????????????? // _FORMAT support. > uint????????????????? Threads::_smr_nested_thread_list_max = 0; > ????????????????????? // # of ThreadsListHandles deleted over VM lifetime. > ????????????????????? // Impl note: Atomically incremented over VM > lifetime so > ????????????????????? // use unsigned for more range. There will be fewer > ????????????????????? // ThreadsListHandles than threads so unsigned > 32-bit > ????????????????????? // should be fine. > volatile uint???????? Threads::_smr_tlh_cnt = 0; > ????????????????????? // Max time in millis to delete a ThreadsListHandle. > ????????????????????? // Impl note: 16-bit might be too small on an > overloaded > ????????????????????? // machine. Use unsigned since this is a time > value. Set > ????????????????????? // via Atomic::cmpxchg() in a loop for correctness. > volatile uint???????? Threads::_smr_tlh_time_max = 0; > ????????????????????? // Cumulative time in millis to delete > ThreadsListHandles. > ????????????????????? // Impl note: Atomically added to over VM > lifetime so use > ????????????????????? // unsigned for more range. Unsigned 64-bit would > be more > ????????????????????? // future proof, but 64-bit atomic inc isn't > available > ????????????????????? // everywhere (or is it?). > volatile uint???????? Threads::_smr_tlh_times = 0; > ThreadsList*????????? Threads::_smr_to_delete_list = NULL; > ????????????????????? // # of parallel ThreadsLists on the to-delete list. > ????????????????????? // Impl note: Hard to imagine > 64K ThreadsLists > needing > ????????????????????? // to be deleted so this could be 16-bit, but > there is no > ????????????????????? // nice 16-bit _FORMAT support. > uint????????????????? Threads::_smr_to_delete_list_cnt = 0; > ????????????????????? // Max # of parallel ThreadsLists on the > to-delete list. > ????????????????????? // Impl note: See _smr_to_delete_list_cnt note. > uint????????????????? Threads::_smr_to_delete_list_max = 0; > > > Yikes! With the additional comments, the additions to thread.hpp and > thread.cpp grew by a bunch... I've done a test build build on my Mac > with these changes and I'm about to kick off a Mach5 tier1 job... > > Dan > > > >> >> ---- >> >> On 19/11/2017 11:49 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Testing of the last round of changes revealed a hang in one of the new >>> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >>> added another TLH test for good measure. >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>> >>> Here is the updated delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>> >>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>> no unexpected failures. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Robbin rebased the project last night/this morning to merge with Thread >>>> Local Handshakes (TLH) and also picked up additional changesets up >>>> thru: >>>> >>>>> Changeset: fa736014cf28 >>>>> Author:??? cjplummer >>>>> Date:????? 2017-11-14 18:08 -0800 >>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>> >>>>> 8191049: Add alternate version of pns() that is callable from >>>>> within hotspot source >>>>> Summary: added pns2() to debug.cpp >>>>> Reviewed-by: stuefe, gthornbr >>>> >>>> This is the first time we've rebased the project to bits that are this >>>> fresh (< 12 hours old at rebase time). We've done this because we think >>>> we're done with this project and are in the final review-change-retest >>>> cycle(s)... In other words, we're not planning on making any more major >>>> changes for this project... :-) >>>> >>>> *** Time for code reviewers to chime in on this thread! *** >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>> >>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>> (and the new baseline also)... >>>> >>>> We're expecting this round to be a little noisier than usual because >>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>> (Yes, we're playing chase-the-repo...) >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>> >>>>> Unlike the previous rebase, there were no changes required to the >>>>> open code to get the rebased bits to build so there is no delta >>>>> webrev. >>>>> >>>>> These bits have been run through JPRT and I've submitted the usual >>>>> Mach5 tier[1-5] test run... >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>> >>>>>> Here are the updated webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>> >>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>> holiday >>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>> closer >>>>>> look today. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Resolving one of the code review comments (from both Stefan K and >>>>>>> Coleen) >>>>>>> on jdk10-04-full required quite a few changes so it is being done >>>>>>> as a >>>>>>> standalone patch and corresponding webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to >>>>>>> use >>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>> >>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>> >>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>> >>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>> describe >>>>>>>> and track the work on this project: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>> >>>>>>>> >>>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>>> quotes >>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>> have a >>>>>>>> solution for that problem yet. >>>>>>>> >>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>> >>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>> tier[2-5] >>>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Daniel Daugherty >>>>>>>> Erik Osterlund >>>>>>>> Robbin Ehn >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> > From daniel.daugherty at oracle.com Tue Nov 21 03:51:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 20 Nov 2017 22:51:16 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> <92d1f572-a745-6f2b-1b5f-e68a1d252bab@oracle.com> Message-ID: <0fc655c8-fffe-03cc-0f7b-a34a9893923d@oracle.com> On 11/20/17 9:13 PM, David Holmes wrote: > Hi Dan, > > Just to be clear my comment about use of jint's was not about expected > size but the fact you were using a j-type instead of a C++ type when > the field is not a Java field. (Coleen has been on a crusade to remove > j-types from where they don't belong - and they were removed from the > Atomic API as part of that recent templatization effort.) Thanks for making that clear. I think I've gotten rid of all the jint's at this point... > No further comments. :) Thanks. I'll be sending out more webrevs when I get through all the code review comments... Dan > > Thanks, > David > > On 21/11/2017 11:50 AM, Daniel D. Daugherty wrote: >> On 11/20/17 12:51 AM, David Holmes wrote: >>> Hi Dan, >>> >>> Figured I'd better cast an eye over this again before it gets pushed :) >> >> Thanks for reviewing again!! >> >> >>> Only one thing (repeated many times) jumped out at me and apologies >>> if this has already been debated back and forth. I missed the >>> exchange where the for loop iteration was rewritten into this >>> unusual form: >>> >>> for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = >>> jtiwh.next(); ) { >>> >>> On first reading I expect most people would mistake the control >>> expression for the iteration-expression due to the next(). I didn't >>> even know the control expression could introduce a local variable! I >>> find this really hard to read stylistically and far too cute/clever >>> for its own good. It also violates the style rules regarding >>> implicit boolean checks. >>> >>> I know Stefan proposed this as he did not like the alternate (in a >>> few places): >>> >>> +? { >>> +??? ThreadsListHandle tlh; >>> +??? JavaThreadIterator jti(tlh.list()); >>> +??? for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { >>> ... >>> +? } >>> >>> but it seems to me the iterator code has evolved since then and only >>> a couple of places need a distinct TLH separate from the actual >>> iterator object. So I'm more in favour of the more classic for-loop, >>> with the iterator declared before the loop. Or even convert to while >>> loops, as this iterator seems more suited to that. >> >> Actually both Coleen and Stefan had a problem with how much additional >> code was added to support an iterator model. In some cases we went from >> 1-line to 3-lines and in some cases we went from 1-line to 5-lines. For >> Coleen, she wanted 2 of the new lines compressed into 1 new line by >> using >> an iterator with an embedded ThreadsListHandle. Stefan wanted us to try >> and get back to 1-line where possible. >> >> The advantages of the new style are: >> >> - 1-line to 1-line in all but a few cases >> - automatic limited scope of the embedded ThreadsListHandle so we were >> ?? able to remove extra braces that were added earlier in most cases >> >> The disadvantages of the new style are: >> >> - it is an unusual for-loop style (in HotSpot) >> - it breaks HotSpot's style rule about implied booleans >> >> >> Stefan K is pretty adamant that the original iterator version where we >> go from 1-line to 3-lines or 1-line to 5-lines is not acceptable for GC >> code. The compiler guys haven't chimed in on this debate so I'm guessing >> they don't have a strong opinion either way. One thing that we don't >> want >> to do is have different styles for the different teams. >> >> So I had to make a judgement call on whether I thought Runtime could >> live >> with Stefan's idea. Originally I wasn't fond of it either and >> breaking the >> implied boolean style rule is a problem for me (I post that comment a >> lot >> in my code reviews). However, I have to say that I'm a lot happier about >> the compactness of the code and the fact that limited ThreadsListHandle >> scope comes for 'free' in most cases. >> >> We're planning to keep the new iterator style for the following reasons: >> >> - smaller change footprint >> - consistent style used for all of the teams >> - limited ThreadsListHandle scope comes for free in most cases >> >> We're hoping that you can live with this decision (for now) and maybe >> even grow to like it in the future. :-) >> >> >>> Other than that just a couple of comments on variable type choices, >>> and a few typos spotted below. >> >> Replies embedded below. >> >> >>> >>> Thanks, >>> David >>> --- >>> >>> src/hotspot/share/runtime/globals.hpp >>> >>> 2476?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, true, >>> ??????? \ >>> 2477?????????? "Enable Thread SMR extra validity checks") \ >>> 2478 ??????? \ >>> 2479?? diagnostic(bool, EnableThreadSMRStatistics, true, ??????? \ >>> 2480?????????? "Enable Thread SMR Statistics") ??????? \ >>> >>> Indent of strings is off by? 3 spaces. >> >> Fixed. >> >> >>> --- >>> >>> src/hotspot/share/runtime/handshake.cpp >>> >>> ?140?????? // There is assumption in code that Threads_lock should >>> be lock >>> ?200?????? // There is assumption in code that Threads_lock should >>> be lock >>> >>> lock -> locked >> >> Fixed. >> >> >>> 146???????? // handshake_process_by_vmthread will check the >>> semaphore for us again >>> >>> Needs period at end. >> >> Fixed. >> >> >>> 148???????? // should be okey since the new thread will not have an >>> operation. >>> >>> okey -> okay >> >> Fixed. >> >> >>> 151???????? // We can't warn here is since the thread do >>> cancel_handshake after it have been removed >>> >>> I think: >>> >>> // We can't warn here since the thread does cancel_handshake after >>> it has been removed >> >> Fixed. >> >> >>> 152???????? // from ThreadsList. So we should just keep looping here >>> until while below return negative. >>> >>> from -> from the >>> >>> Needs period at end. >> >> Fixed both. >> >> >>> >>> ?204???????????? // A new thread on the ThreadsList will not have an >>> operation. >>> >>> Change period to comma, and ... >> >> Fixed. >> >> >>> 205???????????? // Hence is skipped in handshake_process_by_vmthread. >>> >>> Hence is -> hence it is >> >> Fixed. >> >> >>> --- >>> >>> src/hotspot/share/runtime/thread.cpp >>> >>> 1482???? // dcubed - Looks like the Threads_lock is for stable access >>> 1483???? // to _jvmci_old_thread_counters and _jvmci_counters. >>> >>> Does this comment need revisiting? >> >> We've been trying to decide what to do about this comment. We'll be >> filing a follow up bug for the Compiler team to take another look at >> how _jvmci_old_thread_counters and _jvmci_counters are protected. >> Threads_lock is a big hammer and there should be a less expensive >> solution. Once that bug gets filed, this comment can go away. >> >> >>> 3451 volatile jint ... >>> >>> Why are you using jint for field types here? (Surprised Coleen >>> hasn't spotted them! ;-) ). >> >> volatile jint???????? Threads::_smr_delete_notify = 0; >> volatile jint???????? Threads::_smr_deleted_thread_cnt = 0; >> volatile jint???????? Threads::_smr_deleted_thread_time_max = 0; >> volatile jint???????? Threads::_smr_deleted_thread_times = 0; >> : >> volatile jint???????? Threads::_smr_tlh_cnt = 0; >> volatile jint???????? Threads::_smr_tlh_time_max = 0; >> volatile jint???????? Threads::_smr_tlh_times = 0; >> >> _smr_delete_notify is a "flag" that indicates when an _smr_delete_lock >> notify() operation is needed. It counts up and down and should be a >> fairly >> small number. >> >> _smr_deleted_thread_cnt counts the number of Threads that have been >> deleted over the life of the VM. It's an always increasing number so >> it's size depends on how long the VM has been running. >> >> _smr_deleted_thread_time_max is the maximum time in millis it has >> taken to delete a thread. This field was originally a jlong, but >> IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have >> just been Atomic::add() that was not happy) >> >> _smr_deleted_thread_times accumulates the time in millis that it >> has taken to delete threads. It's an always increasing number so >> it's size depends on how long the VM has been running. This field >> was originally a jlong, but IIRC the Atomic::add() code was not >> happy on ARM... (might have just been Atomic::cmpxchg() that was >> not happy) >> >> _smr_tlh_cnt counts the number of ThreadsListHandles that have been >> deleted over the life of the VM. It's an always increasing number so >> it's size depends on how long the VM has been running. >> >> _smr_tlh_time_max is the maximum time in millis it has taken to >> delete a ThreadsListHandle. This field was originally a jlong, but >> IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have >> just been Atomic::add() that was not happy) >> >> _smr_tlh_times? accumulates the time in millis that it has taken to >> delete ThreadsListHandles. It's an always increasing number so >> it's size depends on how long the VM has been running.? This field >> was originally a jlong, but IIRC the Atomic::add() code was not >> happy on ARM... (might have just been Atomic::cmpxchg() that was >> not happy) >> >> >> It just dawned on me that I'm not sure whether you think the 'jint' >> fields should be larger or smaller or the same size but a different >> type... :-) >> >> The fact that I had to write so much to explain what these fields >> are for and how they're used indicates I need more comments. See >> below... >> >> >>> 3456 long Threads::_smr_java_thread_list_alloc_cnt = 1; >>> 3457 long Threads::_smr_java_thread_list_free_cnt = 0; >>> >>> long? If you really want 64-bit counters here you won't get them on >>> Windows with that declaration. If you really want variable sized >>> counters I suggest uintptr_t; otherwise uint64_t. >> >> long????????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; >> long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; >> >> _smr_java_thread_list_alloc_cnt counts the number of ThreadsLists that >> have been allocated over the life of the VM. It's an always increasing >> number so it's size depends on how long the VM has been running and how >> many Threads have been created and destroyed. >> >> _smr_java_thread_list_free_cnt counts the number of ThreadsLists that >> have been freed over the life of the VM. It's an always increasing >> number so it's size depends on how long the VM has been running and how >> many Threads have been created and destroyed. >> >> I can't remember why we chose 'long' and I agree it's not a good choice >> for Win*. >> >> >> Okay so it dawns on me that we haven't written down a description for >> the various new '_cnt', '_max' and '_times" fields so I'm adding these >> comments to thread.hpp: >> >> ??private: >> ?? // Safe Memory Reclamation (SMR) support: >> ?? static Monitor*????????????? _smr_delete_lock; >> ?? // The '_cnt', '_max' and '_times" fields are enabled via >> ?? // -XX:+EnableThreadSMRStatistics: >> ??????????????????????????????? // # of parallel threads in >> _smr_delete_lock->wait(). >> ?? static uint????????????????? _smr_delete_lock_wait_cnt; >> ??????????????????????????????? // Max # of parallel threads in >> _smr_delete_lock->wait(). >> ?? static uint????????????????? _smr_delete_lock_wait_max; >> ??????????????????????????????? // Flag to indicate when an >> _smr_delete_lock->notify() is needed. >> ?? static volatile uint???????? _smr_delete_notify; >> ??????????????????????????????? // # of threads deleted over VM >> lifetime. >> ?? static volatile uint???????? _smr_deleted_thread_cnt; >> ??????????????????????????????? // Max time in millis to delete a >> thread. >> ?? static volatile uint???????? _smr_deleted_thread_time_max; >> ??????????????????????????????? // Cumulative time in millis to >> delete threads. >> ?? static volatile uint???????? _smr_deleted_thread_times; >> ?? static ThreadsList* volatile _smr_java_thread_list; >> ?? static ThreadsList*????????? get_smr_java_thread_list(); >> ?? static ThreadsList* xchg_smr_java_thread_list(ThreadsList* new_list); >> ??????????????????????????????? // # of ThreadsLists allocated over >> VM lifetime. >> ?? static uint64_t????????????? _smr_java_thread_list_alloc_cnt; >> ??????????????????????????????? // # of ThreadsLists freed over VM >> lifetime. >> ?? static uint64_t????????????? _smr_java_thread_list_free_cnt; >> ??????????????????????????????? // Max size ThreadsList allocated. >> ?? static uint????????????????? _smr_java_thread_list_max; >> ??????????????????????????????? // Max # of nested ThreadsLists for a >> thread. >> ?? static uint????????????????? _smr_nested_thread_list_max; >> ??????????????????????????????? // # of ThreadsListHandles deleted >> over VM lifetime. >> ?? static volatile uint???????? _smr_tlh_cnt; >> ??????????????????????????????? // Max time in millis to delete a >> ThreadsListHandle. >> ?? static volatile jint???????? _smr_tlh_time_max; >> ??????????????????????????????? // Cumulative time in millis to >> delete ThreadsListHandles. >> ?? static volatile jint???????? _smr_tlh_times; >> ?? static ThreadsList*????????? _smr_to_delete_list; >> ??????????????????????????????? // # of parallel ThreadsLists on the >> to-delete list. >> ?? static uint????????????????? _smr_to_delete_list_cnt; >> ??????????????????????????????? // Max # of parallel ThreadsLists on >> the to-delete list. >> ?? static uint????????????????? _smr_to_delete_list_max; >> >> >> I've also gone through all the new '_cnt', '_max' and '_times" fields >> in thread.cpp and added an impl note to explain the choice of type: >> >> // Safe Memory Reclamation (SMR) support: >> Monitor*????????????? Threads::_smr_delete_lock = >> ?????????????????????????? new Monitor(Monitor::special, >> "smr_delete_lock", >> ?????????????????????????????????????? false /* allow_vm_block */, >> Monitor::_safepoint_check_never); >> // The '_cnt', '_max' and '_times" fields are enabled via >> // -XX:+EnableThreadSMRStatistics: >> ?????????????????????? // # of parallel threads in >> _smr_delete_lock->wait(). >> ?????????????????????? // Impl note: Hard to imagine > 64K waiting >> threads so >> ?????????????????????? // this could be 16-bit, but there is no nice >> 16-bit >> ?????????????????????? // _FORMAT support. >> uint????????????????? Threads::_smr_delete_lock_wait_cnt = 0; >> ?????????????????????? // Max # of parallel threads in >> _smr_delete_lock->wait(). >> ?????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. >> uint????????????????? Threads::_smr_delete_lock_wait_max = 0; >> ?????????????????????? // Flag to indicate when an >> _smr_delete_lock->notify() is needed. >> ?????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. >> volatile uint???????? Threads::_smr_delete_notify = 0; >> ?????????????????????? // # of threads deleted over VM lifetime. >> ?????????????????????? // Impl note: Atomically incremented over VM >> lifetime so >> ?????????????????????? // use unsigned for more range. Unsigned >> 64-bit would >> ?????????????????????? // be more future proof, but 64-bit atomic inc >> isn't >> ?????????????????????? // available everywhere (or is it?). >> volatile uint???????? Threads::_smr_deleted_thread_cnt = 0; >> ?????????????????????? // Max time in millis to delete a thread. >> ?????????????????????? // Impl note: 16-bit might be too small on an >> overloaded >> ?????????????????????? // machine. Use unsigned since this is a time >> value. Set >> ?????????????????????? // via Atomic::cmpxchg() in a loop for >> correctness. >> volatile uint???????? Threads::_smr_deleted_thread_time_max = 0; >> ?????????????????????? // Cumulative time in millis to delete threads. >> ?????????????????????? // Impl note: Atomically added to over VM >> lifetime so use >> ?????????????????????? // unsigned for more range. Unsigned 64-bit >> would be more >> ?????????????????????? // future proof, but 64-bit atomic inc isn't >> available >> ?????????????????????? // everywhere (or is it?). >> volatile uint???????? Threads::_smr_deleted_thread_times = 0; >> ThreadsList* volatile Threads::_smr_java_thread_list = new >> ThreadsList(0); >> ?????????????????????? // # of ThreadsLists allocated over VM lifetime. >> ?????????????????????? // Impl note: We allocate a new ThreadsList >> for every >> ?????????????????????? // thread create and every thread delete so we >> need a >> ?????????????????????? // bigger type than the >> _smr_deleted_thread_cnt field. >> uint64_t????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; >> ?????????????????????? // # of ThreadsLists freed over VM lifetime. >> ?????????????????????? // Impl note: See >> _smr_java_thread_list_alloc_cnt note. >> uint64_t????????????? Threads::_smr_java_thread_list_free_cnt = 0; >> ?????????????????????? // Max size ThreadsList allocated. >> ?????????????????????? // Impl note: Max # of threads alive at one >> time should >> ?????????????????????? // fit in unsigned 32-bit. >> uint????????????????? Threads::_smr_java_thread_list_max = 0; >> ?????????????????????? // Max # of nested ThreadsLists for a thread. >> ?????????????????????? // Impl note: Hard to imagine > 64K nested >> ThreadsLists >> ?????????????????????? // so his could be 16-bit, but there is no >> nice 16-bit >> ?????????????????????? // _FORMAT support. >> uint????????????????? Threads::_smr_nested_thread_list_max = 0; >> ?????????????????????? // # of ThreadsListHandles deleted over VM >> lifetime. >> ?????????????????????? // Impl note: Atomically incremented over VM >> lifetime so >> ?????????????????????? // use unsigned for more range. There will be >> fewer >> ?????????????????????? // ThreadsListHandles than threads so unsigned >> 32-bit >> ?????????????????????? // should be fine. >> volatile uint???????? Threads::_smr_tlh_cnt = 0; >> ?????????????????????? // Max time in millis to delete a >> ThreadsListHandle. >> ?????????????????????? // Impl note: 16-bit might be too small on an >> overloaded >> ?????????????????????? // machine. Use unsigned since this is a time >> value. Set >> ?????????????????????? // via Atomic::cmpxchg() in a loop for >> correctness. >> volatile uint???????? Threads::_smr_tlh_time_max = 0; >> ?????????????????????? // Cumulative time in millis to delete >> ThreadsListHandles. >> ?????????????????????? // Impl note: Atomically added to over VM >> lifetime so use >> ?????????????????????? // unsigned for more range. Unsigned 64-bit >> would be more >> ?????????????????????? // future proof, but 64-bit atomic inc isn't >> available >> ?????????????????????? // everywhere (or is it?). >> volatile uint???????? Threads::_smr_tlh_times = 0; >> ThreadsList*????????? Threads::_smr_to_delete_list = NULL; >> ?????????????????????? // # of parallel ThreadsLists on the to-delete >> list. >> ?????????????????????? // Impl note: Hard to imagine > 64K >> ThreadsLists needing >> ?????????????????????? // to be deleted so this could be 16-bit, but >> there is no >> ?????????????????????? // nice 16-bit _FORMAT support. >> uint????????????????? Threads::_smr_to_delete_list_cnt = 0; >> ?????????????????????? // Max # of parallel ThreadsLists on the >> to-delete list. >> ?????????????????????? // Impl note: See _smr_to_delete_list_cnt note. >> uint????????????????? Threads::_smr_to_delete_list_max = 0; >> >> >> Yikes! With the additional comments, the additions to thread.hpp and >> thread.cpp grew by a bunch... I've done a test build build on my Mac >> with these changes and I'm about to kick off a Mach5 tier1 job... >> >> Dan >> >> >> >>> >>> ---- >>> >>> On 19/11/2017 11:49 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Testing of the last round of changes revealed a hang in one of the new >>>> TLH tests. Robbin has fixed the hang, updated the existing TLH >>>> test, and >>>> added another TLH test for good measure. >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>> >>>> Here is the updated delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>>> >>>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>>> no unexpected failures. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Robbin rebased the project last night/this morning to merge with >>>>> Thread >>>>> Local Handshakes (TLH) and also picked up additional changesets up >>>>> thru: >>>>> >>>>>> Changeset: fa736014cf28 >>>>>> Author:??? cjplummer >>>>>> Date:????? 2017-11-14 18:08 -0800 >>>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>>> >>>>>> 8191049: Add alternate version of pns() that is callable from >>>>>> within hotspot source >>>>>> Summary: added pns2() to debug.cpp >>>>>> Reviewed-by: stuefe, gthornbr >>>>> >>>>> This is the first time we've rebased the project to bits that are >>>>> this >>>>> fresh (< 12 hours old at rebase time). We've done this because we >>>>> think >>>>> we're done with this project and are in the final >>>>> review-change-retest >>>>> cycle(s)... In other words, we're not planning on making any more >>>>> major >>>>> changes for this project... :-) >>>>> >>>>> *** Time for code reviewers to chime in on this thread! *** >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>>> >>>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>>> >>>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>>> (and the new baseline also)... >>>>> >>>>> We're expecting this round to be a little noisier than usual because >>>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>>> (Yes, we're playing chase-the-repo...) >>>>>> >>>>>> Here is the updated full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>>> >>>>>> Unlike the previous rebase, there were no changes required to the >>>>>> open code to get the rebased bits to build so there is no delta >>>>>> webrev. >>>>>> >>>>>> These bits have been run through JPRT and I've submitted the usual >>>>>> Mach5 tier[1-5] test run... >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>>> >>>>>>> Here are the updated webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>>> >>>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>>> holiday >>>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>>> closer >>>>>>> look today. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>>> and Coleen) >>>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>>> done as a >>>>>>>> standalone patch and corresponding webrevs: >>>>>>>> >>>>>>>> Here's the mq comment for the change: >>>>>>>> >>>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>>> to use >>>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>>> >>>>>>>> Here is the full webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>>> >>>>>>>> And here is the delta webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Dan, Erik and Robbin >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>>> >>>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>>> >>>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>>> >>>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>>> describe >>>>>>>>> and track the work on this project: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>>> >>>>>>>>> >>>>>>>>> Dan has noticed that the indenting is wrong in some of the >>>>>>>>> code quotes >>>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>>> have a >>>>>>>>> solution for that problem yet. >>>>>>>>> >>>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>>> >>>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>>> tier[2-5] >>>>>>>>> testing, additional stress testing on Dan's Solaris X64 >>>>>>>>> server, and >>>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>>> >>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>> >>>>>>>>> Daniel Daugherty >>>>>>>>> Erik Osterlund >>>>>>>>> Robbin Ehn >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >> From vladimir.x.ivanov at oracle.com Tue Nov 21 14:23:38 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 21 Nov 2017 17:23:38 +0300 Subject: RFR(S) 8190817: deopt special-case for _return_register_finalizer is confusing and leads to bugs In-Reply-To: <48b1c46e-8eab-8232-3213-044fe59a462b@oracle.com> References: <480ed17b-fae1-8db4-1d12-3319be262d3d@oracle.com> <48b1c46e-8eab-8232-3213-044fe59a462b@oracle.com> Message-ID: <22a8ec1e-b598-9e8a-e68a-0cca6ffbeadc@oracle.com> > http://cr.openjdk.java.net/~dlong/8190817/webrev.1/ Looks good. Best regards, Vladimir Ivanov > > > On 11/17/17 11:15 AM, Dmitrij Pochepko wrote: >> Hi, >> >> I've built clean fastdebug build with this patch and run >> compiler/runtime/Test8168712.java on AArch64 (ThunderX) and it passed. >> >> Please note that this test can't be run on AArch64 by default because >> of @requires tag. I had to update this tag first. Btw: I wonder if it >> should be also updated as a part of this patch? >> >> >> I also took a look at Aarch64-specific change and it looks good to >> me(not a Reviewer). >> >> >> Thanks, >> >> Dmitrij >> >> >> On 13.11.2017 20:32, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8190817 >>> >>> http://cr.openjdk.java.net/~dlong/8190817/webrev/ >>> >>> This fix replaces the problematic use of >>> _normal_table.entry(Bytecodes::_return).entry(vtos) as a >>> deoptimization entry point with a proper deopt entry point returned >>> by deopt_reexecute_return_entry().? This is needed to handle the >>> situation where compiled code is calling register_finalizer() and >>> gets deoptimized. >>> >>> I also noticed that we generate duplicate entry points unnecessarily, >>> so I cleaned that up at the same time. >>> >>> aarch64/ppc64/s390 folks, please check that >>> compiler/runtime/Test8168712.java still passes. >>> >>> dl >>> >> > From daniel.daugherty at oracle.com Tue Nov 21 14:46:10 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Nov 2017 09:46:10 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Message-ID: <56ab19ad-58d7-f65a-b29b-8503a8f6f72a@oracle.com> Hi Robin W! Welcome to the Thread-SMR party!! On 11/20/17 4:48 AM, Robin Westberg wrote: > Hi Dan, > > Overall I must say this looks very nice, can?t wait to use it! (Also a disclaimer: not a reviewer, and have not looked at the gc or jmvti specific changes nor the tests (yet)). Code reviews are always welcome (OpenJDK role does not matter). > Didn?t spot any real issues, just a few small efficiency related things: > > src/hotspot/share/runtime/biasedLocking.cpp > > 217 for (JavaThread* cur_thread = Threads::first(); cur_thread != NULL; cur_thread = cur_thread->next()) { > 218 if (cur_thread == biased_thread) { > 219 thread_is_alive = true; > > This loop could be replaced with: > > ThreadsListHandle tlh; > thread_is_alive = tlh.includes(biased_thread); Nice catch! Fixed with your proposed change. The careful reader will notice that in revoke_bias() we are not creating a ThreadsListHandle that is in scope for the entire function and we are doing cached monitor info walks without an obvious ThreadsListHandle in place. revoke_bias() is called at a safepoint from most locations. The one call that is not made at a safepoint is from BiasedLocking::revoke_and_rebias() and it is made by a JavaThread that is revoking a bias on itself which is also safe. We should add an assertion to revoke_bias() that looks something like this: ? assert(requesting_thread == Thread::current() || ???????? SafepointSynchronize::is_at_safepoint(), ???????? "must be operating on self or at a safepoint."); but we'll do that in a separate follow up bug since that will require biased locking focused testing. > src/hotspot/share/runtime/memprofiler.cpp > > 55-56 grabs the Threads_lock, shouldn?t be needed anymore. Nice catch! Deleting lines 55-56. > src/hotspot/share/runtime/thread.inline.hpp > > 198 TerminatedTypes l_terminated = (TerminatedTypes) > 199 OrderAccess::load_acquire((volatile jint *) &_terminated); > 200 return check_is_terminated(_terminated); > > The variable used in the return statement was intended to be l_terminated I guess? Ouch! Looks like JavaThread::is_exiting() is right, but JavaThread::is_terminated() has been inefficient all this time. Fixed. > The following are more minor suggestions / comments: > > src/hotspot/share/runtime/thread.cpp > > 3432 // operations over all threads. It is protected by its own Mutex > 3433 // lock, which is also used in other contexts to protect thread > > Should this comment perhaps be revised to mention SMR? It definitely needs some updating... Here's a stab at it: // The Threads class links together all active threads, and provides // operations over all threads. It is protected by the Threads_lock, // which is also used in other global contexts like safepointing. // ThreadsListHandles are used to safely perform operations on one // or more threads without the risk of the thread exiting during the // operation. // // Note: The Threads_lock is currently more widely used than we // would like. We are actively migrating Threads_lock uses to other // mechanisms in order to reduce Threads_lock contention. > 4745 hash_table_size--; > 4746 hash_table_size |= hash_table_size >> 1; > ... > > This calculation is repeated around line 4922 as well, perhaps put it in a function? The hash_table_size parameter is currently unused. We were using a different hash table before that allowed the size to be set. Unfortunately, that hash table didn't support being freed so we switched to ResourceHashtable. We have a project note to come back and update the underlying hash table to work with dynamic table sizes, but Erik hasn't had the cycles to do it yet. > 4828 // If someone set a handshake on us just as we entered exit path, we simple cancel it. > > Perhaps something like ?.. entered the exit path, we simply cancel it.? I went with this: ? if (ThreadLocalHandshakes) { ??? // The thread is about to be deleted so cancel any handshake. ??? thread->cancel_handshake(); ? } > src/hotspot/share/runtime/thread.hpp > > 1179 bool on_thread_list() { return _on_thread_list; } > 1180 void set_on_thread_list() { _on_thread_list = true; } > 1181 > 1182 // thread has called JavaThread::exit() or is terminated > 1183 bool is_exiting() const; > 1184 // thread is terminated (no longer on the threads list); we compare > 1185 // against the two non-terminated values so that a freed JavaThread > 1186 // will also be considered terminated. > 1187 bool check_is_terminated(TerminatedTypes l_terminated) const { > 1188 return l_terminated != _not_terminated && l_terminated != _thread_exiting; > 1189 } > 1190 bool is_terminated(); > > Use of const is inconsistent here, it?s added to 1183, should it perhaps be added to 1179 and 1190 as well then? Fixed. > src/hotspot/share/runtime/vm_operations.hpp > > 406 DeadlockCycle* result() { return _deadlocks; }; > 407 VMOp_Type type() const { return VMOp_FindDeadlocks; } > > Whitespace only change that seems spurious. Agreed. Restored to the original. Thanks for the review! Dan > > Best regards, > Robin > >> On 19 Nov 2017, at 02:49, Daniel D. Daugherty wrote: >> >> Greetings, >> >> Testing of the last round of changes revealed a hang in one of the new >> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >> added another TLH test for good measure. >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >> >> Here is the updated delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >> >> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >> no unexpected failures. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Robbin rebased the project last night/this morning to merge with Thread >>> Local Handshakes (TLH) and also picked up additional changesets up thru: >>> >>>> Changeset: fa736014cf28 >>>> Author: cjplummer >>>> Date: 2017-11-14 18:08 -0800 >>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>> >>>> 8191049: Add alternate version of pns() that is callable from within hotspot source >>>> Summary: added pns2() to debug.cpp >>>> Reviewed-by: stuefe, gthornbr >>> This is the first time we've rebased the project to bits that are this >>> fresh (< 12 hours old at rebase time). We've done this because we think >>> we're done with this project and are in the final review-change-retest >>> cycle(s)... In other words, we're not planning on making any more major >>> changes for this project... :-) >>> >>> *** Time for code reviewers to chime in on this thread! *** >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>> >>> Here's is the delta webrev from the 2017.11.10 rebase: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>> (and the new baseline also)... >>> >>> We're expecting this round to be a little noisier than usual because >>> we did not rebase on a PIT snapshot so the new baseline has not been >>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>> (Yes, we're playing chase-the-repo...) >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>> >>>> Unlike the previous rebase, there were no changes required to the >>>> open code to get the rebased bits to build so there is no delta >>>> webrev. >>>> >>>> These bits have been run through JPRT and I've submitted the usual >>>> Mach5 tier[1-5] test run... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>> >>>>> Here are the updated webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> Rebase to 2017.10.25 PIT snapshot. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>> >>>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>>> look today. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Resolving one of the code review comments (from both Stefan K and Coleen) >>>>>> on jdk10-04-full required quite a few changes so it is being done as a >>>>>> standalone patch and corresponding webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>>> JavaThreadIteratorWithHandle. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>> >>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>> >>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>> >>>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>>> and track the work on this project: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>> >>>>>>> Dan has noticed that the indenting is wrong in some of the code quotes >>>>>>> in the PDF that are not present in the internal wiki. We don't have a >>>>>>> solution for that problem yet. >>>>>>> >>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>> >>>>>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>> additional testing on Erik and Robbin's machines. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Daniel Daugherty >>>>>>> Erik Osterlund >>>>>>> Robbin Ehn >>>>>>> >>>>>> >>>>> >>>> >>> From daniel.daugherty at oracle.com Tue Nov 21 16:28:56 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Nov 2017 11:28:56 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Message-ID: <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> Hi Coleen! Thanks for making time to review the Thread-SMR stuff again!! I have added back the other three OpenJDK aliases... This review is being done on _four_ different OpenJDK aliases. As always, replies are embedded below... On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/os/linux/os_linux.cpp.frames.html > > > I read David's comments about the threads list iterator, and I was > going to say that it can be cleaned up later, as the bulk of the > change is the SMR part but this looks truly bizarre.?? It looks like > it shouldn't compile because 'jt' isn't in scope. > > Why isn't this the syntax: > > JavaThreadIteratorWithHandle jtiwh; > for (JavaThread* jt = jtiwh.first(); jt != NULL; jt = jtiwh.next()) { > } > > Which would do the obvious thing without anyone having to squint at > the code. See my reply to David's review for the more detailed answer. For the above syntax, we would need braces to limit the scope of the 'jtiwh' variable. With Stefan's propsal, you get limited scope on 'jtiwh' for "free". > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.hpp.html > > > As a hater of acronmys, can this file use "Safe Memory Reclaimation" I'm not sure what you mean by this. Do you mean rename the files? ? threadSMR.hpp -> threadSafeMemoryReclaimation.hpp ? threadSMR.cpp -> threadSafeMemoryReclaimation.cpp > and briefly describe the concept in the beginning of the header file, > so one knows why it's called threadSMR.hpp? And then this part of the sentence kind of indicates that you would be okay with the threadSMR.{c,h}pp names if a comment was added to the header file. Please clarify. > It doesn't need to be long and include why Threads list needs this > Sometimes we tell new people that the hotspot documentation is in the > header files. Yup. When I migrated stuff from thread.hpp and thread.cpp to threadSMR.hpp and threadSMR.cpp, I should have written a header comment... I did update a comment in thread.cpp based on Robin W's code review: > > src/hotspot/share/runtime/thread.cpp > > > > 3432 // operations over all threads.? It is protected by its own Mutex > > 3433 // lock, which is also used in other contexts to protect thread > > > > Should this comment perhaps be revised to mention SMR? > > It definitely needs some updating... Here's a stab at it: > > // The Threads class links together all active threads, and provides > // operations over all threads. It is protected by the Threads_lock, > // which is also used in other global contexts like safepointing. > // ThreadsListHandles are used to safely perform operations on one > // or more threads without the risk of the thread exiting during the > // operation. > // > // Note: The Threads_lock is currently more widely used than we > // would like. We are actively migrating Threads_lock uses to other > // mechanisms in order to reduce Threads_lock contention. I'll take a look at adding a header comment to threadSMR.hpp. > 186?? JavaThreadIteratorWithHandle() : _tlh(), _index(0) {} > > This _tlh() call should not be necessary.? The compiler should > generate this for you in the constructor. Deleted. > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html > > > ? 32 ThreadsList::ThreadsList(int entries) : _length(entries), > _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), > _next_list(NULL) { > > Seems like it should be mtThread rather than mtGC. Fixed. Definitely an artifact of Erik's original prototype when he extracted Thread-SMR from his GC work... Thanks for catching it. > Should > > ? 62?? if (EnableThreadSMRStatistics) { > > really be UL, ie: if (log_is_enabled(Info, thread, smr, statistics)) ? EnableThreadSMRStatistics is used in more places than UL code. We use it in Thread::print_*() stuff to control output of Thread-SMR statistics info in thread dumps and hs_err_pid file generation. Currently thread dump and hs_err_pid file output is not generated using UL (and probably can't be?) so we need an option to control the Thread-SMR statistics stuff in all places. > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java.html > > > Can you use for these tests instead (there were a couple): > > *@requires (vm.debug == true)* The test I cloned had this in it: ??? if (!Platform.isDebugBuild()) { ??????? // -XX:ErrorHandlerTest=N option requires debug bits. ??????? return; ??? } and you would like me to switch to the newer mechanism? I have updated the following tests: ? test/hotspot/jtreg/runtime/ErrorHandling/ErrorHandler.java test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/thread.cpp.udiff.html > > > +// thread, has been added the Threads list, the system is not at a > > Has "not" been added to the Threads list?? missing "not"? Nope. If the JavaThread has been added to the Threads list and it is not protected, then it is dangling. In other words, a published JavaThread (on the Threads list) has to be protected by either the system being at a safepoint or the JavaThread has to be on some threads's ThreadsList. > > + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); > > Can you add a comment about where this number came from? I'll have to get that from Erik... > I can't find the caller of threads_do_smr. I'm guessing that's used by the GC code that depends on Thread-SMR... > If these functions xchg_smr_thread_list, get_smr_java_thread_list, > inc_smr_deleted_thread_count are only used by thread.cpp, I think they > should go in that file and not in the .inline.hpp file to be included > and possibly called by other files.? I think they're private to class > Threads. I have a vague memory that some of the compilers don't do inlining when an "inline" function is in a .cpp. I believe we want these functions to be inlined for performance reasons. Erik should probably chime in here. > I don't have any in-depth comments.? This looks really good from my > day of reading it. Thanks for taking the time to review it again! Dan > > Thanks, > Coleen > > On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: > >> Greetings, >> >> Testing of the last round of changes revealed a hang in one of the new >> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >> added another TLH test for good measure. >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >> >> Here is the updated delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >> >> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >> no unexpected failures. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Robbin rebased the project last night/this morning to merge with Thread >>> Local Handshakes (TLH) and also picked up additional changesets up >>> thru: >>> >>>> Changeset: fa736014cf28 >>>> Author:??? cjplummer >>>> Date:????? 2017-11-14 18:08 -0800 >>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>> >>>> 8191049: Add alternate version of pns() that is callable from >>>> within hotspot source >>>> Summary: added pns2() to debug.cpp >>>> Reviewed-by: stuefe, gthornbr >>> >>> This is the first time we've rebased the project to bits that are this >>> fresh (< 12 hours old at rebase time). We've done this because we think >>> we're done with this project and are in the final review-change-retest >>> cycle(s)... In other words, we're not planning on making any more major >>> changes for this project... :-) >>> >>> *** Time for code reviewers to chime in on this thread! *** >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>> >>> Here's is the delta webrev from the 2017.11.10 rebase: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>> (and the new baseline also)... >>> >>> We're expecting this round to be a little noisier than usual because >>> we did not rebase on a PIT snapshot so the new baseline has not been >>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>> (Yes, we're playing chase-the-repo...) >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>> >>>> Unlike the previous rebase, there were no changes required to the >>>> open code to get the rebased bits to build so there is no delta >>>> webrev. >>>> >>>> These bits have been run through JPRT and I've submitted the usual >>>> Mach5 tier[1-5] test run... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>> >>>>> Here are the updated webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>> >>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>> holiday >>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>> closer >>>>> look today. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Resolving one of the code review comments (from both Stefan K and >>>>>> Coleen) >>>>>> on jdk10-04-full required quite a few changes so it is being done >>>>>> as a >>>>>> standalone patch and corresponding webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to >>>>>> use >>>>>> ??? JavaThreadIteratorWithHandle. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>> >>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>> >>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>> >>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>> describe >>>>>>> and track the work on this project: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>> >>>>>>> >>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>> quotes >>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>> have a >>>>>>> solution for that problem yet. >>>>>>> >>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>> >>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>> tier[2-5] >>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>> additional testing on Erik and Robbin's machines. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Daniel Daugherty >>>>>>> Erik Osterlund >>>>>>> Robbin Ehn >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > From dean.long at oracle.com Tue Nov 21 17:10:05 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 21 Nov 2017 09:10:05 -0800 Subject: RFR(S) 8190817: deopt special-case for _return_register_finalizer is confusing and leads to bugs In-Reply-To: <22a8ec1e-b598-9e8a-e68a-0cca6ffbeadc@oracle.com> References: <480ed17b-fae1-8db4-1d12-3319be262d3d@oracle.com> <48b1c46e-8eab-8232-3213-044fe59a462b@oracle.com> <22a8ec1e-b598-9e8a-e68a-0cca6ffbeadc@oracle.com> Message-ID: <96d6012f-8cc4-1262-1b33-e4b67e86d609@oracle.com> On 11/21/17 6:23 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~dlong/8190817/webrev.1/ > > Looks good. > Thanks Vladimir. dl > Best regards, > Vladimir Ivanov > >> >> >> On 11/17/17 11:15 AM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> I've built clean fastdebug build with this patch and run >>> compiler/runtime/Test8168712.java on AArch64 (ThunderX) and it passed. >>> >>> Please note that this test can't be run on AArch64 by default >>> because of @requires tag. I had to update this tag first. Btw: I >>> wonder if it should be also updated as a part of this patch? >>> >>> >>> I also took a look at Aarch64-specific change and it looks good to >>> me(not a Reviewer). >>> >>> >>> Thanks, >>> >>> Dmitrij >>> >>> >>> On 13.11.2017 20:32, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8190817 >>>> >>>> http://cr.openjdk.java.net/~dlong/8190817/webrev/ >>>> >>>> This fix replaces the problematic use of >>>> _normal_table.entry(Bytecodes::_return).entry(vtos) as a >>>> deoptimization entry point with a proper deopt entry point returned >>>> by deopt_reexecute_return_entry().? This is needed to handle the >>>> situation where compiled code is calling register_finalizer() and >>>> gets deoptimized. >>>> >>>> I also noticed that we generate duplicate entry points >>>> unnecessarily, so I cleaned that up at the same time. >>>> >>>> aarch64/ppc64/s390 folks, please check that >>>> compiler/runtime/Test8168712.java still passes. >>>> >>>> dl >>>> >>> >> From coleen.phillimore at oracle.com Tue Nov 21 17:24:11 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Nov 2017 12:24:11 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> Message-ID: <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: > Hi Coleen! > > Thanks for making time to review the Thread-SMR stuff again!! > > I have added back the other three OpenJDK aliases... This review is > being done on _four_ different OpenJDK aliases. > > As always, replies are embedded below... > > > On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/os/linux/os_linux.cpp.frames.html >> >> >> I read David's comments about the threads list iterator, and I was >> going to say that it can be cleaned up later, as the bulk of the >> change is the SMR part but this looks truly bizarre.?? It looks like >> it shouldn't compile because 'jt' isn't in scope. >> >> Why isn't this the syntax: >> >> JavaThreadIteratorWithHandle jtiwh; >> for (JavaThread* jt = jtiwh.first(); jt != NULL; jt = jtiwh.next()) { >> } >> >> Which would do the obvious thing without anyone having to squint at >> the code. > > See my reply to David's review for the more detailed answer. > > For the above syntax, we would need braces to limit the scope of the > 'jtiwh' variable. With Stefan's propsal, you get limited scope on > 'jtiwh' for "free". Yes, thank you, I see that motivation now. > > >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.hpp.html >> >> >> As a hater of acronmys, can this file use "Safe Memory Reclaimation" > > I'm not sure what you mean by this. Do you mean rename the files? > > ? threadSMR.hpp -> threadSafeMemoryReclaimation.hpp > ? threadSMR.cpp -> threadSafeMemoryReclaimation.cpp > No. > >> and briefly describe the concept in the beginning of the header file, >> so one knows why it's called threadSMR.hpp? > > And then this part of the sentence kind of indicates that you would be > okay with the threadSMR.{c,h}pp names if a comment was added to the > header file. > > Please clarify. Yes.? If you added a comment to the beginning of the threadSMR.hpp file that said what SMR stood for and what it was, that would be extremely helpful for future viewers of this file. > > >> It doesn't need to be long and include why Threads list needs this >> Sometimes we tell new people that the hotspot documentation is in the >> header files. > > Yup. When I migrated stuff from thread.hpp and thread.cpp to > threadSMR.hpp > and threadSMR.cpp, I should have written a header comment... > > I did update a comment in thread.cpp based on Robin W's code review: Yes, I think a comment belongs in the SMR file also, or in preference. > >> > src/hotspot/share/runtime/thread.cpp >> > >> > 3432 // operations over all threads.? It is protected by its own Mutex >> > 3433 // lock, which is also used in other contexts to protect thread >> > >> > Should this comment perhaps be revised to mention SMR? >> >> It definitely needs some updating... Here's a stab at it: >> >> // The Threads class links together all active threads, and provides >> // operations over all threads. It is protected by the Threads_lock, >> // which is also used in other global contexts like safepointing. >> // ThreadsListHandles are used to safely perform operations on one >> // or more threads without the risk of the thread exiting during the >> // operation. >> // >> // Note: The Threads_lock is currently more widely used than we >> // would like. We are actively migrating Threads_lock uses to other >> // mechanisms in order to reduce Threads_lock contention. > > I'll take a look at adding a header comment to threadSMR.hpp. > > >> 186?? JavaThreadIteratorWithHandle() : _tlh(), _index(0) {} >> >> This _tlh() call should not be necessary.? The compiler should >> generate this for you in the constructor. > > Deleted. > > >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html >> >> >> ? 32 ThreadsList::ThreadsList(int entries) : _length(entries), >> _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), >> _next_list(NULL) { >> >> Seems like it should be mtThread rather than mtGC. > > Fixed. Definitely an artifact of Erik's original prototype when he > extracted Thread-SMR from his GC work... Thanks for catching it. > > >> Should >> >> ? 62?? if (EnableThreadSMRStatistics) { >> >> really be UL, ie: if (log_is_enabled(Info, thread, smr, statistics)) ? > > EnableThreadSMRStatistics is used in more places than UL code. > We use it in Thread::print_*() stuff to control output of > Thread-SMR statistics info in thread dumps and hs_err_pid file > generation. That sort of thing is also controlled by logging in general. > > Currently thread dump and hs_err_pid file output is not generated > using UL (and probably can't be?) so we need an option to control > the Thread-SMR statistics stuff in all places. > You can use log options in preference to this new diagnostic option in these cases too.?? This option looks a lot like logging to me and would be nice to not have to later convert it. > > >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java.html >> >> >> Can you use for these tests instead (there were a couple): >> >> *@requires (vm.debug == true)* > > The test I cloned had this in it: > > ??? if (!Platform.isDebugBuild()) { > ??????? // -XX:ErrorHandlerTest=N option requires debug bits. > ??????? return; > ??? } > > and you would like me to switch to the newer mechanism? > > I have updated the following tests: > > ? test/hotspot/jtreg/runtime/ErrorHandling/ErrorHandler.java > test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java > > test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java > > > Yes, the newer mechanism makes jtreg not bother to run the test, which makes it faster! >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/thread.cpp.udiff.html >> >> >> +// thread, has been added the Threads list, the system is not at a >> >> Has "not" been added to the Threads list?? missing "not"? > > Nope. If the JavaThread has been added to the Threads list > and it is not protected, then it is dangling. In other words, > a published JavaThread (on the Threads list) has to be protected > by either the system being at a safepoint or the JavaThread has > to be on some threads's ThreadsList. > > >> >> + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); >> >> Can you add a comment about where this number came from? > > I'll have to get that from Erik... > > >> I can't find the caller of threads_do_smr. > > I'm guessing that's used by the GC code that depends on Thread-SMR... > They? should add this API when the add the use of it then.? I don't see it in any sources. > >> If these functions xchg_smr_thread_list, get_smr_java_thread_list, >> inc_smr_deleted_thread_count are only used by thread.cpp, I think >> they should go in that file and not in the .inline.hpp file to be >> included and possibly called by other files.? I think they're private >> to class Threads. > > I have a vague memory that some of the compilers don't do inlining when > an "inline" function is in a .cpp. I believe we want these functions > to be inlined for performance reasons. Erik should probably chime in > here. I don't see why this should be.? Maybe some (older) compilers require it to be found before the call though, but that can still be accomplished in the .cpp file. > > >> I don't have any in-depth comments.? This looks really good from my >> day of reading it. > > Thanks for taking the time to review it again! > Thanks, Coleen > Dan > > >> >> Thanks, >> Coleen >> >> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >> >>> Greetings, >>> >>> Testing of the last round of changes revealed a hang in one of the new >>> TLH tests. Robbin has fixed the hang, updated the existing TLH test, >>> and >>> added another TLH test for good measure. >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>> >>> Here is the updated delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>> >>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>> no unexpected failures. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Robbin rebased the project last night/this morning to merge with >>>> Thread >>>> Local Handshakes (TLH) and also picked up additional changesets up >>>> thru: >>>> >>>>> Changeset: fa736014cf28 >>>>> Author:??? cjplummer >>>>> Date:????? 2017-11-14 18:08 -0800 >>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>> >>>>> 8191049: Add alternate version of pns() that is callable from >>>>> within hotspot source >>>>> Summary: added pns2() to debug.cpp >>>>> Reviewed-by: stuefe, gthornbr >>>> >>>> This is the first time we've rebased the project to bits that are this >>>> fresh (< 12 hours old at rebase time). We've done this because we >>>> think >>>> we're done with this project and are in the final review-change-retest >>>> cycle(s)... In other words, we're not planning on making any more >>>> major >>>> changes for this project... :-) >>>> >>>> *** Time for code reviewers to chime in on this thread! *** >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>> >>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>> (and the new baseline also)... >>>> >>>> We're expecting this round to be a little noisier than usual because >>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>> (Yes, we're playing chase-the-repo...) >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>> >>>>> Unlike the previous rebase, there were no changes required to the >>>>> open code to get the rebased bits to build so there is no delta >>>>> webrev. >>>>> >>>>> These bits have been run through JPRT and I've submitted the usual >>>>> Mach5 tier[1-5] test run... >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>> >>>>>> Here are the updated webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>> >>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>> holiday >>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>> closer >>>>>> look today. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>> and Coleen) >>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>> done as a >>>>>>> standalone patch and corresponding webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>> to use >>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>> >>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>> >>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>> >>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>> describe >>>>>>>> and track the work on this project: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>> >>>>>>>> >>>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>>> quotes >>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>> have a >>>>>>>> solution for that problem yet. >>>>>>>> >>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>> >>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>> tier[2-5] >>>>>>>> testing, additional stress testing on Dan's Solaris X64 server, >>>>>>>> and >>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Daniel Daugherty >>>>>>>> Erik Osterlund >>>>>>>> Robbin Ehn >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> > From daniel.daugherty at oracle.com Tue Nov 21 17:30:52 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Nov 2017 12:30:52 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <9cc8b08b-f373-f493-4429-662d18ff81ad@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> <92d1f572-a745-6f2b-1b5f-e68a1d252bab@oracle.com> <9cc8b08b-f373-f493-4429-662d18ff81ad@oracle.com> Message-ID: Adding back the missing OpenJDK aliases... On 11/21/17 11:14 AM, coleen.phillimore at oracle.com wrote: > > > On 11/20/17 8:50 PM, Daniel D. Daugherty wrote: >> On 11/20/17 12:51 AM, David Holmes wrote: >>> Hi Dan, >>> >>> Figured I'd better cast an eye over this again before it gets pushed :) >> >> Thanks for reviewing again!! >> >> >>> Only one thing (repeated many times) jumped out at me and apologies >>> if this has already been debated back and forth. I missed the >>> exchange where the for loop iteration was rewritten into this >>> unusual form: >>> >>> for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = >>> jtiwh.next(); ) { >>> >>> On first reading I expect most people would mistake the control >>> expression for the iteration-expression due to the next(). I didn't >>> even know the control expression could introduce a local variable! I >>> find this really hard to read stylistically and far too cute/clever >>> for its own good. It also violates the style rules regarding >>> implicit boolean checks. >>> >>> I know Stefan proposed this as he did not like the alternate (in a >>> few places): >>> >>> +? { >>> +??? ThreadsListHandle tlh; >>> +??? JavaThreadIterator jti(tlh.list()); >>> +??? for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { >>> ... >>> +? } >>> >>> but it seems to me the iterator code has evolved since then and only >>> a couple of places need a distinct TLH separate from the actual >>> iterator object. So I'm more in favour of the more classic for-loop, >>> with the iterator declared before the loop. Or even convert to while >>> loops, as this iterator seems more suited to that. >> >> Actually both Coleen and Stefan had a problem with how much additional >> code was added to support an iterator model. In some cases we went from >> 1-line to 3-lines and in some cases we went from 1-line to 5-lines. For >> Coleen, she wanted 2 of the new lines compressed into 1 new line by >> using >> an iterator with an embedded ThreadsListHandle. Stefan wanted us to try >> and get back to 1-line where possible. >> >> The advantages of the new style are: >> >> - 1-line to 1-line in all but a few cases >> - automatic limited scope of the embedded ThreadsListHandle so we were >> ? able to remove extra braces that were added earlier in most cases >> >> The disadvantages of the new style are: >> >> - it is an unusual for-loop style (in HotSpot) >> - it breaks HotSpot's style rule about implied booleans >> >> >> Stefan K is pretty adamant that the original iterator version where we >> go from 1-line to 3-lines or 1-line to 5-lines is not acceptable for GC >> code. The compiler guys haven't chimed in on this debate so I'm guessing >> they don't have a strong opinion either way. One thing that we don't >> want >> to do is have different styles for the different teams. >> >> So I had to make a judgement call on whether I thought Runtime could >> live >> with Stefan's idea. Originally I wasn't fond of it either and >> breaking the >> implied boolean style rule is a problem for me (I post that comment a >> lot >> in my code reviews). However, I have to say that I'm a lot happier about >> the compactness of the code and the fact that limited ThreadsListHandle >> scope comes for 'free' in most cases. >> >> We're planning to keep the new iterator style for the following reasons: >> >> - smaller change footprint >> - consistent style used for all of the teams >> - limited ThreadsListHandle scope comes for free in most cases >> >> We're hoping that you can live with this decision (for now) and maybe >> even grow to like it in the future. :-) > > The limited ThreadsListHandle scope, since ThreadsListHandle registers > and unregisters lists to SMR, seems to be worth the cost of looking at > this strange code pattern.?? Thank you for the explanation. > >> >> >>> Other than that just a couple of comments on variable type choices, >>> and a few typos spotted below. >> >> Replies embedded below. >> >> >>> >>> Thanks, >>> David >>> --- >>> >>> src/hotspot/share/runtime/globals.hpp >>> >>> 2476?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, true, >>> ??????? \ >>> 2477?????????? "Enable Thread SMR extra validity checks") \ >>> 2478 ??????? \ >>> 2479?? diagnostic(bool, EnableThreadSMRStatistics, true, \ >>> 2480?????????? "Enable Thread SMR Statistics") ??????? \ >>> >>> Indent of strings is off by? 3 spaces. >> >> Fixed. >> >> >>> --- >>> >>> src/hotspot/share/runtime/handshake.cpp >>> >>> ?140?????? // There is assumption in code that Threads_lock should >>> be lock >>> ?200?????? // There is assumption in code that Threads_lock should >>> be lock >>> >>> lock -> locked >> >> Fixed. >> >> >>> 146???????? // handshake_process_by_vmthread will check the >>> semaphore for us again >>> >>> Needs period at end. >> >> Fixed. >> >> >>> 148???????? // should be okey since the new thread will not have an >>> operation. >>> >>> okey -> okay >> >> Fixed. >> >> >>> 151???????? // We can't warn here is since the thread do >>> cancel_handshake after it have been removed >>> >>> I think: >>> >>> // We can't warn here since the thread does cancel_handshake after >>> it has been removed >> >> Fixed. >> >> >>> 152???????? // from ThreadsList. So we should just keep looping here >>> until while below return negative. >>> >>> from -> from the >>> >>> Needs period at end. >> >> Fixed both. >> >> >>> >>> ?204???????????? // A new thread on the ThreadsList will not have an >>> operation. >>> >>> Change period to comma, and ... >> >> Fixed. >> >> >>> 205???????????? // Hence is skipped in handshake_process_by_vmthread. >>> >>> Hence is -> hence it is >> >> Fixed. >> >> >>> --- >>> >>> src/hotspot/share/runtime/thread.cpp >>> >>> 1482???? // dcubed - Looks like the Threads_lock is for stable access >>> 1483???? // to _jvmci_old_thread_counters and _jvmci_counters. >>> >>> Does this comment need revisiting? >> >> We've been trying to decide what to do about this comment. We'll be >> filing a follow up bug for the Compiler team to take another look at >> how _jvmci_old_thread_counters and _jvmci_counters are protected. >> Threads_lock is a big hammer and there should be a less expensive >> solution. Once that bug gets filed, this comment can go away. >> >> >>> 3451 volatile jint ... >>> >>> Why are you using jint for field types here? (Surprised Coleen >>> hasn't spotted them! ;-) ). > > Yes, it was the jtypes I would have objected to.? And long isn't a > good choice on windows because it's only 32 bits there. >> >> volatile jint???????? Threads::_smr_delete_notify = 0; >> volatile jint???????? Threads::_smr_deleted_thread_cnt = 0; >> volatile jint???????? Threads::_smr_deleted_thread_time_max = 0; >> volatile jint???????? Threads::_smr_deleted_thread_times = 0; >> : >> volatile jint???????? Threads::_smr_tlh_cnt = 0; >> volatile jint???????? Threads::_smr_tlh_time_max = 0; >> volatile jint???????? Threads::_smr_tlh_times = 0; >> >> _smr_delete_notify is a "flag" that indicates when an _smr_delete_lock >> notify() operation is needed. It counts up and down and should be a >> fairly >> small number. >> >> _smr_deleted_thread_cnt counts the number of Threads that have been >> deleted over the life of the VM. It's an always increasing number so >> it's size depends on how long the VM has been running. >> >> _smr_deleted_thread_time_max is the maximum time in millis it has >> taken to delete a thread. This field was originally a jlong, but >> IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have >> just been Atomic::add() that was not happy) >> >> _smr_deleted_thread_times accumulates the time in millis that it >> has taken to delete threads. It's an always increasing number so >> it's size depends on how long the VM has been running. This field >> was originally a jlong, but IIRC the Atomic::add() code was not >> happy on ARM... (might have just been Atomic::cmpxchg() that was >> not happy) >> >> _smr_tlh_cnt counts the number of ThreadsListHandles that have been >> deleted over the life of the VM. It's an always increasing number so >> it's size depends on how long the VM has been running. >> >> _smr_tlh_time_max is the maximum time in millis it has taken to >> delete a ThreadsListHandle. This field was originally a jlong, but >> IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have >> just been Atomic::add() that was not happy) >> >> _smr_tlh_times? accumulates the time in millis that it has taken to >> delete ThreadsListHandles. It's an always increasing number so >> it's size depends on how long the VM has been running.? This field >> was originally a jlong, but IIRC the Atomic::add() code was not >> happy on ARM... (might have just been Atomic::cmpxchg() that was >> not happy) >> >> >> It just dawned on me that I'm not sure whether you think the 'jint' >> fields should be larger or smaller or the same size but a different >> type... :-) >> >> The fact that I had to write so much to explain what these fields >> are for and how they're used indicates I need more comments. See >> below... >> >> >>> 3456 long Threads::_smr_java_thread_list_alloc_cnt = 1; >>> 3457 long Threads::_smr_java_thread_list_free_cnt = 0; >>> >>> long? If you really want 64-bit counters here you won't get them on >>> Windows with that declaration. If you really want variable sized >>> counters I suggest uintptr_t; otherwise uint64_t. >> >> long????????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; >> long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; >> >> _smr_java_thread_list_alloc_cnt counts the number of ThreadsLists that >> have been allocated over the life of the VM. It's an always increasing >> number so it's size depends on how long the VM has been running and how >> many Threads have been created and destroyed. >> >> _smr_java_thread_list_free_cnt counts the number of ThreadsLists that >> have been freed over the life of the VM. It's an always increasing >> number so it's size depends on how long the VM has been running and how >> many Threads have been created and destroyed. >> >> I can't remember why we chose 'long' and I agree it's not a good choice >> for Win*. >> >> >> Okay so it dawns on me that we haven't written down a description for >> the various new '_cnt', '_max' and '_times" fields so I'm adding these >> comments to thread.hpp: >> > > With this comment format, it's really hard to pick out the name of the > field.? Nobody uses 80 columns anymore.? Can you move the comments > over some spaces so the field names are visible? Yes, I'll update the patch that I have for dholmes CR resolutions. > >> ?private: >> ? // Safe Memory Reclamation (SMR) support: >> ? static Monitor*????????????? _smr_delete_lock; >> ? // The '_cnt', '_max' and '_times" fields are enabled via >> ? // -XX:+EnableThreadSMRStatistics: >> ?????????????????????????????? // # of parallel threads in >> _smr_delete_lock->wait(). >> ? static uint????????????????? _smr_delete_lock_wait_cnt; >> ?????????????????????????????? // Max # of parallel threads in >> _smr_delete_lock->wait(). >> ? static uint????????????????? _smr_delete_lock_wait_max; >> ?????????????????????????????? // Flag to indicate when an >> _smr_delete_lock->notify() is needed. >> ? static volatile uint???????? _smr_delete_notify; >> ?????????????????????????????? // # of threads deleted over VM lifetime. >> ? static volatile uint???????? _smr_deleted_thread_cnt; >> ?????????????????????????????? // Max time in millis to delete a thread. >> ? static volatile uint???????? _smr_deleted_thread_time_max; >> ?????????????????????????????? // Cumulative time in millis to delete >> threads. >> ? static volatile uint???????? _smr_deleted_thread_times; >> ? static ThreadsList* volatile _smr_java_thread_list; >> ? static ThreadsList*????????? get_smr_java_thread_list(); >> ? static ThreadsList* xchg_smr_java_thread_list(ThreadsList* new_list); >> ?????????????????????????????? // # of ThreadsLists allocated over VM >> lifetime. >> ? static uint64_t????????????? _smr_java_thread_list_alloc_cnt; >> ?????????????????????????????? // # of ThreadsLists freed over VM >> lifetime. >> ? static uint64_t????????????? _smr_java_thread_list_free_cnt; >> ?????????????????????????????? // Max size ThreadsList allocated. >> ? static uint????????????????? _smr_java_thread_list_max; >> ?????????????????????????????? // Max # of nested ThreadsLists for a >> thread. >> ? static uint????????????????? _smr_nested_thread_list_max; >> ?????????????????????????????? // # of ThreadsListHandles deleted >> over VM lifetime. >> ? static volatile uint???????? _smr_tlh_cnt; >> ?????????????????????????????? // Max time in millis to delete a >> ThreadsListHandle. >> ? static volatile jint???????? _smr_tlh_time_max; >> ?????????????????????????????? // Cumulative time in millis to delete >> ThreadsListHandles. >> ? static volatile jint???????? _smr_tlh_times; >> ? static ThreadsList*????????? _smr_to_delete_list; >> ?????????????????????????????? // # of parallel ThreadsLists on the >> to-delete list. >> ? static uint????????????????? _smr_to_delete_list_cnt; >> ?????????????????????????????? // Max # of parallel ThreadsLists on >> the to-delete list. >> ? static uint????????????????? _smr_to_delete_list_max; >> >> >> I've also gone through all the new '_cnt', '_max' and '_times" fields >> in thread.cpp and added an impl note to explain the choice of type: >> > > Since this is in the cpp file and there is so much comment text, can > you just make it in column 1 and leave a blank line after each field.? > The indentation style is really hard to read and only useful if the > comment is short. Yes, I'll update the patch that I have for dholmes CR resolutions. > >> // Safe Memory Reclamation (SMR) support: >> Monitor*????????????? Threads::_smr_delete_lock = >> ????????????????????????? new Monitor(Monitor::special, >> "smr_delete_lock", >> ????????????????????????????????????? false /* allow_vm_block */, >> Monitor::_safepoint_check_never); >> // The '_cnt', '_max' and '_times" fields are enabled via >> // -XX:+EnableThreadSMRStatistics: >> ????????????????????? // # of parallel threads in >> _smr_delete_lock->wait(). >> ????????????????????? // Impl note: Hard to imagine > 64K waiting >> threads so >> ????????????????????? // this could be 16-bit, but there is no nice >> 16-bit >> ????????????????????? // _FORMAT support. >> uint????????????????? Threads::_smr_delete_lock_wait_cnt = 0; >> ????????????????????? // Max # of parallel threads in >> _smr_delete_lock->wait(). >> ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. >> uint????????????????? Threads::_smr_delete_lock_wait_max = 0; >> ????????????????????? // Flag to indicate when an >> _smr_delete_lock->notify() is needed. >> ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. >> volatile uint???????? Threads::_smr_delete_notify = 0; >> ????????????????????? // # of threads deleted over VM lifetime. >> ????????????????????? // Impl note: Atomically incremented over VM >> lifetime so >> ????????????????????? // use unsigned for more range. Unsigned 64-bit >> would >> ????????????????????? // be more future proof, but 64-bit atomic inc >> isn't >> ????????????????????? // available everywhere (or is it?). >> volatile uint???????? Threads::_smr_deleted_thread_cnt = 0; >> ????????????????????? // Max time in millis to delete a thread. >> ????????????????????? // Impl note: 16-bit might be too small on an >> overloaded >> ????????????????????? // machine. Use unsigned since this is a time >> value. Set >> ????????????????????? // via Atomic::cmpxchg() in a loop for >> correctness. >> volatile uint???????? Threads::_smr_deleted_thread_time_max = 0; >> ????????????????????? // Cumulative time in millis to delete threads. >> ????????????????????? // Impl note: Atomically added to over VM >> lifetime so use >> ????????????????????? // unsigned for more range. Unsigned 64-bit >> would be more >> ????????????????????? // future proof, but 64-bit atomic inc isn't >> available >> ????????????????????? // everywhere (or is it?). >> volatile uint???????? Threads::_smr_deleted_thread_times = 0; >> ThreadsList* volatile Threads::_smr_java_thread_list = new >> ThreadsList(0); >> ????????????????????? // # of ThreadsLists allocated over VM lifetime. >> ????????????????????? // Impl note: We allocate a new ThreadsList for >> every >> ????????????????????? // thread create and every thread delete so we >> need a >> ????????????????????? // bigger type than the _smr_deleted_thread_cnt >> field. >> uint64_t????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; >> ????????????????????? // # of ThreadsLists freed over VM lifetime. >> ????????????????????? // Impl note: See >> _smr_java_thread_list_alloc_cnt note. >> uint64_t????????????? Threads::_smr_java_thread_list_free_cnt = 0; >> ????????????????????? // Max size ThreadsList allocated. >> ????????????????????? // Impl note: Max # of threads alive at one >> time should >> ????????????????????? // fit in unsigned 32-bit. >> uint????????????????? Threads::_smr_java_thread_list_max = 0; >> ????????????????????? // Max # of nested ThreadsLists for a thread. >> ????????????????????? // Impl note: Hard to imagine > 64K nested >> ThreadsLists >> ????????????????????? // so his could be 16-bit, but there is no nice >> 16-bit >> ????????????????????? // _FORMAT support. >> uint????????????????? Threads::_smr_nested_thread_list_max = 0; >> ????????????????????? // # of ThreadsListHandles deleted over VM >> lifetime. >> ????????????????????? // Impl note: Atomically incremented over VM >> lifetime so >> ????????????????????? // use unsigned for more range. There will be >> fewer >> ????????????????????? // ThreadsListHandles than threads so unsigned >> 32-bit >> ????????????????????? // should be fine. >> volatile uint???????? Threads::_smr_tlh_cnt = 0; >> ????????????????????? // Max time in millis to delete a >> ThreadsListHandle. >> ????????????????????? // Impl note: 16-bit might be too small on an >> overloaded >> ????????????????????? // machine. Use unsigned since this is a time >> value. Set >> ????????????????????? // via Atomic::cmpxchg() in a loop for >> correctness. >> volatile uint???????? Threads::_smr_tlh_time_max = 0; >> ????????????????????? // Cumulative time in millis to delete >> ThreadsListHandles. >> ????????????????????? // Impl note: Atomically added to over VM >> lifetime so use >> ????????????????????? // unsigned for more range. Unsigned 64-bit >> would be more >> ????????????????????? // future proof, but 64-bit atomic inc isn't >> available >> ????????????????????? // everywhere (or is it?). >> volatile uint???????? Threads::_smr_tlh_times = 0; >> ThreadsList*????????? Threads::_smr_to_delete_list = NULL; >> ????????????????????? // # of parallel ThreadsLists on the to-delete >> list. >> ????????????????????? // Impl note: Hard to imagine > 64K >> ThreadsLists needing >> ????????????????????? // to be deleted so this could be 16-bit, but >> there is no >> ????????????????????? // nice 16-bit _FORMAT support. >> uint????????????????? Threads::_smr_to_delete_list_cnt = 0; >> ????????????????????? // Max # of parallel ThreadsLists on the >> to-delete list. >> ????????????????????? // Impl note: See _smr_to_delete_list_cnt note. >> uint????????????????? Threads::_smr_to_delete_list_max = 0; >> >> >> Yikes! With the additional comments, the additions to thread.hpp and >> thread.cpp grew by a bunch... I've done a test build build on my Mac >> with these changes and I'm about to kick off a Mach5 tier1 job... > > Another reason why I agreed with some earlier comment that this should > be in a new file because it's a new thing. I was somewhat surprised > that it's not in threadSMR.{hpp,cpp}.?? This refactoring could be > deferred but thread.cpp is too big! More refactoring is planned for after the initial push of Thread-SMR... Thanks for chiming in on this part of the review thread. Dan > > thanks, > Coleen > >> >> Dan >> >> >> >>> >>> ---- >>> >>> On 19/11/2017 11:49 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Testing of the last round of changes revealed a hang in one of the new >>>> TLH tests. Robbin has fixed the hang, updated the existing TLH >>>> test, and >>>> added another TLH test for good measure. >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>> >>>> Here is the updated delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>>> >>>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>>> no unexpected failures. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Robbin rebased the project last night/this morning to merge with >>>>> Thread >>>>> Local Handshakes (TLH) and also picked up additional changesets up >>>>> thru: >>>>> >>>>>> Changeset: fa736014cf28 >>>>>> Author:??? cjplummer >>>>>> Date:????? 2017-11-14 18:08 -0800 >>>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>>> >>>>>> 8191049: Add alternate version of pns() that is callable from >>>>>> within hotspot source >>>>>> Summary: added pns2() to debug.cpp >>>>>> Reviewed-by: stuefe, gthornbr >>>>> >>>>> This is the first time we've rebased the project to bits that are >>>>> this >>>>> fresh (< 12 hours old at rebase time). We've done this because we >>>>> think >>>>> we're done with this project and are in the final >>>>> review-change-retest >>>>> cycle(s)... In other words, we're not planning on making any more >>>>> major >>>>> changes for this project... :-) >>>>> >>>>> *** Time for code reviewers to chime in on this thread! *** >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>>> >>>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>>> >>>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>>> (and the new baseline also)... >>>>> >>>>> We're expecting this round to be a little noisier than usual because >>>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>>> (Yes, we're playing chase-the-repo...) >>>>>> >>>>>> Here is the updated full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>>> >>>>>> Unlike the previous rebase, there were no changes required to the >>>>>> open code to get the rebased bits to build so there is no delta >>>>>> webrev. >>>>>> >>>>>> These bits have been run through JPRT and I've submitted the usual >>>>>> Mach5 tier[1-5] test run... >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>>> >>>>>>> Here are the updated webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>>> >>>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>>> holiday >>>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>>> closer >>>>>>> look today. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>>> and Coleen) >>>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>>> done as a >>>>>>>> standalone patch and corresponding webrevs: >>>>>>>> >>>>>>>> Here's the mq comment for the change: >>>>>>>> >>>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>>> to use >>>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>>> >>>>>>>> Here is the full webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>>> >>>>>>>> And here is the delta webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Dan, Erik and Robbin >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>>> >>>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>>> >>>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>>> >>>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>>> describe >>>>>>>>> and track the work on this project: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>>> >>>>>>>>> >>>>>>>>> Dan has noticed that the indenting is wrong in some of the >>>>>>>>> code quotes >>>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>>> have a >>>>>>>>> solution for that problem yet. >>>>>>>>> >>>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>>> >>>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>>> tier[2-5] >>>>>>>>> testing, additional stress testing on Dan's Solaris X64 >>>>>>>>> server, and >>>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>>> >>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>> >>>>>>>>> Daniel Daugherty >>>>>>>>> Erik Osterlund >>>>>>>>> Robbin Ehn >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >> > From daniel.daugherty at oracle.com Tue Nov 21 17:36:31 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Nov 2017 12:36:31 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> Message-ID: <5e154ff2-65d4-bad4-db5e-88cf4c733c7d@oracle.com> Thanks for keeping all the OpenJDK aliases! On 11/21/17 12:24 PM, coleen.phillimore at oracle.com wrote: > > > On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: >> Hi Coleen! >> >> Thanks for making time to review the Thread-SMR stuff again!! >> >> I have added back the other three OpenJDK aliases... This review is >> being done on _four_ different OpenJDK aliases. >> >> As always, replies are embedded below... >> >> >> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/os/linux/os_linux.cpp.frames.html >>> >>> >>> I read David's comments about the threads list iterator, and I was >>> going to say that it can be cleaned up later, as the bulk of the >>> change is the SMR part but this looks truly bizarre. It looks like >>> it shouldn't compile because 'jt' isn't in scope. >>> >>> Why isn't this the syntax: >>> >>> JavaThreadIteratorWithHandle jtiwh; >>> for (JavaThread* jt = jtiwh.first(); jt != NULL; jt = jtiwh.next()) { >>> } >>> >>> Which would do the obvious thing without anyone having to squint at >>> the code. >> >> See my reply to David's review for the more detailed answer. >> >> For the above syntax, we would need braces to limit the scope of the >> 'jtiwh' variable. With Stefan's propsal, you get limited scope on >> 'jtiwh' for "free". > > Yes, thank you, I see that motivation now. >> >> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.hpp.html >>> >>> >>> As a hater of acronmys, can this file use "Safe Memory Reclaimation" >> >> I'm not sure what you mean by this. Do you mean rename the files? >> >> ? threadSMR.hpp -> threadSafeMemoryReclaimation.hpp >> ? threadSMR.cpp -> threadSafeMemoryReclaimation.cpp >> > > No. > >> >>> and briefly describe the concept in the beginning of the header file, >>> so one knows why it's called threadSMR.hpp? >> >> And then this part of the sentence kind of indicates that you would be >> okay with the threadSMR.{c,h}pp names if a comment was added to the >> header file. >> >> Please clarify. > > Yes.? If you added a comment to the beginning of the threadSMR.hpp > file that said what SMR stood for and what it was, that would be > extremely helpful for future viewers of this file. Yup. I just finished with the comment... > >> >> >>> It doesn't need to be long and include why Threads list needs this >>> Sometimes we tell new people that the hotspot documentation is in >>> the header files. >> >> Yup. When I migrated stuff from thread.hpp and thread.cpp to >> threadSMR.hpp >> and threadSMR.cpp, I should have written a header comment... >> >> I did update a comment in thread.cpp based on Robin W's code review: > > Yes, I think a comment belongs in the SMR file also, or in preference. Wasn't trying to say that I thought the update I did for Robin W was sufficient... >> >>> > src/hotspot/share/runtime/thread.cpp >>> > >>> > 3432 // operations over all threads.? It is protected by its own >>> Mutex >>> > 3433 // lock, which is also used in other contexts to protect thread >>> > >>> > Should this comment perhaps be revised to mention SMR? >>> >>> It definitely needs some updating... Here's a stab at it: >>> >>> // The Threads class links together all active threads, and provides >>> // operations over all threads. It is protected by the Threads_lock, >>> // which is also used in other global contexts like safepointing. >>> // ThreadsListHandles are used to safely perform operations on one >>> // or more threads without the risk of the thread exiting during the >>> // operation. >>> // >>> // Note: The Threads_lock is currently more widely used than we >>> // would like. We are actively migrating Threads_lock uses to other >>> // mechanisms in order to reduce Threads_lock contention. >> >> I'll take a look at adding a header comment to threadSMR.hpp. >> >> >>> 186?? JavaThreadIteratorWithHandle() : _tlh(), _index(0) {} >>> >>> This _tlh() call should not be necessary.? The compiler should >>> generate this for you in the constructor. >> >> Deleted. >> >> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html >>> >>> >>> ? 32 ThreadsList::ThreadsList(int entries) : _length(entries), >>> _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), >>> _next_list(NULL) { >>> >>> Seems like it should be mtThread rather than mtGC. >> >> Fixed. Definitely an artifact of Erik's original prototype when he >> extracted Thread-SMR from his GC work... Thanks for catching it. >> >> >>> Should >>> >>> ? 62?? if (EnableThreadSMRStatistics) { >>> >>> really be UL, ie: if (log_is_enabled(Info, thread, smr, statistics)) ? >> >> EnableThreadSMRStatistics is used in more places than UL code. >> We use it in Thread::print_*() stuff to control output of >> Thread-SMR statistics info in thread dumps and hs_err_pid file >> generation. > > That sort of thing is also controlled by logging in general. Don't think I want to do that since logging may be be "up" at the time that I need Thread::print_*() or hs_err_pid generation... Something about chickens and eggs... :-) >> >> Currently thread dump and hs_err_pid file output is not generated >> using UL (and probably can't be?) so we need an option to control >> the Thread-SMR statistics stuff in all places. >> > > You can use log options in preference to this new diagnostic option in > these cases too.?? This option looks a lot like logging to me and > would be nice to not have to later convert it. See above reply... > >> >> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java.html >>> >>> >>> Can you use for these tests instead (there were a couple): >>> >>> *@requires (vm.debug == true)* >> >> The test I cloned had this in it: >> >> ??? if (!Platform.isDebugBuild()) { >> ??????? // -XX:ErrorHandlerTest=N option requires debug bits. >> ??????? return; >> ??? } >> >> and you would like me to switch to the newer mechanism? >> >> I have updated the following tests: >> >> ? test/hotspot/jtreg/runtime/ErrorHandling/ErrorHandler.java >> test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java >> >> test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java >> >> >> > Yes, the newer mechanism makes jtreg not bother to run the test, which > makes it faster! More quickly not run the test... Yup... got it... > >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/thread.cpp.udiff.html >>> >>> >>> +// thread, has been added the Threads list, the system is not at a >>> >>> Has "not" been added to the Threads list?? missing "not"? >> >> Nope. If the JavaThread has been added to the Threads list >> and it is not protected, then it is dangling. In other words, >> a published JavaThread (on the Threads list) has to be protected >> by either the system being at a safepoint or the JavaThread has >> to be on some threads's ThreadsList. >> >> >>> >>> + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); >>> >>> Can you add a comment about where this number came from? >> >> I'll have to get that from Erik... >> >> >>> I can't find the caller of threads_do_smr. >> >> I'm guessing that's used by the GC code that depends on Thread-SMR... >> > > They? should add this API when the add the use of it then.? I don't > see it in any sources. We'll see what Erik wants to do... > >> >>> If these functions xchg_smr_thread_list, get_smr_java_thread_list, >>> inc_smr_deleted_thread_count are only used by thread.cpp, I think >>> they should go in that file and not in the .inline.hpp file to be >>> included and possibly called by other files.? I think they're >>> private to class Threads. >> >> I have a vague memory that some of the compilers don't do inlining when >> an "inline" function is in a .cpp. I believe we want these functions >> to be inlined for performance reasons. Erik should probably chime in >> here. > > I don't see why this should be.? Maybe some (older) compilers require > it to be found before the call though, but that can still be > accomplished in the .cpp file. Again, we'll see what Erik wants to do... >> >> >>> I don't have any in-depth comments. This looks really good from my >>> day of reading it. >> >> Thanks for taking the time to review it again! >> > > Thanks, > Coleen And thanks again... Dan > >> Dan >> >> >>> >>> Thanks, >>> Coleen >>> >>> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>> >>>> Greetings, >>>> >>>> Testing of the last round of changes revealed a hang in one of the new >>>> TLH tests. Robbin has fixed the hang, updated the existing TLH >>>> test, and >>>> added another TLH test for good measure. >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>> >>>> Here is the updated delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>>> >>>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>>> no unexpected failures. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Robbin rebased the project last night/this morning to merge with >>>>> Thread >>>>> Local Handshakes (TLH) and also picked up additional changesets up >>>>> thru: >>>>> >>>>>> Changeset: fa736014cf28 >>>>>> Author:??? cjplummer >>>>>> Date:????? 2017-11-14 18:08 -0800 >>>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>>> >>>>>> 8191049: Add alternate version of pns() that is callable from >>>>>> within hotspot source >>>>>> Summary: added pns2() to debug.cpp >>>>>> Reviewed-by: stuefe, gthornbr >>>>> >>>>> This is the first time we've rebased the project to bits that are >>>>> this >>>>> fresh (< 12 hours old at rebase time). We've done this because we >>>>> think >>>>> we're done with this project and are in the final >>>>> review-change-retest >>>>> cycle(s)... In other words, we're not planning on making any more >>>>> major >>>>> changes for this project... :-) >>>>> >>>>> *** Time for code reviewers to chime in on this thread! *** >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>>> >>>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>>> >>>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>>> (and the new baseline also)... >>>>> >>>>> We're expecting this round to be a little noisier than usual because >>>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>>> (Yes, we're playing chase-the-repo...) >>>>>> >>>>>> Here is the updated full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>>> >>>>>> Unlike the previous rebase, there were no changes required to the >>>>>> open code to get the rebased bits to build so there is no delta >>>>>> webrev. >>>>>> >>>>>> These bits have been run through JPRT and I've submitted the usual >>>>>> Mach5 tier[1-5] test run... >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>>> >>>>>>> Here are the updated webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>>> >>>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>>> holiday >>>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>>> closer >>>>>>> look today. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>>> and Coleen) >>>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>>> done as a >>>>>>>> standalone patch and corresponding webrevs: >>>>>>>> >>>>>>>> Here's the mq comment for the change: >>>>>>>> >>>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>>> to use >>>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>>> >>>>>>>> Here is the full webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>>> >>>>>>>> And here is the delta webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Dan, Erik and Robbin >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>>> >>>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>>> >>>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>>> >>>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>>> describe >>>>>>>>> and track the work on this project: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>>> >>>>>>>>> >>>>>>>>> Dan has noticed that the indenting is wrong in some of the >>>>>>>>> code quotes >>>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>>> have a >>>>>>>>> solution for that problem yet. >>>>>>>>> >>>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>>> >>>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>>> tier[2-5] >>>>>>>>> testing, additional stress testing on Dan's Solaris X64 >>>>>>>>> server, and >>>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>>> >>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>> >>>>>>>>> Daniel Daugherty >>>>>>>>> Erik Osterlund >>>>>>>>> Robbin Ehn >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Tue Nov 21 18:50:25 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Nov 2017 10:50:25 -0800 Subject: RFR (XS):8191615 : LogCompilation can show bytes In-Reply-To: <9678f625-4fa1-e749-a7c5-f491d34c8b5c@oracle.com> References: <3a9650cd-7a66-583f-008b-97f8645c50a5@oracle.com> <9678f625-4fa1-e749-a7c5-f491d34c8b5c@oracle.com> Message-ID: <90f65e50-112a-0504-44ea-a51abe48c6bd@oracle.com> +1 Vladimir K On 11/20/17 3:06 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 11/21/17 1:43 AM, Eric Caspole wrote: >> Hi everybody, >> While using the LogCompilation tool, I noticed it would be a bit >> better to show the bytes size of the method being compiled as this >> info is now available in the log. I think this might be an oversight >> that the tool was never updated as the +LogCompilation output got >> better over time. >> >> http://cr.openjdk.java.net/~ecaspole/JDK-8191615/webrev/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8191615 >> >> Thanks, >> Eric From tprintezis at twitter.com Tue Nov 21 20:15:44 2017 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 21 Nov 2017 15:15:44 -0500 Subject: InlineCacheBuffer question Message-ID: Hi all, I?ve been looking at the safepoint behavior of one of our services and I noticed that around 55% of the safepoints that happen don?t execute a VM operation. I?d need to confirm this, but I assume they only happen in order to do some cleanup (SafepointSynchronize::is_cleanup_needed() returns true, which in JDK 8 translates to !InlineCacheBuffer::is_empty()). I?m not familiar with the InlineCacheBuffer at all. How important is it to execute InlineCacheBuffer::update_inline_caches() at regular intervals? Would a modified heuristic, like "a safepoint is required if the buffer is >P% full" (maybe in conjunction with increasing the buffer size) be reasonable? Or maybe increase the value of GuaranteedSafepointInterval? Or both? Note that the overhead of the non-VM op safepoints is actually negligible. I?d just like to try to cut down the number of safepoints we do, as we had issues in the past with safepoint initiation taking too long. Thanks, Tony ????? Tony Printezis | @TonyPrintezis | tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at redhat.com Tue Nov 21 20:40:01 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Nov 2017 21:40:01 +0100 Subject: InlineCacheBuffer question In-Reply-To: References: Message-ID: <251ff986-0dcd-b435-b7b3-60429dc4cdf0@redhat.com> Am 21.11.2017 um 21:15 schrieb Tony Printezis: > Hi all, > > I?ve been looking at the safepoint behavior of one of our services and I > noticed that around 55% of the safepoints that happen don?t execute a VM > operation. I?d need to confirm this, but I assume they only happen in > order to do some cleanup (SafepointSynchronize::is_cleanup_needed() > returns true, which in JDK 8 translates to?!InlineCacheBuffer::is_empty()). This is true. This cleanup is done regularily to clean up zombie nmethods and deflate idle monitors (and some other relatively minor cleanups). > I?m not familiar with the InlineCacheBuffer at all. How important is it > to execute InlineCacheBuffer::update_inline_caches() at regular > intervals? Would a modified heuristic, like "a safepoint is required if > the buffer is >P% full" (maybe in conjunction with increasing the buffer > size) be reasonable? Or maybe increase the value of > GuaranteedSafepointInterval? Or both? I think such a modified heuristic would be reasonable. > Note that the overhead of the non-VM op safepoints is actually > negligible. I?d just like to try to cut down the number of safepoints we > do, as we had issues in the past with safepoint initiation taking too long. > I can feel your pain. There are some ongoing (or infact not-yet-started) efforts to cut this down. One is concurrent monitor deflation: https://bugs.openjdk.java.net/browse/JDK-8183909 Another one is using multiple threads for nmethod sweeping (I proposed a mechanism to do that some months ago, but has been stalled because upstream didn't want it back then), here's some related issue around that: https://bugs.openjdk.java.net/browse/JDK-8132849 https://bugs.openjdk.java.net/browse/JDK-8184751 https://bugs.openjdk.java.net/browse/JDK-8153224 I'd be happy to re-open the discussions around parallel safepoint cleanup. Roman From vladimir.kozlov at oracle.com Tue Nov 21 20:43:48 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Nov 2017 12:43:48 -0800 Subject: [10] RFR(S): 8179026: Remove explicit code cache options processing In-Reply-To: References: Message-ID: <2a9179c1-ee2f-fe74-3809-08f697660beb@oracle.com> Hi, Tobias Looks good. Can you also print size_initial in error message in codeCache.cpp? Thanks, Vladimir On 11/20/17 12:22 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8179026 > http://cr.openjdk.java.net/~thartmann/8179026/webrev.00/ > > I've removed the explicit processing of -XX:CodeCacheExpansionSize, -XX:NonNMethodCodeHeapSize, -XX:ProfiledCodeHeapSize > and -XX:NonProfiledCodeHeapSize because generic option processing already supports memory values. I've also added a > lower bound of vm_page_size() to all of them except the non-profiled and the profiled size because these can be 0. The > actual checking is done in codeCache.cpp. > > All tests pass. > > Thanks, > Tobias > From tprintezis at twitter.com Tue Nov 21 21:01:45 2017 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 21 Nov 2017 16:01:45 -0500 Subject: InlineCacheBuffer question In-Reply-To: <251ff986-0dcd-b435-b7b3-60429dc4cdf0@redhat.com> References: <251ff986-0dcd-b435-b7b3-60429dc4cdf0@redhat.com> Message-ID: Roman, Thanks for the reply. Inline (ha!) ????? Tony Printezis | @TonyPrintezis | tprintezis at twitter.com On November 21, 2017 at 3:40:03 PM, Roman Kennke (rkennke at redhat.com) wrote: Am 21.11.2017 um 21:15 schrieb Tony Printezis: > Hi all, > > I?ve been looking at the safepoint behavior of one of our services and I > noticed that around 55% of the safepoints that happen don?t execute a VM > operation. I?d need to confirm this, but I assume they only happen in > order to do some cleanup (SafepointSynchronize::is_cleanup_needed() > returns true, which in JDK 8 translates to !InlineCacheBuffer::is_empty()). This is true. This cleanup is done regularily to clean up zombie nmethods and deflate idle monitors (and some other relatively minor cleanups). Sure, there are several things that are done during the pre-safepoint cleanup phase (8 separate steps). However, the decision on whether to do a non-VM safepoint or not, basically just to do the cleanup, only seems to consider whether the InlineCacheBuffer is empty or not (in JDK 8; in 10 it also checks the ObjectSynchronizer). > I?m not familiar with the InlineCacheBuffer at all. How important is it > to execute InlineCacheBuffer::update_inline_caches() at regular > intervals? Would a modified heuristic, like "a safepoint is required if > the buffer is >P% full" (maybe in conjunction with increasing the buffer > size) be reasonable? Or maybe increase the value of > GuaranteedSafepointInterval? Or both? I think such a modified heuristic would be reasonable. > Note that the overhead of the non-VM op safepoints is actually > negligible. I?d just like to try to cut down the number of safepoints we > do, as we had issues in the past with safepoint initiation taking too long. > I can feel your pain. I?m all for decreasing the overhead of the various cleanups that are done pre-safepoint (and thanks for the pointers). But, I?m also interested in just decreasing the number of safepoints that we do, if they are not absolutely necessary. Tony There are some ongoing (or infact not-yet-started) efforts to cut this down. One is concurrent monitor deflation: https://bugs.openjdk.java.net/browse/JDK-8183909 Another one is using multiple threads for nmethod sweeping (I proposed a mechanism to do that some months ago, but has been stalled because upstream didn't want it back then), here's some related issue around that: https://bugs.openjdk.java.net/browse/JDK-8132849 https://bugs.openjdk.java.net/browse/JDK-8184751 https://bugs.openjdk.java.net/browse/JDK-8153224 I'd be happy to re-open the discussions around parallel safepoint cleanup. Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Nov 21 21:13:31 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Nov 2017 13:13:31 -0800 Subject: RFR 8190800: Support for vectorization of sqrt float In-Reply-To: <5c9e54c0-cd07-e68f-852b-448239b5f47f@oracle.com> References: <48D92A70936F7946BE99F3FF5ECB6461D8DDF561@ORSMSX113.amr.corp.intel.com> <5c9e54c0-cd07-e68f-852b-448239b5f47f@oracle.com> Message-ID: On 11/20/17 9:36 AM, Vladimir Ivanov wrote: > Looks good. > > I'll sponsor the change. Please, run pre-integration testing before push. Thanks, Vladimir K > > Best regards, > Vladimir Ivanov > > On 11/18/17 12:10 AM, Lupusoru, Razvan A wrote: >> Hello, >> >> The vectorizer cannot currently handle vectorization of sqrt for >> floats even though there is packed single precision sqrt instruction >> supported in AVX. The following patch rectifies the situation by >> adding a new C2 node for floating point version of Sqrt and its >> vectorized version, along with assembler support for it. >> >> https://bugs.openjdk.java.net/browse/JDK-8190800 >> >> The proposed solution can be found here: >> >> http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_sqrtf_02/ >> >> Please let me know if you have any questions or concerns. >> >> --Razvan >> From vladimir.kozlov at oracle.com Tue Nov 21 21:30:30 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Nov 2017 13:30:30 -0800 Subject: RFR 8190800: Support for vectorization of sqrt float In-Reply-To: <48D92A70936F7946BE99F3FF5ECB6461D8DDF6F0@ORSMSX113.amr.corp.intel.com> References: <48D92A70936F7946BE99F3FF5ECB6461D8DDF561@ORSMSX113.amr.corp.intel.com> <48D92A70936F7946BE99F3FF5ECB6461D8DDF6F0@ORSMSX113.amr.corp.intel.com> Message-ID: <50cd6d1f-f8aa-c845-e767-4fb2187147f6@oracle.com> Hi Razvan, Very nice work. Thanks! What testing you ran? On 11/17/17 4:34 PM, Lupusoru, Razvan A wrote: > Hi Jacek, > > You are very welcome and it is nice we had same idea for implementation :) > > Regarding your questions: > > 1)I did not want to change other architecture .ad files because I do not > have the means to test them. Because of that, you will see that the > Ideal conversion restricts conversion to SqrtF node only for > architectures that have a Matcher entry. Namely all non-x86 > architectures will work exact same way as before - this ensures I did > not break anything for them. Yes, that is right approach. > > 2)It appears that it is general convention in the .ad file that all > ?packed? combinations are supported. Thus, you will find many places > where 2F is a supported combination. That is because the vectorizer may > decide (unlikely) that it should pack only 2 floats. The AVX instruction > will apply transform on all 4 lanes (when 128 bit), but the caller of > that .ad entry will only look at the resulting 2 relevant float lanes > (as reflected by dst being vecD). I have ensured now that all 2F entries > use vecD. We have MaxVectorSize flag for testing purpose which limits vector size for debugging and purposes. Also a loop can be unrolled only few times due to its code size and as result you can have less elements per vector than vector instructions support. That is why we have all these packing combinations. Razvan, please, run your testing with different MaxVectorSize (it is in bytes). > > 3)You are right - that is a copy/paste error. It should say ?float? > instead of ?double?. > > I have uploaded a fixed webrev here: > http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_sqrtf_03/ Looks good to me. Thanks, Vladimir > > Thanks, > > Razvan > > *From:*Jacek Tomaka [mailto:jacekt at dug.com] > *Sent:* Friday, November 17, 2017 4:03 PM > *To:* Lupusoru, Razvan A > *Cc:* hotspot-compiler-dev at openjdk.java.net > *Subject:* Re: RFR 8190800: Support for vectorization of sqrt float > > Hi Razvan, > > Thank you for making this patch available. > > I have a few questions regarding your changes: > > 1. Would it make sense to get rid of match(Set dst (ConvD2F (SqrtD > (ConvF2D src))));?for other platforms as well(and just use match(Set dst > (SqrtF src));), now that ConvD2FNode::Ideal?does similar job? > > 2. What would be situations where instruct vsqrt2F_reg?and instruct > vsqrt2F_mem would be used? Isn't AVX only >128 bit? > > 3. In subnode.hpp i think the comment should mention float not double. > It is +// square root a double currently. > > Regards. > > Jacek Tomaka > From vladimir.kozlov at oracle.com Tue Nov 21 21:36:09 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Nov 2017 13:36:09 -0800 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> Message-ID: <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> Thank you, Roland You answered all my comments. I will run testing and push it if testing is clean. Thanks, Vladimir On 11/20/17 2:27 AM, Roland Westrelin wrote: > >> I was thinking may be we should create new Loop node subclass for outer loop. Then you don't need >> special flag for it and it will be obvious what they are in Ideal Graph. The same for outer loop end >> node. > > Here is a new webrev with new node types for the outer loop: > > http://cr.openjdk.java.net/~roland/8186027/webrev.02/ > > Roland. > From rkennke at redhat.com Tue Nov 21 21:40:59 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Nov 2017 22:40:59 +0100 Subject: InlineCacheBuffer question In-Reply-To: References: <251ff986-0dcd-b435-b7b3-60429dc4cdf0@redhat.com> Message-ID: <9c86d1d9-40e1-5681-8b9b-71033a184565@redhat.com> Hi Tony, >> > I?m not familiar with the InlineCacheBuffer at all. How important is it >> > to execute InlineCacheBuffer::update_inline_caches() at regular >> > intervals? Would a modified heuristic, like "a safepoint is required if >> > the buffer is >P% full" (maybe in conjunction with increasing the buffer >> > size) be reasonable? Or maybe increase the value of >> > GuaranteedSafepointInterval? Or both? >> >> I think such a modified heuristic would be reasonable. >> >> > Note that the overhead of the non-VM op safepoints is actually >> > negligible. I?d just like to try to cut down the number of safepoints we >> > do, as we had issues in the past with safepoint initiation taking too long. >> > >> >> I can feel your pain. > > > I?m all for decreasing the overhead of the various cleanups that are > done pre-safepoint (and thanks for the pointers). But, I?m also > interested in just decreasing the number of safepoints that we do, if > they are not absolutely necessary. I agree it would be useful to extend the heuristics to do something similar to what ObjectSynchronizer::is_cleanup_needed() does: check actual usage of InlineCacheBuffer, and compare it to a threshold, and let the threshold be configurable via cmd line option. Roman From jcbeyler at google.com Tue Nov 21 21:50:15 2017 From: jcbeyler at google.com (JC Beyler) Date: Tue, 21 Nov 2017 13:50:15 -0800 Subject: Low-Overhead Heap Profiling In-Reply-To: <1510146425.3155.11.camel@oracle.com> References: <1497366226.2829.109.camel@oracle.com> <1498215147.2741.34.camel@oracle.com> <044f8c75-72f3-79fd-af47-7ee875c071fd@oracle.com> <23f4e6f5-c94e-01f7-ef1d-5e328d4823c8@oracle.com> <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> <1510146425.3155.11.camel@oracle.com> Message-ID: Hi all, I have a new webrev here: http://cr.openjdk.java.net/~rasbold/8171119/webrev.15/ With the incremental one here: http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a_15/ I think I did most items from Thomans and Robbin. I've especially added a new test: http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a_15/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java.patch This tests the path of object allocation (as opposed to only testing the array allocation path). I also updated the JEP: https://bugs.openjdk.java.net/browse/JDK-8171119 I'll work now with Robbin on the next steps. Any additional comments/criticisms are as always welcome :) Jc On Wed, Nov 8, 2017 at 5:07 AM, Thomas Schatzl wrote: > Hi JC, > > sorry for the long wait. > > On Wed, 2017-11-01 at 10:46 -0700, JC Beyler wrote: > > Dear all, > > > > Here is the next webrev: > > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a/ > > > > Incremental since the rebase: > > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14_14a/ > > > > (I'm still not too familiar with hg so I had to do a fresh rebase so > > v14 is once the rebase was done and v14a integrates the changes > > requested from Thomas). > > Yeah, there seem to be something missing in the incremental webrev, but > thanks for the effort. > > > I have also inlined answers to Thomas' email: > > > A few minor issues: > > > > > - in the declaration of CollectedHeap::sample_allocation, it > > > would be nice if the fix_sample_rate parameter would be described - > > > it takes a time to figure out what it's used for. I.e. in case an > > > allocation goes beyond the sampling watermark, this value which > > > represents the amount of overallocation is used to adjust the next > > > sampling watermark to sample at the correct rate. > > > Something like this - and if what I wrote is incorrect, there is > > > even more reason to document it. > > > Or maybe just renaming "fix_sample_rate" to something more > > > descriptive - but I have no good idea about that. > > > With lack of units in the type, it would also be nice to have the > > > unit in the identifier name, as done elsewhere. > > > > Thanks. Could you s/passed/past in that documentation? > > > Done for Robbin's issue and changed it to > > > - some (or most actually) of the new setters and getters in the > > > ThreadLocalAllocBuffer class could be private I think. Also, we > > > typically do not use "simple" getters that just return a member in > > > the class where they are defined. > > > > I removed all that were not used that I could see (not used outside > > the class) moved the ones that are not simple to private if they > > could be. I think it's a bit weird because now some of the setting of > > the tlab internal data is using methods, others are directly setting. > > Let me know what you think. > > That's fine with me. You need to start somewhere I guess. > > > > - ThreadLocalAllocBuffer::pick_next_sample() - I recommend making > > > the first check an assert - it seems that it is only useful to call > > > this with heap monitoring enabled, as is done right now. > > > > Longer conversation below about this, It cannot be an assert (I could > > remove the test altogether though). > > I looked at the description, and you are right. I missed that. Keep it > as is. :) > > > > - HeapMonitoring::next_random() - the different names for the > > > constants use different formatting. Preferable (to me) is > > > UpperCamelCase, but at least make them uniform. > > > > > > > I think done the way you wanted! > > In heapMonitoring.hpp:50-53 the constants still have different format? > > > > > > > - not really convinced that it is a good idea to not somehow > > > guard > > > StartHeapSampling() and StopHeapSampling() against being called by > > > multiple threads. > > > > > > > I added another mutex for the start/stop so that way it will protect > > from that. > > > > Thanks! > > > > > > Otherwise looks okay from what I can see. > > Still okay. I do not need a re-review for the changes suggested in this > email. > > > > > Awesome, what do you think I still need for this before going to the > > next step (which is what by the way? :)). > > I think: > > - look through the JEP if it is still current and fix the descriptions > if required > - add a link to the latest webrev to the JEP as comment > - if not done already, file CSRs [0] for > - the new flag > - JVMTI changes (I think, not sure actually) > - find a sponsor from Oracle to do some internal work (pushing, and > before that there is iirc still some background work related to JEPs > that can only be done by Oracle, mostly shepherding :/). > > I talked to Robbin about this, and he offered to help you with that. > > Thanks, > Thomas > > [0] https://wiki.openjdk.java.net/display/csr/Main > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Nov 21 23:16:24 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Nov 2017 15:16:24 -0800 Subject: RFR(XS): 8191153: assert(u_ctrl != blk1 && u_ctrl != blk2) failed: won't converge In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 11/20/17 6:10 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8191153/webrev.00/ > > The assert that I added with 8186125 is too strong. It assumes that Cmp > and its uses are being cloned down but it's not always the case. > > When the TestSplitIfPinnedCMove::test() from the test case is compiled, > line 63 becomes a CMoveP which is pinned and the if line 66 can then be > split through phi. For that to happen, the CMoveP must first be moved > out of the way: it can be split up but the CmpI that feeds into the > CMoveP has more than one use. A first pass through > PhaseIdealLoop::split_up() causes the CmpI->Bol->CMoveP chain to be > cloned and a second call to PhaseIdealLoop::split_up() splits the CmpI > up. The assert fires on the first call but it's too strong because we're > not splitting the CmpI->Bol->CMoveP chain down. > > Roland. > From daniel.daugherty at oracle.com Wed Nov 22 00:12:49 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Nov 2017 19:12:49 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Message-ID: <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> Greetings, *** We are wrapping up code review on this project so it is time *** *** for the various code reviewers to chime in one last time. *** In this latest round, we had three different reviewers chime in so we're doing delta webrevs for each of those resolutions: David H's resolutions: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ ? mq comment for dholmes_CR: ??? - Fix indents, trailing spaces and various typos. ??? - Add descriptions for the '_cnt', '_max' and '_times" fields, ????? add impl notes to document the type choices. ? src/hotspot/share/runtime/globals.hpp change is white-space only so it ? is only visible via the file's patch link. Robin W's resolutions: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ ? mq comment for robinw_CR: ??? - Fix some inefficient code, update some comments, fix some indents, ????? and add some 'const' specifiers. ? src/hotspot/share/runtime/vm_operations.hpp change is white-space only so ? it is only visible via the file's patch link. Coleen's resolutions: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ ? mq comment for coleenp_CR: ??? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', ??? - add header comment to threadSMR.hpp file, ??? - cleanup JavaThreadIteratorWithHandle ctr, ??? - make ErrorHandling more efficient. Some folks prefer to see all of the delta webrevs together so here is a delta webrev relative to jdk10-09-full: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ ? src/hotspot/share/runtime/globals.hpp and ? src/hotspot/share/runtime/vm_operations.hpp changes are white-space only ? so they are only visible via the file's patch link. And, of course, some folks prefer to see everything all at once so here is the latest full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... The project is currently baselined on Jesper's 2017-11-17 PIT snapshot so there will be some catching up to do before integration... We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: > Greetings, > > Testing of the last round of changes revealed a hang in one of the new > TLH tests. Robbin has fixed the hang, updated the existing TLH test, and > added another TLH test for good measure. > > Here is the updated full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ > > Here is the updated delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ > > Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are > no unexpected failures. > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Robbin rebased the project last night/this morning to merge with Thread >> Local Handshakes (TLH) and also picked up additional changesets up thru: >> >>> Changeset: fa736014cf28 >>> Author:??? cjplummer >>> Date:????? 2017-11-14 18:08 -0800 >>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>> >>> 8191049: Add alternate version of pns() that is callable from within >>> hotspot source >>> Summary: added pns2() to debug.cpp >>> Reviewed-by: stuefe, gthornbr >> >> This is the first time we've rebased the project to bits that are this >> fresh (< 12 hours old at rebase time). We've done this because we think >> we're done with this project and are in the final review-change-retest >> cycle(s)... In other words, we're not planning on making any more major >> changes for this project... :-) >> >> *** Time for code reviewers to chime in on this thread! *** >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >> >> Here's is the delta webrev from the 2017.11.10 rebase: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >> >> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >> (and the new baseline also)... >> >> We're expecting this round to be a little noisier than usual because >> we did not rebase on a PIT snapshot so the new baseline has not been >> through Jesper's usual care-and-feeding of integration_blockers, etc. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>> (Yes, we're playing chase-the-repo...) >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>> >>> Unlike the previous rebase, there were no changes required to the >>> open code to get the rebased bits to build so there is no delta >>> webrev. >>> >>> These bits have been run through JPRT and I've submitted the usual >>> Mach5 tier[1-5] test run... >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>> >>>> Here are the updated webrevs: >>>> >>>> Here's the mq comment for the change: >>>> >>>> ? Rebase to 2017.10.25 PIT snapshot. >>>> >>>> Here is the full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>> >>>> And here is the delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>> >>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>> look today. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Resolving one of the code review comments (from both Stefan K and >>>>> Coleen) >>>>> on jdk10-04-full required quite a few changes so it is being done >>>>> as a >>>>> standalone patch and corresponding webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>> ??? JavaThreadIteratorWithHandle. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> We have a (eXtra Large) fix for the following bug: >>>>>> >>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>> >>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>> >>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>> and track the work on this project: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>> >>>>>> >>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>> quotes >>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>> have a >>>>>> solution for that problem yet. >>>>>> >>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>> >>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>> tier[2-5] >>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>> additional testing on Erik and Robbin's machines. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Daniel Daugherty >>>>>> Erik Osterlund >>>>>> Robbin Ehn >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From dean.long at oracle.com Wed Nov 22 00:45:40 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 21 Nov 2017 16:45:40 -0800 Subject: RFR(XS) 8191688: Assert failed in > 200 tests: failed dependencies, but counter didn't change Message-ID: <9270bb34-71b6-b737-f5d3-62b7dbc82fa1@oracle.com> The recently pushed 8160548 changed inlining behavior and also accidentally undid a fix for an old bug, 6328518, which relied on "cannot be compiled" implying "cannot be inlined". So now that we can inline methods that are cannot be compiled, we need another way to prevent a method from being inlined. https://bugs.openjdk.java.net/browse/JDK-8191688 http://cr.openjdk.java.net/~dlong/8191688/webrev/ dl From vladimir.kozlov at oracle.com Wed Nov 22 01:03:00 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Nov 2017 17:03:00 -0800 Subject: RFR(XS) 8191688: Assert failed in > 200 tests: failed dependencies, but counter didn't change In-Reply-To: <9270bb34-71b6-b737-f5d3-62b7dbc82fa1@oracle.com> References: <9270bb34-71b6-b737-f5d3-62b7dbc82fa1@oracle.com> Message-ID: Good. Thanks, Vladimir On 11/21/17 4:45 PM, dean.long at oracle.com wrote: > The recently pushed 8160548 changed inlining behavior and also > accidentally undid a fix for an old bug, 6328518, which relied on > "cannot be compiled" implying "cannot be inlined".? So now that we can > inline methods that are cannot be compiled, we need another way to > prevent a method from being inlined. > > https://bugs.openjdk.java.net/browse/JDK-8191688 > http://cr.openjdk.java.net/~dlong/8191688/webrev/ > > dl > From dean.long at oracle.com Wed Nov 22 01:49:06 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 21 Nov 2017 17:49:06 -0800 Subject: RFR(XS) 8191688: Assert failed in > 200 tests: failed dependencies, but counter didn't change In-Reply-To: References: <9270bb34-71b6-b737-f5d3-62b7dbc82fa1@oracle.com> Message-ID: Thanks Vladimir. dl On 11/21/17 5:03 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 11/21/17 4:45 PM, dean.long at oracle.com wrote: >> The recently pushed 8160548 changed inlining behavior and also >> accidentally undid a fix for an old bug, 6328518, which relied on >> "cannot be compiled" implying "cannot be inlined".? So now that we >> can inline methods that are cannot be compiled, we need another way >> to prevent a method from being inlined. >> >> https://bugs.openjdk.java.net/browse/JDK-8191688 >> http://cr.openjdk.java.net/~dlong/8191688/webrev/ >> >> dl >> From david.holmes at oracle.com Wed Nov 22 04:26:39 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Nov 2017 14:26:39 +1000 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> Message-ID: <4d5d448e-3902-8465-197e-18a5607fbd70@oracle.com> Hi Dan, On 22/11/2017 10:12 AM, Daniel D. Daugherty wrote: > Greetings, > > *** We are wrapping up code review on this project so it is time *** > *** for the various code reviewers to chime in one last time. *** > > In this latest round, we had three different reviewers chime in so we're > doing delta webrevs for each of those resolutions: > > David H's resolutions: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ > > > ? mq comment for dholmes_CR: > ??? - Fix indents, trailing spaces and various typos. > ??? - Add descriptions for the '_cnt', '_max' and '_times" fields, > ????? add impl notes to document the type choices. src/hotspot/share/runtime/thread.cpp 3466 // range. Unsigned 64-bit would be more future proof, but 64-bit atomic inc 3467 // isn't available everywhere (or is it?). 64-bit atomics should be available on all currently supported platforms (the last time this was an issue was for PPC32 - and the atomic templates should have filled in any previous holes in the allowed types). But if it's always 64-bit then you'd have to use Atomic::load to allow for 32-bit platforms. These counts etc are all just for statistics so we aren't really concerned about eventual overflows in long running VMs - right? --- // # of parallel threads in _smr_delete_lock->wait(). static uint _smr_delete_lock_wait_cnt; // Max # of parallel threads in _smr_delete_lock->wait(). why are the comments indented like that? I thought this is what Coleen previously commented on. Please just start the comments in the first column - no need for any indent. Thanks. > ? src/hotspot/share/runtime/globals.hpp change is white-space only so it > ? is only visible via the file's patch link. > > > Robin W's resolutions: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ > > > ? mq comment for robinw_CR: > ??? - Fix some inefficient code, update some comments, fix some indents, > ????? and add some 'const' specifiers. > > ? src/hotspot/share/runtime/vm_operations.hpp change is white-space > only so > ? it is only visible via the file's patch link. All looks fine to me. Some good catches there from Robin! > Coleen's resolutions: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ > > > ? mq comment for coleenp_CR: > ??? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', > ??? - add header comment to threadSMR.hpp file, > ??? - cleanup JavaThreadIteratorWithHandle ctr, > ??? - make ErrorHandling more efficient. src/hotspot/share/runtime/threadSMR.hpp + // Thread Safe Memory Reclaimation (Thread-SMR) support. Only one 'i' in Reclamation :) Thanks, David ------ > > Some folks prefer to see all of the delta webrevs together so here is > a delta webrev relative to jdk10-09-full: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ > > > ? src/hotspot/share/runtime/globals.hpp and > ? src/hotspot/share/runtime/vm_operations.hpp changes are white-space only > ? so they are only visible via the file's patch link. > > > And, of course, some folks prefer to see everything all at once so here > is the latest full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ > > > Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The > prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... > > The project is currently baselined on Jesper's 2017-11-17 PIT snapshot > so there will be some catching up to do before integration... > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Testing of the last round of changes revealed a hang in one of the new >> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >> added another TLH test for good measure. >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >> >> Here is the updated delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >> >> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >> no unexpected failures. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Robbin rebased the project last night/this morning to merge with Thread >>> Local Handshakes (TLH) and also picked up additional changesets up thru: >>> >>>> Changeset: fa736014cf28 >>>> Author:??? cjplummer >>>> Date:????? 2017-11-14 18:08 -0800 >>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>> >>>> 8191049: Add alternate version of pns() that is callable from within >>>> hotspot source >>>> Summary: added pns2() to debug.cpp >>>> Reviewed-by: stuefe, gthornbr >>> >>> This is the first time we've rebased the project to bits that are this >>> fresh (< 12 hours old at rebase time). We've done this because we think >>> we're done with this project and are in the final review-change-retest >>> cycle(s)... In other words, we're not planning on making any more major >>> changes for this project... :-) >>> >>> *** Time for code reviewers to chime in on this thread! *** >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>> >>> Here's is the delta webrev from the 2017.11.10 rebase: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>> (and the new baseline also)... >>> >>> We're expecting this round to be a little noisier than usual because >>> we did not rebase on a PIT snapshot so the new baseline has not been >>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>> (Yes, we're playing chase-the-repo...) >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>> >>>> Unlike the previous rebase, there were no changes required to the >>>> open code to get the rebased bits to build so there is no delta >>>> webrev. >>>> >>>> These bits have been run through JPRT and I've submitted the usual >>>> Mach5 tier[1-5] test run... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>> >>>>> Here are the updated webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>> >>>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>>> look today. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Resolving one of the code review comments (from both Stefan K and >>>>>> Coleen) >>>>>> on jdk10-04-full required quite a few changes so it is being done >>>>>> as a >>>>>> standalone patch and corresponding webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>>> ??? JavaThreadIteratorWithHandle. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>> >>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>> >>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>> >>>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>>> and track the work on this project: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>> >>>>>>> >>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>> quotes >>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>> have a >>>>>>> solution for that problem yet. >>>>>>> >>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>> >>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>> tier[2-5] >>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>> additional testing on Erik and Robbin's machines. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Daniel Daugherty >>>>>>> Erik Osterlund >>>>>>> Robbin Ehn >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > From igor.veresov at oracle.com Wed Nov 22 05:24:51 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 21 Nov 2017 21:24:51 -0800 Subject: RFR(XS) 8191683: Compile problem on ARM after JDK-8043070 Message-ID: <00D6751E-3C45-40ED-B951-C9A7FC100CD5@oracle.com> My recent change caused a compilation problem on ARM, where char is unsigned by default. This fix changes _state to be signed explicitly. Webrev: http://cr.openjdk.java.net/~iveresov/8191683/webrev.00/ Thanks, igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Wed Nov 22 06:04:23 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 22 Nov 2017 07:04:23 +0100 Subject: RFR(XS) 8191683: Compile problem on ARM after JDK-8043070 In-Reply-To: <00D6751E-3C45-40ED-B951-C9A7FC100CD5@oracle.com> References: <00D6751E-3C45-40ED-B951-C9A7FC100CD5@oracle.com> Message-ID: <13994b02-6542-422a-e387-68498d17f302@oracle.com> Hi Igor, looks good to me. Best regards, Tobias On 22.11.2017 06:24, Igor Veresov wrote: > My recent change caused a compilation problem on ARM, where char is unsigned by default. This fix changes _state to be > signed explicitly. > > Webrev:?http://cr.openjdk.java.net/~iveresov/8191683/webrev.00/ > > Thanks, > igor From igor.veresov at oracle.com Wed Nov 22 06:55:56 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 21 Nov 2017 22:55:56 -0800 Subject: RFR(XS) 8191683: Compile problem on ARM after JDK-8043070 In-Reply-To: <13994b02-6542-422a-e387-68498d17f302@oracle.com> References: <00D6751E-3C45-40ED-B951-C9A7FC100CD5@oracle.com> <13994b02-6542-422a-e387-68498d17f302@oracle.com> Message-ID: <5F702A7B-B5D1-42D5-ACC1-DFA2DE51F87D@oracle.com> Thanks, Tobias! igor > On Nov 21, 2017, at 10:04 PM, Tobias Hartmann wrote: > > Hi Igor, > > looks good to me. > > Best regards, > Tobias > > On 22.11.2017 06:24, Igor Veresov wrote: >> My recent change caused a compilation problem on ARM, where char is unsigned by default. This fix changes _state to be >> signed explicitly. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8191683/webrev.00/ >> >> Thanks, >> igor From tobias.hartmann at oracle.com Wed Nov 22 07:05:24 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 22 Nov 2017 08:05:24 +0100 Subject: [10] RFR(S): 8179026: Remove explicit code cache options processing In-Reply-To: <2a9179c1-ee2f-fe74-3809-08f697660beb@oracle.com> References: <2a9179c1-ee2f-fe74-3809-08f697660beb@oracle.com> Message-ID: Hi Vladimir, thanks for the review! On 21.11.2017 21:43, Vladimir Kozlov wrote: > Looks good. Can you also print size_initial in error message in codeCache.cpp? Sure, here's the updated webrev: http://cr.openjdk.java.net/~thartmann/8179026/webrev.01/ Best regards, Tobias > On 11/20/17 12:22 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8179026 >> http://cr.openjdk.java.net/~thartmann/8179026/webrev.00/ >> >> I've removed the explicit processing of -XX:CodeCacheExpansionSize, -XX:NonNMethodCodeHeapSize, -XX:ProfiledCodeHeapSize >> and -XX:NonProfiledCodeHeapSize because generic option processing already supports memory values. I've also added a >> lower bound of vm_page_size() to all of them except the non-profiled and the profiled size because these can be 0. The >> actual checking is done in codeCache.cpp. >> >> All tests pass. >> >> Thanks, >> Tobias >> From erik.osterlund at oracle.com Wed Nov 22 09:07:30 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 22 Nov 2017 10:07:30 +0100 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> Message-ID: <5A153E52.8000704@oracle.com> Hi, Some replies... On 2017-11-21 17:28, Daniel D. Daugherty wrote: > Hi Coleen! > > Thanks for making time to review the Thread-SMR stuff again!! > > I have added back the other three OpenJDK aliases... This review is > being done on _four_ different OpenJDK aliases. > > As always, replies are embedded below... > > > On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html >> >> >> 32 ThreadsList::ThreadsList(int entries) : _length(entries), >> _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), >> _next_list(NULL) { >> >> Seems like it should be mtThread rather than mtGC. > > Fixed. Definitely an artifact of Erik's original prototype when he > extracted Thread-SMR from his GC work... Thanks for catching it. > Confirmed. At the time I considered the Threads list overheads GC overheads, but I agree mtThread is a better fit today. > >> >> + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); >> >> Can you add a comment about where this number came from? > > I'll have to get that from Erik... Wow, that looks like code I wrote a *very* long time ago. :) That is a variation of Knuth's multiplicative hash which is outlined in a comment in synchronizer.cpp and referred to in that comment as a phi-based scheme. Basically the magic number is 2^32 * Phi (the golden ratio), which happens to be a useful value for building a reasonably simple yet pretty good hash function. It is not the optimal hash function, but seemed to definitely be good enough for our purposes. Thanks, /Erik From erik.osterlund at oracle.com Wed Nov 22 09:48:32 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 22 Nov 2017 10:48:32 +0100 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5e154ff2-65d4-bad4-db5e-88cf4c733c7d@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> <5e154ff2-65d4-bad4-db5e-88cf4c733c7d@oracle.com> Message-ID: <5A1547F0.7040206@oracle.com> Hi, Some replies... On 2017-11-21 18:36, Daniel D. Daugherty wrote: > Thanks for keeping all the OpenJDK aliases! > > > On 11/21/17 12:24 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: >>> >>> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>> >>>> I can't find the caller of threads_do_smr. >>> >>> I'm guessing that's used by the GC code that depends on Thread-SMR... >>> >> >> They should add this API when the add the use of it then. I don't >> see it in any sources. > > We'll see what Erik wants to do... The new iterators should be more than enough, so that closure-based API is not going to be missed when removed. > >> >>> >>>> If these functions xchg_smr_thread_list, get_smr_java_thread_list, >>>> inc_smr_deleted_thread_count are only used by thread.cpp, I think >>>> they should go in that file and not in the .inline.hpp file to be >>>> included and possibly called by other files. I think they're >>>> private to class Threads. >>> >>> I have a vague memory that some of the compilers don't do inlining when >>> an "inline" function is in a .cpp. I believe we want these functions >>> to be inlined for performance reasons. Erik should probably chime in >>> here. >> >> I don't see why this should be. Maybe some (older) compilers require >> it to be found before the call though, but that can still be >> accomplished in the .cpp file. > > Again, we'll see what Erik wants to do... I don't mind. Either file works for me. For me it's more intuitive if inline member function definitions are in the .inline.hpp files. But if there are strong forces to move this to the cpp file, then sure. Thanks, /Erik From vladimir.x.ivanov at oracle.com Wed Nov 22 11:46:12 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 22 Nov 2017 14:46:12 +0300 Subject: RFR 8190800: Support for vectorization of sqrt float In-Reply-To: References: <48D92A70936F7946BE99F3FF5ECB6461D8DDF561@ORSMSX113.amr.corp.intel.com> <5c9e54c0-cd07-e68f-852b-448239b5f47f@oracle.com> Message-ID: <29be9217-be75-e771-3efa-c871e125c89c@oracle.com> Test results are fine. Pushed: http://hg.openjdk.java.net/jdk/hs/rev/22c9856fc2c2 Best regards, Vladimir Ivanov On 11/22/17 12:13 AM, Vladimir Kozlov wrote: > On 11/20/17 9:36 AM, Vladimir Ivanov wrote: >> Looks good. >> >> I'll sponsor the change. > > Please, run pre-integration testing before push. > > Thanks, > Vladimir K > >> >> Best regards, >> Vladimir Ivanov >> >> On 11/18/17 12:10 AM, Lupusoru, Razvan A wrote: >>> Hello, >>> >>> The vectorizer cannot currently handle vectorization of sqrt for >>> floats even though there is packed single precision sqrt instruction >>> supported in AVX. The following patch rectifies the situation by >>> adding a new C2 node for floating point version of Sqrt and its >>> vectorized version, along with assembler support for it. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8190800 >>> >>> The proposed solution can be found here: >>> >>> http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_sqrtf_02/ >>> >>> Please let me know if you have any questions or concerns. >>> >>> --Razvan >>> From vladimir.x.ivanov at oracle.com Wed Nov 22 12:13:32 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 22 Nov 2017 15:13:32 +0300 Subject: RFR(XS) 8191688: Assert failed in > 200 tests: failed dependencies, but counter didn't change In-Reply-To: <9270bb34-71b6-b737-f5d3-62b7dbc82fa1@oracle.com> References: <9270bb34-71b6-b737-f5d3-62b7dbc82fa1@oracle.com> Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8191688 > http://cr.openjdk.java.net/~dlong/8191688/webrev/ The fix looks good. An observation not related to the bug: + if (env->jvmti_can_hotswap_or_post_breakpoint()) { // 6328518 check hotswap conditions under the right lock. MutexLocker locker(Compile_lock); if (Dependencies::check_evol_method(h_m()) != NULL) { _is_c1_compilable = false; _is_c2_compilable = false; + _can_be_parsed = false; } } else { Klass* Dependencies::check_evol_method(Method* m) { ... if (m->is_old() || m->number_of_breakpoints() > 0) { return m->method_holder(); It seems once there's a breakpoint set in a method, it will never be compiled again. (I looked in the code couldn't find where _is_c1_compilable/_is_c2_compilable are reset once all breakpoints are cleared). If that's the case, it has severe performance consequences, so better to fix it. Also, some nitpicking follows: + bool _can_be_parsed; + bool can_be_parsed() const { return _can_be_parsed; } The name confuses me. I'd presume it signals there are some problems with parsing the method, so don't even try. It seems the choice was affected by InlineTree::check_can_parse(), but the latter looks justified: const char* InlineTree::check_can_parse(ciMethod* callee) { // Certain methods cannot be parsed at all: if ( callee->is_native()) return "native method"; if ( callee->is_abstract()) return "abstract method"; if (!callee->has_balanced_monitors()) return "not compilable (unbalanced monitors)"; if ( callee->get_flow_analysis()->failing()) return "not compilable (flow analysis failed)"; Why doesn't it stress it's all about inlining? E.g., ciMethod::can_be_inlined looks more descriptive in that context. Best regards, Vladimir Ivanov From daniel.daugherty at oracle.com Wed Nov 22 12:51:10 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 07:51:10 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <4d5d448e-3902-8465-197e-18a5607fbd70@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> <4d5d448e-3902-8465-197e-18a5607fbd70@oracle.com> Message-ID: <4fd06a59-f6b5-33b2-53f5-7bfc96f866a7@oracle.com> On 11/21/17 11:26 PM, David Holmes wrote: > Hi Dan, > > On 22/11/2017 10:12 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> *** We are wrapping up code review on this project so it is time *** >> *** for the various code reviewers to chime in one last time. *** >> >> In this latest round, we had three different reviewers chime in so we're >> doing delta webrevs for each of those resolutions: >> >> David H's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ >> >> >> ?? mq comment for dholmes_CR: >> ???? - Fix indents, trailing spaces and various typos. >> ???? - Add descriptions for the '_cnt', '_max' and '_times" fields, >> ?????? add impl notes to document the type choices. > > src/hotspot/share/runtime/thread.cpp > > 3466 // range. Unsigned 64-bit would be more future proof, but 64-bit > atomic inc > 3467 // isn't available everywhere (or is it?). > > 64-bit atomics should be available on all currently supported > platforms (the last time this was an issue was for PPC32 - and the > atomic templates should have filled in any previous holes in the > allowed types). Hmmm... I ran into this when I merged the project with the atomic templates. I got a JPRT build failure on one of the ARM platforms... Unfortunately, I didn't save the log files so I can't quote the error message from the template stuff... > But if it's always 64-bit then you'd have to use Atomic::load to allow > for 32-bit platforms. What's the official story on 32-bit platforms? Is that what bit me in JPRT? i.e., did we still have a 32-bit ARM build config'ed in JPRT a month or two ago??? > These counts etc are all just for statistics so we aren't really > concerned about eventual overflows in long running VMs - right? Yup these are just statistics... overflow is not a killer. > > --- > > ?????????????????????????????????????? // # of parallel threads in > _smr_delete_lock->wait(). > ? static uint????????????????? _smr_delete_lock_wait_cnt; > ?????????????????????????????????????? // Max # of parallel threads in > _smr_delete_lock->wait(). > > > why are the comments indented like that? I thought this is what Coleen > previously commented on. Please just start the comments in the first > column - no need for any indent. Thanks. Coleen asked for the new comments in thread.cpp to be moved over to column 1. She asked for the new comments in thread.hpp to be indented with more spaces. I started with 2 spaces and the variables still didn't stand out. I tried 4 spaces and they still didn't stand out probably because of the leading _smr_... So I went with 8 spaces... > >> ?? src/hotspot/share/runtime/globals.hpp change is white-space only >> so it >> ?? is only visible via the file's patch link. >> >> >> Robin W's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ >> >> >> ?? mq comment for robinw_CR: >> ???? - Fix some inefficient code, update some comments, fix some >> indents, >> ?????? and add some 'const' specifiers. >> >> ?? src/hotspot/share/runtime/vm_operations.hpp change is white-space >> only so >> ?? it is only visible via the file's patch link. > > All looks fine to me. Some good catches there from Robin! Yes, a new pair of eyes on this code is always useful. > >> Coleen's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ >> >> >> ?? mq comment for coleenp_CR: >> ???? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', >> ???? - add header comment to threadSMR.hpp file, >> ???? - cleanup JavaThreadIteratorWithHandle ctr, >> ???? - make ErrorHandling more efficient. > > src/hotspot/share/runtime/threadSMR.hpp > > + // Thread Safe Memory Reclaimation (Thread-SMR) support. > > Only one 'i' in Reclamation :) Will fix. I tried typing both and neither looked right to me. (I might be getting blurry eyed with this stuff)... So I went with the spelling from Coleen's comment... :-) Thanks for taking another look!! Dan > > Thanks, > David > ------ > >> >> Some folks prefer to see all of the delta webrevs together so here is >> a delta webrev relative to jdk10-09-full: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ >> >> >> ?? src/hotspot/share/runtime/globals.hpp and >> ?? src/hotspot/share/runtime/vm_operations.hpp changes are >> white-space only >> ?? so they are only visible via the file's patch link. >> >> >> And, of course, some folks prefer to see everything all at once so here >> is the latest full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ >> >> >> Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The >> prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... >> >> The project is currently baselined on Jesper's 2017-11-17 PIT snapshot >> so there will be some catching up to do before integration... >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Testing of the last round of changes revealed a hang in one of the new >>> TLH tests. Robbin has fixed the hang, updated the existing TLH test, >>> and >>> added another TLH test for good measure. >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>> >>> Here is the updated delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>> >>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>> no unexpected failures. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Robbin rebased the project last night/this morning to merge with >>>> Thread >>>> Local Handshakes (TLH) and also picked up additional changesets up >>>> thru: >>>> >>>>> Changeset: fa736014cf28 >>>>> Author:??? cjplummer >>>>> Date:????? 2017-11-14 18:08 -0800 >>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>> >>>>> 8191049: Add alternate version of pns() that is callable from >>>>> within hotspot source >>>>> Summary: added pns2() to debug.cpp >>>>> Reviewed-by: stuefe, gthornbr >>>> >>>> This is the first time we've rebased the project to bits that are this >>>> fresh (< 12 hours old at rebase time). We've done this because we >>>> think >>>> we're done with this project and are in the final review-change-retest >>>> cycle(s)... In other words, we're not planning on making any more >>>> major >>>> changes for this project... :-) >>>> >>>> *** Time for code reviewers to chime in on this thread! *** >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>> >>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>> (and the new baseline also)... >>>> >>>> We're expecting this round to be a little noisier than usual because >>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>> (Yes, we're playing chase-the-repo...) >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>> >>>>> Unlike the previous rebase, there were no changes required to the >>>>> open code to get the rebased bits to build so there is no delta >>>>> webrev. >>>>> >>>>> These bits have been run through JPRT and I've submitted the usual >>>>> Mach5 tier[1-5] test run... >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>> >>>>>> Here are the updated webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>> >>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>> holiday >>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>> closer >>>>>> look today. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>> and Coleen) >>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>> done as a >>>>>>> standalone patch and corresponding webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>> to use >>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>> >>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>> >>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>> >>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>> describe >>>>>>>> and track the work on this project: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>> >>>>>>>> >>>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>>> quotes >>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>> have a >>>>>>>> solution for that problem yet. >>>>>>>> >>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>> >>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>> tier[2-5] >>>>>>>> testing, additional stress testing on Dan's Solaris X64 server, >>>>>>>> and >>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Daniel Daugherty >>>>>>>> Erik Osterlund >>>>>>>> Robbin Ehn >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> From daniel.daugherty at oracle.com Wed Nov 22 12:53:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 07:53:16 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5A153E52.8000704@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <5A153E52.8000704@oracle.com> Message-ID: On 11/22/17 4:07 AM, Erik ?sterlund wrote: > Hi, > > Some replies... > > On 2017-11-21 17:28, Daniel D. Daugherty wrote: >> Hi Coleen! >> >> Thanks for making time to review the Thread-SMR stuff again!! >> >> I have added back the other three OpenJDK aliases... This review is >> being done on _four_ different OpenJDK aliases. >> >> As always, replies are embedded below... >> >> >> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html >>> >>> >>> ? 32 ThreadsList::ThreadsList(int entries) : _length(entries), >>> _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), >>> _next_list(NULL) { >>> >>> Seems like it should be mtThread rather than mtGC. >> >> Fixed. Definitely an artifact of Erik's original prototype when he >> extracted Thread-SMR from his GC work... Thanks for catching it. >> > > Confirmed. At the time I considered the Threads list overheads GC > overheads, but I agree mtThread is a better fit today. > >> >>> >>> + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); >>> >>> Can you add a comment about where this number came from? >> >> I'll have to get that from Erik... > > Wow, that looks like code I wrote a *very* long time ago. :) That is a > variation of Knuth's multiplicative hash which is outlined in a > comment in synchronizer.cpp and referred to in that comment as a > phi-based scheme. Basically the magic number is 2^32 * Phi (the golden > ratio), which happens to be a useful value for building a reasonably > simple yet pretty good hash function. It is not the optimal hash > function, but seemed to definitely be good enough for our purposes. So a reasonable comment would be: // The literal value is 2^32 * Phi (the golden ratio). If so, then I'll add it in my wrap up round... Dan > > Thanks, > /Erik From daniel.daugherty at oracle.com Wed Nov 22 12:54:51 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 07:54:51 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5A1547F0.7040206@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> <5e154ff2-65d4-bad4-db5e-88cf4c733c7d@oracle.com> <5A1547F0.7040206@oracle.com> Message-ID: <6906e0e0-e5cc-a415-6db2-13eff8d76ca8@oracle.com> On 11/22/17 4:48 AM, Erik ?sterlund wrote: > Hi, > > Some replies... > > On 2017-11-21 18:36, Daniel D. Daugherty wrote: >> Thanks for keeping all the OpenJDK aliases! >> >> >> On 11/21/17 12:24 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: >>>> >>>> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>>> >>>>> I can't find the caller of threads_do_smr. >>>> >>>> I'm guessing that's used by the GC code that depends on Thread-SMR... >>>> >>> >>> They? should add this API when the add the use of it then.? I don't >>> see it in any sources. >> >> We'll see what Erik wants to do... > > The new iterators should be more than enough, so that closure-based > API is not going to be missed when removed. I will delete it in the wrap up round. > >> >>> >>>> >>>>> If these functions xchg_smr_thread_list, get_smr_java_thread_list, >>>>> inc_smr_deleted_thread_count are only used by thread.cpp, I think >>>>> they should go in that file and not in the .inline.hpp file to be >>>>> included and possibly called by other files.? I think they're >>>>> private to class Threads. >>>> >>>> I have a vague memory that some of the compilers don't do inlining >>>> when >>>> an "inline" function is in a .cpp. I believe we want these functions >>>> to be inlined for performance reasons. Erik should probably chime in >>>> here. >>> >>> I don't see why this should be.? Maybe some (older) compilers >>> require it to be found before the call though, but that can still be >>> accomplished in the .cpp file. >> >> Again, we'll see what Erik wants to do... > > I don't mind. Either file works for me. For me it's more intuitive if > inline member function definitions are in the .inline.hpp files. But > if there are strong forces to move this to the cpp file, then sure. I prefer inline member function definitions in the .inline.hpp files. (There might even be a style guide note about this...) Coleen, are you okay if we leave them there? Dan > > Thanks, > /Erik > From coleen.phillimore at oracle.com Wed Nov 22 13:02:32 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Nov 2017 08:02:32 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <6906e0e0-e5cc-a415-6db2-13eff8d76ca8@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> <5e154ff2-65d4-bad4-db5e-88cf4c733c7d@oracle.com> <5A1547F0.7040206@oracle.com> <6906e0e0-e5cc-a415-6db2-13eff8d76ca8@oracle.com> Message-ID: <50fdb219-4aa2-bdcc-cf69-8f60c935208f@oracle.com> On 11/22/17 7:54 AM, Daniel D. Daugherty wrote: > On 11/22/17 4:48 AM, Erik ?sterlund wrote: >> Hi, >> >> Some replies... >> >> On 2017-11-21 18:36, Daniel D. Daugherty wrote: >>> Thanks for keeping all the OpenJDK aliases! >>> >>> >>> On 11/21/17 12:24 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: >>>>> >>>>> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>>> I can't find the caller of threads_do_smr. >>>>> >>>>> I'm guessing that's used by the GC code that depends on Thread-SMR... >>>>> >>>> >>>> They? should add this API when the add the use of it then. I don't >>>> see it in any sources. >>> >>> We'll see what Erik wants to do... >> >> The new iterators should be more than enough, so that closure-based >> API is not going to be missed when removed. > > I will delete it in the wrap up round. > > Thank you. >> >>> >>>> >>>>> >>>>>> If these functions xchg_smr_thread_list, >>>>>> get_smr_java_thread_list, inc_smr_deleted_thread_count are only >>>>>> used by thread.cpp, I think they should go in that file and not >>>>>> in the .inline.hpp file to be included and possibly called by >>>>>> other files.? I think they're private to class Threads. >>>>> >>>>> I have a vague memory that some of the compilers don't do inlining >>>>> when >>>>> an "inline" function is in a .cpp. I believe we want these functions >>>>> to be inlined for performance reasons. Erik should probably chime in >>>>> here. >>>> >>>> I don't see why this should be.? Maybe some (older) compilers >>>> require it to be found before the call though, but that can still >>>> be accomplished in the .cpp file. >>> >>> Again, we'll see what Erik wants to do... >> >> I don't mind. Either file works for me. For me it's more intuitive if >> inline member function definitions are in the .inline.hpp files. But >> if there are strong forces to move this to the cpp file, then sure. > > I prefer inline member function definitions in the .inline.hpp files. > (There might even be a style guide note about this...) > > Coleen, are you okay if we leave them there? Yes, that's fine. Coleen > > Dan > > >> >> Thanks, >> /Erik >> > From erik.osterlund at oracle.com Wed Nov 22 13:06:50 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 22 Nov 2017 14:06:50 +0100 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <5A153E52.8000704@oracle.com> Message-ID: <5A15766A.1090701@oracle.com> Hi Dan, On 2017-11-22 13:53, Daniel D. Daugherty wrote: > On 11/22/17 4:07 AM, Erik ?sterlund wrote: >> Hi, >> >> Some replies... >> >> On 2017-11-21 17:28, Daniel D. Daugherty wrote: >>> Hi Coleen! >>> >>> Thanks for making time to review the Thread-SMR stuff again!! >>> >>> I have added back the other three OpenJDK aliases... This review is >>> being done on _four_ different OpenJDK aliases. >>> >>> As always, replies are embedded below... >>> >>> >>> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html >>>> >>>> >>>> 32 ThreadsList::ThreadsList(int entries) : _length(entries), >>>> _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), >>>> _next_list(NULL) { >>>> >>>> Seems like it should be mtThread rather than mtGC. >>> >>> Fixed. Definitely an artifact of Erik's original prototype when he >>> extracted Thread-SMR from his GC work... Thanks for catching it. >>> >> >> Confirmed. At the time I considered the Threads list overheads GC >> overheads, but I agree mtThread is a better fit today. >> >>> >>>> >>>> + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); >>>> >>>> Can you add a comment about where this number came from? >>> >>> I'll have to get that from Erik... >> >> Wow, that looks like code I wrote a *very* long time ago. :) That is >> a variation of Knuth's multiplicative hash which is outlined in a >> comment in synchronizer.cpp and referred to in that comment as a >> phi-based scheme. Basically the magic number is 2^32 * Phi (the >> golden ratio), which happens to be a useful value for building a >> reasonably simple yet pretty good hash function. It is not the >> optimal hash function, but seemed to definitely be good enough for >> our purposes. > > So a reasonable comment would be: > > // The literal value is 2^32 * Phi (the golden ratio). > Yes. > If so, then I'll add it in my wrap up round... Excellent, thanks Dan. /Erik > Dan > >> >> Thanks, >> /Erik > From daniel.daugherty at oracle.com Wed Nov 22 13:09:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 08:09:16 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> <4d5d448e-3902-8465-197e-18a5607fbd70@oracle.com> <4fd06a59-f6b5-33b2-53f5-7bfc96f866a7@oracle.com> Message-ID: <1e70bbf5-6f52-315d-85ba-fd53a01b66ca@oracle.com> Adding back the other OpenJDK aliases... On 11/22/17 8:01 AM, coleen.phillimore at oracle.com wrote: > > > On 11/22/17 7:51 AM, Daniel D. Daugherty wrote: >> On 11/21/17 11:26 PM, David Holmes wrote: >>> Hi Dan, >>> >>> On 22/11/2017 10:12 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> *** We are wrapping up code review on this project so it is time *** >>>> *** for the various code reviewers to chime in one last time. *** >>>> >>>> In this latest round, we had three different reviewers chime in so >>>> we're >>>> doing delta webrevs for each of those resolutions: >>>> >>>> David H's resolutions: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ >>>> >>>> >>>> ?? mq comment for dholmes_CR: >>>> ???? - Fix indents, trailing spaces and various typos. >>>> ???? - Add descriptions for the '_cnt', '_max' and '_times" fields, >>>> ?????? add impl notes to document the type choices. >>> >>> src/hotspot/share/runtime/thread.cpp >>> >>> 3466 // range. Unsigned 64-bit would be more future proof, but >>> 64-bit atomic inc >>> 3467 // isn't available everywhere (or is it?). >>> >>> 64-bit atomics should be available on all currently supported >>> platforms (the last time this was an issue was for PPC32 - and the >>> atomic templates should have filled in any previous holes in the >>> allowed types). >> >> Hmmm... I ran into this when I merged the project with the atomic >> templates. I got a JPRT build failure on one of the ARM platforms... >> Unfortunately, I didn't save the log files so I can't quote the >> error message from the template stuff... >> >> >>> But if it's always 64-bit then you'd have to use Atomic::load to >>> allow for 32-bit platforms. >> >> What's the official story on 32-bit platforms? Is that what >> bit me in JPRT? i.e., did we still have a 32-bit ARM build >> config'ed in JPRT a month or two ago??? >> >> >>> These counts etc are all just for statistics so we aren't really >>> concerned about eventual overflows in long running VMs - right? >> >> Yup these are just statistics... overflow is not a killer. >> >> >>> >>> --- >>> >>> ?????????????????????????????????????? // # of parallel threads in >>> _smr_delete_lock->wait(). >>> ? static uint????????????????? _smr_delete_lock_wait_cnt; >>> ?????????????????????????????????????? // Max # of parallel threads >>> in _smr_delete_lock->wait(). >>> >>> >>> why are the comments indented like that? I thought this is what >>> Coleen previously commented on. Please just start the comments in >>> the first column - no need for any indent. Thanks. >> >> Coleen asked for the new comments in thread.cpp to be moved >> over to column 1. She asked for the new comments in thread.hpp >> to be indented with more spaces. I started with 2 spaces and >> the variables still didn't stand out. I tried 4 spaces and >> they still didn't stand out probably because of the leading >> _smr_... So I went with 8 spaces... > > Since you have the same but more indepth comments in the .cpp file, > and at least for my sampling the comments in the .hpp file look > redundant, I think you should not have the same comments in the .hpp > file.?? They're really values that the implementation uses, not part > of the interface.? My vote is to remove the comments from the .hpp file. The first line is intended to be a 1-line summary and it is identical between thread.cpp and thread.hpp. My thinking was that someone would look in thread.hpp first to see what the field was for and if they wanted the gory details about the field they could look at the impl notes in thread.cpp... Of course, that creates a maintenance problem in keeping the 1-liners in sync between thread.hpp and thread.cpp. I'm okay with deleting the 1-liners from thread.hpp if folks think they should go... Dan > > Coleen >> >> >>> >>>> src/hotspot/share/runtime/globals.hpp change is white-space only so it >>>> ?? is only visible via the file's patch link. >>>> >>>> >>>> Robin W's resolutions: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ >>>> >>>> >>>> ?? mq comment for robinw_CR: >>>> ???? - Fix some inefficient code, update some comments, fix some >>>> indents, >>>> ?????? and add some 'const' specifiers. >>>> >>>> ?? src/hotspot/share/runtime/vm_operations.hpp change is >>>> white-space only so >>>> ?? it is only visible via the file's patch link. >>> >>> All looks fine to me. Some good catches there from Robin! >> >> Yes, a new pair of eyes on this code is always useful. >> >> >>> >>>> Coleen's resolutions: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ >>>> >>>> >>>> ?? mq comment for coleenp_CR: >>>> ???? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', >>>> ???? - add header comment to threadSMR.hpp file, >>>> ???? - cleanup JavaThreadIteratorWithHandle ctr, >>>> ???? - make ErrorHandling more efficient. >>> >>> src/hotspot/share/runtime/threadSMR.hpp >>> >>> + // Thread Safe Memory Reclaimation (Thread-SMR) support. >>> >>> Only one 'i' in Reclamation :) >> >> Will fix. I tried typing both and neither looked right to me. >> (I might be getting blurry eyed with this stuff)... >> So I went with the spelling from Coleen's comment... :-) >> >> Thanks for taking another look!! >> >> Dan >> >> >>> >>> Thanks, >>> David >>> ------ >>> >>>> >>>> Some folks prefer to see all of the delta webrevs together so here is >>>> a delta webrev relative to jdk10-09-full: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ >>>> >>>> >>>> ?? src/hotspot/share/runtime/globals.hpp and >>>> ?? src/hotspot/share/runtime/vm_operations.hpp changes are >>>> white-space only >>>> ?? so they are only visible via the file's patch link. >>>> >>>> >>>> And, of course, some folks prefer to see everything all at once so >>>> here >>>> is the latest full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ >>>> >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The >>>> prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... >>>> >>>> The project is currently baselined on Jesper's 2017-11-17 PIT snapshot >>>> so there will be some catching up to do before integration... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Testing of the last round of changes revealed a hang in one of the >>>>> new >>>>> TLH tests. Robbin has fixed the hang, updated the existing TLH >>>>> test, and >>>>> added another TLH test for good measure. >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>>> >>>>> Here is the updated delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>>>> >>>>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>>>> no unexpected failures. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Robbin rebased the project last night/this morning to merge with >>>>>> Thread >>>>>> Local Handshakes (TLH) and also picked up additional changesets >>>>>> up thru: >>>>>> >>>>>>> Changeset: fa736014cf28 >>>>>>> Author:??? cjplummer >>>>>>> Date:????? 2017-11-14 18:08 -0800 >>>>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>>>> >>>>>>> 8191049: Add alternate version of pns() that is callable from >>>>>>> within hotspot source >>>>>>> Summary: added pns2() to debug.cpp >>>>>>> Reviewed-by: stuefe, gthornbr >>>>>> >>>>>> This is the first time we've rebased the project to bits that are >>>>>> this >>>>>> fresh (< 12 hours old at rebase time). We've done this because we >>>>>> think >>>>>> we're done with this project and are in the final >>>>>> review-change-retest >>>>>> cycle(s)... In other words, we're not planning on making any more >>>>>> major >>>>>> changes for this project... :-) >>>>>> >>>>>> *** Time for code reviewers to chime in on this thread! *** >>>>>> >>>>>> Here is the updated full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>>>> >>>>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>>>> >>>>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>>>> (and the new baseline also)... >>>>>> >>>>>> We're expecting this round to be a little noisier than usual because >>>>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>>>> through Jesper's usual care-and-feeding of integration_blockers, >>>>>> etc. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>>>> (Yes, we're playing chase-the-repo...) >>>>>>> >>>>>>> Here is the updated full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>>>> >>>>>>> Unlike the previous rebase, there were no changes required to the >>>>>>> open code to get the rebased bits to build so there is no delta >>>>>>> webrev. >>>>>>> >>>>>>> These bits have been run through JPRT and I've submitted the usual >>>>>>> Mach5 tier[1-5] test run... >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>>>> >>>>>>>> Here are the updated webrevs: >>>>>>>> >>>>>>>> Here's the mq comment for the change: >>>>>>>> >>>>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>>>> >>>>>>>> Here is the full webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>>>> >>>>>>>> And here is the delta webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>>>> >>>>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>>>> holiday >>>>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>>>> closer >>>>>>>> look today. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Dan, Erik and Robbin >>>>>>>> >>>>>>>> >>>>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>>>> and Coleen) >>>>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>>>> done as a >>>>>>>>> standalone patch and corresponding webrevs: >>>>>>>>> >>>>>>>>> Here's the mq comment for the change: >>>>>>>>> >>>>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>>>> to use >>>>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>>>> >>>>>>>>> Here is the full webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>>>> >>>>>>>>> And here is the delta webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>>>> >>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>> >>>>>>>>> Dan, Erik and Robbin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>>>> >>>>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>>>> >>>>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>>>> >>>>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>>>> describe >>>>>>>>>> and track the work on this project: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Dan has noticed that the indenting is wrong in some of the >>>>>>>>>> code quotes >>>>>>>>>> in the PDF that are not present in the internal wiki. We >>>>>>>>>> don't have a >>>>>>>>>> solution for that problem yet. >>>>>>>>>> >>>>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>>>> >>>>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>>>> tier[2-5] >>>>>>>>>> testing, additional stress testing on Dan's Solaris X64 >>>>>>>>>> server, and >>>>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>>>> >>>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>>> >>>>>>>>>> Daniel Daugherty >>>>>>>>>> Erik Osterlund >>>>>>>>>> Robbin Ehn >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >> > From daniel.daugherty at oracle.com Wed Nov 22 13:10:34 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 08:10:34 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <50fdb219-4aa2-bdcc-cf69-8f60c935208f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> <5e154ff2-65d4-bad4-db5e-88cf4c733c7d@oracle.com> <5A1547F0.7040206@oracle.com> <6906e0e0-e5cc-a415-6db2-13eff8d76ca8@oracle.com> <50fdb219-4aa2-bdcc-cf69-8f60c935208f@oracle.com> Message-ID: <6fa0d4d9-4acd-99eb-9769-613735561e93@oracle.com> On 11/22/17 8:02 AM, coleen.phillimore at oracle.com wrote: > > > On 11/22/17 7:54 AM, Daniel D. Daugherty wrote: >> On 11/22/17 4:48 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> Some replies... >>> >>> On 2017-11-21 18:36, Daniel D. Daugherty wrote: >>>> Thanks for keeping all the OpenJDK aliases! >>>> >>>> >>>> On 11/21/17 12:24 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: >>>>>> >>>>>> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>>> I can't find the caller of threads_do_smr. >>>>>> >>>>>> I'm guessing that's used by the GC code that depends on >>>>>> Thread-SMR... >>>>>> >>>>> >>>>> They? should add this API when the add the use of it then. I don't >>>>> see it in any sources. >>>> >>>> We'll see what Erik wants to do... >>> >>> The new iterators should be more than enough, so that closure-based >>> API is not going to be missed when removed. >> >> I will delete it in the wrap up round. >> >> > > Thank you. > >>> >>>> >>>>> >>>>>> >>>>>>> If these functions xchg_smr_thread_list, >>>>>>> get_smr_java_thread_list, inc_smr_deleted_thread_count are only >>>>>>> used by thread.cpp, I think they should go in that file and not >>>>>>> in the .inline.hpp file to be included and possibly called by >>>>>>> other files.? I think they're private to class Threads. >>>>>> >>>>>> I have a vague memory that some of the compilers don't do >>>>>> inlining when >>>>>> an "inline" function is in a .cpp. I believe we want these functions >>>>>> to be inlined for performance reasons. Erik should probably chime in >>>>>> here. >>>>> >>>>> I don't see why this should be.? Maybe some (older) compilers >>>>> require it to be found before the call though, but that can still >>>>> be accomplished in the .cpp file. >>>> >>>> Again, we'll see what Erik wants to do... >>> >>> I don't mind. Either file works for me. For me it's more intuitive >>> if inline member function definitions are in the .inline.hpp files. >>> But if there are strong forces to move this to the cpp file, then sure. >> >> I prefer inline member function definitions in the .inline.hpp files. >> (There might even be a style guide note about this...) >> >> Coleen, are you okay if we leave them there? > > Yes, that's fine. Thanks for confirmation! Dan > > Coleen > >> >> Dan >> >> >>> >>> Thanks, >>> /Erik >>> >> > From daniel.daugherty at oracle.com Wed Nov 22 13:10:58 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 08:10:58 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5A15766A.1090701@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <5A153E52.8000704@oracle.com> <5A15766A.1090701@oracle.com> Message-ID: <40b27a38-d7f2-5a3b-0022-92d3678e5971@oracle.com> On 11/22/17 8:06 AM, Erik ?sterlund wrote: > Hi Dan, > > On 2017-11-22 13:53, Daniel D. Daugherty wrote: >> On 11/22/17 4:07 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> Some replies... >>> >>> On 2017-11-21 17:28, Daniel D. Daugherty wrote: >>>> Hi Coleen! >>>> >>>> Thanks for making time to review the Thread-SMR stuff again!! >>>> >>>> I have added back the other three OpenJDK aliases... This review is >>>> being done on _four_ different OpenJDK aliases. >>>> >>>> As always, replies are embedded below... >>>> >>>> >>>> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html >>>>> >>>>> >>>>> ? 32 ThreadsList::ThreadsList(int entries) : _length(entries), >>>>> _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), >>>>> _next_list(NULL) { >>>>> >>>>> Seems like it should be mtThread rather than mtGC. >>>> >>>> Fixed. Definitely an artifact of Erik's original prototype when he >>>> extracted Thread-SMR from his GC work... Thanks for catching it. >>>> >>> >>> Confirmed. At the time I considered the Threads list overheads GC >>> overheads, but I agree mtThread is a better fit today. >>> >>>> >>>>> >>>>> + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); >>>>> >>>>> Can you add a comment about where this number came from? >>>> >>>> I'll have to get that from Erik... >>> >>> Wow, that looks like code I wrote a *very* long time ago. :) That is >>> a variation of Knuth's multiplicative hash which is outlined in a >>> comment in synchronizer.cpp and referred to in that comment as a >>> phi-based scheme. Basically the magic number is 2^32 * Phi (the >>> golden ratio), which happens to be a useful value for building a >>> reasonably simple yet pretty good hash function. It is not the >>> optimal hash function, but seemed to definitely be good enough for >>> our purposes. >> >> So a reasonable comment would be: >> >> // The literal value is 2^32 * Phi (the golden ratio). >> > > Yes. > >> If so, then I'll add it in my wrap up round... > > Excellent, thanks Dan. Thanks for confirmation! Dan > > /Erik > >> Dan >> >>> >>> Thanks, >>> /Erik >> > From tobias.hartmann at oracle.com Wed Nov 22 13:51:13 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 22 Nov 2017 14:51:13 +0100 Subject: [10] RFR(S): 8087339: The code heap might use different alignment for committed size and reserved size Message-ID: Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8087339 http://cr.openjdk.java.net/~thartmann/8087339/webrev.00/ The alignment of the code cache is determined in CodeCache::reserve_heap_memory() by computing the minimum of the page size for the ReservedCodeCacheSize and the InitialCodeCacheSize (which is usually very small and not aligned to the large page size). As a result, when using large pages (by enabling UseTransparentHugePages or UseHugeTLBFS), the ReservedSpace is only backed by large pages if the InitialCodeCacheSize is large page aligned as well. I've changed the implementation to not consider InitialCodeCacheSize and re-factored the code to use CodeCache::page_size() both for the alignment of heap sizes as well as the alignment of the entire reserved space. I've verified that this sets the correct alignment on my machine when using 2048K pages instead of 4K pages. Thanks, Tobias From rwestrel at redhat.com Wed Nov 22 14:47:52 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 22 Nov 2017 15:47:52 +0100 Subject: RFR(XS): 8191153: assert(u_ctrl != blk1 && u_ctrl != blk2) failed: won't converge In-Reply-To: References: Message-ID: Thanks for the review! Roland. From rwestrel at redhat.com Wed Nov 22 14:57:55 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 22 Nov 2017 15:57:55 +0100 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> Message-ID: > You answered all my comments. > I will run testing and push it if testing is clean. Thanks for the review and taking care of sponsoring. On JBS, you asked about a performance regression: SPECjvm2008-Sparse.small-G1 show significant regression - about 10%. The generated code looks ok to me. Inner loop with strip mining off: 0x00007f5d5b3698b0: mov 0x10(%r9,%rax,4),%r11d ;*iaload {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 65 (line 63) 0x00007f5d5b3698b5: cmp %r10d,%r11d 0x00007f5d5b3698b8: jae 0x00007f5d5b3698f1 0x00007f5d5b3698ba: vmovsd 0x10(%rcx,%rax,8),%xmm5 ;*daload {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 70 (line 63) 0x00007f5d5b3698c0: vmulsd 0x10(%r14,%r11,8),%xmm5,%xmm5 0x00007f5d5b3698c7: vaddsd %xmm5,%xmm4,%xmm4 ;*dadd {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 72 (line 63) 0x00007f5d5b3698cb: inc %eax ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 75 (line 62) 0x00007f5d5b3698cd: cmp %esi,%eax 0x00007f5d5b3698cf: jl 0x00007f5d5b3698b0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} Inner loop + strip mined outer loop with strip mining: 0x00007f0a02f27289: mov %ebx,%ebp 0x00007f0a02f2728b: sub %r9d,%ebp 0x00007f0a02f2728e: cmp %esi,%ebp 0x00007f0a02f27290: cmovg %esi,%ebp 0x00007f0a02f27293: add %r9d,%ebp 0x00007f0a02f27296: data16 nopw 0x0(%rax,%rax,1) ;*dload {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 57 (line 63) 0x00007f0a02f272a0: vmovq %xmm4,%r13 0x00007f0a02f272a5: mov 0x10(%r13,%r9,4),%r8d ;*iaload {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 65 (line 63) 0x00007f0a02f272aa: cmp %r11d,%r8d 0x00007f0a02f272ad: jae 0x00007f0a02f272df 0x00007f0a02f272af: vmovsd 0x10(%rcx,%r9,8),%xmm7 ;*daload {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 70 (line 63) 0x00007f0a02f272b6: vmovq %xmm2,%r13 0x00007f0a02f272bb: vmulsd 0x10(%r13,%r8,8),%xmm7,%xmm7 0x00007f0a02f272c2: vaddsd %xmm7,%xmm6,%xmm6 ;*dadd {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 72 (line 63) 0x00007f0a02f272c6: inc %r9d ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 75 (line 62) 0x00007f0a02f272c9: cmp %ebp,%r9d 0x00007f0a02f272cc: jl 0x00007f0a02f272a0 ;*goto {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 78 (line 62) 0x00007f0a02f272ce: mov 0x58(%r15),%r8 ; ImmutableOopMap{rcx=Oop rdx=Oop xmm0=Oop xmm2=Oop xmm4=Oop [0]=Oop } ;*goto {reexecute=1 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 78 (line 62) 0x00007f0a02f272d2: test %eax,(%r8) ;*goto {reexecute=0 rethrow=0 return_oop=0} ; - spec.benchmarks.scimark.SparseCompRow::matmult at 78 (line 62) ; {poll} 0x00007f0a02f272d5: cmp %ebx,%r9d 0x00007f0a02f272d8: jl 0x00007f0a02f27289 There are extra spill instructions for some reason but I think the bigger problem here is that the inner loop runs for a small number of iterations (~2) and so the outer strip mined loop is executed too often. I have an experimental patch that, for loop executed a small number of iterations (from profiling), makes 2 copies: one with the outer strip mined loop, one without. The code picks one or the other at runtime based on the actual number of iterations so there's still an overhead. I didn't include it here because it doesn't make the regression go away entirely and it's extra complexity. Roland. From dmitry.chuyko at bell-sw.com Wed Nov 22 14:58:55 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 22 Nov 2017 17:58:55 +0300 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function Message-ID: Hello, Please review a fix for JNI Critical test failures and crashes on aarch64, it includes common tests changes. bug: https://bugs.openjdk.java.net/browse/JDK-8191129 webrev: http://cr.openjdk.java.net/~dchuyko/8191129/webrev.00/ 1. Platform specific part Original fix from JDK-8167409 was imported, it makes failures more deterministic: Unimplemented() or ShouldNotReachHere(). Implementation of the feature is not complete so another change is to forcibly set CriticalJNINatives to false during initialization. 2. Common part (tests) Tests in criticalnatives read CriticalJNINatives flag using WhiteBox and ignore values check if the flag is false. Both tests pass on x86_64 and aarch64. -Dmitry From dmitry.chuyko at bell-sw.com Wed Nov 22 16:08:48 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 22 Nov 2017 19:08:48 +0300 Subject: RFR (XS): AARCH64 - Fix hint instructions encoding Message-ID: <7417388c-48e8-c051-39b9-e4269509609e@bell-sw.com> Hello, Please review a small fix for aarch64 assembler. In hint(imm) imm is now encoded as op2. I also added known hints under their names from spec. rfe: https://bugs.openjdk.java.net/browse/JDK-8191769 webrev: http://cr.openjdk.java.net/~dchuyko/8191769/webrev.00/ -Dmitry From adinn at redhat.com Wed Nov 22 16:40:06 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 22 Nov 2017 16:40:06 +0000 Subject: RFR (XS): AARCH64 - Fix hint instructions encoding In-Reply-To: <7417388c-48e8-c051-39b9-e4269509609e@bell-sw.com> References: <7417388c-48e8-c051-39b9-e4269509609e@bell-sw.com> Message-ID: <8541fef2-5277-0d75-b748-8eb4b3a52136@redhat.com> On 22/11/17 16:08, Dmitry Chuyko wrote: > Please review a small fix for aarch64 assembler. In hint(imm) imm is now > encoded as op2. I also added known hints under their names from spec. > > rfe: https://bugs.openjdk.java.net/browse/JDK-8191769 > webrev: http://cr.openjdk.java.net/~dchuyko/8191769/webrev.00/ Yes, that patch looks good. regards, Andrew Dinn ----------- From dean.long at oracle.com Wed Nov 22 19:14:20 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 22 Nov 2017 11:14:20 -0800 Subject: RFR(XS) 8191688: Assert failed in > 200 tests: failed dependencies, but counter didn't change In-Reply-To: References: <9270bb34-71b6-b737-f5d3-62b7dbc82fa1@oracle.com> Message-ID: <51c5c857-9cdc-fc90-9bf3-eb48efe6edfc@oracle.com> On 11/22/17 4:13 AM, Vladimir Ivanov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8191688 >> http://cr.openjdk.java.net/~dlong/8191688/webrev/ > > The fix looks good. > Thanks Vladimir.? I already pushed it, so I wasn't able to add you as a reviewer. > An observation not related to the bug: > > +? if (env->jvmti_can_hotswap_or_post_breakpoint()) { > ???? // 6328518 check hotswap conditions under the right lock. > ???? MutexLocker locker(Compile_lock); > ???? if (Dependencies::check_evol_method(h_m()) != NULL) { > ?????? _is_c1_compilable = false; > ?????? _is_c2_compilable = false; > +????? _can_be_parsed = false; > ???? } > ?? } else { > > Klass* Dependencies::check_evol_method(Method* m) { > ... > ? if (m->is_old() > ????? || m->number_of_breakpoints() > 0) { > ??? return m->method_holder(); > > It seems once there's a breakpoint set in a method, it will never be > compiled again. (I looked in the code couldn't find where > _is_c1_compilable/_is_c2_compilable are reset once all breakpoints are > cleared). If that's the case, it has severe performance consequences, > so better to fix it. > The ciMethod only lasts for the lifetime of the compiler task, right? > Also, some nitpicking follows: > > +? bool _can_be_parsed; > > +? bool can_be_parsed() const { return _can_be_parsed; } > > The name confuses me. I'd presume it signals there are some problems > with parsing the method, so don't even try. It seems the choice was > affected by InlineTree::check_can_parse(), but the latter looks > justified: > > const char* InlineTree::check_can_parse(ciMethod* callee) { > ? // Certain methods cannot be parsed at all: > ? if ( callee->is_native())???????????????????? return "native method"; > ? if ( callee->is_abstract())?????????????????? return "abstract method"; > ? if (!callee->has_balanced_monitors())???????? return "not compilable > (unbalanced monitors)"; > ? if ( callee->get_flow_analysis()->failing())? return "not compilable > (flow analysis failed)"; > > Why doesn't it stress it's all about inlining? E.g., > ciMethod::can_be_inlined looks more descriptive in that context. > The way things are now, "can be parsed" seems to mean "can be compiled or inlined".? If there was a way to say a method can be compiled but not inlined, then I agree can_be_inlined would make sense. dl > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Wed Nov 22 19:58:09 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Nov 2017 11:58:09 -0800 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> Message-ID: <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> Thank you, Roland I also ran pre-integration testing again and I see that testing with -Xcomp took longer with this fix than without it. I am running testing again. But if this will repeat and presence of this Sparse.small regression suggesting to me that may be we should keep this optimization off by default - keep UseCountedLoopSafepoints false. We may switch it on later with additional changes which address regressions. What do you think? Thanks, Vladimir On 11/22/17 6:57 AM, Roland Westrelin wrote: > >> You answered all my comments. >> I will run testing and push it if testing is clean. > > Thanks for the review and taking care of sponsoring. > > On JBS, you asked about a performance regression: > SPECjvm2008-Sparse.small-G1 show significant regression - about 10%. > > The generated code looks ok to me. Inner loop with strip mining off: > > 0x00007f5d5b3698b0: mov 0x10(%r9,%rax,4),%r11d ;*iaload {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 65 (line 63) > 0x00007f5d5b3698b5: cmp %r10d,%r11d > 0x00007f5d5b3698b8: jae 0x00007f5d5b3698f1 > 0x00007f5d5b3698ba: vmovsd 0x10(%rcx,%rax,8),%xmm5 ;*daload {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 70 (line 63) > 0x00007f5d5b3698c0: vmulsd 0x10(%r14,%r11,8),%xmm5,%xmm5 > 0x00007f5d5b3698c7: vaddsd %xmm5,%xmm4,%xmm4 ;*dadd {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 72 (line 63) > 0x00007f5d5b3698cb: inc %eax ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 75 (line 62) > 0x00007f5d5b3698cd: cmp %esi,%eax > 0x00007f5d5b3698cf: jl 0x00007f5d5b3698b0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} > > Inner loop + strip mined outer loop with strip mining: > > 0x00007f0a02f27289: mov %ebx,%ebp > 0x00007f0a02f2728b: sub %r9d,%ebp > 0x00007f0a02f2728e: cmp %esi,%ebp > 0x00007f0a02f27290: cmovg %esi,%ebp > 0x00007f0a02f27293: add %r9d,%ebp > 0x00007f0a02f27296: data16 nopw 0x0(%rax,%rax,1) ;*dload {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 57 (line 63) > 0x00007f0a02f272a0: vmovq %xmm4,%r13 > 0x00007f0a02f272a5: mov 0x10(%r13,%r9,4),%r8d ;*iaload {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 65 (line 63) > 0x00007f0a02f272aa: cmp %r11d,%r8d > 0x00007f0a02f272ad: jae 0x00007f0a02f272df > 0x00007f0a02f272af: vmovsd 0x10(%rcx,%r9,8),%xmm7 ;*daload {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 70 (line 63) > 0x00007f0a02f272b6: vmovq %xmm2,%r13 > 0x00007f0a02f272bb: vmulsd 0x10(%r13,%r8,8),%xmm7,%xmm7 > 0x00007f0a02f272c2: vaddsd %xmm7,%xmm6,%xmm6 ;*dadd {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 72 (line 63) > 0x00007f0a02f272c6: inc %r9d ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 75 (line 62) > 0x00007f0a02f272c9: cmp %ebp,%r9d > 0x00007f0a02f272cc: jl 0x00007f0a02f272a0 ;*goto {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 78 (line 62) > 0x00007f0a02f272ce: mov 0x58(%r15),%r8 ; ImmutableOopMap{rcx=Oop rdx=Oop xmm0=Oop xmm2=Oop xmm4=Oop [0]=Oop } > ;*goto {reexecute=1 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 78 (line 62) > 0x00007f0a02f272d2: test %eax,(%r8) ;*goto {reexecute=0 rethrow=0 return_oop=0} > ; - spec.benchmarks.scimark.SparseCompRow::matmult at 78 (line 62) > ; {poll} > 0x00007f0a02f272d5: cmp %ebx,%r9d > 0x00007f0a02f272d8: jl 0x00007f0a02f27289 > > There are extra spill instructions for some reason but I think the > bigger problem here is that the inner loop runs for a small number of > iterations (~2) and so the outer strip mined loop is executed too > often. I have an experimental patch that, for loop executed a small > number of iterations (from profiling), makes 2 copies: one with the > outer strip mined loop, one without. The code picks one or the other at > runtime based on the actual number of iterations so there's still an > overhead. I didn't include it here because it doesn't make the > regression go away entirely and it's extra complexity. > > Roland. > From vladimir.kozlov at oracle.com Wed Nov 22 20:23:49 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Nov 2017 12:23:49 -0800 Subject: [10] RFR(S): 8087339: The code heap might use different alignment for committed size and reserved size In-Reply-To: References: Message-ID: <143fd037-ef76-0334-70ca-0b248c1e6fbd@oracle.com> Good. Thanks, Vladimir On 11/22/17 5:51 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8087339 > http://cr.openjdk.java.net/~thartmann/8087339/webrev.00/ > > The alignment of the code cache is determined in CodeCache::reserve_heap_memory() by computing the minimum of the page > size for the ReservedCodeCacheSize and the InitialCodeCacheSize (which is usually very small and not aligned to the > large page size). As a result, when using large pages (by enabling UseTransparentHugePages or UseHugeTLBFS), the > ReservedSpace is only backed by large pages if the InitialCodeCacheSize is large page aligned as well. > > I've changed the implementation to not consider InitialCodeCacheSize and re-factored the code to use > CodeCache::page_size() both for the alignment of heap sizes as well as the alignment of the entire reserved space. > > I've verified that this sets the correct alignment on my machine when using 2048K pages instead of 4K pages. > > Thanks, > Tobias > From vladimir.kozlov at oracle.com Wed Nov 22 20:26:53 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Nov 2017 12:26:53 -0800 Subject: [10] RFR(S): 8179026: Remove explicit code cache options processing In-Reply-To: References: <2a9179c1-ee2f-fe74-3809-08f697660beb@oracle.com> Message-ID: <05ff6a24-c198-68a2-34bd-6800d15eb745@oracle.com> Good. Thanks, Vladimir On 11/21/17 11:05 PM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > On 21.11.2017 21:43, Vladimir Kozlov wrote: >> Looks good. Can you also print size_initial in error message in codeCache.cpp? > > Sure, here's the updated webrev: > http://cr.openjdk.java.net/~thartmann/8179026/webrev.01/ > > Best regards, > Tobias >> On 11/20/17 12:22 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8179026 >>> http://cr.openjdk.java.net/~thartmann/8179026/webrev.00/ >>> >>> I've removed the explicit processing of -XX:CodeCacheExpansionSize, -XX:NonNMethodCodeHeapSize, -XX:ProfiledCodeHeapSize >>> and -XX:NonProfiledCodeHeapSize because generic option processing already supports memory values. I've also added a >>> lower bound of vm_page_size() to all of them except the non-profiled and the profiled size because these can be 0. The >>> actual checking is done in codeCache.cpp. >>> >>> All tests pass. >>> >>> Thanks, >>> Tobias >>> From ioi.lam at oracle.com Wed Nov 22 20:38:05 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 22 Nov 2017 12:38:05 -0800 Subject: RFR(XS): 8191653: Test failures in BootAppendTests - missing jdk.internal.vm.compiler module In-Reply-To: References: <5A15AE6E.1000004@oracle.com> <350B4F2D-8CD7-40C1-938C-F9A7317D1C59@oracle.com> <7ca98e81-13d2-fa58-4176-ba172d409966@oracle.com> Message-ID: <969574dd-8ac7-2cdf-e137-c38d6e28da64@oracle.com> Adding hotspot-compiler-dev at openjdk.java.net I am not sure if @require vm.graal is the right fix for this bug. In fact, this test has nothing to do with graal. The reason ??? --limit-modules=java.base,jdk.internal.vm.compiler was added was because of JDK-8190975 [Graal] Tests which run with "--limit-modules java.base" could fail when Graal is used as JIT ??? https://bugs.openjdk.java.net/browse/JDK-8190975 Unfortunately, JDK-8190975 leaks dependencies of jdk.internal.vm.compiler into tests unrelated to graal. I think it's better to backout JDK-8190975, and then fix the VM such that if "-Djvmci.Compiler=graal" is added in the command-line, jdk.internal.vm.compiler is automatically added to the list of available modules, regardless of any --limit-modules flag. Thanks - Ioi On 11/22/17 11:32 AM, Vladimir Kozlov wrote: > Note, we can't use vm.graal.enabled key because it is set only when > Graal is used as JIT with VM flags: > > http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l299 > > > Vladimir > > On 11/22/17 11:29 AM, Vladimir Kozlov wrote: >> On 11/22/17 10:37 AM, Ioi Lam wrote: >>> Hi Calvin, >>> >>> Instead of hard coding for Solaris, is it possible to check if the >>> VM has the graal module programmatically? >> >> Yes, it would be better. We do plan extend support of Graal >> (jdk.internal.vm.compiler) to other platforms in a future. >> >> For example, we do check presence of jaotc file for setting jtreg key >> vm.aot: >> >> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l270 >> >> >> Would be nice to add vm.graal jtreg key and use with @require. >> >> Thanks, >> Vladimir >> >>> >>> Thanks >>> Ioi >>> >>>> On Nov 22, 2017, at 9:05 AM, Calvin Cheung >>>> wrote: >>>> >>>> The jdk.internal.vm.compiler module is not available on >>>> Solaris/Sparc. A simple fix is to detect if the platform is Solaris >>>> and not adding the module to the --limit-modules option. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191653 >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8191653/webrev.00/ >>>> >>>> Tested on 64-bit platforms: linux, solaris/sparc, macosx, windows. >>>> >>>> thanks, >>>> Calvin >>> From vladimir.kozlov at oracle.com Wed Nov 22 21:01:06 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Nov 2017 13:01:06 -0800 Subject: RFR(XS): 8191653: Test failures in BootAppendTests - missing jdk.internal.vm.compiler module In-Reply-To: <969574dd-8ac7-2cdf-e137-c38d6e28da64@oracle.com> References: <5A15AE6E.1000004@oracle.com> <350B4F2D-8CD7-40C1-938C-F9A7317D1C59@oracle.com> <7ca98e81-13d2-fa58-4176-ba172d409966@oracle.com> <969574dd-8ac7-2cdf-e137-c38d6e28da64@oracle.com> Message-ID: <89d9fb75-5ed7-8995-7111-d06be67f997a@oracle.com> On 11/22/17 12:38 PM, Ioi Lam wrote: > Adding hotspot-compiler-dev at openjdk.java.net > > I am not sure if @require vm.graal is the right fix for this bug. In > fact, this test has nothing to do with graal. The reason > > ??? --limit-modules=java.base,jdk.internal.vm.compiler > > was added was because of JDK-8190975 [Graal] Tests which run with > "--limit-modules java.base" could fail when Graal is used as JIT > > ??? https://bugs.openjdk.java.net/browse/JDK-8190975 > > Unfortunately, JDK-8190975 leaks dependencies of > jdk.internal.vm.compiler into tests unrelated to graal. > > I think it's better to backout JDK-8190975, and then fix the VM such > that if "-Djvmci.Compiler=graal" is added in the command-line, > jdk.internal.vm.compiler is automatically added to the list of available > modules, regardless of any --limit-modules flag. Agree. Thanks, Vladimir > > Thanks > - Ioi > > > On 11/22/17 11:32 AM, Vladimir Kozlov wrote: >> Note, we can't use vm.graal.enabled key because it is set only when >> Graal is used as JIT with VM flags: >> >> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l299 >> >> >> Vladimir >> >> On 11/22/17 11:29 AM, Vladimir Kozlov wrote: >>> On 11/22/17 10:37 AM, Ioi Lam wrote: >>>> Hi Calvin, >>>> >>>> Instead of hard coding for Solaris, is it possible to check if the >>>> VM has the graal module programmatically? >>> >>> Yes, it would be better. We do plan extend support of Graal >>> (jdk.internal.vm.compiler) to other platforms in a future. >>> >>> For example, we do check presence of jaotc file for setting jtreg key >>> vm.aot: >>> >>> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l270 >>> >>> >>> Would be nice to add vm.graal jtreg key and use with @require. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks >>>> Ioi >>>> >>>>> On Nov 22, 2017, at 9:05 AM, Calvin Cheung >>>>> wrote: >>>>> >>>>> The jdk.internal.vm.compiler module is not available on >>>>> Solaris/Sparc. A simple fix is to detect if the platform is Solaris >>>>> and not adding the module to the --limit-modules option. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191653 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8191653/webrev.00/ >>>>> >>>>> Tested on 64-bit platforms: linux, solaris/sparc, macosx, windows. >>>>> >>>>> thanks, >>>>> Calvin >>>> > From daniel.daugherty at oracle.com Wed Nov 22 21:48:50 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 16:48:50 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> Message-ID: <06e3a59e-9225-ee56-eefe-2614e29bd8f9@oracle.com> Thanks Jerry! Dan On 11/22/17 3:21 PM, Gerald Thornbrugh wrote: > Hi Dan, > > Your changes look good. > > Jerry > >> On Nov 21, 2017, at 5:12 PM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> *** We are wrapping up code review on this project so it is time *** >> *** for the various code reviewers to chime in one last time. *** >> >> In this latest round, we had three different reviewers chime in so we're >> doing delta webrevs for each of those resolutions: >> >> David H's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ >> >> mq comment for dholmes_CR: >> - Fix indents, trailing spaces and various typos. >> - Add descriptions for the '_cnt', '_max' and '_times" fields, >> add impl notes to document the type choices. >> >> src/hotspot/share/runtime/globals.hpp change is white-space only so it >> is only visible via the file's patch link. >> >> >> Robin W's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ >> >> mq comment for robinw_CR: >> - Fix some inefficient code, update some comments, fix some indents, >> and add some 'const' specifiers. >> >> src/hotspot/share/runtime/vm_operations.hpp change is white-space only so >> it is only visible via the file's patch link. >> >> >> Coleen's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ >> >> mq comment for coleenp_CR: >> - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', >> - add header comment to threadSMR.hpp file, >> - cleanup JavaThreadIteratorWithHandle ctr, >> - make ErrorHandling more efficient. >> >> >> Some folks prefer to see all of the delta webrevs together so here is >> a delta webrev relative to jdk10-09-full: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ >> >> src/hotspot/share/runtime/globals.hpp and >> src/hotspot/share/runtime/vm_operations.hpp changes are white-space only >> so they are only visible via the file's patch link. >> >> >> And, of course, some folks prefer to see everything all at once so here >> is the latest full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ >> >> >> Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The >> prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... >> >> The project is currently baselined on Jesper's 2017-11-17 PIT snapshot >> so there will be some catching up to do before integration... >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Testing of the last round of changes revealed a hang in one of the new >>> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >>> added another TLH test for good measure. >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>> >>> Here is the updated delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>> >>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>> no unexpected failures. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Robbin rebased the project last night/this morning to merge with Thread >>>> Local Handshakes (TLH) and also picked up additional changesets up thru: >>>> >>>>> Changeset: fa736014cf28 >>>>> Author: cjplummer >>>>> Date: 2017-11-14 18:08 -0800 >>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>> >>>>> 8191049: Add alternate version of pns() that is callable from within hotspot source >>>>> Summary: added pns2() to debug.cpp >>>>> Reviewed-by: stuefe, gthornbr >>>> This is the first time we've rebased the project to bits that are this >>>> fresh (< 12 hours old at rebase time). We've done this because we think >>>> we're done with this project and are in the final review-change-retest >>>> cycle(s)... In other words, we're not planning on making any more major >>>> changes for this project... :-) >>>> >>>> *** Time for code reviewers to chime in on this thread! *** >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>> >>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>> (and the new baseline also)... >>>> >>>> We're expecting this round to be a little noisier than usual because >>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>> (Yes, we're playing chase-the-repo...) >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>> >>>>> Unlike the previous rebase, there were no changes required to the >>>>> open code to get the rebased bits to build so there is no delta >>>>> webrev. >>>>> >>>>> These bits have been run through JPRT and I've submitted the usual >>>>> Mach5 tier[1-5] test run... >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>> >>>>>> Here are the updated webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> Rebase to 2017.10.25 PIT snapshot. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>> >>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>>>> look today. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Resolving one of the code review comments (from both Stefan K and Coleen) >>>>>>> on jdk10-04-full required quite a few changes so it is being done as a >>>>>>> standalone patch and corresponding webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>>>> JavaThreadIteratorWithHandle. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>> >>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>> >>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>> >>>>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>>>> and track the work on this project: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>> >>>>>>>> Dan has noticed that the indenting is wrong in some of the code quotes >>>>>>>> in the PDF that are not present in the internal wiki. We don't have a >>>>>>>> solution for that problem yet. >>>>>>>> >>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>> >>>>>>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Daniel Daugherty >>>>>>>> Erik Osterlund >>>>>>>> Robbin Ehn >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> From calvin.cheung at oracle.com Wed Nov 22 22:47:55 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 22 Nov 2017 14:47:55 -0800 Subject: RFR(XS): 8191653: Test failures in BootAppendTests - missing jdk.internal.vm.compiler module In-Reply-To: <969574dd-8ac7-2cdf-e137-c38d6e28da64@oracle.com> References: <5A15AE6E.1000004@oracle.com> <350B4F2D-8CD7-40C1-938C-F9A7317D1C59@oracle.com> <7ca98e81-13d2-fa58-4176-ba172d409966@oracle.com> <969574dd-8ac7-2cdf-e137-c38d6e28da64@oracle.com> Message-ID: <5A15FE9B.1020304@oracle.com> On 11/22/17, 12:38 PM, Ioi Lam wrote: > Adding hotspot-compiler-dev at openjdk.java.net > > I am not sure if @require vm.graal is the right fix for this bug. In > fact, this test has nothing to do with graal. The reason > > --limit-modules=java.base,jdk.internal.vm.compiler > > was added was because of JDK-8190975 [Graal] Tests which run with > "--limit-modules java.base" could fail when Graal is used as JIT > > https://bugs.openjdk.java.net/browse/JDK-8190975 > > Unfortunately, JDK-8190975 leaks dependencies of > jdk.internal.vm.compiler into tests unrelated to graal. > > I think it's better to backout JDK-8190975, Here's an updated webrev for backing out fix for JDK-8190975: http://cr.openjdk.java.net/~ccheung/8191653/webrev.01/ Tested locally on linux-x64. Testing underway on other platforms. > and then fix the VM such that if "-Djvmci.Compiler=graal" is added in > the command-line, jdk.internal.vm.compiler is automatically added to > the list of available modules, regardless of any --limit-modules flag. I've filed the following RFE: https://bugs.openjdk.java.net/browse/JDK-8191788 thanks, Calvin > > Thanks > - Ioi > > > On 11/22/17 11:32 AM, Vladimir Kozlov wrote: >> Note, we can't use vm.graal.enabled key because it is set only when >> Graal is used as JIT with VM flags: >> >> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l299 >> >> >> Vladimir >> >> On 11/22/17 11:29 AM, Vladimir Kozlov wrote: >>> On 11/22/17 10:37 AM, Ioi Lam wrote: >>>> Hi Calvin, >>>> >>>> Instead of hard coding for Solaris, is it possible to check if the >>>> VM has the graal module programmatically? >>> >>> Yes, it would be better. We do plan extend support of Graal >>> (jdk.internal.vm.compiler) to other platforms in a future. >>> >>> For example, we do check presence of jaotc file for setting jtreg >>> key vm.aot: >>> >>> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l270 >>> >>> >>> Would be nice to add vm.graal jtreg key and use with @require. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks >>>> Ioi >>>> >>>>> On Nov 22, 2017, at 9:05 AM, Calvin Cheung >>>>> wrote: >>>>> >>>>> The jdk.internal.vm.compiler module is not available on >>>>> Solaris/Sparc. A simple fix is to detect if the platform is >>>>> Solaris and not adding the module to the --limit-modules option. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191653 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8191653/webrev.00/ >>>>> >>>>> Tested on 64-bit platforms: linux, solaris/sparc, macosx, windows. >>>>> >>>>> thanks, >>>>> Calvin >>>> > From vladimir.kozlov at oracle.com Wed Nov 22 23:01:49 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Nov 2017 15:01:49 -0800 Subject: RFR(XS): 8191653: Test failures in BootAppendTests - missing jdk.internal.vm.compiler module In-Reply-To: <5A15FE9B.1020304@oracle.com> References: <5A15AE6E.1000004@oracle.com> <350B4F2D-8CD7-40C1-938C-F9A7317D1C59@oracle.com> <7ca98e81-13d2-fa58-4176-ba172d409966@oracle.com> <969574dd-8ac7-2cdf-e137-c38d6e28da64@oracle.com> <5A15FE9B.1020304@oracle.com> Message-ID: <85f0cde7-1dc9-6b4b-77c7-249ddf06b9ee@oracle.com> On 11/22/17 2:47 PM, Calvin Cheung wrote: > > > On 11/22/17, 12:38 PM, Ioi Lam wrote: >> Adding hotspot-compiler-dev at openjdk.java.net >> >> I am not sure if @require vm.graal is the right fix for this bug. In >> fact, this test has nothing to do with graal. The reason >> >> ??? --limit-modules=java.base,jdk.internal.vm.compiler >> >> was added was because of JDK-8190975 [Graal] Tests which run with >> "--limit-modules java.base" could fail when Graal is used as JIT >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8190975 >> >> Unfortunately, JDK-8190975 leaks dependencies of >> jdk.internal.vm.compiler into tests unrelated to graal. >> >> I think it's better to backout JDK-8190975, > Here's an updated webrev for backing out fix for JDK-8190975: > ??? http://cr.openjdk.java.net/~ccheung/8191653/webrev.01/ Good. > > Tested locally on linux-x64. Testing underway on other platforms. >> and then fix the VM such that if "-Djvmci.Compiler=graal" is added in >> the command-line, jdk.internal.vm.compiler is automatically added to >> the list of available modules, regardless of any --limit-modules flag. > I've filed the following RFE: > ??? https://bugs.openjdk.java.net/browse/JDK-8191788 Thanks, Vladimir > > thanks, > Calvin >> >> Thanks >> - Ioi >> >> >> On 11/22/17 11:32 AM, Vladimir Kozlov wrote: >>> Note, we can't use vm.graal.enabled key because it is set only when >>> Graal is used as JIT with VM flags: >>> >>> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l299 >>> >>> >>> Vladimir >>> >>> On 11/22/17 11:29 AM, Vladimir Kozlov wrote: >>>> On 11/22/17 10:37 AM, Ioi Lam wrote: >>>>> Hi Calvin, >>>>> >>>>> Instead of hard coding for Solaris, is it possible to check if the >>>>> VM has the graal module programmatically? >>>> >>>> Yes, it would be better. We do plan extend support of Graal >>>> (jdk.internal.vm.compiler) to other platforms in a future. >>>> >>>> For example, we do check presence of jaotc file for setting jtreg >>>> key vm.aot: >>>> >>>> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l270 >>>> >>>> >>>> Would be nice to add vm.graal jtreg key and use with @require. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thanks >>>>> Ioi >>>>> >>>>>> On Nov 22, 2017, at 9:05 AM, Calvin Cheung >>>>>> wrote: >>>>>> >>>>>> The jdk.internal.vm.compiler module is not available on >>>>>> Solaris/Sparc. A simple fix is to detect if the platform is >>>>>> Solaris and not adding the module to the --limit-modules option. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191653 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8191653/webrev.00/ >>>>>> >>>>>> Tested on 64-bit platforms: linux, solaris/sparc, macosx, windows. >>>>>> >>>>>> thanks, >>>>>> Calvin >>>>> >> From calvin.cheung at oracle.com Wed Nov 22 23:37:53 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 22 Nov 2017 15:37:53 -0800 Subject: RFR(XS): 8191653: Test failures in BootAppendTests - missing jdk.internal.vm.compiler module In-Reply-To: <85f0cde7-1dc9-6b4b-77c7-249ddf06b9ee@oracle.com> References: <5A15AE6E.1000004@oracle.com> <350B4F2D-8CD7-40C1-938C-F9A7317D1C59@oracle.com> <7ca98e81-13d2-fa58-4176-ba172d409966@oracle.com> <969574dd-8ac7-2cdf-e137-c38d6e28da64@oracle.com> <5A15FE9B.1020304@oracle.com> <85f0cde7-1dc9-6b4b-77c7-249ddf06b9ee@oracle.com> Message-ID: <5A160A51.1030907@oracle.com> Thanks - Vladimir. Calvin On 11/22/17, 3:01 PM, Vladimir Kozlov wrote: > On 11/22/17 2:47 PM, Calvin Cheung wrote: >> >> >> On 11/22/17, 12:38 PM, Ioi Lam wrote: >>> Adding hotspot-compiler-dev at openjdk.java.net >>> >>> I am not sure if @require vm.graal is the right fix for this bug. In >>> fact, this test has nothing to do with graal. The reason >>> >>> --limit-modules=java.base,jdk.internal.vm.compiler >>> >>> was added was because of JDK-8190975 [Graal] Tests which run with >>> "--limit-modules java.base" could fail when Graal is used as JIT >>> >>> https://bugs.openjdk.java.net/browse/JDK-8190975 >>> >>> Unfortunately, JDK-8190975 leaks dependencies of >>> jdk.internal.vm.compiler into tests unrelated to graal. >>> >>> I think it's better to backout JDK-8190975, >> Here's an updated webrev for backing out fix for JDK-8190975: >> http://cr.openjdk.java.net/~ccheung/8191653/webrev.01/ > > Good. > >> >> Tested locally on linux-x64. Testing underway on other platforms. >>> and then fix the VM such that if "-Djvmci.Compiler=graal" is added >>> in the command-line, jdk.internal.vm.compiler is automatically added >>> to the list of available modules, regardless of any --limit-modules >>> flag. >> I've filed the following RFE: >> https://bugs.openjdk.java.net/browse/JDK-8191788 > > Thanks, > Vladimir > >> >> thanks, >> Calvin >>> >>> Thanks >>> - Ioi >>> >>> >>> On 11/22/17 11:32 AM, Vladimir Kozlov wrote: >>>> Note, we can't use vm.graal.enabled key because it is set only when >>>> Graal is used as JIT with VM flags: >>>> >>>> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l299 >>>> >>>> >>>> Vladimir >>>> >>>> On 11/22/17 11:29 AM, Vladimir Kozlov wrote: >>>>> On 11/22/17 10:37 AM, Ioi Lam wrote: >>>>>> Hi Calvin, >>>>>> >>>>>> Instead of hard coding for Solaris, is it possible to check if >>>>>> the VM has the graal module programmatically? >>>>> >>>>> Yes, it would be better. We do plan extend support of Graal >>>>> (jdk.internal.vm.compiler) to other platforms in a future. >>>>> >>>>> For example, we do check presence of jaotc file for setting jtreg >>>>> key vm.aot: >>>>> >>>>> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l270 >>>>> >>>>> >>>>> Would be nice to add vm.graal jtreg key and use with @require. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Thanks >>>>>> Ioi >>>>>> >>>>>>> On Nov 22, 2017, at 9:05 AM, Calvin Cheung >>>>>>> wrote: >>>>>>> >>>>>>> The jdk.internal.vm.compiler module is not available on >>>>>>> Solaris/Sparc. A simple fix is to detect if the platform is >>>>>>> Solaris and not adding the module to the --limit-modules option. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191653 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8191653/webrev.00/ >>>>>>> >>>>>>> Tested on 64-bit platforms: linux, solaris/sparc, macosx, windows. >>>>>>> >>>>>>> thanks, >>>>>>> Calvin >>>>>> >>> From ioi.lam at oracle.com Wed Nov 22 23:44:40 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 22 Nov 2017 15:44:40 -0800 Subject: RFR(XS): 8191653: Test failures in BootAppendTests - missing jdk.internal.vm.compiler module In-Reply-To: <85f0cde7-1dc9-6b4b-77c7-249ddf06b9ee@oracle.com> References: <5A15AE6E.1000004@oracle.com> <350B4F2D-8CD7-40C1-938C-F9A7317D1C59@oracle.com> <7ca98e81-13d2-fa58-4176-ba172d409966@oracle.com> <969574dd-8ac7-2cdf-e137-c38d6e28da64@oracle.com> <5A15FE9B.1020304@oracle.com> <85f0cde7-1dc9-6b4b-77c7-249ddf06b9ee@oracle.com> Message-ID: <3601DB7A-653F-4DF6-9964-40E3E40969D4@oracle.com> +1 Thanks Ioi > On Nov 22, 2017, at 3:01 PM, Vladimir Kozlov wrote: > >> On 11/22/17 2:47 PM, Calvin Cheung wrote: >>> On 11/22/17, 12:38 PM, Ioi Lam wrote: >>> Adding hotspot-compiler-dev at openjdk.java.net >>> >>> I am not sure if @require vm.graal is the right fix for this bug. In fact, this test has nothing to do with graal. The reason >>> >>> --limit-modules=java.base,jdk.internal.vm.compiler >>> >>> was added was because of JDK-8190975 [Graal] Tests which run with "--limit-modules java.base" could fail when Graal is used as JIT >>> >>> https://bugs.openjdk.java.net/browse/JDK-8190975 >>> >>> Unfortunately, JDK-8190975 leaks dependencies of jdk.internal.vm.compiler into tests unrelated to graal. >>> >>> I think it's better to backout JDK-8190975, >> Here's an updated webrev for backing out fix for JDK-8190975: >> http://cr.openjdk.java.net/~ccheung/8191653/webrev.01/ > > Good. > >> Tested locally on linux-x64. Testing underway on other platforms. >>> and then fix the VM such that if "-Djvmci.Compiler=graal" is added in the command-line, jdk.internal.vm.compiler is automatically added to the list of available modules, regardless of any --limit-modules flag. >> I've filed the following RFE: >> https://bugs.openjdk.java.net/browse/JDK-8191788 > > Thanks, > Vladimir > >> thanks, >> Calvin >>> >>> Thanks >>> - Ioi >>> >>> >>>> On 11/22/17 11:32 AM, Vladimir Kozlov wrote: >>>> Note, we can't use vm.graal.enabled key because it is set only when Graal is used as JIT with VM flags: >>>> >>>> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l299 >>>> >>>> Vladimir >>>> >>>>> On 11/22/17 11:29 AM, Vladimir Kozlov wrote: >>>>>> On 11/22/17 10:37 AM, Ioi Lam wrote: >>>>>> Hi Calvin, >>>>>> >>>>>> Instead of hard coding for Solaris, is it possible to check if the VM has the graal module programmatically? >>>>> >>>>> Yes, it would be better. We do plan extend support of Graal (jdk.internal.vm.compiler) to other platforms in a future. >>>>> >>>>> For example, we do check presence of jaotc file for setting jtreg key vm.aot: >>>>> >>>>> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l270 >>>>> >>>>> Would be nice to add vm.graal jtreg key and use with @require. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Thanks >>>>>> Ioi >>>>>> >>>>>>> On Nov 22, 2017, at 9:05 AM, Calvin Cheung wrote: >>>>>>> >>>>>>> The jdk.internal.vm.compiler module is not available on Solaris/Sparc. A simple fix is to detect if the platform is Solaris and not adding the module to the --limit-modules option. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191653 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8191653/webrev.00/ >>>>>>> >>>>>>> Tested on 64-bit platforms: linux, solaris/sparc, macosx, windows. >>>>>>> >>>>>>> thanks, >>>>>>> Calvin >>>>>> >>> From calvin.cheung at oracle.com Wed Nov 22 23:47:22 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 22 Nov 2017 15:47:22 -0800 Subject: RFR(XS): 8191653: Test failures in BootAppendTests - missing jdk.internal.vm.compiler module In-Reply-To: <3601DB7A-653F-4DF6-9964-40E3E40969D4@oracle.com> References: <5A15AE6E.1000004@oracle.com> <350B4F2D-8CD7-40C1-938C-F9A7317D1C59@oracle.com> <7ca98e81-13d2-fa58-4176-ba172d409966@oracle.com> <969574dd-8ac7-2cdf-e137-c38d6e28da64@oracle.com> <5A15FE9B.1020304@oracle.com> <85f0cde7-1dc9-6b4b-77c7-249ddf06b9ee@oracle.com> <3601DB7A-653F-4DF6-9964-40E3E40969D4@oracle.com> Message-ID: <5A160C8A.2000200@oracle.com> Thanks - Ioi. Calvin On 11/22/17, 3:44 PM, Ioi Lam wrote: > +1 > > Thanks > Ioi > >> On Nov 22, 2017, at 3:01 PM, Vladimir Kozlov wrote: >> >>> On 11/22/17 2:47 PM, Calvin Cheung wrote: >>>> On 11/22/17, 12:38 PM, Ioi Lam wrote: >>>> Adding hotspot-compiler-dev at openjdk.java.net >>>> >>>> I am not sure if @require vm.graal is the right fix for this bug. In fact, this test has nothing to do with graal. The reason >>>> >>>> --limit-modules=java.base,jdk.internal.vm.compiler >>>> >>>> was added was because of JDK-8190975 [Graal] Tests which run with "--limit-modules java.base" could fail when Graal is used as JIT >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8190975 >>>> >>>> Unfortunately, JDK-8190975 leaks dependencies of jdk.internal.vm.compiler into tests unrelated to graal. >>>> >>>> I think it's better to backout JDK-8190975, >>> Here's an updated webrev for backing out fix for JDK-8190975: >>> http://cr.openjdk.java.net/~ccheung/8191653/webrev.01/ >> Good. >> >>> Tested locally on linux-x64. Testing underway on other platforms. >>>> and then fix the VM such that if "-Djvmci.Compiler=graal" is added in the command-line, jdk.internal.vm.compiler is automatically added to the list of available modules, regardless of any --limit-modules flag. >>> I've filed the following RFE: >>> https://bugs.openjdk.java.net/browse/JDK-8191788 >> Thanks, >> Vladimir >> >>> thanks, >>> Calvin >>>> Thanks >>>> - Ioi >>>> >>>> >>>>> On 11/22/17 11:32 AM, Vladimir Kozlov wrote: >>>>> Note, we can't use vm.graal.enabled key because it is set only when Graal is used as JIT with VM flags: >>>>> >>>>> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l299 >>>>> >>>>> Vladimir >>>>> >>>>>> On 11/22/17 11:29 AM, Vladimir Kozlov wrote: >>>>>>> On 11/22/17 10:37 AM, Ioi Lam wrote: >>>>>>> Hi Calvin, >>>>>>> >>>>>>> Instead of hard coding for Solaris, is it possible to check if the VM has the graal module programmatically? >>>>>> Yes, it would be better. We do plan extend support of Graal (jdk.internal.vm.compiler) to other platforms in a future. >>>>>> >>>>>> For example, we do check presence of jaotc file for setting jtreg key vm.aot: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk10/hs/file/d85284ccd1bd/test/jtreg-ext/requires/VMProps.java#l270 >>>>>> >>>>>> Would be nice to add vm.graal jtreg key and use with @require. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> Thanks >>>>>>> Ioi >>>>>>> >>>>>>>> On Nov 22, 2017, at 9:05 AM, Calvin Cheung wrote: >>>>>>>> >>>>>>>> The jdk.internal.vm.compiler module is not available on Solaris/Sparc. A simple fix is to detect if the platform is Solaris and not adding the module to the --limit-modules option. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191653 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8191653/webrev.00/ >>>>>>>> >>>>>>>> Tested on 64-bit platforms: linux, solaris/sparc, macosx, windows. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Calvin From daniel.daugherty at oracle.com Thu Nov 23 02:16:35 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 21:16:35 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> Message-ID: <567339a6-e36a-5416-5c34-2a87cbfa6cdd@oracle.com> Greetings, I've made minor tweaks to the Thread-SMR project based on the remaining code review comments over the last couple of days. I've also rebased the project to jdk/hs bits as of mid-afternoon (my TZ) on 2017.11.22. I'm running baseline Mach5 Tier[1-5] testing and prototype Mach5 Tier[1-5] testing... Here's a delta webrev for the latest round of tweaks: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-11-delta Here's the proposed commit message: $ cat SMR_prototype_10/open/commit.txt 8167108: inconsistent handling of SR_lock can lead to crashes Summary: Add Thread Safe Memory Reclamation (Thread-SMR) mechanism. Reviewed-by: coleenp, dcubed, dholmes, eosterlund, gthornbr, kbarrett, rehn, sspitsyn, stefank Contributed-by: daniel.daugherty at oracle.com, erik.osterlund at oracle.com, robbin.ehn at oracle.com I've gone through 880+ emails in my archive for this project and added anyone that made a code review comment. Reviewers are not in my usual by-comment-posting order; it was way too hard to figure that out... So reviewers and contributors are simply in alpha-sort order... Here's the collection of follow-up bugs that I filed based on sifting through the email archive: 8191784 JavaThread::collect_counters() should stop using Threads_lock https://bugs.openjdk.java.net/browse/JDK-8191784 8191785 revoke_bias() needs a new assertion https://bugs.openjdk.java.net/browse/JDK-8191785 8191786 Thread-SMR hash table size should be dynamic https://bugs.openjdk.java.net/browse/JDK-8191786 8191787 move private inline functions from thread.inline.hpp -> thread.cpp https://bugs.openjdk.java.net/browse/JDK-8191787 8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp https://bugs.openjdk.java.net/browse/JDK-8191789 8191798 redo nested ThreadsListHandle to drop Threads_lock https://bugs.openjdk.java.net/browse/JDK-8191789 I have undoubtedly missed at least one future idea that someone had and for that my apologies... Thanks again to everyone who contributed to the Thread-SMR project!! Special thanks goes to Karen Kinnear, Kim Barrett and David Holmes for their rigorous review of the design that we documented on the wiki. Thanks for keeping us honest! I also have to thank my co-contributor Erik ?sterlund for starting the ball rolling on this crazy project with his presentation on Safe Memory Reclamation, for the initial prototype and for all your patches. Erik, hopefully we got far enough in your crazy vision... :-) Thanks to my co-contributor Robbin Ehn for proposing that we do early code reviews in the form of patches. Don't like something? Fix it with a patch and a new test if appropriate!! A pretty cool way to work that was new to me. Finally, many thanks to Jerry Thornbrugh for all the early code reviews, whiteboard chats and phone calls. Thanks for asking the right questions and pointing out some places where our logic was faulty. Also thanks for keeping me sane when I was literally on my own in Monument, CO. Dan On 11/21/17 7:12 PM, Daniel D. Daugherty wrote: > Greetings, > > *** We are wrapping up code review on this project so it is time *** > *** for the various code reviewers to chime in one last time. *** > > In this latest round, we had three different reviewers chime in so we're > doing delta webrevs for each of those resolutions: > > David H's resolutions: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ > > > ? mq comment for dholmes_CR: > ??? - Fix indents, trailing spaces and various typos. > ??? - Add descriptions for the '_cnt', '_max' and '_times" fields, > ????? add impl notes to document the type choices. > > ? src/hotspot/share/runtime/globals.hpp change is white-space only so it > ? is only visible via the file's patch link. > > > Robin W's resolutions: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ > > > ? mq comment for robinw_CR: > ??? - Fix some inefficient code, update some comments, fix some indents, > ????? and add some 'const' specifiers. > > ? src/hotspot/share/runtime/vm_operations.hpp change is white-space > only so > ? it is only visible via the file's patch link. > > > Coleen's resolutions: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ > > > ? mq comment for coleenp_CR: > ??? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', > ??? - add header comment to threadSMR.hpp file, > ??? - cleanup JavaThreadIteratorWithHandle ctr, > ??? - make ErrorHandling more efficient. > > > Some folks prefer to see all of the delta webrevs together so here is > a delta webrev relative to jdk10-09-full: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ > > > ? src/hotspot/share/runtime/globals.hpp and > ? src/hotspot/share/runtime/vm_operations.hpp changes are white-space > only > ? so they are only visible via the file's patch link. > > > And, of course, some folks prefer to see everything all at once so here > is the latest full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ > > > Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The > prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... > > The project is currently baselined on Jesper's 2017-11-17 PIT snapshot > so there will be some catching up to do before integration... > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Testing of the last round of changes revealed a hang in one of the new >> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >> added another TLH test for good measure. >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >> >> Here is the updated delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >> >> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >> no unexpected failures. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Robbin rebased the project last night/this morning to merge with Thread >>> Local Handshakes (TLH) and also picked up additional changesets up >>> thru: >>> >>>> Changeset: fa736014cf28 >>>> Author:??? cjplummer >>>> Date:????? 2017-11-14 18:08 -0800 >>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>> >>>> 8191049: Add alternate version of pns() that is callable from >>>> within hotspot source >>>> Summary: added pns2() to debug.cpp >>>> Reviewed-by: stuefe, gthornbr >>> >>> This is the first time we've rebased the project to bits that are this >>> fresh (< 12 hours old at rebase time). We've done this because we think >>> we're done with this project and are in the final review-change-retest >>> cycle(s)... In other words, we're not planning on making any more major >>> changes for this project... :-) >>> >>> *** Time for code reviewers to chime in on this thread! *** >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>> >>> Here's is the delta webrev from the 2017.11.10 rebase: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>> (and the new baseline also)... >>> >>> We're expecting this round to be a little noisier than usual because >>> we did not rebase on a PIT snapshot so the new baseline has not been >>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>> (Yes, we're playing chase-the-repo...) >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>> >>>> Unlike the previous rebase, there were no changes required to the >>>> open code to get the rebased bits to build so there is no delta >>>> webrev. >>>> >>>> These bits have been run through JPRT and I've submitted the usual >>>> Mach5 tier[1-5] test run... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>> >>>>> Here are the updated webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>> >>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>> holiday >>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>> closer >>>>> look today. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Resolving one of the code review comments (from both Stefan K and >>>>>> Coleen) >>>>>> on jdk10-04-full required quite a few changes so it is being done >>>>>> as a >>>>>> standalone patch and corresponding webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to >>>>>> use >>>>>> ??? JavaThreadIteratorWithHandle. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>> >>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>> >>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>> >>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>> describe >>>>>>> and track the work on this project: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>> >>>>>>> >>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>> quotes >>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>> have a >>>>>>> solution for that problem yet. >>>>>>> >>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>> >>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>> tier[2-5] >>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>> additional testing on Erik and Robbin's machines. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Daniel Daugherty >>>>>>> Erik Osterlund >>>>>>> Robbin Ehn >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From robbin.ehn at oracle.com Thu Nov 23 08:20:01 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 23 Nov 2017 09:20:01 +0100 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <567339a6-e36a-5416-5c34-2a87cbfa6cdd@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> <567339a6-e36a-5416-5c34-2a87cbfa6cdd@oracle.com> Message-ID: <5976a6bf-c9b0-c0d5-d5f9-fcdf7dc9a1a8@oracle.com> Thanks Dan for dragging this freight train to the docks, it's time to ship it! Created follow-up bug: 8191809: Threads::number_of_threads() is not 'MT-safe' https://bugs.openjdk.java.net/browse/JDK-8191809 /Robbin On 2017-11-23 03:16, Daniel D. Daugherty wrote: > Greetings, > > I've made minor tweaks to the Thread-SMR project based on the remaining > code review comments over the last couple of days. I've also rebased the > project to jdk/hs bits as of mid-afternoon (my TZ) on 2017.11.22. I'm > running baseline Mach5 Tier[1-5] testing and prototype Mach5 Tier[1-5] > testing... > > Here's a delta webrev for the latest round of tweaks: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-11-delta > > > Here's the proposed commit message: > > $ cat SMR_prototype_10/open/commit.txt > 8167108: inconsistent handling of SR_lock can lead to crashes > Summary: Add Thread Safe Memory Reclamation (Thread-SMR) mechanism. > Reviewed-by: coleenp, dcubed, dholmes, eosterlund, gthornbr, kbarrett, rehn, sspitsyn, stefank > Contributed-by: daniel.daugherty at oracle.com, erik.osterlund at oracle.com, robbin.ehn at oracle.com > > I've gone through 880+ emails in my archive for this project and added > anyone that made a code review comment. Reviewers are not in my usual > by-comment-posting order; it was way too hard to figure that out... So > reviewers and contributors are simply in alpha-sort order... > > Here's the collection of follow-up bugs that I filed based on sifting > through the email archive: > > 8191784 JavaThread::collect_counters() should stop using Threads_lock > https://bugs.openjdk.java.net/browse/JDK-8191784 > > 8191785 revoke_bias() needs a new assertion > https://bugs.openjdk.java.net/browse/JDK-8191785 > > 8191786 Thread-SMR hash table size should be dynamic > https://bugs.openjdk.java.net/browse/JDK-8191786 > > 8191787 move private inline functions from thread.inline.hpp -> thread.cpp > https://bugs.openjdk.java.net/browse/JDK-8191787 > > 8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp > https://bugs.openjdk.java.net/browse/JDK-8191789 > > 8191798 redo nested ThreadsListHandle to drop Threads_lock > https://bugs.openjdk.java.net/browse/JDK-8191789 > > I have undoubtedly missed at least one future idea that someone had > and for that my apologies... > > Thanks again to everyone who contributed to the Thread-SMR project!! > > Special thanks goes to Karen Kinnear, Kim Barrett and David Holmes for > their rigorous review of the design that we documented on the wiki. > Thanks for keeping us honest! > > I also have to thank my co-contributor Erik ?sterlund for starting the > ball rolling on this crazy project with his presentation on Safe Memory > Reclamation, for the initial prototype and for all your patches. Erik, > hopefully we got far enough in your crazy vision... :-) > > Thanks to my co-contributor Robbin Ehn for proposing that we do early > code reviews in the form of patches. Don't like something? Fix it with > a patch and a new test if appropriate!! A pretty cool way to work that > was new to me. > > Finally, many thanks to Jerry Thornbrugh for all the early code reviews, > whiteboard chats and phone calls. Thanks for asking the right questions > and pointing out some places where our logic was faulty. Also thanks for > keeping me sane when I was literally on my own in Monument, CO. > > Dan > > > On 11/21/17 7:12 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> *** We are wrapping up code review on this project so it is time *** >> *** for the various code reviewers to chime in one last time. *** >> >> In this latest round, we had three different reviewers chime in so we're >> doing delta webrevs for each of those resolutions: >> >> David H's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ >> >> ? mq comment for dholmes_CR: >> ??? - Fix indents, trailing spaces and various typos. >> ??? - Add descriptions for the '_cnt', '_max' and '_times" fields, >> ????? add impl notes to document the type choices. >> >> ? src/hotspot/share/runtime/globals.hpp change is white-space only so it >> ? is only visible via the file's patch link. >> >> >> Robin W's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ >> >> ? mq comment for robinw_CR: >> ??? - Fix some inefficient code, update some comments, fix some indents, >> ????? and add some 'const' specifiers. >> >> ? src/hotspot/share/runtime/vm_operations.hpp change is white-space only so >> ? it is only visible via the file's patch link. >> >> >> Coleen's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ >> >> ? mq comment for coleenp_CR: >> ??? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', >> ??? - add header comment to threadSMR.hpp file, >> ??? - cleanup JavaThreadIteratorWithHandle ctr, >> ??? - make ErrorHandling more efficient. >> >> >> Some folks prefer to see all of the delta webrevs together so here is >> a delta webrev relative to jdk10-09-full: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ >> >> ? src/hotspot/share/runtime/globals.hpp and >> ? src/hotspot/share/runtime/vm_operations.hpp changes are white-space only >> ? so they are only visible via the file's patch link. >> >> >> And, of course, some folks prefer to see everything all at once so here >> is the latest full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ >> >> >> Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The >> prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... >> >> The project is currently baselined on Jesper's 2017-11-17 PIT snapshot >> so there will be some catching up to do before integration... >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Testing of the last round of changes revealed a hang in one of the new >>> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >>> added another TLH test for good measure. >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>> >>> Here is the updated delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>> >>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>> no unexpected failures. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Robbin rebased the project last night/this morning to merge with Thread >>>> Local Handshakes (TLH) and also picked up additional changesets up thru: >>>> >>>>> Changeset: fa736014cf28 >>>>> Author:??? cjplummer >>>>> Date:????? 2017-11-14 18:08 -0800 >>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>> >>>>> 8191049: Add alternate version of pns() that is callable from within hotspot source >>>>> Summary: added pns2() to debug.cpp >>>>> Reviewed-by: stuefe, gthornbr >>>> >>>> This is the first time we've rebased the project to bits that are this >>>> fresh (< 12 hours old at rebase time). We've done this because we think >>>> we're done with this project and are in the final review-change-retest >>>> cycle(s)... In other words, we're not planning on making any more major >>>> changes for this project... :-) >>>> >>>> *** Time for code reviewers to chime in on this thread! *** >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>> >>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>> (and the new baseline also)... >>>> >>>> We're expecting this round to be a little noisier than usual because >>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>> (Yes, we're playing chase-the-repo...) >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>> >>>>> Unlike the previous rebase, there were no changes required to the >>>>> open code to get the rebased bits to build so there is no delta >>>>> webrev. >>>>> >>>>> These bits have been run through JPRT and I've submitted the usual >>>>> Mach5 tier[1-5] test run... >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>> >>>>>> Here are the updated webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>> >>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>>>> look today. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Resolving one of the code review comments (from both Stefan K and Coleen) >>>>>>> on jdk10-04-full required quite a few changes so it is being done as a >>>>>>> standalone patch and corresponding webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>> >>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>> >>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>> >>>>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>>>> and track the work on this project: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>> >>>>>>>> Dan has noticed that the indenting is wrong in some of the code quotes >>>>>>>> in the PDF that are not present in the internal wiki. We don't have a >>>>>>>> solution for that problem yet. >>>>>>>> >>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>> >>>>>>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Daniel Daugherty >>>>>>>> Erik Osterlund >>>>>>>> Robbin Ehn >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > From rahul.v.raghavan at oracle.com Thu Nov 23 08:56:37 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 23 Nov 2017 14:26:37 +0530 Subject: [10] RFR: 8191227: issues with unsafe handle resolution Message-ID: <2bebdde2-b579-3049-4610-4e3949c88d01@oracle.com> Hi, Please review the following fix proposal. webrev - http://cr.openjdk.java.net/~rraghavan/8191227/webrev.02/ Please check jbs comments - jbs - https://bugs.openjdk.java.net/browse/JDK-8191227 - related - https://bugs.openjdk.java.net/browse/JDK-8160166 Fix tried - -- ConstantOopWriteValue::write_on() Used ThreadInVMfromUnknown and added required comment. -- ConstantOopWriteValue::print_on() found no issue in testing with usage of ThreadInVMfromNative here. -- LIR_Assembler::jobject2reg() Similarly used ThreadInVMfromNative, before the assert. No new issues with testing - tier1, tier2, tier3, compiler pre-checkin and also jprt (-testset hotspot). Thanks, Rahul From nils.eliasson at oracle.com Thu Nov 23 09:36:16 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 23 Nov 2017 10:36:16 +0100 Subject: RFR(XS) 8191688: Assert failed in > 200 tests: failed dependencies, but counter didn't change In-Reply-To: <51c5c857-9cdc-fc90-9bf3-eb48efe6edfc@oracle.com> References: <9270bb34-71b6-b737-f5d3-62b7dbc82fa1@oracle.com> <51c5c857-9cdc-fc90-9bf3-eb48efe6edfc@oracle.com> Message-ID: <50ca06de-3378-58ac-9dc6-e918c7aee25f@oracle.com> On 2017-11-22 20:14, dean.long at oracle.com wrote: > On 11/22/17 4:13 AM, Vladimir Ivanov wrote: > >>> https://bugs.openjdk.java.net/browse/JDK-8191688 >>> http://cr.openjdk.java.net/~dlong/8191688/webrev/ >> >> The fix looks good. >> > > Thanks Vladimir. I already pushed it, so I wasn't able to add you as > a reviewer. > >> An observation not related to the bug: >> >> + if (env->jvmti_can_hotswap_or_post_breakpoint()) { >> // 6328518 check hotswap conditions under the right lock. >> MutexLocker locker(Compile_lock); >> if (Dependencies::check_evol_method(h_m()) != NULL) { >> _is_c1_compilable = false; >> _is_c2_compilable = false; >> + _can_be_parsed = false; >> } >> } else { >> >> Klass* Dependencies::check_evol_method(Method* m) { >> ... >> if (m->is_old() >> || m->number_of_breakpoints() > 0) { >> return m->method_holder(); >> >> It seems once there's a breakpoint set in a method, it will never be >> compiled again. (I looked in the code couldn't find where >> _is_c1_compilable/_is_c2_compilable are reset once all breakpoints >> are cleared). If that's the case, it has severe performance >> consequences, so better to fix it. >> > > The ciMethod only lasts for the lifetime of the compiler task, right? Vladmir is right, it will never be compiled again. _is_c*_compilable is never reset. A core problem is that _is_c*_compilable was overloaded with at least three different meanings: 1) Have a breakpoint 2) Have had too many failures compiling 3) Have been excluded for compilation by compile command. (And before my fix it was also used for not inlining anything that was specified by 3, but only after the first compilation attempt. Not at all surprising.) At these three have different effects - (1) and (2) should exclude compilation and inlining, (3) only compilation. (1) and (3) should be resettable. (1) applies to all compilation levels, (2) and (3) is per level. After Deans change 1 is split out into can_be_parsed. That is good, but I think the field name should be changed to reflect the reason. The effect are clear from the accessor methods (can_be_parsed(), can_be_compiled(), should_inline()) that contains easy to read list of reasons. Regards, Nils > >> Also, some nitpicking follows: >> >> + bool _can_be_parsed; >> >> + bool can_be_parsed() const { return _can_be_parsed; } >> >> The name confuses me. I'd presume it signals there are some problems >> with parsing the method, so don't even try. It seems the choice was >> affected by InlineTree::check_can_parse(), but the latter looks >> justified: >> >> const char* InlineTree::check_can_parse(ciMethod* callee) { >> // Certain methods cannot be parsed at all: >> if ( callee->is_native()) return "native method"; >> if ( callee->is_abstract()) return "abstract >> method"; >> if (!callee->has_balanced_monitors()) return "not >> compilable (unbalanced monitors)"; >> if ( callee->get_flow_analysis()->failing()) return "not >> compilable (flow analysis failed)"; >> >> Why doesn't it stress it's all about inlining? E.g., >> ciMethod::can_be_inlined looks more descriptive in that context. >> > > The way things are now, "can be parsed" seems to mean "can be compiled > or inlined". If there was a way to say a method can be compiled but > not inlined, then I agree can_be_inlined would make sense. > > dl > >> Best regards, >> Vladimir Ivanov > From stuart.monteith at linaro.org Thu Nov 23 09:44:35 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 23 Nov 2017 09:44:35 +0000 Subject: RFR (XS): AARCH64 - Fix hint instructions encoding In-Reply-To: <7417388c-48e8-c051-39b9-e4269509609e@bell-sw.com> References: <7417388c-48e8-c051-39b9-e4269509609e@bell-sw.com> Message-ID: Hi, That looks correct for the ranges you are using (0 to 5). BR, Stuart On 22 November 2017 at 16:08, Dmitry Chuyko wrote: > Hello, > > Please review a small fix for aarch64 assembler. In hint(imm) imm is now > encoded as op2. I also added known hints under their names from spec. > > rfe: https://bugs.openjdk.java.net/browse/JDK-8191769 > webrev: http://cr.openjdk.java.net/~dchuyko/8191769/webrev.00/ > > -Dmitry > From vladimir.x.ivanov at oracle.com Thu Nov 23 11:49:05 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 23 Nov 2017 14:49:05 +0300 Subject: [10] RFR: 8191227: issues with unsafe handle resolution In-Reply-To: <2bebdde2-b579-3049-4610-4e3949c88d01@oracle.com> References: <2bebdde2-b579-3049-4610-4e3949c88d01@oracle.com> Message-ID: > webrev - http://cr.openjdk.java.net/~rraghavan/8191227/webrev.02/ Please, use ThreadInVMfromUnknown in ConstantOopWriteValue::print_on() as well. Otherwise, looks good. Best regards, Vladimir Ivanov > > > Please check jbs comments - > jbs - https://bugs.openjdk.java.net/browse/JDK-8191227 > ??? - related - https://bugs.openjdk.java.net/browse/JDK-8160166 > > Fix tried - > -- ConstantOopWriteValue::write_on() > ??? Used ThreadInVMfromUnknown and added required comment. > -- ConstantOopWriteValue::print_on() > ??? found no issue in testing with usage of ThreadInVMfromNative here. > -- LIR_Assembler::jobject2reg() > ??? Similarly used ThreadInVMfromNative, before the assert. > > No new issues with testing - tier1, tier2, tier3, compiler pre-checkin > ?and also jprt (-testset hotspot). > > > Thanks, > Rahul From daniel.daugherty at oracle.com Thu Nov 23 13:31:30 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 23 Nov 2017 08:31:30 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5976a6bf-c9b0-c0d5-d5f9-fcdf7dc9a1a8@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> <567339a6-e36a-5416-5c34-2a87cbfa6cdd@oracle.com> <5976a6bf-c9b0-c0d5-d5f9-fcdf7dc9a1a8@oracle.com> Message-ID: <28edcbec-4e10-6c3c-df46-5dba25a93c58@oracle.com> On 11/23/17 3:20 AM, Robbin Ehn wrote: > Thanks Dan for dragging this freight train to the docks, it's time to > ship it! Working on that very thing today... will likely push late today (my TZ)... > Created follow-up bug: > 8191809: Threads::number_of_threads() is not 'MT-safe' > https://bugs.openjdk.java.net/browse/JDK-8191809 Nice follow-up! Thanks for filing it. Dan > > /Robbin > > On 2017-11-23 03:16, Daniel D. Daugherty wrote: >> Greetings, >> >> I've made minor tweaks to the Thread-SMR project based on the remaining >> code review comments over the last couple of days. I've also rebased the >> project to jdk/hs bits as of mid-afternoon (my TZ) on 2017.11.22. I'm >> running baseline Mach5 Tier[1-5] testing and prototype Mach5 Tier[1-5] >> testing... >> >> Here's a delta webrev for the latest round of tweaks: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-11-delta >> >> >> Here's the proposed commit message: >> >> $ cat SMR_prototype_10/open/commit.txt >> 8167108: inconsistent handling of SR_lock can lead to crashes >> Summary: Add Thread Safe Memory Reclamation (Thread-SMR) mechanism. >> Reviewed-by: coleenp, dcubed, dholmes, eosterlund, gthornbr, >> kbarrett, rehn, sspitsyn, stefank >> Contributed-by: daniel.daugherty at oracle.com, >> erik.osterlund at oracle.com, robbin.ehn at oracle.com >> >> I've gone through 880+ emails in my archive for this project and added >> anyone that made a code review comment. Reviewers are not in my usual >> by-comment-posting order; it was way too hard to figure that out... So >> reviewers and contributors are simply in alpha-sort order... >> >> Here's the collection of follow-up bugs that I filed based on sifting >> through the email archive: >> >> 8191784 JavaThread::collect_counters() should stop using Threads_lock >> https://bugs.openjdk.java.net/browse/JDK-8191784 >> >> 8191785 revoke_bias() needs a new assertion >> https://bugs.openjdk.java.net/browse/JDK-8191785 >> >> 8191786 Thread-SMR hash table size should be dynamic >> https://bugs.openjdk.java.net/browse/JDK-8191786 >> >> 8191787 move private inline functions from thread.inline.hpp -> >> thread.cpp >> https://bugs.openjdk.java.net/browse/JDK-8191787 >> >> 8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> >> threadSMR.[ch]pp >> https://bugs.openjdk.java.net/browse/JDK-8191789 >> >> 8191798 redo nested ThreadsListHandle to drop Threads_lock >> https://bugs.openjdk.java.net/browse/JDK-8191789 >> >> I have undoubtedly missed at least one future idea that someone had >> and for that my apologies... >> >> Thanks again to everyone who contributed to the Thread-SMR project!! >> >> Special thanks goes to Karen Kinnear, Kim Barrett and David Holmes for >> their rigorous review of the design that we documented on the wiki. >> Thanks for keeping us honest! >> >> I also have to thank my co-contributor Erik ?sterlund for starting the >> ball rolling on this crazy project with his presentation on Safe Memory >> Reclamation, for the initial prototype and for all your patches. Erik, >> hopefully we got far enough in your crazy vision... :-) >> >> Thanks to my co-contributor Robbin Ehn for proposing that we do early >> code reviews in the form of patches. Don't like something? Fix it with >> a patch and a new test if appropriate!! A pretty cool way to work that >> was new to me. >> >> Finally, many thanks to Jerry Thornbrugh for all the early code reviews, >> whiteboard chats and phone calls. Thanks for asking the right questions >> and pointing out some places where our logic was faulty. Also thanks for >> keeping me sane when I was literally on my own in Monument, CO. >> >> Dan >> >> >> On 11/21/17 7:12 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> *** We are wrapping up code review on this project so it is time *** >>> *** for the various code reviewers to chime in one last time. *** >>> >>> In this latest round, we had three different reviewers chime in so >>> we're >>> doing delta webrevs for each of those resolutions: >>> >>> David H's resolutions: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ >>> >>> >>> ? mq comment for dholmes_CR: >>> ??? - Fix indents, trailing spaces and various typos. >>> ??? - Add descriptions for the '_cnt', '_max' and '_times" fields, >>> ????? add impl notes to document the type choices. >>> >>> ? src/hotspot/share/runtime/globals.hpp change is white-space only >>> so it >>> ? is only visible via the file's patch link. >>> >>> >>> Robin W's resolutions: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ >>> >>> >>> ? mq comment for robinw_CR: >>> ??? - Fix some inefficient code, update some comments, fix some >>> indents, >>> ????? and add some 'const' specifiers. >>> >>> ? src/hotspot/share/runtime/vm_operations.hpp change is white-space >>> only so >>> ? it is only visible via the file's patch link. >>> >>> >>> Coleen's resolutions: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ >>> >>> >>> ? mq comment for coleenp_CR: >>> ??? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', >>> ??? - add header comment to threadSMR.hpp file, >>> ??? - cleanup JavaThreadIteratorWithHandle ctr, >>> ??? - make ErrorHandling more efficient. >>> >>> >>> Some folks prefer to see all of the delta webrevs together so here is >>> a delta webrev relative to jdk10-09-full: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ >>> >>> >>> ? src/hotspot/share/runtime/globals.hpp and >>> ? src/hotspot/share/runtime/vm_operations.hpp changes are >>> white-space only >>> ? so they are only visible via the file's patch link. >>> >>> >>> And, of course, some folks prefer to see everything all at once so here >>> is the latest full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ >>> >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The >>> prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... >>> >>> The project is currently baselined on Jesper's 2017-11-17 PIT snapshot >>> so there will be some catching up to do before integration... >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Testing of the last round of changes revealed a hang in one of the new >>>> TLH tests. Robbin has fixed the hang, updated the existing TLH >>>> test, and >>>> added another TLH test for good measure. >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>> >>>> Here is the updated delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>>> >>>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>>> no unexpected failures. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Robbin rebased the project last night/this morning to merge with >>>>> Thread >>>>> Local Handshakes (TLH) and also picked up additional changesets up >>>>> thru: >>>>> >>>>>> Changeset: fa736014cf28 >>>>>> Author:??? cjplummer >>>>>> Date:????? 2017-11-14 18:08 -0800 >>>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>>> >>>>>> 8191049: Add alternate version of pns() that is callable from >>>>>> within hotspot source >>>>>> Summary: added pns2() to debug.cpp >>>>>> Reviewed-by: stuefe, gthornbr >>>>> >>>>> This is the first time we've rebased the project to bits that are >>>>> this >>>>> fresh (< 12 hours old at rebase time). We've done this because we >>>>> think >>>>> we're done with this project and are in the final >>>>> review-change-retest >>>>> cycle(s)... In other words, we're not planning on making any more >>>>> major >>>>> changes for this project... :-) >>>>> >>>>> *** Time for code reviewers to chime in on this thread! *** >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>>> >>>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>>> >>>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>>> (and the new baseline also)... >>>>> >>>>> We're expecting this round to be a little noisier than usual because >>>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>>> (Yes, we're playing chase-the-repo...) >>>>>> >>>>>> Here is the updated full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>>> >>>>>> Unlike the previous rebase, there were no changes required to the >>>>>> open code to get the rebased bits to build so there is no delta >>>>>> webrev. >>>>>> >>>>>> These bits have been run through JPRT and I've submitted the usual >>>>>> Mach5 tier[1-5] test run... >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>>> >>>>>>> Here are the updated webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>>> >>>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>>> holiday >>>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>>> closer >>>>>>> look today. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>>> and Coleen) >>>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>>> done as a >>>>>>>> standalone patch and corresponding webrevs: >>>>>>>> >>>>>>>> Here's the mq comment for the change: >>>>>>>> >>>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>>> to use >>>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>>> >>>>>>>> Here is the full webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>>> >>>>>>>> And here is the delta webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Dan, Erik and Robbin >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>>> >>>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>>> >>>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>>> >>>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>>> describe >>>>>>>>> and track the work on this project: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>>> >>>>>>>>> >>>>>>>>> Dan has noticed that the indenting is wrong in some of the >>>>>>>>> code quotes >>>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>>> have a >>>>>>>>> solution for that problem yet. >>>>>>>>> >>>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>>> >>>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>>> tier[2-5] >>>>>>>>> testing, additional stress testing on Dan's Solaris X64 >>>>>>>>> server, and >>>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>>> >>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>> >>>>>>>>> Daniel Daugherty >>>>>>>>> Erik Osterlund >>>>>>>>> Robbin Ehn >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> From rwestrel at redhat.com Thu Nov 23 14:18:28 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 23 Nov 2017 15:18:28 +0100 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> Message-ID: Hi Vladimir, > I am running testing again. But if this will repeat and presence of this > Sparse.small regression suggesting to me that may be we should keep this > optimization off by default - keep UseCountedLoopSafepoints false. > > We may switch it on later with additional changes which address regressions. > > What do you think? If the inner loop runs for a small number of iterations and the compiler can't statically prove it, I don't see a way to remove the overhead of loop strip mining entirely. So I'm not optimistic the regression can be fixed. If loop strip mining defaults to false, would there we be any regular testing on your side? It seems to me that it would make sense to enable loop strip mining depending on what GC is used: it makes little sense for parallel gc but we'll want it enabled for Shenandoah for instance. Where does G1 fit? I can't really say and I don't have a strong opinion. But as I understand, G1 was made default under the assumption that users would be ok trading throughput for better latency. Maybe, that same reasoning applies to loop strip mining? Roland. From jamsheed.c.m at oracle.com Thu Nov 23 14:32:26 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Thu, 23 Nov 2017 20:02:26 +0530 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function In-Reply-To: References: Message-ID: <17cc5a02-449b-d52a-06e4-1f762b2a6d09@oracle.com> Hi Dmitry, Looks good, thank you for making changes. Best regards, Jamsheed On Wednesday 22 November 2017 08:28 PM, Dmitry Chuyko wrote: > Hello, > > Please review a fix for JNI Critical test failures and crashes on > aarch64, it includes common tests changes. > > bug: https://bugs.openjdk.java.net/browse/JDK-8191129 > webrev: http://cr.openjdk.java.net/~dchuyko/8191129/webrev.00/ > > 1. Platform specific part > > Original fix from JDK-8167409 was imported, it makes failures more > deterministic: Unimplemented() or ShouldNotReachHere(). Implementation > of the feature is not complete so another change is to forcibly set > CriticalJNINatives to false during initialization. > > 2. Common part (tests) > > Tests in criticalnatives read CriticalJNINatives flag using WhiteBox > and ignore values check if the flag is false. > > Both tests pass on x86_64 and aarch64. > > -Dmitry > From thomas.schatzl at oracle.com Thu Nov 23 15:20:19 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 23 Nov 2017 16:20:19 +0100 Subject: Low-Overhead Heap Profiling In-Reply-To: References: <1497366226.2829.109.camel@oracle.com> <1498215147.2741.34.camel@oracle.com> <044f8c75-72f3-79fd-af47-7ee875c071fd@oracle.com> <23f4e6f5-c94e-01f7-ef1d-5e328d4823c8@oracle.com> <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> <1510146425.3155.11.camel@oracle.com> Message-ID: <1511450419.2477.24.camel@oracle.com> On Tue, 2017-11-21 at 13:50 -0800, JC Beyler wrote: > Hi all, > > I have a new webrev here: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.15/ > > With the incremental one here: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a_15/ > > I think I did most items from Thomans and Robbin. I've especially > added a new test: Thanks. Looks good. Thanks, Thomas From nils.eliasson at oracle.com Thu Nov 23 21:59:48 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 23 Nov 2017 22:59:48 +0100 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> Message-ID: Hi, On 2017-11-23 15:18, Roland Westrelin wrote: > Hi Vladimir, > >> I am running testing again. But if this will repeat and presence of this >> Sparse.small regression suggesting to me that may be we should keep this >> optimization off by default - keep UseCountedLoopSafepoints false. >> >> We may switch it on later with additional changes which address regressions. >> >> What do you think? > If the inner loop runs for a small number of iterations and the compiler > can't statically prove it, I don't see a way to remove the overhead of > loop strip mining entirely. So I'm not optimistic the regression can be > fixed. Agreed. In other words: Loop strip mining adds a guarantee that time-to-safepoint won't be too long, and that has a small cost The current situation is that we have some extra performance with UseCountedLoopSafepoints default off, but let some users have a bad experience when they encounter long time-to-safepoint times or failures (https://bugs.openjdk.java.net/browse/JDK-5014723). I rather turn the table and have loop strip mining on, and let the power users experiment with turning it off for any uncertain performance boost. > If loop strip mining defaults to false, would there we be any regular > testing on your side? We would have to add some. > > It seems to me that it would make sense to enable loop strip mining > depending on what GC is used: it makes little sense for parallel gc but > we'll want it enabled for Shenandoah for instance. Where does G1 fit? I > can't really say and I don't have a strong opinion. But as I understand, > G1 was made default under the assumption that users would be ok trading > throughput for better latency. Maybe, that same reasoning applies to > loop strip mining? Scimark.sparse.small show a regression, but having long time-to-safepoint has a throughput cost in some settings like the companion benchmark scimark.sparse.large. Numbers using G1: -XX:-UseCountedLoopSafepoints (default) ~86 ops/m -XX:+UseCountedLoopSafepoints ~106 ops/m -XX:+UseCountedLoopSafepoints -XX:LoopStripMiningIter=1000 ~111 ops/m I would prefer having it on by default, at least in G1. Let's ask the G1 GC-team on their opinion. // Nils > > Roland. From aph at redhat.com Fri Nov 24 08:38:14 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Nov 2017 08:38:14 +0000 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> Message-ID: <7b3451be-ca02-d2b5-c097-93386192df93@redhat.com> On 23/11/17 21:59, Nils Eliasson wrote: > The current situation is that we have some extra performance with > UseCountedLoopSafepoints default off, but let some users have a bad > experience when they encounter long time-to-safepoint times or failures > (https://bugs.openjdk.java.net/browse/JDK-5014723). I rather turn the > table and have loop strip mining on, and let the power users experiment > with turning it off for any uncertain performance boost. That just sounds sensible to me, and very Java: we default to a reasonable balance of throughput and predictability. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.schatzl at oracle.com Fri Nov 24 09:22:23 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 24 Nov 2017 10:22:23 +0100 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> Message-ID: <1511515343.2425.11.camel@oracle.com> Hi Nils, On Thu, 2017-11-23 at 22:59 +0100, Nils Eliasson wrote: > Hi, > > > On 2017-11-23 15:18, Roland Westrelin wrote: > > Hi Vladimir, > > > > > I am running testing again. But if this will repeat and presence > > > of this Sparse.small regression suggesting to me that may be we > > > should keep this optimization off by default - keep > > > UseCountedLoopSafepoints false. > > > > > > We may switch it on later with additional changes which address > > > regressions. > > > > > > What do you think? > > > > If the inner loop runs for a small number of iterations and the > > compiler can't statically prove it, I don't see a way to remove the > > overhead of loop strip mining entirely. So I'm not optimistic the > > regression can be fixed. > > Agreed. In other words: Loop strip mining adds a guarantee that > time-to-safepoint won't be too long, and that has a small cost > > The current situation is that we have some extra performance with > UseCountedLoopSafepoints default off, but let some users have a bad > experience when they encounter long time-to-safepoint times or > failures (https://bugs.openjdk.java.net/browse/JDK-5014723). I rather > turn the table and have loop strip mining on, and let the power users > experiment with turning it off for any uncertain performance boost. > > > If loop strip mining defaults to false, would there we be any > > regular testing on your side? > > We would have to add some. > > > > It seems to me that it would make sense to enable loop strip mining > > depending on what GC is used: it makes little sense for parallel gc > > but we'll want it enabled for Shenandoah for instance. Where does > > G1 fit? I can't really say and I don't have a strong opinion. But > > as I understand, G1 was made default under the assumption that > > users would be ok trading throughput for better latency. Maybe, > > that same reasoning applies to loop strip mining? > > Scimark.sparse.small show a regression, but having long > time-to-safepoint has a throughput cost in some settings like the > companion benchmark scimark.sparse.large. Numbers using G1: > > -XX:-UseCountedLoopSafepoints (default) ~86 ops/m > -XX:+UseCountedLoopSafepoints ~106 ops/m > -XX:+UseCountedLoopSafepoints -XX:LoopStripMiningIter=1000 ~111 ops/m > > I would prefer having it on by default, at least in G1. Let's ask the > G1 GC-team on their opinion. our perf team uses -XX:+UseCountedLoopSafepoints for _all_ collectors for some time now. When asked, they replied that predictability of results is very important for them too. We also closed out some perf regressions (e.g. JDK-8177704) due to the problems with -XX:-UseCountedLoopSafepoints after you posted these results in agreement with the perf team. So I am all for making it default for G1 (and I am sure others agree), if not for all GCs. However I recommend having a separate CR for changing the defaults. Makes it easier reverting it in case things go wrong. Thanks, Thomas From rahul.v.raghavan at oracle.com Fri Nov 24 11:16:23 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Fri, 24 Nov 2017 16:46:23 +0530 Subject: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1 Message-ID: Hi, Please review the following fix proposal for 8191813. webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/ jbs - https://bugs.openjdk.java.net/browse/JDK-8191813 -- reported issue - After the latest sync from jdk/jdk the test SpreadNullArg started to fail in tier1 on all platforms. -- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix. jbs - https://bugs.openjdk.java.net/browse/JDK-8157246. 'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to specify invocation-time behavior'. changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34 - So now with 8157246 fix, if method handle is invoked with a null array reference, NullPointerException will be thrown. (Not IllegalArgumentException) - So above fix proposal in SpreadNullArg.java to expect NullPointerException after 8157246 changes. Thanks, Rahul From daniel.daugherty at oracle.com Fri Nov 24 15:26:08 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 24 Nov 2017 10:26:08 -0500 Subject: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1 In-Reply-To: References: Message-ID: <752a4e80-9141-6115-dee6-2bbd0ec99e92@oracle.com> On 11/24/17 6:16 AM, Rahul Raghavan wrote: > Hi, > > Please review the following fix proposal for 8191813. > > webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/ test/hotspot/jtreg/compiler/runtime/SpreadNullArg.java ??? No comments. So this style of call: ??? mh_spreadInvoker.invokeExact(mh_spread_target, (Object[]) null); was changed from throwing IllegalArgumentException due to the "null" parameter to throwing NullPointerException. You've updated the test cleanly to switch from one exception to the other. Thumbs up! I believe this patch qualifies as trivial and does not need to wait for 24 hours. I leave it up to you whether you wait for a Compiler team member review also. Dan > > > jbs - https://bugs.openjdk.java.net/browse/JDK-8191813 > > -- reported issue - After the latest sync from jdk/jdk the test > SpreadNullArg started to fail in tier1 on all platforms. > > -- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix. > jbs - https://bugs.openjdk.java.net/browse/JDK-8157246. > 'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to > specify invocation-time behavior'. > changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34 > > - So now with 8157246 fix, if method handle is invoked with a null > array reference, NullPointerException will be thrown. (Not > IllegalArgumentException) > > - So above fix proposal in SpreadNullArg.java to expect > NullPointerException after 8157246 changes. > > > Thanks, > Rahul From mandy.chung at oracle.com Fri Nov 24 17:41:34 2017 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 24 Nov 2017 09:41:34 -0800 Subject: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1 In-Reply-To: References: Message-ID: <792dadfc-89d3-054c-d3f2-303a69346be6@oracle.com> Looks good.? Thanks for fixing the test, Rahul. Mandy On 11/24/17 3:16 AM, Rahul Raghavan wrote: > Hi, > > Please review the following fix proposal for 8191813. > > webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/ > > > jbs - https://bugs.openjdk.java.net/browse/JDK-8191813 > > -- reported issue - After the latest sync from jdk/jdk the test > SpreadNullArg started to fail in tier1 on all platforms. > > -- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix. > jbs - https://bugs.openjdk.java.net/browse/JDK-8157246. > 'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to > specify invocation-time behavior'. > changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34 > > - So now with 8157246 fix, if method handle is invoked with a null > array reference, NullPointerException will be thrown. (Not > IllegalArgumentException) > > - So above fix proposal in SpreadNullArg.java to expect > NullPointerException after 8157246 changes. > > > Thanks, > Rahul -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Nov 24 18:13:20 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 24 Nov 2017 13:13:20 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <567339a6-e36a-5416-5c34-2a87cbfa6cdd@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> <567339a6-e36a-5416-5c34-2a87cbfa6cdd@oracle.com> Message-ID: Greetings, The Thread-SMR bits were pushed to jdk/hs late last night! Mach5 Tier[1-5] on the exact bits that were pushed showed no unexpected failures. I've looked at the jdk/hs CI pipeline test results for my push and for the push before and after mine and I don't see anything that worries me there either. Obviously I'll be keeping an eye on testing for the next several days, but so far everything looks good!! Dan On 11/22/17 9:16 PM, Daniel D. Daugherty wrote: > Greetings, > > I've made minor tweaks to the Thread-SMR project based on the remaining > code review comments over the last couple of days. I've also rebased the > project to jdk/hs bits as of mid-afternoon (my TZ) on 2017.11.22. I'm > running baseline Mach5 Tier[1-5] testing and prototype Mach5 Tier[1-5] > testing... > > Here's a delta webrev for the latest round of tweaks: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-11-delta > > > Here's the proposed commit message: > > $ cat SMR_prototype_10/open/commit.txt > 8167108: inconsistent handling of SR_lock can lead to crashes > Summary: Add Thread Safe Memory Reclamation (Thread-SMR) mechanism. > Reviewed-by: coleenp, dcubed, dholmes, eosterlund, gthornbr, kbarrett, > rehn, sspitsyn, stefank > Contributed-by: daniel.daugherty at oracle.com, > erik.osterlund at oracle.com, robbin.ehn at oracle.com > > I've gone through 880+ emails in my archive for this project and added > anyone that made a code review comment. Reviewers are not in my usual > by-comment-posting order; it was way too hard to figure that out... So > reviewers and contributors are simply in alpha-sort order... > > Here's the collection of follow-up bugs that I filed based on sifting > through the email archive: > > 8191784 JavaThread::collect_counters() should stop using Threads_lock > https://bugs.openjdk.java.net/browse/JDK-8191784 > > 8191785 revoke_bias() needs a new assertion > https://bugs.openjdk.java.net/browse/JDK-8191785 > > 8191786 Thread-SMR hash table size should be dynamic > https://bugs.openjdk.java.net/browse/JDK-8191786 > > 8191787 move private inline functions from thread.inline.hpp -> > thread.cpp > https://bugs.openjdk.java.net/browse/JDK-8191787 > > 8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> > threadSMR.[ch]pp > https://bugs.openjdk.java.net/browse/JDK-8191789 > > 8191798 redo nested ThreadsListHandle to drop Threads_lock > https://bugs.openjdk.java.net/browse/JDK-8191789 > > I have undoubtedly missed at least one future idea that someone had > and for that my apologies... > > Thanks again to everyone who contributed to the Thread-SMR project!! > > Special thanks goes to Karen Kinnear, Kim Barrett and David Holmes for > their rigorous review of the design that we documented on the wiki. > Thanks for keeping us honest! > > I also have to thank my co-contributor Erik ?sterlund for starting the > ball rolling on this crazy project with his presentation on Safe Memory > Reclamation, for the initial prototype and for all your patches. Erik, > hopefully we got far enough in your crazy vision... :-) > > Thanks to my co-contributor Robbin Ehn for proposing that we do early > code reviews in the form of patches. Don't like something? Fix it with > a patch and a new test if appropriate!! A pretty cool way to work that > was new to me. > > Finally, many thanks to Jerry Thornbrugh for all the early code reviews, > whiteboard chats and phone calls. Thanks for asking the right questions > and pointing out some places where our logic was faulty. Also thanks for > keeping me sane when I was literally on my own in Monument, CO. > > Dan > > > On 11/21/17 7:12 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> *** We are wrapping up code review on this project so it is time *** >> *** for the various code reviewers to chime in one last time. *** >> >> In this latest round, we had three different reviewers chime in so we're >> doing delta webrevs for each of those resolutions: >> >> David H's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ >> >> >> ? mq comment for dholmes_CR: >> ??? - Fix indents, trailing spaces and various typos. >> ??? - Add descriptions for the '_cnt', '_max' and '_times" fields, >> ????? add impl notes to document the type choices. >> >> ? src/hotspot/share/runtime/globals.hpp change is white-space only so it >> ? is only visible via the file's patch link. >> >> >> Robin W's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ >> >> >> ? mq comment for robinw_CR: >> ??? - Fix some inefficient code, update some comments, fix some indents, >> ????? and add some 'const' specifiers. >> >> ? src/hotspot/share/runtime/vm_operations.hpp change is white-space >> only so >> ? it is only visible via the file's patch link. >> >> >> Coleen's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ >> >> >> ? mq comment for coleenp_CR: >> ??? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', >> ??? - add header comment to threadSMR.hpp file, >> ??? - cleanup JavaThreadIteratorWithHandle ctr, >> ??? - make ErrorHandling more efficient. >> >> >> Some folks prefer to see all of the delta webrevs together so here is >> a delta webrev relative to jdk10-09-full: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ >> >> >> ? src/hotspot/share/runtime/globals.hpp and >> ? src/hotspot/share/runtime/vm_operations.hpp changes are white-space >> only >> ? so they are only visible via the file's patch link. >> >> >> And, of course, some folks prefer to see everything all at once so here >> is the latest full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ >> >> >> Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The >> prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... >> >> The project is currently baselined on Jesper's 2017-11-17 PIT snapshot >> so there will be some catching up to do before integration... >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Testing of the last round of changes revealed a hang in one of the new >>> TLH tests. Robbin has fixed the hang, updated the existing TLH test, >>> and >>> added another TLH test for good measure. >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>> >>> Here is the updated delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>> >>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>> no unexpected failures. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Robbin rebased the project last night/this morning to merge with >>>> Thread >>>> Local Handshakes (TLH) and also picked up additional changesets up >>>> thru: >>>> >>>>> Changeset: fa736014cf28 >>>>> Author:??? cjplummer >>>>> Date:????? 2017-11-14 18:08 -0800 >>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>> >>>>> 8191049: Add alternate version of pns() that is callable from >>>>> within hotspot source >>>>> Summary: added pns2() to debug.cpp >>>>> Reviewed-by: stuefe, gthornbr >>>> >>>> This is the first time we've rebased the project to bits that are this >>>> fresh (< 12 hours old at rebase time). We've done this because we >>>> think >>>> we're done with this project and are in the final review-change-retest >>>> cycle(s)... In other words, we're not planning on making any more >>>> major >>>> changes for this project... :-) >>>> >>>> *** Time for code reviewers to chime in on this thread! *** >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>> >>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>> (and the new baseline also)... >>>> >>>> We're expecting this round to be a little noisier than usual because >>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>> (Yes, we're playing chase-the-repo...) >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>> >>>>> Unlike the previous rebase, there were no changes required to the >>>>> open code to get the rebased bits to build so there is no delta >>>>> webrev. >>>>> >>>>> These bits have been run through JPRT and I've submitted the usual >>>>> Mach5 tier[1-5] test run... >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>> >>>>>> Here are the updated webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>> >>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>> holiday >>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>> closer >>>>>> look today. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>> and Coleen) >>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>> done as a >>>>>>> standalone patch and corresponding webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>> to use >>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>> >>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>> >>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>> >>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>> describe >>>>>>>> and track the work on this project: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>> >>>>>>>> >>>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>>> quotes >>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>> have a >>>>>>>> solution for that problem yet. >>>>>>>> >>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>> >>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>> tier[2-5] >>>>>>>> testing, additional stress testing on Dan's Solaris X64 server, >>>>>>>> and >>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Daniel Daugherty >>>>>>>> Erik Osterlund >>>>>>>> Robbin Ehn >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From rahul.v.raghavan at oracle.com Sun Nov 26 17:09:36 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Sun, 26 Nov 2017 22:39:36 +0530 Subject: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1 In-Reply-To: <752a4e80-9141-6115-dee6-2bbd0ec99e92@oracle.com> References: <752a4e80-9141-6115-dee6-2bbd0ec99e92@oracle.com> Message-ID: <9e8de2ad-8ea2-3e66-7ea1-bd5d90acf936@oracle.com> Thank you Dan for the review. Rahul On Friday 24 November 2017 08:56 PM, Daniel D. Daugherty wrote: > On 11/24/17 6:16 AM, Rahul Raghavan wrote: >> Hi, >> >> Please review the following fix proposal for 8191813. >> >> webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/ > > test/hotspot/jtreg/compiler/runtime/SpreadNullArg.java > ??? No comments. > > So this style of call: > > ??? mh_spreadInvoker.invokeExact(mh_spread_target, (Object[]) null); > > was changed from throwing IllegalArgumentException due to the "null" > parameter to throwing NullPointerException. You've updated the test > cleanly to switch from one exception to the other. > > Thumbs up! I believe this patch qualifies as trivial and does not > need to wait for 24 hours. I leave it up to you whether you wait > for a Compiler team member review also. > > Dan > > >> >> >> jbs - https://bugs.openjdk.java.net/browse/JDK-8191813 >> >> -- reported issue - After the latest sync from jdk/jdk the test >> SpreadNullArg started to fail in tier1 on all platforms. >> >> -- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix. >> jbs - https://bugs.openjdk.java.net/browse/JDK-8157246. >> 'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to >> specify invocation-time behavior'. >> changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34 >> >> - So now with 8157246 fix, if method handle is invoked with a null >> array reference, NullPointerException will be thrown. (Not >> IllegalArgumentException) >> >> - So above fix proposal in SpreadNullArg.java to expect >> NullPointerException after 8157246 changes. >> >> >> Thanks, >> Rahul > From rahul.v.raghavan at oracle.com Sun Nov 26 17:10:21 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Sun, 26 Nov 2017 22:40:21 +0530 Subject: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1 In-Reply-To: <792dadfc-89d3-054c-d3f2-303a69346be6@oracle.com> References: <792dadfc-89d3-054c-d3f2-303a69346be6@oracle.com> Message-ID: <011150aa-9a29-2786-522f-c755469f0335@oracle.com> Thank you Mandy for review. On Friday 24 November 2017 11:11 PM, mandy chung wrote: > Looks good.? Thanks for fixing the test, Rahul. > > Mandy > > On 11/24/17 3:16 AM, Rahul Raghavan wrote: >> Hi, >> >> Please review the following fix proposal for 8191813. >> >> webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/ >> >> >> jbs - https://bugs.openjdk.java.net/browse/JDK-8191813 >> >> -- reported issue - After the latest sync from jdk/jdk the test >> SpreadNullArg started to fail in tier1 on all platforms. >> >> -- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix. >> jbs - https://bugs.openjdk.java.net/browse/JDK-8157246. >> 'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to >> specify invocation-time behavior'. >> changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34 >> >> - So now with 8157246 fix, if method handle is invoked with a null >> array reference, NullPointerException will be thrown. (Not >> IllegalArgumentException) >> >> - So above fix proposal in SpreadNullArg.java to expect >> NullPointerException after 8157246 changes. >> >> >> Thanks, >> Rahul > From tobias.hartmann at oracle.com Mon Nov 27 08:14:47 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Nov 2017 09:14:47 +0100 Subject: [10] RFR(S): 8087339: The code heap might use different alignment for committed size and reserved size In-Reply-To: <143fd037-ef76-0334-70ca-0b248c1e6fbd@oracle.com> References: <143fd037-ef76-0334-70ca-0b248c1e6fbd@oracle.com> Message-ID: Hi Vladimir, thanks for the review! Best regards, Tobias On 22.11.2017 21:23, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 11/22/17 5:51 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8087339 >> http://cr.openjdk.java.net/~thartmann/8087339/webrev.00/ >> >> The alignment of the code cache is determined in CodeCache::reserve_heap_memory() by computing the minimum of the page >> size for the ReservedCodeCacheSize and the InitialCodeCacheSize (which is usually very small and not aligned to the >> large page size). As a result, when using large pages (by enabling UseTransparentHugePages or UseHugeTLBFS), the >> ReservedSpace is only backed by large pages if the InitialCodeCacheSize is large page aligned as well. >> >> I've changed the implementation to not consider InitialCodeCacheSize and re-factored the code to use >> CodeCache::page_size() both for the alignment of heap sizes as well as the alignment of the entire reserved space. >> >> I've verified that this sets the correct alignment on my machine when using 2048K pages instead of 4K pages. >> >> Thanks, >> Tobias >> From tobias.hartmann at oracle.com Mon Nov 27 08:15:00 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Nov 2017 09:15:00 +0100 Subject: [10] RFR(S): 8179026: Remove explicit code cache options processing In-Reply-To: <05ff6a24-c198-68a2-34bd-6800d15eb745@oracle.com> References: <2a9179c1-ee2f-fe74-3809-08f697660beb@oracle.com> <05ff6a24-c198-68a2-34bd-6800d15eb745@oracle.com> Message-ID: <0b1111ea-9796-46b6-d436-12f9779f6e7b@oracle.com> Thanks Vladimir. Best regards, Tobias On 22.11.2017 21:26, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 11/21/17 11:05 PM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> On 21.11.2017 21:43, Vladimir Kozlov wrote: >>> Looks good. Can you also print size_initial in error message in codeCache.cpp? >> >> Sure, here's the updated webrev: >> http://cr.openjdk.java.net/~thartmann/8179026/webrev.01/ >> >> Best regards, >> Tobias >>> On 11/20/17 12:22 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> https://bugs.openjdk.java.net/browse/JDK-8179026 >>>> http://cr.openjdk.java.net/~thartmann/8179026/webrev.00/ >>>> >>>> I've removed the explicit processing of -XX:CodeCacheExpansionSize, -XX:NonNMethodCodeHeapSize, >>>> -XX:ProfiledCodeHeapSize >>>> and -XX:NonProfiledCodeHeapSize because generic option processing already supports memory values. I've also added a >>>> lower bound of vm_page_size() to all of them except the non-profiled and the profiled size because these can be 0. The >>>> actual checking is done in codeCache.cpp. >>>> >>>> All tests pass. >>>> >>>> Thanks, >>>> Tobias >>>> From rahul.v.raghavan at oracle.com Mon Nov 27 09:54:27 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 27 Nov 2017 15:24:27 +0530 Subject: [10] RFR: 8191227: issues with unsafe handle resolution In-Reply-To: References: <2bebdde2-b579-3049-4610-4e3949c88d01@oracle.com> Message-ID: Hi, On Thursday 23 November 2017 05:19 PM, Vladimir Ivanov wrote: > >> webrev - http://cr.openjdk.java.net/~rraghavan/8191227/webrev.02/ > > Please, use ThreadInVMfromUnknown in ConstantOopWriteValue::print_on() > as well. Done. http://cr.openjdk.java.net/~rraghavan/8191227/webrev.03/ Thank you Vladimir for review. > > Otherwise, looks good. > > Best regards, > Vladimir Ivanov > Thanks, Rahul From tobias.hartmann at oracle.com Mon Nov 27 09:59:49 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Nov 2017 10:59:49 +0100 Subject: [10] RFR: 8191227: issues with unsafe handle resolution In-Reply-To: References: <2bebdde2-b579-3049-4610-4e3949c88d01@oracle.com> Message-ID: Hi Rahul, On 27.11.2017 10:54, Rahul Raghavan wrote: >>> webrev - http://cr.openjdk.java.net/~rraghavan/8191227/webrev.02/ Looks good to me! Best regards, Tobias From rwestrel at redhat.com Mon Nov 27 10:21:28 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 27 Nov 2017 11:21:28 +0100 Subject: RFR(S): 8191887: assert(b->is_Bool()) in PhaseIdealLoop::clone_iff() due to Opaque4 node Message-ID: http://cr.openjdk.java.net/~roland/8191887/webrev.00/ Following 8176506, we can have the following graph shape: If->Opaque4->Bool->CmpP When cloning the body of a loop, if the If is out of loop but the Opaque4 is in the loop, an assert fires. I fixed that by adding special handling for the graph shape above so the Opaque4->Bool->CmpP is cloned out of loop. I also fixed the case where If->Opaque4 is out of loop but Bool->CmpP is in the loop in a similar way. Roland. From rahul.v.raghavan at oracle.com Mon Nov 27 10:45:19 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 27 Nov 2017 16:15:19 +0530 Subject: [10] RFR: 8191227: issues with unsafe handle resolution In-Reply-To: References: <2bebdde2-b579-3049-4610-4e3949c88d01@oracle.com> Message-ID: Thank you Tobias. On Monday 27 November 2017 03:29 PM, Tobias Hartmann wrote: > Hi Rahul, > > On 27.11.2017 10:54, Rahul Raghavan wrote: >>>> webrev - http://cr.openjdk.java.net/~rraghavan/8191227/webrev.02/ > > Looks good to me! > > Best regards, > Tobias > From vladimir.x.ivanov at oracle.com Mon Nov 27 12:29:56 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 27 Nov 2017 15:29:56 +0300 Subject: [10] RFR: 8191227: issues with unsafe handle resolution In-Reply-To: References: <2bebdde2-b579-3049-4610-4e3949c88d01@oracle.com> Message-ID: <50761764-2293-788a-142b-c479eebce77b@oracle.com> Looks good. Best regards, Vladimir Ivanov On 11/27/17 12:54 PM, Rahul Raghavan wrote: > Hi, > > On Thursday 23 November 2017 05:19 PM, Vladimir Ivanov wrote: >> >>> webrev - http://cr.openjdk.java.net/~rraghavan/8191227/webrev.02/ >> >> Please, use ThreadInVMfromUnknown in ConstantOopWriteValue::print_on() >> as well. > > Done. > http://cr.openjdk.java.net/~rraghavan/8191227/webrev.03/ > Thank you Vladimir for review. > >> >> Otherwise, looks good. >> >> Best regards, >> Vladimir Ivanov >> > > Thanks, > Rahul From vladimir.kozlov at oracle.com Mon Nov 27 18:19:55 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Nov 2017 10:19:55 -0800 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: <1511515343.2425.11.camel@oracle.com> References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> <1511515343.2425.11.camel@oracle.com> Message-ID: <45aa8e04-9244-4089-001f-acba24e7e4ee@oracle.com> Second pre-integration re-run finshed and there were timeouts. Looks like it depend what hosts were used to run tests. I agree to enable it by default on subset if GCs which are sensitive to pauses: G1 and Shenandoah. Roland, please, prepare changeset. I am not sure we need separate CR for setting defaults. It is simple to file bug and change only defaults if we need. Thanks, Vladimir On 11/24/17 1:22 AM, Thomas Schatzl wrote: > Hi Nils, > > On Thu, 2017-11-23 at 22:59 +0100, Nils Eliasson wrote: >> Hi, >> >> >> On 2017-11-23 15:18, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>>> I am running testing again. But if this will repeat and presence >>>> of this Sparse.small regression suggesting to me that may be we >>>> should keep this optimization off by default - keep >>>> UseCountedLoopSafepoints false. >>>> >>>> We may switch it on later with additional changes which address >>>> regressions. >>>> >>>> What do you think? >>> >>> If the inner loop runs for a small number of iterations and the >>> compiler can't statically prove it, I don't see a way to remove the >>> overhead of loop strip mining entirely. So I'm not optimistic the >>> regression can be fixed. >> >> Agreed. In other words: Loop strip mining adds a guarantee that >> time-to-safepoint won't be too long, and that has a small cost >> >> The current situation is that we have some extra performance with >> UseCountedLoopSafepoints default off, but let some users have a bad >> experience when they encounter long time-to-safepoint times or >> failures (https://bugs.openjdk.java.net/browse/JDK-5014723). I rather >> turn the table and have loop strip mining on, and let the power users >> experiment with turning it off for any uncertain performance boost. >> >>> If loop strip mining defaults to false, would there we be any >>> regular testing on your side? >> >> We would have to add some. >>> >>> It seems to me that it would make sense to enable loop strip mining >>> depending on what GC is used: it makes little sense for parallel gc >>> but we'll want it enabled for Shenandoah for instance. Where does >>> G1 fit? I can't really say and I don't have a strong opinion. But >>> as I understand, G1 was made default under the assumption that >>> users would be ok trading throughput for better latency. Maybe, >>> that same reasoning applies to loop strip mining? >> >> Scimark.sparse.small show a regression, but having long >> time-to-safepoint has a throughput cost in some settings like the >> companion benchmark scimark.sparse.large. Numbers using G1: >> >> -XX:-UseCountedLoopSafepoints (default) ~86 ops/m >> -XX:+UseCountedLoopSafepoints ~106 ops/m >> -XX:+UseCountedLoopSafepoints -XX:LoopStripMiningIter=1000 ~111 ops/m >> >> I would prefer having it on by default, at least in G1. Let's ask the >> G1 GC-team on their opinion. > > our perf team uses -XX:+UseCountedLoopSafepoints for _all_ collectors > for some time now. When asked, they replied that predictability of > results is very important for them too. > > We also closed out some perf regressions (e.g. JDK-8177704) due to the > problems with -XX:-UseCountedLoopSafepoints after you posted these > results in agreement with the perf team. > > So I am all for making it default for G1 (and I am sure others agree), > if not for all GCs. However I recommend having a separate CR for > changing the defaults. Makes it easier reverting it in case things go > wrong. > > Thanks, > Thomas > From vladimir.kozlov at oracle.com Mon Nov 27 18:55:54 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Nov 2017 10:55:54 -0800 Subject: RFR(S): 8191887: assert(b->is_Bool()) in PhaseIdealLoop::clone_iff() due to Opaque4 node In-Reply-To: References: Message-ID: subnode.hpp is empty - please remove from changes. Looks good otherwise. I started testing. Please, send changeset. Thanks, Vladimir On 11/27/17 2:21 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8191887/webrev.00/ > > Following 8176506, we can have the following graph shape: > > If->Opaque4->Bool->CmpP > > When cloning the body of a loop, if the If is out of loop but the > Opaque4 is in the loop, an assert fires. I fixed that by adding special > handling for the graph shape above so the Opaque4->Bool->CmpP is cloned > out of loop. I also fixed the case where If->Opaque4 is out of loop but > Bool->CmpP is in the loop in a similar way. > > Roland. > From thomas.schatzl at oracle.com Mon Nov 27 19:44:42 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 27 Nov 2017 20:44:42 +0100 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: <45aa8e04-9244-4089-001f-acba24e7e4ee@oracle.com> References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> <1511515343.2425.11.camel@oracle.com> <45aa8e04-9244-4089-001f-acba24e7e4ee@oracle.com> Message-ID: <1511811882.2241.4.camel@oracle.com> Hi, On Mon, 2017-11-27 at 10:19 -0800, Vladimir Kozlov wrote: > Second pre-integration re-run finshed and there were timeouts. Looks > like it depend what hosts were used to run tests. > > I agree to enable it by default on subset if GCs which are sensitive > to pauses: G1 and Shenandoah. > > Roland, please, prepare changeset. > > I am not sure we need separate CR for setting defaults. It is simple > to file bug and change only defaults if we need. the reason I suggested it is because this defaults change will then be more prominent when browsing the changesets for explanations of regressions. Ie. I am very sure we in the GC team would do that change seperately, but ymmv. Thanks, Thomas From eric.caspole at oracle.com Mon Nov 27 23:08:20 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Mon, 27 Nov 2017 18:08:20 -0500 Subject: RFR: 8191779 : LogCompilation throws java.lang.Error: scope underflow Message-ID: <27ea10eb-cc56-11e0-2b04-b73a89654b04@oracle.com> Hi everybody, Apparently due to bit rot in the LogCompilation tool, there can be a "scope underflow" error thrown while processing recent logs. http://cr.openjdk.java.net/~ecaspole/JDK-8191779/webrev/ JBS: https://bugs.openjdk.java.net/browse/JDK-8191779 I currently have a scenario that creates this problem and tested the fix there. Thanks, Eric From vladimir.kozlov at oracle.com Tue Nov 28 00:00:38 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Nov 2017 16:00:38 -0800 Subject: RFR: 8191779 : LogCompilation throws java.lang.Error: scope underflow In-Reply-To: <27ea10eb-cc56-11e0-2b04-b73a89654b04@oracle.com> References: <27ea10eb-cc56-11e0-2b04-b73a89654b04@oracle.com> Message-ID: Looks good. Thanks, Vladimir On 11/27/17 3:08 PM, Eric Caspole wrote: > Hi everybody, > Apparently due to bit rot in the LogCompilation tool, there can be a "scope underflow" error thrown > while processing recent logs. > > http://cr.openjdk.java.net/~ecaspole/JDK-8191779/webrev/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8191779 > > I currently have a scenario that creates this problem and tested the fix there. > Thanks, > Eric From vladimir.kozlov at oracle.com Tue Nov 28 00:06:32 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Nov 2017 16:06:32 -0800 Subject: RFR(S): 8191887: assert(b->is_Bool()) in PhaseIdealLoop::clone_iff() due to Opaque4 node In-Reply-To: References: Message-ID: <04fff476-b1f9-1701-5e0e-b956863600ca@oracle.com> Testing passed and I pushed changes (removed blank line in subnode.hpp). Vladimir On 11/27/17 10:55 AM, Vladimir Kozlov wrote: > subnode.hpp is empty - please remove from changes. > > Looks good otherwise. I started testing. Please, send changeset. > > Thanks, > Vladimir > > On 11/27/17 2:21 AM, Roland Westrelin wrote: >> >> http://cr.openjdk.java.net/~roland/8191887/webrev.00/ >> >> Following 8176506, we can have the following graph shape: >> >> If->Opaque4->Bool->CmpP >> >> When cloning the body of a loop, if the If is out of loop but the >> Opaque4 is in the loop, an assert fires. I fixed that by adding special >> handling for the graph shape above so the Opaque4->Bool->CmpP is cloned >> out of loop. I also fixed the case where If->Opaque4 is out of loop but >> Bool->CmpP is in the loop in a similar way. >> >> Roland. >> From vladimir.kozlov at oracle.com Tue Nov 28 00:59:09 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Nov 2017 16:59:09 -0800 Subject: RFR: 8181633: Vectorization fails for some multiplication with constant cases In-Reply-To: <8dc56cfb-21e6-0616-60b3-3f7e5804aa44@oracle.com> References: <6cbd9d91-7f06-85d8-d1ee-77978e3e609e@oracle.com> <8dc56cfb-21e6-0616-60b3-3f7e5804aa44@oracle.com> Message-ID: <6bb0b51b-d28c-b6bc-a272-7ddbd5e1d4f8@oracle.com> It "falls through cracks" - I forgot about it. I rerun these changes with latest jdk10/hs sources in pre-integration testing: http://cr.openjdk.java.net/~njian/8181633/webrev.00/ Testing passed and I pushed it. Regards, Vladimir On 6/21/17 12:43 AM, Vladimir Kozlov wrote: > Very nice results! > > From correctness point of view changes seem fine but I may miss something. > > It would be nice if our friends in RedHat and Intel test these changes on regular java benchmarks. > > Thanks, > Vladimir > > On 6/20/17 11:34 PM, Yang Zhang wrote: >>> >>> Do I understand correctly that the problem is we pack not similar nodes into >>> the same set? Which cause later non-profitable result for such sets. >>> I am trying understand why additional restriction helps. >> >> Yes. Just like the following Packs. In Pack 24 and 25, node pair >> (434,117) and (440,157) are packed incorrectly. In IdealGraph, this >> problem would be more clear. I also attach the generated assembly >> files( test case is previous code. opt is the result with the patch). >> Please check it. >> >> Pack: 18 >> ? align: 8 432 StoreI ===? 525? 477? 439? 433? [[ 418? 192? 151? 112 ]] >> ? align: 12 192 StoreI ===? 525? 432? 190? 158? [[ 416? 533? 406 ]] >> Pack: 19 >> ? align: 8 442 LoadI ===? 228? 477? 443? [[ 440? 441 ]] >> ? align: 12 112 LoadI ===? 228? 432? 110? [[ 117? 116 ]] >> Pack: 20 >> ? align: 8 445 LoadI ===? 244? 477? 446? [[ 435? 444 ]] >> ? align: 12 151 LoadI ===? 244? 432? 149? [[ 156? 154 ]] >> Pack: 21 >> ? align: 8 433 AddI === _? 434? 440? [[ 432 ]] >> ? align: 12 158 AddI === _? 117? 157? [[ 192 ]] >> Pack: 22 >> ? align: 8 441 LShiftI === _? 442? 108? [[ 440 ]] >> ? align: 12 116 LShiftI === _? 112? 108? [[ 117 ]] >> Pack: 23 >> ? align: 8 435 LShiftI === _? 445? 40? [[ 434 ]] >> ? align: 12 154 LShiftI === _? 151? 40? [[ 157 ]] >> Pack: 24 >> ? align: 8 434 AddI === _? 435? 444? [[ 433 ]] >> ? align: 12 117 AddI === _? 116? 112? [[ 158 ]] >> Pack: 25 >> ? align: 8 440 AddI === _? 441? 442? [[ 433 ]] >> ? align: 12 157 AddI === _? 154? 156? [[ 158 ]] >> Pack: 26 >> ? align: 8 444 LShiftI === _? 445? 155? [[ 434 ]] >> ? align: 12 156 LShiftI === _? 151? 155? [[ 157 ]] >> >> >>> >>> Did you try constants with 1 bit set (which converted to simple shift) or 3 >>> bits set (which keep multipmultiplication)? >>> >> >> In my test, both of constants should be split to shift and add, such >> as (5, 10) (9, 17) . For other cases, such as (5, 8) (7, 11), there >> won't be such a problem. >> >> >>>> >>>> This bug results from that the rules of matching two similar >>>> independent nodes are not strict enough. So that I add more matching >>>> rules. With this patch, both on x86 and aarch64, SIMD instructions can >>>> be generated for above test case. And there is obvious performance >>>> improvement (~30% in jmh). >>> >>> >>> What other performance tests you ran? >> >> No. >> >> Regards, >> Yang >> From ningsheng.jian at linaro.org Tue Nov 28 01:55:40 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Tue, 28 Nov 2017 09:55:40 +0800 Subject: RFR: 8181633: Vectorization fails for some multiplication with constant cases In-Reply-To: <6bb0b51b-d28c-b6bc-a272-7ddbd5e1d4f8@oracle.com> References: <6cbd9d91-7f06-85d8-d1ee-77978e3e609e@oracle.com> <8dc56cfb-21e6-0616-60b3-3f7e5804aa44@oracle.com> <6bb0b51b-d28c-b6bc-a272-7ddbd5e1d4f8@oracle.com> Message-ID: Thank you, Vladimir! Regards, Ningsheng On 28 November 2017 at 08:59, Vladimir Kozlov wrote: > It "falls through cracks" - I forgot about it. > I rerun these changes with latest jdk10/hs sources in pre-integration > testing: > > http://cr.openjdk.java.net/~njian/8181633/webrev.00/ > > Testing passed and I pushed it. > > Regards, > Vladimir > > > On 6/21/17 12:43 AM, Vladimir Kozlov wrote: >> >> Very nice results! >> >> From correctness point of view changes seem fine but I may miss >> something. >> >> It would be nice if our friends in RedHat and Intel test these changes on >> regular java benchmarks. >> >> Thanks, >> Vladimir >> >> On 6/20/17 11:34 PM, Yang Zhang wrote: >>>> >>>> >>>> Do I understand correctly that the problem is we pack not similar nodes >>>> into >>>> the same set? Which cause later non-profitable result for such sets. >>>> I am trying understand why additional restriction helps. >>> >>> >>> Yes. Just like the following Packs. In Pack 24 and 25, node pair >>> (434,117) and (440,157) are packed incorrectly. In IdealGraph, this >>> problem would be more clear. I also attach the generated assembly >>> files( test case is previous code. opt is the result with the patch). >>> Please check it. >>> >>> Pack: 18 >>> align: 8 432 StoreI === 525 477 439 433 [[ 418 192 151 112 ]] >>> align: 12 192 StoreI === 525 432 190 158 [[ 416 533 406 ]] >>> Pack: 19 >>> align: 8 442 LoadI === 228 477 443 [[ 440 441 ]] >>> align: 12 112 LoadI === 228 432 110 [[ 117 116 ]] >>> Pack: 20 >>> align: 8 445 LoadI === 244 477 446 [[ 435 444 ]] >>> align: 12 151 LoadI === 244 432 149 [[ 156 154 ]] >>> Pack: 21 >>> align: 8 433 AddI === _ 434 440 [[ 432 ]] >>> align: 12 158 AddI === _ 117 157 [[ 192 ]] >>> Pack: 22 >>> align: 8 441 LShiftI === _ 442 108 [[ 440 ]] >>> align: 12 116 LShiftI === _ 112 108 [[ 117 ]] >>> Pack: 23 >>> align: 8 435 LShiftI === _ 445 40 [[ 434 ]] >>> align: 12 154 LShiftI === _ 151 40 [[ 157 ]] >>> Pack: 24 >>> align: 8 434 AddI === _ 435 444 [[ 433 ]] >>> align: 12 117 AddI === _ 116 112 [[ 158 ]] >>> Pack: 25 >>> align: 8 440 AddI === _ 441 442 [[ 433 ]] >>> align: 12 157 AddI === _ 154 156 [[ 158 ]] >>> Pack: 26 >>> align: 8 444 LShiftI === _ 445 155 [[ 434 ]] >>> align: 12 156 LShiftI === _ 151 155 [[ 157 ]] >>> >>> >>>> >>>> Did you try constants with 1 bit set (which converted to simple shift) >>>> or 3 >>>> bits set (which keep multipmultiplication)? >>>> >>> >>> In my test, both of constants should be split to shift and add, such >>> as (5, 10) (9, 17) . For other cases, such as (5, 8) (7, 11), there >>> won't be such a problem. >>> >>> >>>>> >>>>> This bug results from that the rules of matching two similar >>>>> independent nodes are not strict enough. So that I add more matching >>>>> rules. With this patch, both on x86 and aarch64, SIMD instructions can >>>>> be generated for above test case. And there is obvious performance >>>>> improvement (~30% in jmh). >>>> >>>> >>>> >>>> What other performance tests you ran? >>> >>> >>> No. >>> >>> Regards, >>> Yang >>> > From ningsheng.jian at linaro.org Tue Nov 28 05:54:23 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Tue, 28 Nov 2017 13:54:23 +0800 Subject: RFR: 8191954: AArch64: disable UseCISCSpill in C2 Message-ID: Hi, Please help to review. JBS: https://bugs.openjdk.java.net/browse/JDK-8191954 Webrev: http://cr.openjdk.java.net/~njian/8191954/webrev.00/ This sets UseCISCSpill to false on AArch64, as we actually don't use that. jtreg tests passed with fastdebug build. Thanks, Ningsheng From david.holmes at oracle.com Tue Nov 28 08:01:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Nov 2017 18:01:27 +1000 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5976a6bf-c9b0-c0d5-d5f9-fcdf7dc9a1a8@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> <567339a6-e36a-5416-5c34-2a87cbfa6cdd@oracle.com> <5976a6bf-c9b0-c0d5-d5f9-fcdf7dc9a1a8@oracle.com> Message-ID: <157a90ee-35c9-1adf-490a-9910f3ee646f@oracle.com> Just for the record ... On 23/11/2017 6:20 PM, Robbin Ehn wrote: > Thanks Dan for dragging this freight train to the docks, it's time to > ship it! I agree. The latest delta seems fine to me. > Created follow-up bug: > 8191809: Threads::number_of_threads() is not 'MT-safe' > https://bugs.openjdk.java.net/browse/JDK-8191809 Just updated that bug - I don't see any MT issues there. :) Cheers, David PS. Dan: yes JPRT was still doing 32-bit ARM a "month or two back". 64-bit atomics should not be a concern. That said I thought all the atomic updates were done for ARM etc. > /Robbin > > On 2017-11-23 03:16, Daniel D. Daugherty wrote: >> Greetings, >> >> I've made minor tweaks to the Thread-SMR project based on the remaining >> code review comments over the last couple of days. I've also rebased the >> project to jdk/hs bits as of mid-afternoon (my TZ) on 2017.11.22. I'm >> running baseline Mach5 Tier[1-5] testing and prototype Mach5 Tier[1-5] >> testing... >> >> Here's a delta webrev for the latest round of tweaks: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-11-delta >> >> >> Here's the proposed commit message: >> >> $ cat SMR_prototype_10/open/commit.txt >> 8167108: inconsistent handling of SR_lock can lead to crashes >> Summary: Add Thread Safe Memory Reclamation (Thread-SMR) mechanism. >> Reviewed-by: coleenp, dcubed, dholmes, eosterlund, gthornbr, kbarrett, >> rehn, sspitsyn, stefank >> Contributed-by: daniel.daugherty at oracle.com, >> erik.osterlund at oracle.com, robbin.ehn at oracle.com >> >> I've gone through 880+ emails in my archive for this project and added >> anyone that made a code review comment. Reviewers are not in my usual >> by-comment-posting order; it was way too hard to figure that out... So >> reviewers and contributors are simply in alpha-sort order... >> >> Here's the collection of follow-up bugs that I filed based on sifting >> through the email archive: >> >> 8191784 JavaThread::collect_counters() should stop using Threads_lock >> https://bugs.openjdk.java.net/browse/JDK-8191784 >> >> 8191785 revoke_bias() needs a new assertion >> https://bugs.openjdk.java.net/browse/JDK-8191785 >> >> 8191786 Thread-SMR hash table size should be dynamic >> https://bugs.openjdk.java.net/browse/JDK-8191786 >> >> 8191787 move private inline functions from thread.inline.hpp -> >> thread.cpp >> https://bugs.openjdk.java.net/browse/JDK-8191787 >> >> 8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> >> threadSMR.[ch]pp >> https://bugs.openjdk.java.net/browse/JDK-8191789 >> >> 8191798 redo nested ThreadsListHandle to drop Threads_lock >> https://bugs.openjdk.java.net/browse/JDK-8191789 >> >> I have undoubtedly missed at least one future idea that someone had >> and for that my apologies... >> >> Thanks again to everyone who contributed to the Thread-SMR project!! >> >> Special thanks goes to Karen Kinnear, Kim Barrett and David Holmes for >> their rigorous review of the design that we documented on the wiki. >> Thanks for keeping us honest! >> >> I also have to thank my co-contributor Erik ?sterlund for starting the >> ball rolling on this crazy project with his presentation on Safe Memory >> Reclamation, for the initial prototype and for all your patches. Erik, >> hopefully we got far enough in your crazy vision... :-) >> >> Thanks to my co-contributor Robbin Ehn for proposing that we do early >> code reviews in the form of patches. Don't like something? Fix it with >> a patch and a new test if appropriate!! A pretty cool way to work that >> was new to me. >> >> Finally, many thanks to Jerry Thornbrugh for all the early code reviews, >> whiteboard chats and phone calls. Thanks for asking the right questions >> and pointing out some places where our logic was faulty. Also thanks for >> keeping me sane when I was literally on my own in Monument, CO. >> >> Dan >> >> >> On 11/21/17 7:12 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> *** We are wrapping up code review on this project so it is time *** >>> *** for the various code reviewers to chime in one last time. *** >>> >>> In this latest round, we had three different reviewers chime in so we're >>> doing delta webrevs for each of those resolutions: >>> >>> David H's resolutions: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ >>> >>> >>> ? mq comment for dholmes_CR: >>> ??? - Fix indents, trailing spaces and various typos. >>> ??? - Add descriptions for the '_cnt', '_max' and '_times" fields, >>> ????? add impl notes to document the type choices. >>> >>> ? src/hotspot/share/runtime/globals.hpp change is white-space only so it >>> ? is only visible via the file's patch link. >>> >>> >>> Robin W's resolutions: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ >>> >>> >>> ? mq comment for robinw_CR: >>> ??? - Fix some inefficient code, update some comments, fix some indents, >>> ????? and add some 'const' specifiers. >>> >>> ? src/hotspot/share/runtime/vm_operations.hpp change is white-space >>> only so >>> ? it is only visible via the file's patch link. >>> >>> >>> Coleen's resolutions: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ >>> >>> >>> ? mq comment for coleenp_CR: >>> ??? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', >>> ??? - add header comment to threadSMR.hpp file, >>> ??? - cleanup JavaThreadIteratorWithHandle ctr, >>> ??? - make ErrorHandling more efficient. >>> >>> >>> Some folks prefer to see all of the delta webrevs together so here is >>> a delta webrev relative to jdk10-09-full: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ >>> >>> >>> ? src/hotspot/share/runtime/globals.hpp and >>> ? src/hotspot/share/runtime/vm_operations.hpp changes are white-space >>> only >>> ? so they are only visible via the file's patch link. >>> >>> >>> And, of course, some folks prefer to see everything all at once so here >>> is the latest full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ >>> >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The >>> prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... >>> >>> The project is currently baselined on Jesper's 2017-11-17 PIT snapshot >>> so there will be some catching up to do before integration... >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Testing of the last round of changes revealed a hang in one of the new >>>> TLH tests. Robbin has fixed the hang, updated the existing TLH test, >>>> and >>>> added another TLH test for good measure. >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>> >>>> Here is the updated delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>>> >>>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>>> no unexpected failures. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Robbin rebased the project last night/this morning to merge with >>>>> Thread >>>>> Local Handshakes (TLH) and also picked up additional changesets up >>>>> thru: >>>>> >>>>>> Changeset: fa736014cf28 >>>>>> Author:??? cjplummer >>>>>> Date:????? 2017-11-14 18:08 -0800 >>>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>>> >>>>>> 8191049: Add alternate version of pns() that is callable from >>>>>> within hotspot source >>>>>> Summary: added pns2() to debug.cpp >>>>>> Reviewed-by: stuefe, gthornbr >>>>> >>>>> This is the first time we've rebased the project to bits that are this >>>>> fresh (< 12 hours old at rebase time). We've done this because we >>>>> think >>>>> we're done with this project and are in the final review-change-retest >>>>> cycle(s)... In other words, we're not planning on making any more >>>>> major >>>>> changes for this project... :-) >>>>> >>>>> *** Time for code reviewers to chime in on this thread! *** >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>>> >>>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>>> >>>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>>> (and the new baseline also)... >>>>> >>>>> We're expecting this round to be a little noisier than usual because >>>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>>> (Yes, we're playing chase-the-repo...) >>>>>> >>>>>> Here is the updated full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>>> >>>>>> Unlike the previous rebase, there were no changes required to the >>>>>> open code to get the rebased bits to build so there is no delta >>>>>> webrev. >>>>>> >>>>>> These bits have been run through JPRT and I've submitted the usual >>>>>> Mach5 tier[1-5] test run... >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>>> >>>>>>> Here are the updated webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>>> >>>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>>> holiday >>>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>>> closer >>>>>>> look today. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>>> and Coleen) >>>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>>> done as a >>>>>>>> standalone patch and corresponding webrevs: >>>>>>>> >>>>>>>> Here's the mq comment for the change: >>>>>>>> >>>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>>> to use >>>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>>> >>>>>>>> Here is the full webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>>> >>>>>>>> And here is the delta webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Dan, Erik and Robbin >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>>> >>>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>>> >>>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>>> >>>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>>> describe >>>>>>>>> and track the work on this project: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>>> >>>>>>>>> >>>>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>>>> quotes >>>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>>> have a >>>>>>>>> solution for that problem yet. >>>>>>>>> >>>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>>> >>>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>>> tier[2-5] >>>>>>>>> testing, additional stress testing on Dan's Solaris X64 server, >>>>>>>>> and >>>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>>> >>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>> >>>>>>>>> Daniel Daugherty >>>>>>>>> Erik Osterlund >>>>>>>>> Robbin Ehn >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> From aph at redhat.com Tue Nov 28 08:49:21 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Nov 2017 08:49:21 +0000 Subject: [aarch64-port-dev ] RFR: 8191954: AArch64: disable UseCISCSpill in C2 In-Reply-To: References: Message-ID: <2bbe989e-558f-7cf6-a453-1fefd8ba9551@redhat.com> On 28/11/17 05:54, Ningsheng Jian wrote: > JBS: > https://bugs.openjdk.java.net/browse/JDK-8191954 > > Webrev: > http://cr.openjdk.java.net/~njian/8191954/webrev.00/ > > This sets UseCISCSpill to false on AArch64, as we actually don't use > that. jtreg tests passed with fastdebug build. That's too risky right now. We'll look at it in the next cycle. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Tue Nov 28 09:35:09 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 Nov 2017 09:35:09 +0000 Subject: [aarch64-port-dev ] RFR: 8191954: AArch64: disable UseCISCSpill in C2 In-Reply-To: <2bbe989e-558f-7cf6-a453-1fefd8ba9551@redhat.com> References: <2bbe989e-558f-7cf6-a453-1fefd8ba9551@redhat.com> Message-ID: On 28/11/17 08:49, Andrew Haley wrote: > On 28/11/17 05:54, Ningsheng Jian wrote: >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8191954 >> >> Webrev: >> http://cr.openjdk.java.net/~njian/8191954/webrev.00/ >> >> This sets UseCISCSpill to false on AArch64, as we actually don't use >> that. jtreg tests passed with fastdebug build. > > That's too risky right now. We'll look at it in the next cycle. I don't think it is actually /risky/ because UseCISCSpill would only take effect if aarch64.ad declared a cisc_spilling_operand_name in the frame section (it doesn't). That declaration drives adlc to generate an overriding version of a virtual method of class Node which is used by the chaitin allocator to determine how to spill a value. Without any override the method always returns -1, meaning that operands are never considered for CISC spilling. So, leaving UseCISCSpill set to true causes a small amount of extra checking to be done but no action is ever taken. Of course that also means the change is not going to be /critical/ to performance i.e. rushing to squeeze it into jdk10 is not justified. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From ningsheng.jian at linaro.org Tue Nov 28 09:54:54 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Tue, 28 Nov 2017 17:54:54 +0800 Subject: RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error Message-ID: Hi, Please help to review this small fix for AArch64. JBS: https://bugs.openjdk.java.net/browse/JDK-8191955 (with some descriptions) Webrev: http://cr.openjdk.java.net/~njian/8191955/webrev.00/ An unexpected distance triggers the error for PRFM instruction generation. This patch will warn and fix the unexpected input value. jtreg passed with fastdebug build. OK for 10? Thanks, Ningsheng From ningsheng.jian at linaro.org Tue Nov 28 10:02:12 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Tue, 28 Nov 2017 18:02:12 +0800 Subject: [aarch64-port-dev ] RFR: 8191954: AArch64: disable UseCISCSpill in C2 In-Reply-To: References: <2bbe989e-558f-7cf6-a453-1fefd8ba9551@redhat.com> Message-ID: Thanks for the review! On 28 November 2017 at 17:35, Andrew Dinn wrote: > On 28/11/17 08:49, Andrew Haley wrote: >> On 28/11/17 05:54, Ningsheng Jian wrote: >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8191954 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~njian/8191954/webrev.00/ >>> >>> This sets UseCISCSpill to false on AArch64, as we actually don't use >>> that. jtreg tests passed with fastdebug build. >> >> That's too risky right now. We'll look at it in the next cycle. > I don't think it is actually /risky/ because UseCISCSpill would only > take effect if aarch64.ad declared a cisc_spilling_operand_name in the > frame section (it doesn't). > > That declaration drives adlc to generate an overriding version of a > virtual method of class Node which is used by the chaitin allocator to > determine how to spill a value. Without any override the method always > returns -1, meaning that operands are never considered for CISC spilling. Yes, that's why I think it's low risk but also trivial. > > So, leaving UseCISCSpill set to true causes a small amount of extra > checking to be done but no action is ever taken. Of course that also > means the change is not going to be /critical/ to performance i.e. > rushing to squeeze it into jdk10 is not justified. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander Thanks, Ningsheng From aph at redhat.com Tue Nov 28 10:11:21 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Nov 2017 10:11:21 +0000 Subject: [aarch64-port-dev ] RFR: 8191954: AArch64: disable UseCISCSpill in C2 In-Reply-To: References: <2bbe989e-558f-7cf6-a453-1fefd8ba9551@redhat.com> Message-ID: <9c3ad319-39dc-61e4-0f38-b5c4ff27fc37@redhat.com> On 28/11/17 09:35, Andrew Dinn wrote: > On 28/11/17 08:49, Andrew Haley wrote: >> On 28/11/17 05:54, Ningsheng Jian wrote: > > So, leaving UseCISCSpill set to true causes a small amount of extra > checking to be done but no action is ever taken. Of course that also > means the change is not going to be /critical/ to performance i.e. > rushing to squeeze it into jdk10 is not justified. OK, so there's no hurry to change it, then. :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Nov 28 10:15:32 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Nov 2017 10:15:32 +0000 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: Message-ID: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> On 28/11/17 09:54, Ningsheng Jian wrote: > OK for 10? Please test with AllocatePrefetchDistance == -1. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Tue Nov 28 10:26:13 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 28 Nov 2017 11:26:13 +0100 Subject: RFR(XS): 8191153: assert(u_ctrl != blk1 && u_ctrl != blk2) failed: won't converge In-Reply-To: References: Message-ID: Thanks for sponsoring, Vladimir. Roland. From rwestrel at redhat.com Tue Nov 28 10:27:24 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 28 Nov 2017 11:27:24 +0100 Subject: RFR(S): 8191887: assert(b->is_Bool()) in PhaseIdealLoop::clone_iff() due to Opaque4 node In-Reply-To: <04fff476-b1f9-1701-5e0e-b956863600ca@oracle.com> References: <04fff476-b1f9-1701-5e0e-b956863600ca@oracle.com> Message-ID: > Testing passed and I pushed changes (removed blank line in subnode.hpp). Thanks for reviewing and sponsoring. Roland. From ningsheng.jian at linaro.org Tue Nov 28 10:31:10 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Tue, 28 Nov 2017 18:31:10 +0800 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> Message-ID: OK, AllocatePrefetchDistanceConstraintFunc has constraint to make sure it should be [0, 512], which does not match document... On 28 November 2017 at 18:15, Andrew Haley wrote: > On 28/11/17 09:54, Ningsheng Jian wrote: >> OK for 10? > > Please test with AllocatePrefetchDistance == -1. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Tue Nov 28 11:00:34 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 28 Nov 2017 12:00:34 +0100 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: <45aa8e04-9244-4089-001f-acba24e7e4ee@oracle.com> References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> <1511515343.2425.11.camel@oracle.com> <45aa8e04-9244-4089-001f-acba24e7e4ee@oracle.com> Message-ID: Hi Vladimir, > Roland, please, prepare changeset. Here is the changeset: http://cr.openjdk.java.net/~roland/8186027/loop-strip-mining.patch It includes the patch below to enable it with G1. Roland. diff --git a/src/hotspot/share/gc/g1/g1Arguments.cpp b/src/hotspot/share/gc/g1/g1Arguments.cpp --- a/src/hotspot/share/gc/g1/g1Arguments.cpp +++ b/src/hotspot/share/gc/g1/g1Arguments.cpp @@ -92,6 +92,16 @@ } log_trace(gc)("MarkStackSize: %uk MarkStackSizeMax: %uk", (unsigned int) (MarkStackSize / K), (uint) (MarkStackSizeMax / K)); + +#ifdef COMPILER2 + // Enable loop strip mining to offer better pause time guarantees + if (FLAG_IS_DEFAULT(UseCountedLoopSafepoints)) { + FLAG_SET_DEFAULT(UseCountedLoopSafepoints, true); + } + if (UseCountedLoopSafepoints && FLAG_IS_DEFAULT(LoopStripMiningIter)) { + FLAG_SET_DEFAULT(LoopStripMiningIter, 1000); + } +#endif } CollectedHeap* G1Arguments::create_heap() { diff --git a/src/hotspot/share/opto/c2_globals.hpp b/src/hotspot/share/opto/c2_globals.hpp --- a/src/hotspot/share/opto/c2_globals.hpp +++ b/src/hotspot/share/opto/c2_globals.hpp @@ -741,7 +741,7 @@ develop(bool, RenumberLiveNodes, true, \ "Renumber live nodes") \ \ - product(uintx, LoopStripMiningIter, 1000, \ + product(uintx, LoopStripMiningIter, 0, \ "Number of iterations in strip mined loop") \ range(0, max_juint) \ \ From rahul.v.raghavan at oracle.com Tue Nov 28 12:04:01 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Tue, 28 Nov 2017 17:34:01 +0530 Subject: RFR: 8187676: Disable harmless uninitialized warnings for two files In-Reply-To: <1a8dd6cc-8cf2-bb0e-af09-ea53324c85e3@oracle.com> References: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> <7512e87d-4e28-27a1-5e10-5cdfa794cdf4@oracle.com> <4f5b0427-54bf-2b85-0a94-bb41049d2676@oracle.com> <1a8dd6cc-8cf2-bb0e-af09-ea53324c85e3@oracle.com> Message-ID: <7cd41397-6f67-5bca-f08d-d85d73bcd631@oracle.com> Hi, Further to below email thread - https://bugs.openjdk.java.net/browse/JDK-8187676 https://bugs.openjdk.java.net/browse/JDK-8160404 Please note 8187676 task was blocked by related 8160404. But as mentioned in latest jbs comments of 8160404, found the build warning with gcc7 persists with latest 8160404-patch. More work to be done for complete, correct fix of 8160404. But for now will request to defer 8160404 task to jdk11. Since 8160404 is taking more time, as Erik suggested earlier, can we please go ahead, get approval and disable the gcc warnings for now as part of 8187676 fix - http://cr.openjdk.java.net/~ehelin/8187676/00/ and re-enable later as part of 8160404 patch. Understood that now only the problems highlighted by JDK-8187676/8160404 is stopping hotspot from compiling with more recent versions of GCC. Also as Erik mentioned earlier, disabling these uninitialized warnings seems to be harmless. Thanks, Rahul On Thursday 21 September 2017 02:32 PM, Erik Helin wrote: > Ok, lets wait for Rahul's patches. Rahul, when you post your patches, CC > me and I can check if gcc 7.1.1 still complains :) > > Thanks, > Erik > > On 09/19/2017 06:25 PM, Vladimir Kozlov wrote: >> I would prefer to have general solution Rahul is working on because >> code is general - not only x86 is affected. >> >> Thanks, >> Vladimir >> >> On 9/19/17 7:59 AM, Rahul Raghavan wrote: >>> Hi Erik, >>> >>> Please note that this 8187676 seems to be related to 8160404. >>> ??? https://bugs.openjdk.java.net/browse/JDK-8160404 >>> ??? (RelocationHolder constructors have bugs) >>> >>> As per the latest notes comments added for 8160404-jbs, I will submit >>> webrev/RFR soon and will request help confirm similar issues with >>> latest gcc7 gets solved. >>> >>> Thanks, >>> Rahul >>> >>> On Tuesday 19 September 2017 07:07 PM, Erik Helin wrote: >>>> Hi all, >>>> >>>> with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the >>>> potential usage of maybe uninitialized memory in >>>> src/hotspot/cpu/x86/assembler_x86.cpp and in >>>> src/hotspot/cpu/x86/interp_masm_x86.cpp. >>>> >>>> The problems arises from the class RelocationHolder in >>>> src/hotspot/share/code/relocInfo.hpp which has the private fields: >>>> ?? enum { _relocbuf_size = 5 }; >>>> ?? void* _relocbuf[ _relocbuf_size ]; >>>> >>>> and the default constructor for RelocationHolder does not initialize >>>> the elements of _relocbuf. I _think_ this is an optimization, >>>> RelocationHolder is used *a lot* and setting the elements of >>>> RelocationHolder::_relocbuf to NULL (or some other value) in the >>>> default constructor might result in a performance penalty. Have a >>>> look in >>>> build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles >>>> and you will see that RelocationHolder is used all over the place :) >>>> >>>> AFAICS all users of RelocationHolder::_relocbuf take care to not use >>>> uninitialized memory, which means that this warning is wrong, so I >>>> suggest we disable the warning -Wmaybe-uninitialized for >>>> src/hotspot/cpu/x86/assembler_x86.cpp. >>>> >>>> The problem continues because the class Address in >>>> src/hotspot/cpu/x86/assembler_x86.hpp has a private field, >>>> `RelocationHolder _rspec;` and the default constructor for Address >>>> does not initialize _rspec._relocbuf (most likely for performance >>>> reasons). The class Address also has a default copy constructor, >>>> which will copy all the elements of _rspec._relocbuf, which will >>>> result in a read of uninitialized memory. However, this is a benign >>>> usage of uninitialized memory, since we take no action based on the >>>> content of the uninitialized memory (it is just copied byte for byte). >>>> >>>> So, in this case too, I suggest we disable the warning >>>> -Wuninitialized for src/hotspot/cpu/x86/assembler_x86.hpp. >>>> >>>> What do you think? >>>> >>>> Patch: >>>> http://cr.openjdk.java.net/~ehelin/8187676/00/ >>>> >>>> --- old/make/hotspot/lib/JvmOverrideFiles.gmk??? 2017-09-19 >>>> 15:11:45.036108983 +0200 >>>> +++ new/make/hotspot/lib/JvmOverrideFiles.gmk??? 2017-09-19 >>>> 15:11:44.692107277 +0200 >>>> @@ -32,6 +32,8 @@ >>>> ? ifeq ($(TOOLCHAIN_TYPE), gcc) >>>> ??? BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := >>>> -fno-var-tracking-assignments -O0 >>>> ??? BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := >>>> -fno-var-tracking-assignments >>>> +? BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized >>>> +? BUILD_LIBJVM_interp_masm_x86.cpp_CXXFLAGS := -Wno-uninitialized >>>> ? endif >>>> >>>> ? ifeq ($(OPENJDK_TARGET_OS), linux) >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8187676 >>>> >>>> Testing: >>>> - Compiles with: >>>> ?? - gcc 7.1.1 and glibc 2.25 on Fedora 26 >>>> ?? - gcc 4.9.2 and glibc 2.12 on OEL 6.4 >>>> - JPRT >>>> >>>> Thanks, >>>> Erik From daniel.daugherty at oracle.com Tue Nov 28 12:31:02 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Nov 2017 07:31:02 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <157a90ee-35c9-1adf-490a-9910f3ee646f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> <567339a6-e36a-5416-5c34-2a87cbfa6cdd@oracle.com> <5976a6bf-c9b0-c0d5-d5f9-fcdf7dc9a1a8@oracle.com> <157a90ee-35c9-1adf-490a-9910f3ee646f@oracle.com> Message-ID: On 11/28/17 3:01 AM, David Holmes wrote: > Just for the record ... > > On 23/11/2017 6:20 PM, Robbin Ehn wrote: >> Thanks Dan for dragging this freight train to the docks, it's time to >> ship it! > > I agree. The latest delta seems fine to me. Thanks! > >> Created follow-up bug: >> 8191809: Threads::number_of_threads() is not 'MT-safe' >> https://bugs.openjdk.java.net/browse/JDK-8191809 > > Just updated that bug - I don't see any MT issues there. :) > > Cheers, > David > > PS. Dan: yes JPRT was still doing 32-bit ARM a "month or two back". > 64-bit atomics should not be a concern. That said I thought all the > atomic updates were done for ARM etc. The atomic template updates were done for ARM. It was the new template stuff that gave me the error about a match not being available for one of the operations on a 64-bit field. I'm going to guess that pre-template, we would have gotten a runtime error or something... I really wish I had saved that JPRT build log... :-( Dan > >> /Robbin >> >> On 2017-11-23 03:16, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I've made minor tweaks to the Thread-SMR project based on the remaining >>> code review comments over the last couple of days. I've also rebased >>> the >>> project to jdk/hs bits as of mid-afternoon (my TZ) on 2017.11.22. I'm >>> running baseline Mach5 Tier[1-5] testing and prototype Mach5 Tier[1-5] >>> testing... >>> >>> Here's a delta webrev for the latest round of tweaks: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-11-delta >>> >>> >>> Here's the proposed commit message: >>> >>> $ cat SMR_prototype_10/open/commit.txt >>> 8167108: inconsistent handling of SR_lock can lead to crashes >>> Summary: Add Thread Safe Memory Reclamation (Thread-SMR) mechanism. >>> Reviewed-by: coleenp, dcubed, dholmes, eosterlund, gthornbr, >>> kbarrett, rehn, sspitsyn, stefank >>> Contributed-by: daniel.daugherty at oracle.com, >>> erik.osterlund at oracle.com, robbin.ehn at oracle.com >>> >>> I've gone through 880+ emails in my archive for this project and added >>> anyone that made a code review comment. Reviewers are not in my usual >>> by-comment-posting order; it was way too hard to figure that out... So >>> reviewers and contributors are simply in alpha-sort order... >>> >>> Here's the collection of follow-up bugs that I filed based on sifting >>> through the email archive: >>> >>> 8191784 JavaThread::collect_counters() should stop using Threads_lock >>> https://bugs.openjdk.java.net/browse/JDK-8191784 >>> >>> 8191785 revoke_bias() needs a new assertion >>> https://bugs.openjdk.java.net/browse/JDK-8191785 >>> >>> 8191786 Thread-SMR hash table size should be dynamic >>> https://bugs.openjdk.java.net/browse/JDK-8191786 >>> >>> 8191787 move private inline functions from thread.inline.hpp -> >>> thread.cpp >>> https://bugs.openjdk.java.net/browse/JDK-8191787 >>> >>> 8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> >>> threadSMR.[ch]pp >>> https://bugs.openjdk.java.net/browse/JDK-8191789 >>> >>> 8191798 redo nested ThreadsListHandle to drop Threads_lock >>> https://bugs.openjdk.java.net/browse/JDK-8191789 >>> >>> I have undoubtedly missed at least one future idea that someone had >>> and for that my apologies... >>> >>> Thanks again to everyone who contributed to the Thread-SMR project!! >>> >>> Special thanks goes to Karen Kinnear, Kim Barrett and David Holmes for >>> their rigorous review of the design that we documented on the wiki. >>> Thanks for keeping us honest! >>> >>> I also have to thank my co-contributor Erik ?sterlund for starting the >>> ball rolling on this crazy project with his presentation on Safe Memory >>> Reclamation, for the initial prototype and for all your patches. Erik, >>> hopefully we got far enough in your crazy vision... :-) >>> >>> Thanks to my co-contributor Robbin Ehn for proposing that we do early >>> code reviews in the form of patches. Don't like something? Fix it with >>> a patch and a new test if appropriate!! A pretty cool way to work that >>> was new to me. >>> >>> Finally, many thanks to Jerry Thornbrugh for all the early code >>> reviews, >>> whiteboard chats and phone calls. Thanks for asking the right questions >>> and pointing out some places where our logic was faulty. Also thanks >>> for >>> keeping me sane when I was literally on my own in Monument, CO. >>> >>> Dan >>> >>> >>> On 11/21/17 7:12 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> *** We are wrapping up code review on this project so it is time *** >>>> *** for the various code reviewers to chime in one last time. *** >>>> >>>> In this latest round, we had three different reviewers chime in so >>>> we're >>>> doing delta webrevs for each of those resolutions: >>>> >>>> David H's resolutions: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ >>>> >>>> >>>> ? mq comment for dholmes_CR: >>>> ??? - Fix indents, trailing spaces and various typos. >>>> ??? - Add descriptions for the '_cnt', '_max' and '_times" fields, >>>> ????? add impl notes to document the type choices. >>>> >>>> ? src/hotspot/share/runtime/globals.hpp change is white-space only >>>> so it >>>> ? is only visible via the file's patch link. >>>> >>>> >>>> Robin W's resolutions: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ >>>> >>>> >>>> ? mq comment for robinw_CR: >>>> ??? - Fix some inefficient code, update some comments, fix some >>>> indents, >>>> ????? and add some 'const' specifiers. >>>> >>>> ? src/hotspot/share/runtime/vm_operations.hpp change is white-space >>>> only so >>>> ? it is only visible via the file's patch link. >>>> >>>> >>>> Coleen's resolutions: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ >>>> >>>> >>>> ? mq comment for coleenp_CR: >>>> ??? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', >>>> ??? - add header comment to threadSMR.hpp file, >>>> ??? - cleanup JavaThreadIteratorWithHandle ctr, >>>> ??? - make ErrorHandling more efficient. >>>> >>>> >>>> Some folks prefer to see all of the delta webrevs together so here is >>>> a delta webrev relative to jdk10-09-full: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ >>>> >>>> >>>> ? src/hotspot/share/runtime/globals.hpp and >>>> ? src/hotspot/share/runtime/vm_operations.hpp changes are >>>> white-space only >>>> ? so they are only visible via the file's patch link. >>>> >>>> >>>> And, of course, some folks prefer to see everything all at once so >>>> here >>>> is the latest full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ >>>> >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The >>>> prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... >>>> >>>> The project is currently baselined on Jesper's 2017-11-17 PIT snapshot >>>> so there will be some catching up to do before integration... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Testing of the last round of changes revealed a hang in one of the >>>>> new >>>>> TLH tests. Robbin has fixed the hang, updated the existing TLH >>>>> test, and >>>>> added another TLH test for good measure. >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>>> >>>>> Here is the updated delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>>>> >>>>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>>>> no unexpected failures. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Robbin rebased the project last night/this morning to merge with >>>>>> Thread >>>>>> Local Handshakes (TLH) and also picked up additional changesets >>>>>> up thru: >>>>>> >>>>>>> Changeset: fa736014cf28 >>>>>>> Author:??? cjplummer >>>>>>> Date:????? 2017-11-14 18:08 -0800 >>>>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>>>> >>>>>>> 8191049: Add alternate version of pns() that is callable from >>>>>>> within hotspot source >>>>>>> Summary: added pns2() to debug.cpp >>>>>>> Reviewed-by: stuefe, gthornbr >>>>>> >>>>>> This is the first time we've rebased the project to bits that are >>>>>> this >>>>>> fresh (< 12 hours old at rebase time). We've done this because we >>>>>> think >>>>>> we're done with this project and are in the final >>>>>> review-change-retest >>>>>> cycle(s)... In other words, we're not planning on making any more >>>>>> major >>>>>> changes for this project... :-) >>>>>> >>>>>> *** Time for code reviewers to chime in on this thread! *** >>>>>> >>>>>> Here is the updated full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>>>> >>>>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>>>> >>>>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>>>> (and the new baseline also)... >>>>>> >>>>>> We're expecting this round to be a little noisier than usual because >>>>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>>>> through Jesper's usual care-and-feeding of integration_blockers, >>>>>> etc. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>>>> (Yes, we're playing chase-the-repo...) >>>>>>> >>>>>>> Here is the updated full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>>>> >>>>>>> Unlike the previous rebase, there were no changes required to the >>>>>>> open code to get the rebased bits to build so there is no delta >>>>>>> webrev. >>>>>>> >>>>>>> These bits have been run through JPRT and I've submitted the usual >>>>>>> Mach5 tier[1-5] test run... >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>>>> >>>>>>>> Here are the updated webrevs: >>>>>>>> >>>>>>>> Here's the mq comment for the change: >>>>>>>> >>>>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>>>> >>>>>>>> Here is the full webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>>>> >>>>>>>> And here is the delta webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>>>> >>>>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>>>> holiday >>>>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>>>> closer >>>>>>>> look today. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Dan, Erik and Robbin >>>>>>>> >>>>>>>> >>>>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>>>> and Coleen) >>>>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>>>> done as a >>>>>>>>> standalone patch and corresponding webrevs: >>>>>>>>> >>>>>>>>> Here's the mq comment for the change: >>>>>>>>> >>>>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>>>> to use >>>>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>>>> >>>>>>>>> Here is the full webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>>>> >>>>>>>>> And here is the delta webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>>>> >>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>> >>>>>>>>> Dan, Erik and Robbin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>>>> >>>>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>>>> >>>>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>>>> >>>>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>>>> describe >>>>>>>>>> and track the work on this project: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Dan has noticed that the indenting is wrong in some of the >>>>>>>>>> code quotes >>>>>>>>>> in the PDF that are not present in the internal wiki. We >>>>>>>>>> don't have a >>>>>>>>>> solution for that problem yet. >>>>>>>>>> >>>>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>>>> >>>>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>>>> tier[2-5] >>>>>>>>>> testing, additional stress testing on Dan's Solaris X64 >>>>>>>>>> server, and >>>>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>>>> >>>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>>> >>>>>>>>>> Daniel Daugherty >>>>>>>>>> Erik Osterlund >>>>>>>>>> Robbin Ehn >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> From aph at redhat.com Tue Nov 28 13:19:49 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Nov 2017 13:19:49 +0000 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> Message-ID: On 28/11/17 10:31, Ningsheng Jian wrote: > OK, AllocatePrefetchDistanceConstraintFunc has constraint to make sure > it should be [0, 512], which does not match document... OK, but this patch is about AllocatePrefetchDistance. Does your patch work with -1? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Tue Nov 28 17:16:20 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Nov 2017 09:16:20 -0800 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> <1511515343.2425.11.camel@oracle.com> <45aa8e04-9244-4089-001f-acba24e7e4ee@oracle.com> Message-ID: <4a7c6d8c-10ed-6fb0-1238-e1cf9b65baa4@oracle.com> UseCountedLoopSafepoints should be false by default too. Otherwise code in arguments.cpp will set LoopStripMiningIter to 1. I will remove next change in c2_globals.hpp: - product(bool, UseCountedLoopSafepoints, false, \ + product(bool, UseCountedLoopSafepoints, true, \ Thanks, Vladimir On 11/28/17 3:00 AM, Roland Westrelin wrote: > > Hi Vladimir, > >> Roland, please, prepare changeset. > > Here is the changeset: > > http://cr.openjdk.java.net/~roland/8186027/loop-strip-mining.patch > > It includes the patch below to enable it with G1. > > Roland. > > diff --git a/src/hotspot/share/gc/g1/g1Arguments.cpp b/src/hotspot/share/gc/g1/g1Arguments.cpp > --- a/src/hotspot/share/gc/g1/g1Arguments.cpp > +++ b/src/hotspot/share/gc/g1/g1Arguments.cpp > @@ -92,6 +92,16 @@ > } > > log_trace(gc)("MarkStackSize: %uk MarkStackSizeMax: %uk", (unsigned int) (MarkStackSize / K), (uint) (MarkStackSizeMax / K)); > + > +#ifdef COMPILER2 > + // Enable loop strip mining to offer better pause time guarantees > + if (FLAG_IS_DEFAULT(UseCountedLoopSafepoints)) { > + FLAG_SET_DEFAULT(UseCountedLoopSafepoints, true); > + } > + if (UseCountedLoopSafepoints && FLAG_IS_DEFAULT(LoopStripMiningIter)) { > + FLAG_SET_DEFAULT(LoopStripMiningIter, 1000); > + } > +#endif > } > > CollectedHeap* G1Arguments::create_heap() { > diff --git a/src/hotspot/share/opto/c2_globals.hpp b/src/hotspot/share/opto/c2_globals.hpp > --- a/src/hotspot/share/opto/c2_globals.hpp > +++ b/src/hotspot/share/opto/c2_globals.hpp > @@ -741,7 +741,7 @@ > develop(bool, RenumberLiveNodes, true, \ > "Renumber live nodes") \ > \ > - product(uintx, LoopStripMiningIter, 1000, \ > + product(uintx, LoopStripMiningIter, 0, \ > "Number of iterations in strip mined loop") \ > range(0, max_juint) \ > \ > From tobias.hartmann at oracle.com Tue Nov 28 17:32:12 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Nov 2017 18:32:12 +0100 Subject: [10] RFR(XS): 8191996: VM startup fails with CodeCacheExpansionSize=32768 is outside the allowed range Message-ID: <87cc6a9b-f0c1-b583-7d83-8028af4faadd@oracle.com> Hi, please review the following fix: https://bugs.openjdk.java.net/browse/JDK-8191996 http://cr.openjdk.java.net/~thartmann/8191996/webrev.00/ JDK-8179026 [1] set the minimum CodeCacheExpansionSize to vm_page_size() because in CodeCache::initialize() we align to page size anyway. However, there are platforms where the default CodeCacheExpansionSize is 32*K which might be < vm_page_size(). I've fixed this by setting the minimum value to 32*K. A better fix would be to set the default value to os::vm_page_size() (see [2]) but that would require including runtime/os.hpp which introduces circular dependencies. Thanks to Adrian for reporting this [3]. Thanks, Tobias [1] http://hg.openjdk.java.net/jdk/hs/rev/7f40c1cdde28 [2] http://cr.openjdk.java.net/~thartmann/8191996/webrev.01/ [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-November/029365.html From vladimir.kozlov at oracle.com Tue Nov 28 17:51:53 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Nov 2017 09:51:53 -0800 Subject: [10] RFR(XS): 8191996: VM startup fails with CodeCacheExpansionSize=32768 is outside the allowed range In-Reply-To: <87cc6a9b-f0c1-b583-7d83-8028af4faadd@oracle.com> References: <87cc6a9b-f0c1-b583-7d83-8028af4faadd@oracle.com> Message-ID: <1e373701-87a6-7b78-c501-3bb6bb25e1ea@oracle.com> Looks good. I don't think we can call a function to set flag value. We use only constants and macros. Thanks, Vladimir On 11/28/17 9:32 AM, Tobias Hartmann wrote: > Hi, > > please review the following fix: > https://bugs.openjdk.java.net/browse/JDK-8191996 > http://cr.openjdk.java.net/~thartmann/8191996/webrev.00/ > > JDK-8179026 [1] set the minimum CodeCacheExpansionSize to vm_page_size() because in CodeCache::initialize() we align to > page size anyway. However, there are platforms where the default CodeCacheExpansionSize is 32*K which might be < > vm_page_size(). I've fixed this by setting the minimum value to 32*K. > > A better fix would be to set the default value to os::vm_page_size() (see [2]) but that would require including > runtime/os.hpp which introduces circular dependencies. > > Thanks to Adrian for reporting this [3]. > > Thanks, > Tobias > > [1] http://hg.openjdk.java.net/jdk/hs/rev/7f40c1cdde28 > [2] http://cr.openjdk.java.net/~thartmann/8191996/webrev.01/ > [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-November/029365.html > From tobias.hartmann at oracle.com Tue Nov 28 17:53:48 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Nov 2017 18:53:48 +0100 Subject: [10] RFR(XS): 8191996: VM startup fails with CodeCacheExpansionSize=32768 is outside the allowed range In-Reply-To: <1e373701-87a6-7b78-c501-3bb6bb25e1ea@oracle.com> References: <87cc6a9b-f0c1-b583-7d83-8028af4faadd@oracle.com> <1e373701-87a6-7b78-c501-3bb6bb25e1ea@oracle.com> Message-ID: Hi Vladimir, thanks for the review! I'll push this directly because the fix is trivial. On 28.11.2017 18:51, Vladimir Kozlov wrote: > I don't think we can call a function to set flag value. We use only constants and macros. Yes, I think so too. Best regards, Tobias > On 11/28/17 9:32 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following fix: >> https://bugs.openjdk.java.net/browse/JDK-8191996 >> http://cr.openjdk.java.net/~thartmann/8191996/webrev.00/ >> >> JDK-8179026 [1] set the minimum CodeCacheExpansionSize to vm_page_size() because in CodeCache::initialize() we align to >> page size anyway. However, there are platforms where the default CodeCacheExpansionSize is 32*K which might be < >> vm_page_size(). I've fixed this by setting the minimum value to 32*K. >> >> A better fix would be to set the default value to os::vm_page_size() (see [2]) but that would require including >> runtime/os.hpp which introduces circular dependencies. >> >> Thanks to Adrian for reporting this [3]. >> >> Thanks, >> Tobias >> >> [1] http://hg.openjdk.java.net/jdk/hs/rev/7f40c1cdde28 >> [2] http://cr.openjdk.java.net/~thartmann/8191996/webrev.01/ >> [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-November/029365.html >> From Derek.White at cavium.com Tue Nov 28 19:50:05 2017 From: Derek.White at cavium.com (White, Derek) Date: Tue, 28 Nov 2017 19:50:05 +0000 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> Message-ID: Hi Andrew, AllocatePrefetchDistanceConstraintFunc is the bounds-checking function for AllocatePrefetchDistance. It's not possible run with -1 specified on the command line (with or without Ningsheng's patch). > java -XX:AllocatePrefetchDistance=-1 -version AllocatePrefetchDistance (-1) must be between 0 and 512 Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Andrew Haley > Sent: Tuesday, November 28, 2017 8:20 AM > To: Ningsheng Jian > Cc: hotspot compiler ; aarch64- > port-dev > Subject: Re: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch > distance causes an internal error > > On 28/11/17 10:31, Ningsheng Jian wrote: > > OK, AllocatePrefetchDistanceConstraintFunc has constraint to make sure > > it should be [0, 512], which does not match document... > > OK, but this patch is about AllocatePrefetchDistance. Does your patch work > with -1? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From tom.rodriguez at oracle.com Tue Nov 28 21:54:14 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 28 Nov 2017 13:54:14 -0800 Subject: RFR 8191052: [Graal] java/lang/invoke/CallSiteTest.java intermittently fails with "Failed dependency of type call_site_target_value" when running with Graal as JIT Message-ID: <5A1DDB06.30908@oracle.com> http://cr.openjdk.java.net/~never/8191052/webrev https://bugs.openjdk.java.net/browse/JDK-8191052 This consolidates the logic to validate dependencies before code installation. JVMCI was missing logic to treat call_site_target_value failures benignly and the code had also diverged over time. Tested with Graal and Truffle. mach5 testing is being submitted. tom From vladimir.kozlov at oracle.com Tue Nov 28 22:20:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Nov 2017 14:20:50 -0800 Subject: RFR 8191052: [Graal] java/lang/invoke/CallSiteTest.java intermittently fails with "Failed dependency of type call_site_target_value" when running with Graal as JIT In-Reply-To: <5A1DDB06.30908@oracle.com> References: <5A1DDB06.30908@oracle.com> Message-ID: On 11/28/17 1:54 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8191052/webrev > https://bugs.openjdk.java.net/browse/JDK-8191052 Looks good to me. > > This consolidates the logic to validate dependencies before code installation.? JVMCI was missing > logic to treat call_site_target_value failures benignly and the code had also diverged over time. > Tested with Graal and Truffle.? mach5 testing is being submitted. Please, add mach5 job link to confidential comment in JBS. Thanks, Vladimir > > > tom From vladimir.kozlov at oracle.com Wed Nov 29 01:55:22 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Nov 2017 17:55:22 -0800 Subject: [10] (S) RFR 8184361: AOT lib at jdk/lib/libjava.base-coop.so seems to override -XX:AOTLibrary= Message-ID: http://cr.openjdk.java.net/~kvn/8184361/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8184361 Change priority in which AOT libraries are loaded. First, load libraries specified by AOTLibrary. And then, well known libraries from JAVA installation directory. Don't load a library if an other library with the same name is already loaded. It will allow do quick experiments with modified libraries. Manual testing and AOT jtreg tests. Thanks, Vladimir From dean.long at oracle.com Wed Nov 29 01:58:17 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 28 Nov 2017 17:58:17 -0800 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function In-Reply-To: References: Message-ID: On 11/22/17 6:58 AM, Dmitry Chuyko wrote: > Hello, > > Please review a fix for JNI Critical test failures and crashes on > aarch64, it includes common tests changes. > > bug: https://bugs.openjdk.java.net/browse/JDK-8191129 > webrev: http://cr.openjdk.java.net/~dchuyko/8191129/webrev.00/ > > 1. Platform specific part > > Original fix from JDK-8167409 was imported, it makes failures more > deterministic: Unimplemented() or ShouldNotReachHere(). Implementation > of the feature is not complete so another change is to forcibly set > CriticalJNINatives to false during initialization. > Do you want to print a warning if the flag was set to true on the command-line? > 2. Common part (tests) > > Tests in criticalnatives read CriticalJNINatives flag using WhiteBox > and ignore values check if the flag is false. > Would "@requires vm.opt.CriticalJNINatives" also work? The rest looks OK. dl > Both tests pass on x86_64 and aarch64. > > -Dmitry > From dean.long at oracle.com Wed Nov 29 02:19:16 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 28 Nov 2017 18:19:16 -0800 Subject: [10] (S) RFR 8184361: AOT lib at jdk/lib/libjava.base-coop.so seems to override -XX:AOTLibrary= In-Reply-To: References: Message-ID: <55912432-7765-cec4-f7b7-df63f02cf2a1@oracle.com> On 11/28/17 5:55 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8184361/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8184361 > > Change priority in which AOT libraries are loaded. > > First, load libraries specified by AOTLibrary. And then, well known > libraries from JAVA installation directory. Don't load a library if an > other library with the same name is already loaded. > > It will allow do quick experiments with modified libraries. > > Manual testing and AOT jtreg tests. > > Thanks, > Vladimir It looks OK, but it imposes an undocumented? naming convention that must be followed.? If have use dir1/foo.so and dir2/foo.so, then only first will get loaded, so I need to use unique file names.? And if I (accidentally) name it lib.so, then the system version won't get loaded, so users must know the naming convention to avoid conflicts.? If users need to following a naming convention to avoid conflicts, then it might make sense to deprecate AOTLibrary and instead have something more convenient for multiple libraries, like a AOTLibraryPath search path option. I wonder if we should always print the warning, instead of putting it under PrintAOT. dl From vladimir.kozlov at oracle.com Wed Nov 29 02:38:21 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Nov 2017 18:38:21 -0800 Subject: [10] (S) RFR 8184361: AOT lib at jdk/lib/libjava.base-coop.so seems to override -XX:AOTLibrary= In-Reply-To: <55912432-7765-cec4-f7b7-df63f02cf2a1@oracle.com> References: <55912432-7765-cec4-f7b7-df63f02cf2a1@oracle.com> Message-ID: Thank you, Dean On 11/28/17 6:19 PM, dean.long at oracle.com wrote: > On 11/28/17 5:55 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8184361/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8184361 >> >> Change priority in which AOT libraries are loaded. >> >> First, load libraries specified by AOTLibrary. And then, well known libraries from JAVA >> installation directory. Don't load a library if an other library with the same name is already >> loaded. >> >> It will allow do quick experiments with modified libraries. >> >> Manual testing and AOT jtreg tests. >> >> Thanks, >> Vladimir > > It looks OK, but it imposes an undocumented? naming convention that must be followed.? If have use > dir1/foo.so and dir2/foo.so, then only first will get loaded, so I need to use unique file names. > And if I (accidentally) name it lib.so, then the system version won't get loaded, so users > must know the naming convention to avoid conflicts.? If users need to following a naming convention > to avoid conflicts, then it might make sense to deprecate AOTLibrary and instead have something more > convenient for multiple libraries, like a AOTLibraryPath search path option. Yes, you should use different names if you are loading AOT libraries with different classes. Allowing to load libraries with the same name was oversight. It cause at least one bug JDK-8167526 which you fixed. Search path has the same problem, I think. You don't know what will be loaded first. Names of well-known AOT libraries are documented in AOT JEP just before "Steps to generate and use an AOT library for the java.base module" section: http://openjdk.java.net/jeps/295 > > I wonder if we should always print the warning, instead of putting it under PrintAOT. This is what we do in other cases with AOT - most AOT messages are under PrintAOT. Thanks, Vladimir > > dl From ningsheng.jian at linaro.org Wed Nov 29 02:43:21 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Wed, 29 Nov 2017 10:43:21 +0800 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> Message-ID: Hi, Thanks for the review! Because of the constraint func, with and without the patch it will report an error for -1 input. But since the constraint func is called after get_processor_features, I've updated the patch to leave -1 to be handled by the constraint func. http://cr.openjdk.java.net/~njian/8191955/webrev.01/ With and without patch: $ java -XX:AllocatePrefetchDistance=-1 -version AllocatePrefetchDistance (-1) must be between 0 and 512 Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Thanks, Ningsheng On 29 November 2017 at 03:50, White, Derek wrote: > Hi Andrew, > > AllocatePrefetchDistanceConstraintFunc is the bounds-checking function for AllocatePrefetchDistance. It's not possible run with -1 specified on the command line (with or without Ningsheng's patch). > >> java -XX:AllocatePrefetchDistance=-1 -version > AllocatePrefetchDistance (-1) must be between 0 and 512 > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > - Derek > >> -----Original Message----- >> From: aarch64-port-dev [mailto:aarch64-port-dev- >> bounces at openjdk.java.net] On Behalf Of Andrew Haley >> Sent: Tuesday, November 28, 2017 8:20 AM >> To: Ningsheng Jian >> Cc: hotspot compiler ; aarch64- >> port-dev >> Subject: Re: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch >> distance causes an internal error >> >> On 28/11/17 10:31, Ningsheng Jian wrote: >> > OK, AllocatePrefetchDistanceConstraintFunc has constraint to make sure >> > it should be [0, 512], which does not match document... >> >> OK, but this patch is about AllocatePrefetchDistance. Does your patch work >> with -1? >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitry.chuyko at bell-sw.com Wed Nov 29 09:13:49 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 29 Nov 2017 12:13:49 +0300 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function In-Reply-To: References: Message-ID: <0548e175-ec4c-144c-00ef-34ce25e5bde4@bell-sw.com> Hi Dean, On 11/29/2017 04:58 AM, dean.long at oracle.com wrote: > On 11/22/17 6:58 AM, Dmitry Chuyko wrote: > >> Hello, >> >> Please review a fix for JNI Critical test failures and crashes on >> aarch64, it includes common tests changes. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8191129 >> webrev: http://cr.openjdk.java.net/~dchuyko/8191129/webrev.00/ >> >> 1. Platform specific part >> >> Original fix from JDK-8167409 was imported, it makes failures more >> deterministic: Unimplemented() or ShouldNotReachHere(). >> Implementation of the feature is not complete so another change is to >> forcibly set CriticalJNINatives to false during initialization. >> > > Do you want to print a warning if the flag was set to true on the > command-line? Thanks, I think we should do so. > >> 2. Common part (tests) >> >> Tests in criticalnatives read CriticalJNINatives flag using WhiteBox >> and ignore values check if the flag is false. >> > > Would "@requires vm.opt.CriticalJNINatives" also work? It would. But if we don't require it the tests also cover possible crashes (on ARM). -Dmitry > > The rest looks OK. > > dl > >> Both tests pass on x86_64 and aarch64. >> >> -Dmitry >> > From aph at redhat.com Wed Nov 29 10:17:32 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Nov 2017 10:17:32 +0000 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> Message-ID: <8f438b6d-d388-d560-0db9-37707e9f89be@redhat.com> On 28/11/17 19:50, White, Derek wrote: > AllocatePrefetchDistanceConstraintFunc is the bounds-checking function for AllocatePrefetchDistance. It's not possible run with -1 specified on the command line (with or without Ningsheng's patch). > >> java -XX:AllocatePrefetchDistance=-1 -version > AllocatePrefetchDistance (-1) must be between 0 and 512 > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. Fair enough. The patch is OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Nov 29 10:17:49 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Nov 2017 10:17:49 +0000 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> Message-ID: <1acbacd7-7967-8da3-2f67-f3babb40f909@redhat.com> On 29/11/17 02:43, Ningsheng Jian wrote: > Thanks for the review! Because of the constraint func, with and > without the patch it will report an error for -1 input. But since the > constraint func is called after get_processor_features, I've updated > the patch to leave -1 to be handled by the constraint func. > > http://cr.openjdk.java.net/~njian/8191955/webrev.01/ OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.x.ivanov at oracle.com Wed Nov 29 11:16:47 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Nov 2017 14:16:47 +0300 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function In-Reply-To: References: Message-ID: <2cb34bc7-98da-12b4-11af-0d8886747691@oracle.com> >> bug: https://bugs.openjdk.java.net/browse/JDK-8191129 >> webrev: http://cr.openjdk.java.net/~dchuyko/8191129/webrev.00/ >> 1. Platform specific part >> >> Original fix from JDK-8167409 was imported, it makes failures more >> deterministic: Unimplemented() or ShouldNotReachHere(). Implementation >> of the feature is not complete so another change is to forcibly set >> CriticalJNINatives to false during initialization. >> > > Do you want to print a warning if the flag was set to true on the > command-line? IMO it should be: if (CriticalJNINatives) { warning("CriticalJNINatives aren't supported"); FLAG_SET_DEFAULT(CriticalJNINatives, false); } There's on point in enabling it if it is known the functionality is broken. Also, I question putting it into VM_Version::initialize(). I haven't found a proper place for such checks, but VM_Version::get_processor_features() is where most of the platform-specific setup is performed (besides *_pd). Better to hear from aarch64 port maintainers where they prefer to see it. >> 2. Common part (tests) >> >> Tests in criticalnatives read CriticalJNINatives flag using WhiteBox >> and ignore values check if the flag is false. >> > > Would "@requires vm.opt.CriticalJNINatives" also work? I'd prefer to see the test explicitly specifying -XX:+CriticalJNINative and excluded on aarch64 (@requires os.arch != aarch64) until the missing functionality is implemented there. But I'm fine with "@requires vm.opt.CriticalJNINatives" as well. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Nov 29 11:50:31 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Nov 2017 14:50:31 +0300 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function In-Reply-To: <2cb34bc7-98da-12b4-11af-0d8886747691@oracle.com> References: <2cb34bc7-98da-12b4-11af-0d8886747691@oracle.com> Message-ID: <4130e57a-0369-915d-9c99-05e308b5d4e7@oracle.com> On 11/29/17 2:16 PM, Vladimir Ivanov wrote: > ? if (CriticalJNINatives) { > ??? warning("CriticalJNINatives aren't supported"); > ??? FLAG_SET_DEFAULT(CriticalJNINatives, false); > ? } What I meant is: if (CriticalJNINatives && !FLAG_IS_DEFAULT(CriticalJNINatives)) { warning("CriticalJNINatives aren't supported"); } FLAG_SET_DEFAULT(CriticalJNINatives, false); Sorry for the confusion. Best regards, Vladimir Ivanov From rwestrel at redhat.com Wed Nov 29 15:33:52 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 29 Nov 2017 16:33:52 +0100 Subject: RFR(L): 8186027: C2: loop strip mining In-Reply-To: <4a7c6d8c-10ed-6fb0-1238-e1cf9b65baa4@oracle.com> References: <35a024b5-6632-0488-a001-14f960257fc7@oracle.com> <8b9f8985-daae-b3b4-ba48-3d9c6185ed95@oracle.com> <0972a0db-2115-daa3-9990-7d58915a74a5@oracle.com> <3e3e2048-5ee5-f3c2-8ec0-cdd36cff07af@oracle.com> <7ae8403a-b650-5171-5d79-0107d7d99059@oracle.com> <1511515343.2425.11.camel@oracle.com> <45aa8e04-9244-4089-001f-acba24e7e4ee@oracle.com> <4a7c6d8c-10ed-6fb0-1238-e1cf9b65baa4@oracle.com> Message-ID: > UseCountedLoopSafepoints should be false by default too. Otherwise code in arguments.cpp will set LoopStripMiningIter to > 1. I will remove next change in c2_globals.hpp: > > - product(bool, UseCountedLoopSafepoints, false, \ > + product(bool, UseCountedLoopSafepoints, true, \ Right. Thanks for pushing this. Roland. From dean.long at oracle.com Wed Nov 29 17:42:59 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 29 Nov 2017 09:42:59 -0800 Subject: [10] (S) RFR 8184361: AOT lib at jdk/lib/libjava.base-coop.so seems to override -XX:AOTLibrary= In-Reply-To: References: <55912432-7765-cec4-f7b7-df63f02cf2a1@oracle.com> Message-ID: <1b9882cf-9218-0fc3-d7ce-dbf591190f75@oracle.com> On 11/28/17 6:38 PM, Vladimir Kozlov wrote: > Thank you, Dean > > On 11/28/17 6:19 PM, dean.long at oracle.com wrote: >> On 11/28/17 5:55 PM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/8184361/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8184361 >>> >>> Change priority in which AOT libraries are loaded. >>> >>> First, load libraries specified by AOTLibrary. And then, well known >>> libraries from JAVA installation directory. Don't load a library if >>> an other library with the same name is already loaded. >>> >>> It will allow do quick experiments with modified libraries. >>> >>> Manual testing and AOT jtreg tests. >>> >>> Thanks, >>> Vladimir >> >> It looks OK, but it imposes an undocumented? naming convention that >> must be followed.? If have use dir1/foo.so and dir2/foo.so, then only >> first will get loaded, so I need to use unique file names.? And if I >> (accidentally) name it lib.so, then the system version won't >> get loaded, so users must know the naming convention to avoid >> conflicts.? If users need to following a naming convention to avoid >> conflicts, then it might make sense to deprecate AOTLibrary and >> instead have something more convenient for multiple libraries, like a >> AOTLibraryPath search path option. > > Yes, you should use different names if you are loading AOT libraries > with different classes. > Allowing to load libraries with the same name was oversight. It cause > at least one bug JDK-8167526 which you fixed. > > Search path has the same problem, I think. You don't know what will be > loaded first. > > Names of well-known AOT libraries are documented in AOT JEP just > before "Steps to generate and use an AOT library for the java.base > module" section: > > http://openjdk.java.net/jeps/295 > >> >> I wonder if we should always print the warning, instead of putting it >> under PrintAOT. > > This is what we do in other cases with AOT - most AOT messages are > under PrintAOT. > OK, sounds good. dl > Thanks, > Vladimir > >> >> dl From vladimir.kozlov at oracle.com Wed Nov 29 18:26:03 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Nov 2017 10:26:03 -0800 Subject: [10] (S) RFR 8184361: AOT lib at jdk/lib/libjava.base-coop.so seems to override -XX:AOTLibrary= In-Reply-To: <1b9882cf-9218-0fc3-d7ce-dbf591190f75@oracle.com> References: <55912432-7765-cec4-f7b7-df63f02cf2a1@oracle.com> <1b9882cf-9218-0fc3-d7ce-dbf591190f75@oracle.com> Message-ID: <099a92d0-813b-6292-5ac6-ce6a1bae64d0@oracle.com> Thank you, Dean Vladimir On 11/29/17 9:42 AM, dean.long at oracle.com wrote: > On 11/28/17 6:38 PM, Vladimir Kozlov wrote: > >> Thank you, Dean >> >> On 11/28/17 6:19 PM, dean.long at oracle.com wrote: >>> On 11/28/17 5:55 PM, Vladimir Kozlov wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/8184361/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8184361 >>>> >>>> Change priority in which AOT libraries are loaded. >>>> >>>> First, load libraries specified by AOTLibrary. And then, well known libraries from JAVA installation directory. >>>> Don't load a library if an other library with the same name is already loaded. >>>> >>>> It will allow do quick experiments with modified libraries. >>>> >>>> Manual testing and AOT jtreg tests. >>>> >>>> Thanks, >>>> Vladimir >>> >>> It looks OK, but it imposes an undocumented? naming convention that must be followed.? If have use dir1/foo.so and >>> dir2/foo.so, then only first will get loaded, so I need to use unique file names.? And if I (accidentally) name it >>> lib.so, then the system version won't get loaded, so users must know the naming convention to avoid >>> conflicts.? If users need to following a naming convention to avoid conflicts, then it might make sense to deprecate >>> AOTLibrary and instead have something more convenient for multiple libraries, like a AOTLibraryPath search path option. >> >> Yes, you should use different names if you are loading AOT libraries with different classes. >> Allowing to load libraries with the same name was oversight. It cause at least one bug JDK-8167526 which you fixed. >> >> Search path has the same problem, I think. You don't know what will be loaded first. >> >> Names of well-known AOT libraries are documented in AOT JEP just before "Steps to generate and use an AOT library for >> the java.base module" section: >> >> http://openjdk.java.net/jeps/295 >> >>> >>> I wonder if we should always print the warning, instead of putting it under PrintAOT. >> >> This is what we do in other cases with AOT - most AOT messages are under PrintAOT. >> > > OK, sounds good. > > dl > >> Thanks, >> Vladimir >> >>> >>> dl > From eric.caspole at oracle.com Wed Nov 29 21:15:51 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 29 Nov 2017 16:15:51 -0500 Subject: RFR: 8191779 : LogCompilation throws java.lang.Error: scope underflow In-Reply-To: References: <27ea10eb-cc56-11e0-2b04-b73a89654b04@oracle.com> Message-ID: <13212278-8eb5-08a6-b2a4-d8b0a2733132@oracle.com> Thanks Vladimir! Could anyone else look at this? Thanks, Eric On 11/27/2017 07:00 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 11/27/17 3:08 PM, Eric Caspole wrote: >> Hi everybody, >> Apparently due to bit rot in the LogCompilation tool, there can be a >> "scope underflow" error thrown while processing recent logs. >> >> http://cr.openjdk.java.net/~ecaspole/JDK-8191779/webrev/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8191779 >> >> I currently have a scenario that creates this problem and tested the >> fix there. >> Thanks, >> Eric From cthalinger at twitter.com Wed Nov 29 21:33:44 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 29 Nov 2017 13:33:44 -0800 Subject: [10] (S) RFR 8184361: AOT lib at jdk/lib/libjava.base-coop.so seems to override -XX:AOTLibrary= In-Reply-To: References: Message-ID: > On Nov 28, 2017, at 5:55 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8184361/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8184361 > > Change priority in which AOT libraries are loaded. > > First, load libraries specified by AOTLibrary. And then, well known libraries from JAVA installation directory. Don't load a library if an other library with the same name is already loaded. Looks good. > > It will allow do quick experiments with modified libraries. > > Manual testing and AOT jtreg tests. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Nov 29 22:03:35 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Nov 2017 14:03:35 -0800 Subject: [10] (S) RFR 8184361: AOT lib at jdk/lib/libjava.base-coop.so seems to override -XX:AOTLibrary= In-Reply-To: References: Message-ID: <8ec146ef-defd-4a00-de86-c6eeb8fdab0b@oracle.com> Thank you, Chris Vladimir On 11/29/17 1:33 PM, Christian Thalinger wrote: > > >> On Nov 28, 2017, at 5:55 PM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8184361/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8184361 >> >> Change priority in which AOT libraries are loaded. >> >> First, load libraries specified by AOTLibrary. And then, well known libraries from JAVA installation directory. Don't load a library if an other library with the same name is already loaded. > > Looks good. > >> >> It will allow do quick experiments with modified libraries. >> >> Manual testing and AOT jtreg tests. >> >> Thanks, >> Vladimir > From ningsheng.jian at linaro.org Thu Nov 30 01:39:11 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Thu, 30 Nov 2017 09:39:11 +0800 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: <1acbacd7-7967-8da3-2f67-f3babb40f909@redhat.com> References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> <1acbacd7-7967-8da3-2f67-f3babb40f909@redhat.com> Message-ID: Thank you Andrew! Regards, Ningsheng On 29 November 2017 at 18:17, Andrew Haley wrote: > On 29/11/17 02:43, Ningsheng Jian wrote: >> Thanks for the review! Because of the constraint func, with and >> without the patch it will report an error for -1 input. But since the >> constraint func is called after get_processor_features, I've updated >> the patch to leave -1 to be handled by the constraint func. >> >> http://cr.openjdk.java.net/~njian/8191955/webrev.01/ > > OK. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From igor.veresov at oracle.com Thu Nov 30 06:59:33 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 29 Nov 2017 22:59:33 -0800 Subject: RFR(XXS) 8192756: SIGSEGV in nmethod::new_native_nmethod Message-ID: <9072916D-23D7-41BF-8ADE-59411CB86856@oracle.com> Add the missing null check. Webrev: http://cr.openjdk.java.net/~iveresov/8192756/webrev.00/ Thanks, igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.ulasevich at bell-sw.com Thu Nov 30 09:20:20 2017 From: boris.ulasevich at bell-sw.com (boris.ulasevich at bell-sw.com) Date: Thu, 30 Nov 2017 12:20:20 +0300 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter Message-ID: <712921512033620@web42g.yandex.ru> An HTML attachment was scrubbed... URL: From boris.ulasevich at bell-sw.com Thu Nov 30 09:47:31 2017 From: boris.ulasevich at bell-sw.com (Boris) Date: Thu, 30 Nov 2017 12:47:31 +0300 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <712921512033620@web42g.yandex.ru> References: <712921512033620@web42g.yandex.ru> Message-ID: [this time in plain text] Please review bugfix to enable parameters type profiling missing in aarch64 interpreter to make it consistent with other ports. Additionally to aarch64 specific change I am going to add shared jtreg test to discover the case I have fixed. The test is very similar to TestArrayCopyNoInitDeopt.java (see JDK-8188221, Return type profiling is not performed from aarch64 interpreter). The test expects to see additional C2 deoptimization caused by speculative type check when profiling data became outdated. Existing profile_parameters_type() got minor fix and it is now used in interpreted method entries. CR: https://bugs.openjdk.java.net/browse/JDK-8189439 Webrew: http://cr.openjdk.java.net/~dchuyko/8189439/webrev.00/ Tested with jtreg on ARM64, X86. New test works Ok on X86, and the given change fixes test fail on ARM64. Thanks, Boris Ulasevich From aph at redhat.com Thu Nov 30 10:21:16 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Nov 2017 10:21:16 +0000 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: References: <712921512033620@web42g.yandex.ru> Message-ID: <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> On 30/11/17 09:47, Boris wrote: > [this time in plain text] > > Please review bugfix to enable parameters type profiling missing in > aarch64 interpreter to make it consistent with other ports. > > Additionally to aarch64 specific change I am going to add shared jtreg > test to discover the case I have fixed. The test is very similar to > TestArrayCopyNoInitDeopt.java (see JDK-8188221, Return type profiling is > not performed from aarch64 interpreter). The test expects to see > additional C2 deoptimization caused by speculative type check when > profiling data became outdated. > > Existing profile_parameters_type() got minor fix and it is now used in > interpreted method entries. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8189439 > > Webrew: > http://cr.openjdk.java.net/~dchuyko/8189439/webrev.00/ Good catch! Some comments: In this hunk, there is one other change needed: 1753 // Load the offset of the area within the MDO used for 1754 // parameters. If it's negative we're not profiling any parameters 1755 ldr(tmp1, Address(mdp, in_bytes(MethodData::parameters_type_data_di_offset()) - in_bytes(MethodData::data_offset()))); I think this should be ldrw. 1756 tbnz(tmp1, 31, profile_continue); // i.e. sign bit set The changes to orptr don't seem to do anything. There is no need to parameterize rscratch1, which is available as a scratch register to all assembler macros. Is there a register conflict in there somewhere? I'm wondering if perhaps we should get rid of optr altogether, because it does not help readability at all. In this hunk, tmp1 and tmp2 doesn't seem to have any purpose. All they do is make the code more complicated. 1674 Register tmp1 = r1; 1675 Register tmp2 = r2; 1676 Register mdp = r4; 1677 Label no_mdp; 1678 __ ldr(mdp, Address(rmethod, Method::method_data_offset())); 1679 __ cbz(mdp, no_mdp); 1680 __ add(mdp, mdp, in_bytes(MethodData::data_offset())); 1681 __ profile_parameters_type(mdp, tmp1, tmp2); 1682 __ bind(no_mdp); 1683 Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From boris.ulasevich at bell-sw.com Thu Nov 30 12:55:29 2017 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Thu, 30 Nov 2017 15:55:29 +0300 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> Message-ID: <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> 30.11.2017 13:21, Andrew Haley wrote: > On 30/11/17 09:47, Boris wrote: >> [this time in plain text] >> >> Please review bugfix to enable parameters type profiling missing in >> aarch64 interpreter to make it consistent with other ports. >> >> Additionally to aarch64 specific change I am going to add shared jtreg >> test to discover the case I have fixed. The test is very similar to >> TestArrayCopyNoInitDeopt.java (see JDK-8188221, Return type profiling is >> not performed from aarch64 interpreter). The test expects to see >> additional C2 deoptimization caused by speculative type check when >> profiling data became outdated. >> >> Existing profile_parameters_type() got minor fix and it is now used in >> interpreted method entries. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8189439 >> >> Webrew: >> http://cr.openjdk.java.net/~dchuyko/8189439/webrev.00/ > > Good catch! Some comments: > > In this hunk, there is one other change needed: > > 1753 // Load the offset of the area within the MDO used for > 1754 // parameters. If it's negative we're not profiling any parameters > 1755 ldr(tmp1, Address(mdp, in_bytes(MethodData::parameters_type_data_di_offset()) - in_bytes(MethodData::data_offset()))); > > I think this should be ldrw. > > 1756 tbnz(tmp1, 31, profile_continue); // i.e. sign bit set > > The changes to orptr don't seem to do anything. There is no need to > parameterize rscratch1, which is available as a scratch register to > all assembler macros. Is there a register conflict in there > somewhere? I'm wondering if perhaps we should get rid of optr > altogether, because it does not help readability at all. > > In this hunk, tmp1 and tmp2 doesn't seem to have any purpose. All they > do is make the code more complicated. > > 1674 Register tmp1 = r1; > 1675 Register tmp2 = r2; > 1676 Register mdp = r4; > 1677 Label no_mdp; > 1678 __ ldr(mdp, Address(rmethod, Method::method_data_offset())); > 1679 __ cbz(mdp, no_mdp); > 1680 __ add(mdp, mdp, in_bytes(MethodData::data_offset())); > 1681 __ profile_parameters_type(mdp, tmp1, tmp2); > 1682 __ bind(no_mdp); > 1683 > > Thanks. > I agree with you on ldrw and excessive tmp1/tmp2. About orptr - yes, we have register conflict on rscratch2 which is used as arg_type pointer in profile_parameters_type and profile_obj_type methods. I have updated orptr to use rscratch1 directly. Updated Webrew: http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.01/ Thank you, Boris Ulasevich From aph at redhat.com Thu Nov 30 13:00:32 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Nov 2017 13:00:32 +0000 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> Message-ID: <6e422a25-e3c6-23ee-a982-1c3b5d495b6c@redhat.com> On 30/11/17 12:55, Boris Ulasevich wrote: > I agree with you on ldrw and excessive tmp1/tmp2. About orptr - yes, we > have register conflict on rscratch2 which is used as arg_type pointer in > profile_parameters_type and profile_obj_type methods. I have updated > orptr to use rscratch1 directly. > > Updated Webrew: > http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.01/ Ah, OK. That use of arg_type really needs an assert_different_registers with rscratch1 and the other args. Please add that, and your patch is good to go. Thanks! -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From tobias.hartmann at oracle.com Thu Nov 30 13:00:35 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 30 Nov 2017 14:00:35 +0100 Subject: RFR(XXS) 8192756: SIGSEGV in nmethod::new_native_nmethod In-Reply-To: <9072916D-23D7-41BF-8ADE-59411CB86856@oracle.com> References: <9072916D-23D7-41BF-8ADE-59411CB86856@oracle.com> Message-ID: Hi Igor, looks good. Best regards, Tobias On 30.11.2017 07:59, Igor Veresov wrote: > Add the missing null check. > > Webrev:?http://cr.openjdk.java.net/~iveresov/8192756/webrev.00/ > > Thanks, > igor From tobias.hartmann at oracle.com Thu Nov 30 13:02:31 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 30 Nov 2017 14:02:31 +0100 Subject: RFR: 8191779 : LogCompilation throws java.lang.Error: scope underflow In-Reply-To: <13212278-8eb5-08a6-b2a4-d8b0a2733132@oracle.com> References: <27ea10eb-cc56-11e0-2b04-b73a89654b04@oracle.com> <13212278-8eb5-08a6-b2a4-d8b0a2733132@oracle.com> Message-ID: <37708ee3-0826-7a33-7d4a-1196fe89bed2@oracle.com> Hi Eric, On 29.11.2017 22:15, Eric Caspole wrote: > Could anyone else look at this? Looks good to me too. Best regards, Tobias From rwestrel at redhat.com Thu Nov 30 15:00:16 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 30 Nov 2017 16:00:16 +0100 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> Message-ID: Hi Boris, > Updated Webrew: > http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.01/ FYI, the current practice is to not use the bug number in the test name but instead use a descriptive name. Also test/hotspot/jtreg/compiler/profiling would be a better location for the test. Roland. From vivek.r.deshpande at intel.com Thu Nov 30 15:28:20 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 30 Nov 2017 15:28:20 +0000 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> Hi I have bug fix for 8190494: Different results with UseAVX=3 when calling AVX-512 native function via JNI. Mask register not being reset after JNI and the scalar floating point instructions using the mask register encoding with AVX 512 in the assembler causing this problem. I have tested it with jtreg on hotspot/compiler and SPECjvm2008 on knights landing and skylake. Webrev: http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ I have also updated the JBS entry. https://bugs.openjdk.java.net/browse/JDK-8190494 Would you please review and sponsor it. Regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Nov 30 15:35:07 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 07:35:07 -0800 Subject: RFR(XXS) 8192756: SIGSEGV in nmethod::new_native_nmethod In-Reply-To: <9072916D-23D7-41BF-8ADE-59411CB86856@oracle.com> References: <9072916D-23D7-41BF-8ADE-59411CB86856@oracle.com> Message-ID: <1bf3a0d9-39ed-dbaa-ce1f-3d2dfce33072@oracle.com> Good. Thanks, Vladimir On 11/29/17 10:59 PM, Igor Veresov wrote: > Add the missing null check. > > Webrev: http://cr.openjdk.java.net/~iveresov/8192756/webrev.00/ > > Thanks, > igor From igor.veresov at oracle.com Thu Nov 30 16:03:10 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 30 Nov 2017 08:03:10 -0800 Subject: RFR(XXS) 8192756: SIGSEGV in nmethod::new_native_nmethod In-Reply-To: <1bf3a0d9-39ed-dbaa-ce1f-3d2dfce33072@oracle.com> References: <9072916D-23D7-41BF-8ADE-59411CB86856@oracle.com> <1bf3a0d9-39ed-dbaa-ce1f-3d2dfce33072@oracle.com> Message-ID: <81A6B0CA-7D20-4D14-BEC5-36282F5A234C@oracle.com> Thanks, Vladimir and Tobias! igor > On Nov 30, 2017, at 7:35 AM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 11/29/17 10:59 PM, Igor Veresov wrote: >> Add the missing null check. >> Webrev: http://cr.openjdk.java.net/~iveresov/8192756/webrev.00/ >> Thanks, >> igor From lutz.schmidt at sap.com Thu Nov 30 16:14:25 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 30 Nov 2017 16:14:25 +0000 Subject: RFR(XS): 8192818: [s390]: restoring register contents calculates wrong value Message-ID: <74C2EC38-9DA2-4B89-AAA9-FE5927FF1CC9@sap.com> Dear all, I would like to request reviews for this s390-only bux fix (one-liner): Bug: https://bugs.openjdk.java.net/browse/JDK-8192818 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8192818.00/index.html Thank you! Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Thu Nov 30 16:22:27 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Thu, 30 Nov 2017 21:52:27 +0530 Subject: [10] RFR: 8006887: Comment about LIR_OprDesc.value in c1_LIR.hpp is incorrect Message-ID: <2e327521-c312-c9d8-a7a7-ab410391065a@oracle.com> Hi, request for review, webrev: http://cr.openjdk.java.net/~jcm/8006887/webrev.00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8006887 desc: comment correction. Best regards, Jamsheed From boris.ulasevich at bell-sw.com Thu Nov 30 16:28:04 2017 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Thu, 30 Nov 2017 19:28:04 +0300 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> Message-ID: <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> Thanks for good points! Updated webrew (with asserts and renamed test moved to better location): http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ best regards, Boris Ulasevich 30.11.2017 18:00, Roland Westrelin ?????: > Hi Boris, > >> Updated Webrew: >> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.01/ > FYI, the current practice is to not use the bug number in the test name > but instead use a descriptive name. Also > test/hotspot/jtreg/compiler/profiling would be a better location for the > test. > > Roland. From aph at redhat.com Thu Nov 30 16:31:57 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Nov 2017 16:31:57 +0000 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> Message-ID: <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> On 30/11/17 16:28, Boris Ulasevich wrote: > Thanks for good points! > > Updated webrew (with asserts and renamed test moved to better location): > http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ Great, that's good to go. I think you have to get someone from Oracle to help because it includes a new test case. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dean.long at oracle.com Thu Nov 30 16:49:58 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 30 Nov 2017 08:49:58 -0800 Subject: [10] RFR: 8006887: Comment about LIR_OprDesc.value in c1_LIR.hpp is incorrect In-Reply-To: <2e327521-c312-c9d8-a7a7-ab410391065a@oracle.com> References: <2e327521-c312-c9d8-a7a7-ab410391065a@oracle.com> Message-ID: <606dbd1a-1c27-6df8-2e2f-89326e687af3@oracle.com> Looks good. dl On 11/30/17 8:22 AM, jamsheed wrote: > Hi, > > request for review, > > webrev: http://cr.openjdk.java.net/~jcm/8006887/webrev.00/ > > jbs: https://bugs.openjdk.java.net/browse/JDK-8006887 > > desc: comment correction. > > Best regards, > > Jamsheed > From vladimir.kozlov at oracle.com Thu Nov 30 16:50:05 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 08:50:05 -0800 Subject: [10] RFR: 8006887: Comment about LIR_OprDesc.value in c1_LIR.hpp is incorrect In-Reply-To: <2e327521-c312-c9d8-a7a7-ab410391065a@oracle.com> References: <2e327521-c312-c9d8-a7a7-ab410391065a@oracle.com> Message-ID: <4da10d62-c0c0-bc86-ac3f-1135c77a6660@oracle.com> Hi Jamsheed There are no diffs in webrev. Vladimir On 11/30/17 8:22 AM, jamsheed wrote: > Hi, > > request for review, > > webrev: http://cr.openjdk.java.net/~jcm/8006887/webrev.00/ > > jbs: https://bugs.openjdk.java.net/browse/JDK-8006887 > > desc: comment correction. > > Best regards, > > Jamsheed > From dean.long at oracle.com Thu Nov 30 16:53:15 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 30 Nov 2017 08:53:15 -0800 Subject: [10] RFR: 8006887: Comment about LIR_OprDesc.value in c1_LIR.hpp is incorrect In-Reply-To: <4da10d62-c0c0-bc86-ac3f-1135c77a6660@oracle.com> References: <2e327521-c312-c9d8-a7a7-ab410391065a@oracle.com> <4da10d62-c0c0-bc86-ac3f-1135c77a6660@oracle.com> Message-ID: <43e99ac2-9767-8f31-6493-2b3a0347f447@oracle.com> It's all white space.? Take a look here: http://cr.openjdk.java.net/~jcm/8006887/webrev.00/open.patch dl On 11/30/17 8:50 AM, Vladimir Kozlov wrote: > Hi Jamsheed > > There are no diffs in webrev. > > Vladimir > > On 11/30/17 8:22 AM, jamsheed wrote: >> Hi, >> >> request for review, >> >> webrev: http://cr.openjdk.java.net/~jcm/8006887/webrev.00/ >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8006887 >> >> desc: comment correction. >> >> Best regards, >> >> Jamsheed >> From vladimir.kozlov at oracle.com Thu Nov 30 16:55:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 08:55:52 -0800 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> Message-ID: <5fd2f8dd-bf78-12ce-3620-0cdd1eb84fc3@oracle.com> Thank you, Vivek Changes looks good based on your description. Please, explain why using mask register in scalar instructions is bad. I will start pre-integration testing and let you know results. Thanks, Vladimir On 11/30/17 7:28 AM, Deshpande, Vivek R wrote: > Hi > > I have bug fix for 8190494: Different results with UseAVX=3 when calling AVX-512 native function via JNI. > > Mask register not being reset after JNI and the scalar floating point instructions using the mask register encoding with > AVX 512 in the assembler causing this problem. > > I have tested it with jtreg on hotspot/compiler and SPECjvm2008 on knights landing and skylake. > > Webrev: > > http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ > > I have also updated the JBS entry. > > https://bugs.openjdk.java.net/browse/JDK-8190494 > > Would you please review and sponsor it. > > Regards, > > Vivek > From vladimir.kozlov at oracle.com Thu Nov 30 16:57:39 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 08:57:39 -0800 Subject: [10] RFR: 8006887: Comment about LIR_OprDesc.value in c1_LIR.hpp is incorrect In-Reply-To: <4da10d62-c0c0-bc86-ac3f-1135c77a6660@oracle.com> References: <2e327521-c312-c9d8-a7a7-ab410391065a@oracle.com> <4da10d62-c0c0-bc86-ac3f-1135c77a6660@oracle.com> Message-ID: <411d55a3-015d-6854-30d2-daf70092e790@oracle.com> Difference (spacing) could be seen here: http://cr.openjdk.java.net/~jcm/8006887/webrev.00/open.patch Looks good. Vladimir On 11/30/17 8:50 AM, Vladimir Kozlov wrote: > Hi Jamsheed > > There are no diffs in webrev. > > Vladimir > > On 11/30/17 8:22 AM, jamsheed wrote: >> Hi, >> >> request for review, >> >> webrev: http://cr.openjdk.java.net/~jcm/8006887/webrev.00/ >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8006887 >> >> desc: comment correction. >> >> Best regards, >> >> Jamsheed >> From martin.doerr at sap.com Thu Nov 30 17:17:20 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 30 Nov 2017 17:17:20 +0000 Subject: RFR(S): 8192825: PPC64: Missing null check in C1 inline cache check Message-ID: <7b820cb2a7b345c7851aa9a74bdb1545@sap.com> Hi, I found a problem on AIX which is cause by a missing null check. Compiled methods need to perform a null check in the unverified entry. This is usually done implicitly by loading the Klass*. However, implicit null checks may be off on PPC64 (especially on AIX where the 0 page is readable). Null checks are especially needed after: 8160543: C1: Crash in java.lang.String.indexOf in some java.sql tests Summary: C1 must use unverified entry point for unloaded methods. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8192825_PPC64_C1_ic_nullcheck/webrev.00/ Please review. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.caspole at oracle.com Thu Nov 30 17:57:00 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 30 Nov 2017 12:57:00 -0500 Subject: RFR: 8192821 : Make LogCompilation into a maven project Message-ID: Hi everyone, please review this change to build the LogCompilation tool with Maven rather than a Makefile, so it can easily be imported and used with IDEs. This will allow in future for test cases etc and help prevent bit rot in this useful tool. Thanks, Eric JBS: https://bugs.openjdk.java.net/browse/JDK-8192821 webrev: http://cr.openjdk.java.net/~ecaspole/JDK-8192821/webrev/ From vladimir.kozlov at oracle.com Thu Nov 30 18:08:15 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 10:08:15 -0800 Subject: RFR: 8192821 : Make LogCompilation into a maven project In-Reply-To: References: Message-ID: <44c0c5a2-efdf-e9b5-5088-eeba5392c74a@oracle.com> Thank you, Eric Can you still keep ability to build with Makefile? Please, update README with how to build with Maven. Thanks, Vladimir On 11/30/17 9:57 AM, Eric Caspole wrote: > Hi everyone, please review this change to build the LogCompilation tool with Maven rather than a Makefile, so it can > easily be imported and used with IDEs. This will allow in future for test cases etc and help prevent bit rot in this > useful tool. > Thanks, > Eric > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8192821 > > webrev: http://cr.openjdk.java.net/~ecaspole/JDK-8192821/webrev/ From eric.caspole at oracle.com Thu Nov 30 18:11:52 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 30 Nov 2017 13:11:52 -0500 Subject: RFR: 8192821 : Make LogCompilation into a maven project In-Reply-To: <44c0c5a2-efdf-e9b5-5088-eeba5392c74a@oracle.com> References: <44c0c5a2-efdf-e9b5-5088-eeba5392c74a@oracle.com> Message-ID: On 11/30/2017 01:08 PM, Vladimir Kozlov wrote: > Thank you, Eric > > Can you still keep ability to build with Makefile? > Please, update README with how to build with Maven. Sure let me fix the old Makefile to fit the new structure and I will update the webrev. > > Thanks, > Vladimir > > On 11/30/17 9:57 AM, Eric Caspole wrote: >> Hi everyone, please review this change to build the LogCompilation >> tool with Maven rather than a Makefile, so it can easily be imported >> and used with IDEs. This will allow in future for test cases etc and >> help prevent bit rot in this useful tool. >> Thanks, >> Eric >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8192821 >> >> webrev: http://cr.openjdk.java.net/~ecaspole/JDK-8192821/webrev/ From dmitry.chuyko at bell-sw.com Thu Nov 30 18:22:42 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 30 Nov 2017 21:22:42 +0300 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function In-Reply-To: <4130e57a-0369-915d-9c99-05e308b5d4e7@oracle.com> References: <2cb34bc7-98da-12b4-11af-0d8886747691@oracle.com> <4130e57a-0369-915d-9c99-05e308b5d4e7@oracle.com> Message-ID: <6902d304-e1bf-5473-3f39-80869de85280@bell-sw.com> http://cr.openjdk.java.net/~dchuyko/8191129/webrev.01/ I think for tests it then will be better to explicitly exclude aarch64 until complete feature implementation and to add the flag. Flag disabling was changed to UNSUPPORTED_OPTION() which also prints a warning in case of manual -XX+. -Dmitry On 11/29/2017 02:50 PM, Vladimir Ivanov wrote: > > > On 11/29/17 2:16 PM, Vladimir Ivanov wrote: >> ?? if (CriticalJNINatives) { >> ???? warning("CriticalJNINatives aren't supported"); >> ???? FLAG_SET_DEFAULT(CriticalJNINatives, false); >> ?? } > > What I meant is: > ? if (CriticalJNINatives && !FLAG_IS_DEFAULT(CriticalJNINatives)) { > ??? warning("CriticalJNINatives aren't supported"); > ? } > ? FLAG_SET_DEFAULT(CriticalJNINatives, false); > > Sorry for the confusion. > > Best regards, > Vladimir Ivanov From eric.caspole at oracle.com Thu Nov 30 19:14:16 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 30 Nov 2017 14:14:16 -0500 Subject: RFR: 8192821 : Make LogCompilation into a maven project In-Reply-To: <44c0c5a2-efdf-e9b5-5088-eeba5392c74a@oracle.com> References: <44c0c5a2-efdf-e9b5-5088-eeba5392c74a@oracle.com> Message-ID: On 11/30/2017 01:08 PM, Vladimir Kozlov wrote: > Thank you, Eric > > Can you still keep ability to build with Makefile? New one: http://cr.openjdk.java.net/~ecaspole/JDK-8192821/02/webrev/ Yes now 'make' still works. Also I added a step in the maven build to copy the artifact to the top as logc.jar, so now whether you build with maven or make you will get a logc.jar at the top as it has always worked, that are functionally the same. > Please, update README with how to build with Maven. Done. Also I forgot to say earlier I made slight changes to modernize the javadoc markup in LogParser.java so the javadoc builds in maven. Is this OK for 10? Thanks, Eric > > Thanks, > Vladimir > > On 11/30/17 9:57 AM, Eric Caspole wrote: >> Hi everyone, please review this change to build the LogCompilation >> tool with Maven rather than a Makefile, so it can easily be imported >> and used with IDEs. This will allow in future for test cases etc and >> help prevent bit rot in this useful tool. >> Thanks, >> Eric >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8192821 >> >> webrev: http://cr.openjdk.java.net/~ecaspole/JDK-8192821/webrev/ From dean.long at oracle.com Thu Nov 30 20:00:16 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 30 Nov 2017 12:00:16 -0800 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function In-Reply-To: <6902d304-e1bf-5473-3f39-80869de85280@bell-sw.com> References: <2cb34bc7-98da-12b4-11af-0d8886747691@oracle.com> <4130e57a-0369-915d-9c99-05e308b5d4e7@oracle.com> <6902d304-e1bf-5473-3f39-80869de85280@bell-sw.com> Message-ID: <22c27b8e-abf4-6831-2138-bd02d52fa56c@oracle.com> Does @requires vm.opt.CriticalJNINatives still work instead of os.arch != "aarch64" (I'm not sure if flags on the @run line are added to "vm.opt")? If not, looks good. dl On 11/30/17 10:22 AM, Dmitry Chuyko wrote: > http://cr.openjdk.java.net/~dchuyko/8191129/webrev.01/ > > I think for tests it then will be better to explicitly exclude aarch64 > until complete feature implementation and to add the flag. > > Flag disabling was changed to UNSUPPORTED_OPTION() which also prints a > warning in case of manual -XX+. > > -Dmitry > > > On 11/29/2017 02:50 PM, Vladimir Ivanov wrote: >> >> >> On 11/29/17 2:16 PM, Vladimir Ivanov wrote: >>> ?? if (CriticalJNINatives) { >>> ???? warning("CriticalJNINatives aren't supported"); >>> ???? FLAG_SET_DEFAULT(CriticalJNINatives, false); >>> ?? } >> >> What I meant is: >> ? if (CriticalJNINatives && !FLAG_IS_DEFAULT(CriticalJNINatives)) { >> ??? warning("CriticalJNINatives aren't supported"); >> ? } >> ? FLAG_SET_DEFAULT(CriticalJNINatives, false); >> >> Sorry for the confusion. >> >> Best regards, >> Vladimir Ivanov > From dmitry.chuyko at bell-sw.com Thu Nov 30 20:27:17 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 30 Nov 2017 23:27:17 +0300 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function In-Reply-To: <22c27b8e-abf4-6831-2138-bd02d52fa56c@oracle.com> References: <2cb34bc7-98da-12b4-11af-0d8886747691@oracle.com> <4130e57a-0369-915d-9c99-05e308b5d4e7@oracle.com> <6902d304-e1bf-5473-3f39-80869de85280@bell-sw.com> <22c27b8e-abf4-6831-2138-bd02d52fa56c@oracle.com> Message-ID: <56dcd9b9-4d8f-19e3-89dc-2c2142838ac5@bell-sw.com> On 11/30/2017 11:00 PM, dean.long at oracle.com wrote: > Does @requires vm.opt.CriticalJNINatives still work instead of os.arch > != "aarch64" (I'm not sure if flags on the @run line are added to > "vm.opt")? It is actually vm.opt.CriticalJNINatives==null for me on x86 either explicit or implicit run setting (whitebox declarations added etc.) which looks more like it doesn't work. -Dmitry > > If not, looks good. > > dl > > > On 11/30/17 10:22 AM, Dmitry Chuyko wrote: >> http://cr.openjdk.java.net/~dchuyko/8191129/webrev.01/ >> >> I think for tests it then will be better to explicitly exclude >> aarch64 until complete feature implementation and to add the flag. >> >> Flag disabling was changed to UNSUPPORTED_OPTION() which also prints >> a warning in case of manual -XX+. >> >> -Dmitry >> >> >> On 11/29/2017 02:50 PM, Vladimir Ivanov wrote: >>> >>> >>> On 11/29/17 2:16 PM, Vladimir Ivanov wrote: >>>> ?? if (CriticalJNINatives) { >>>> ???? warning("CriticalJNINatives aren't supported"); >>>> ???? FLAG_SET_DEFAULT(CriticalJNINatives, false); >>>> ?? } >>> >>> What I meant is: >>> ? if (CriticalJNINatives && !FLAG_IS_DEFAULT(CriticalJNINatives)) { >>> ??? warning("CriticalJNINatives aren't supported"); >>> ? } >>> ? FLAG_SET_DEFAULT(CriticalJNINatives, false); >>> >>> Sorry for the confusion. >>> >>> Best regards, >>> Vladimir Ivanov >> > From vladimir.kozlov at oracle.com Thu Nov 30 20:43:18 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 12:43:18 -0800 Subject: RFR: 8192821 : Make LogCompilation into a maven project In-Reply-To: References: <44c0c5a2-efdf-e9b5-5088-eeba5392c74a@oracle.com> Message-ID: <0c723c3e-81ce-b2ca-45ed-ac92858c2ea0@oracle.com> On 11/30/17 11:14 AM, Eric Caspole wrote: > > On 11/30/2017 01:08 PM, Vladimir Kozlov wrote: >> Thank you, Eric >> >> Can you still keep ability to build with Makefile? > > New one: http://cr.openjdk.java.net/~ecaspole/JDK-8192821/02/webrev/ Good. > > Yes now 'make' still works. Also I added a step in the maven build to copy the artifact to the top > as logc.jar, so now whether you build with maven or make you will get a logc.jar at the top as it > has always worked, that are functionally the same. > >> Please, update README with how to build with Maven. > > Done. > > Also I forgot to say earlier I made slight changes to modernize the javadoc markup in LogParser.java > so the javadoc builds in maven. Okay. > > Is this OK for 10? Yes, you can push it today. Cut out day is tomorrow. And these changes does not affect testing. Thanks, Vladimir > Thanks, > Eric > > >> >> Thanks, >> Vladimir >> >> On 11/30/17 9:57 AM, Eric Caspole wrote: >>> Hi everyone, please review this change to build the LogCompilation tool with Maven rather than a >>> Makefile, so it can easily be imported and used with IDEs. This will allow in future for test >>> cases etc and help prevent bit rot in this useful tool. >>> Thanks, >>> Eric >>> >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8192821 >>> >>> webrev: http://cr.openjdk.java.net/~ecaspole/JDK-8192821/webrev/ From eric.caspole at oracle.com Thu Nov 30 20:43:03 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 30 Nov 2017 15:43:03 -0500 Subject: RFR: 8192821 : Make LogCompilation into a maven project In-Reply-To: <0c723c3e-81ce-b2ca-45ed-ac92858c2ea0@oracle.com> References: <44c0c5a2-efdf-e9b5-5088-eeba5392c74a@oracle.com> <0c723c3e-81ce-b2ca-45ed-ac92858c2ea0@oracle.com> Message-ID: <847216a5-6ca8-5f0b-f8f4-52f3fc929af2@oracle.com> Thanks Vladimir! Eric On 11/30/2017 03:43 PM, Vladimir Kozlov wrote: > On 11/30/17 11:14 AM, Eric Caspole wrote: >> >> On 11/30/2017 01:08 PM, Vladimir Kozlov wrote: >>> Thank you, Eric >>> >>> Can you still keep ability to build with Makefile? >> >> New one: http://cr.openjdk.java.net/~ecaspole/JDK-8192821/02/webrev/ > > Good. > >> >> Yes now 'make' still works. Also I added a step in the maven build to >> copy the artifact to the top as logc.jar, so now whether you build >> with maven or make you will get a logc.jar at the top as it has always >> worked, that are functionally the same. >> >>> Please, update README with how to build with Maven. >> >> Done. >> >> Also I forgot to say earlier I made slight changes to modernize the >> javadoc markup in LogParser.java so the javadoc builds in maven. > > Okay. > >> >> Is this OK for 10? > > Yes, you can push it today. Cut out day is tomorrow. And these changes > does not affect testing. > > Thanks, > Vladimir > >> Thanks, >> Eric >> >> >>> >>> Thanks, >>> Vladimir >>> >>> On 11/30/17 9:57 AM, Eric Caspole wrote: >>>> Hi everyone, please review this change to build the LogCompilation >>>> tool with Maven rather than a Makefile, so it can easily be imported >>>> and used with IDEs. This will allow in future for test cases etc and >>>> help prevent bit rot in this useful tool. >>>> Thanks, >>>> Eric >>>> >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8192821 >>>> >>>> webrev: http://cr.openjdk.java.net/~ecaspole/JDK-8192821/webrev/ From vladimir.x.ivanov at oracle.com Thu Nov 30 21:28:34 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Dec 2017 00:28:34 +0300 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> Message-ID: <725b89eb-74ac-bfb5-198b-f97d439f72e6@oracle.com> > http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ Thanks, Vivek. I verified that the reported problem goes away with the fix. src/hotspot/cpu/x86/macroAssembler_x86.cpp + // Reset k1 to 0xffff. + if (VM_Version::supports_evex()) { + push(rcx); + movl(rcx, 0xffff); + kmovwl(k1, rcx); + pop(rcx); + } Why do you preserve rcx which is already caller-saved and shouldn't contain anything valuable after a JNI call? Best regards, Vladimir Ivanov From razvan.a.lupusoru at intel.com Thu Nov 30 21:48:25 2017 From: razvan.a.lupusoru at intel.com (Lupusoru, Razvan A) Date: Thu, 30 Nov 2017 21:48:25 +0000 Subject: RFR(S) 8192846: Extend cmov vectorization to work for float Message-ID: <48D92A70936F7946BE99F3FF5ECB6461D8DE1631@ORSMSX113.amr.corp.intel.com> Hi all, This submission is to the issue noted in JDK-8192846 - namely that vectorized cmov for floats is not supported. This patch rectifies the situation so that when scalar Cmov for float and double is generated (or forced generated by passing -XX:+UseCMoveUnconditionally), it stands a chance for Vectorization using existing functionality previously enabled for doubles. The following code pattern will get vectorized with patch above: private void cmove_kernel_float(float[] in1, float[] in2, int length, float[] out) { for (int i = 0; i < length; i++) { out[i] = (in1[i] > in2[i]) ? in1[i] : in2[i]; } } Instructions generated for loop are: vmovdqu 0x10(%rcx,%r10,4),%ymm0 vmovdqu 0x10(%rdx,%r10,4),%ymm1 vcmpleps %ymm0,%ymm1,%ymm2 vblendvps %ymm2,%ymm0,%ymm1,%ymm2 vmovdqu %ymm2,0x10(%r9,%r10,4) The patch is available for review here: http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_cmovevf_00/ Jtreg testing with compiler tests has successfully passed. Thanks for review! --Razvan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivek.r.deshpande at intel.com Thu Nov 30 22:50:53 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 30 Nov 2017 22:50:53 +0000 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. In-Reply-To: <725b89eb-74ac-bfb5-198b-f97d439f72e6@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> <725b89eb-74ac-bfb5-198b-f97d439f72e6@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A771CEEBD@ORSMSX106.amr.corp.intel.com> Hi Vladimir Thanks for testing the patch. To be on the safe side, I am preserving the rcx register and don't want to introduce any new bugs. Regards, Vivek -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Thursday, November 30, 2017 1:29 PM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. > http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ Thanks, Vivek. I verified that the reported problem goes away with the fix. src/hotspot/cpu/x86/macroAssembler_x86.cpp + // Reset k1 to 0xffff. + if (VM_Version::supports_evex()) { + push(rcx); + movl(rcx, 0xffff); + kmovwl(k1, rcx); + pop(rcx); + } Why do you preserve rcx which is already caller-saved and shouldn't contain anything valuable after a JNI call? Best regards, Vladimir Ivanov From vivek.r.deshpande at intel.com Thu Nov 30 22:51:02 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 30 Nov 2017 22:51:02 +0000 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. In-Reply-To: <5fd2f8dd-bf78-12ce-3620-0cdd1eb84fc3@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> <5fd2f8dd-bf78-12ce-3620-0cdd1eb84fc3@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A771CEED3@ORSMSX106.amr.corp.intel.com> HI Vladimir We are removing the mask register encoding from the scalar instructions as it is not needed. The JIT is not doing any masked scalar operations. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, November 30, 2017 8:56 AM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net Cc: Viswanathan, Sandhya Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. Thank you, Vivek Changes looks good based on your description. Please, explain why using mask register in scalar instructions is bad. I will start pre-integration testing and let you know results. Thanks, Vladimir On 11/30/17 7:28 AM, Deshpande, Vivek R wrote: > Hi > > I have bug fix for 8190494: Different results with UseAVX=3 when calling AVX-512 native function via JNI. > > Mask register not being reset after JNI and the scalar floating point > instructions using the mask register encoding with AVX 512 in the assembler causing this problem. > > I have tested it with jtreg on hotspot/compiler and SPECjvm2008 on knights landing and skylake. > > Webrev: > > http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ > > I have also updated the JBS entry. > > https://bugs.openjdk.java.net/browse/JDK-8190494 > > Would you please review and sponsor it. > > Regards, > > Vivek > From dean.long at oracle.com Thu Nov 30 23:10:11 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 30 Nov 2017 15:10:11 -0800 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function In-Reply-To: <56dcd9b9-4d8f-19e3-89dc-2c2142838ac5@bell-sw.com> References: <2cb34bc7-98da-12b4-11af-0d8886747691@oracle.com> <4130e57a-0369-915d-9c99-05e308b5d4e7@oracle.com> <6902d304-e1bf-5473-3f39-80869de85280@bell-sw.com> <22c27b8e-abf4-6831-2138-bd02d52fa56c@oracle.com> <56dcd9b9-4d8f-19e3-89dc-2c2142838ac5@bell-sw.com> Message-ID: <10c74db1-8238-b315-a188-c15cc65abb7c@oracle.com> On 11/30/17 12:27 PM, Dmitry Chuyko wrote: > On 11/30/2017 11:00 PM, dean.long at oracle.com wrote: >> Does @requires vm.opt.CriticalJNINatives still work instead of >> os.arch != "aarch64" (I'm not sure if flags on the @run line are >> added to "vm.opt")? > It is actually vm.opt.CriticalJNINatives==null for me on x86 either > explicit or implicit run setting (whitebox declarations added etc.) > which looks more like it doesn't work. > OK, thanks for checking. dl > -Dmitry > >> >> If not, looks good. >> >> dl >> >> >> On 11/30/17 10:22 AM, Dmitry Chuyko wrote: >>> http://cr.openjdk.java.net/~dchuyko/8191129/webrev.01/ >>> >>> I think for tests it then will be better to explicitly exclude >>> aarch64 until complete feature implementation and to add the flag. >>> >>> Flag disabling was changed to UNSUPPORTED_OPTION() which also prints >>> a warning in case of manual -XX+. >>> >>> -Dmitry >>> >>> >>> On 11/29/2017 02:50 PM, Vladimir Ivanov wrote: >>>> >>>> >>>> On 11/29/17 2:16 PM, Vladimir Ivanov wrote: >>>>> ?? if (CriticalJNINatives) { >>>>> ???? warning("CriticalJNINatives aren't supported"); >>>>> ???? FLAG_SET_DEFAULT(CriticalJNINatives, false); >>>>> ?? } >>>> >>>> What I meant is: >>>> ? if (CriticalJNINatives && !FLAG_IS_DEFAULT(CriticalJNINatives)) { >>>> ??? warning("CriticalJNINatives aren't supported"); >>>> ? } >>>> ? FLAG_SET_DEFAULT(CriticalJNINatives, false); >>>> >>>> Sorry for the confusion. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>> >> > From vladimir.kozlov at oracle.com Thu Nov 30 23:44:16 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 15:44:16 -0800 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771CEED3@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> <5fd2f8dd-bf78-12ce-3620-0cdd1eb84fc3@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771CEED3@ORSMSX106.amr.corp.intel.com> Message-ID: <1e320f59-24a6-0bb8-ff3f-a2c99d47a038@oracle.com> On 11/30/17 2:51 PM, Deshpande, Vivek R wrote: > HI Vladimir > > We are removing the mask register encoding from the scalar instructions as it is not needed. The JIT is not doing any masked scalar operations. Does it affect execution if we don't remove mask register encoding? Thanks, Vladimir > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, November 30, 2017 8:56 AM > To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net > Cc: Viswanathan, Sandhya > Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. > > Thank you, Vivek > > Changes looks good based on your description. > > Please, explain why using mask register in scalar instructions is bad. > > I will start pre-integration testing and let you know results. > > Thanks, > Vladimir > > On 11/30/17 7:28 AM, Deshpande, Vivek R wrote: >> Hi >> >> I have bug fix for 8190494: Different results with UseAVX=3 when calling AVX-512 native function via JNI. >> >> Mask register not being reset after JNI and the scalar floating point >> instructions using the mask register encoding with AVX 512 in the assembler causing this problem. >> >> I have tested it with jtreg on hotspot/compiler and SPECjvm2008 on knights landing and skylake. >> >> Webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ >> >> I have also updated the JBS entry. >> >> https://bugs.openjdk.java.net/browse/JDK-8190494 >> >> Would you please review and sponsor it. >> >> Regards, >> >> Vivek >> From vladimir.kozlov at oracle.com Thu Nov 30 23:45:51 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 15:45:51 -0800 Subject: RFR(S) 8192846: Extend cmov vectorization to work for float In-Reply-To: <48D92A70936F7946BE99F3FF5ECB6461D8DE1631@ORSMSX113.amr.corp.intel.com> References: <48D92A70936F7946BE99F3FF5ECB6461D8DE1631@ORSMSX113.amr.corp.intel.com> Message-ID: <86784639-2e3c-d5da-3369-8a71bdd74632@oracle.com> Thank you, Razvan I have one question: why you removed _do_vector_loop checks in superword.cpp? Also I think it is late for jdk 10. I will test and push when jdk 10 is forked. Thanks, Vladimir On 11/30/17 1:48 PM, Lupusoru, Razvan A wrote: > Hi all, > > This submission is to the issue noted in JDK-8192846 ?- namely that vectorized cmov for floats is > not supported. > > This patch rectifies the situation so that when scalar Cmov for float and double is generated (or > forced generated by passing -XX:+UseCMoveUnconditionally), it stands a chance for Vectorization > using existing functionality previously enabled for doubles. The following code pattern will get > vectorized with patch above: > > private void cmove_kernel_float(float[] in1, float[] in2, int length, float[] out) { > > ? for (int i = 0; i < length; i++) { > > ??? out[i] = (in1[i] > in2[i]) ? in1[i] : in2[i]; > > ? } > > } > > Instructions generated for loop are: > > ? vmovdqu 0x10(%rcx,%r10,4),%ymm0 > > ? vmovdqu 0x10(%rdx,%r10,4),%ymm1 > > ? vcmpleps %ymm0,%ymm1,%ymm2 > > ? vblendvps %ymm2,%ymm0,%ymm1,%ymm2 > > ? vmovdqu %ymm2,0x10(%r9,%r10,4) > > The patch is available for review here: > > http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_cmovevf_00/ > > Jtreg testing with compiler tests has successfully passed. Thanks for review! > > --Razvan >